Most everything else ends up in `/vendor`.Non-drupal libraries that you specifically pull in will usually go to `web/libraries` (e.g ckeditor libraries).Contrib modules go to `/web/modules/contrib`.Both of those files are just json, though, and the actual code gets installed in several places: This file also operates as the source of truth for every version of every package and will yell at you if you try to install something that conflicts. The `composer.lock` file stores both sets of dependencies and information about them. Keep in mind that this list is technically incomplete in that the listed packages have their own dependencies. The `composer.json` file is primarily a list of all the packages (and their versions) that make up your site. I told you to remove var-dumper… why are you updating it?īefore tackling these issues, it’s important to have a clear understanding of composer’s elements and how they interact. However, this assumes that Composer isn’t being the inscrutable eldritch beast that it devolves into from time to time. Essentially this process boils down to running composer require ' drupal/core-recommended:^9' and composer update and enjoying your newly upgraded site. With your environment and code up to date, you can follow the official docs to apply the D9 upgrade. Once you’ve wrangled your code, I recommend committing two separate PRs, one for contrib work and one for custom for the same reasons we made the previous step into its own PR. If none of that works you could just copy the module code into your custom modules and make the changes yourself, but this should be a last resort. info file, then the composer lenient endpoint will allow you to apply the requisite patch and make the upgrade (Note: you need to be on Composer 2 to use lenient). If all the module needs is that core_version_requirement: ^8 || ^9 line in its. This part should be relatively easy however, one snag worth mentioning is the awkward situation when a contrib module you need isn’t up to date. If you need a specific version instead, use composer require drupal/module_name "1.2.3". Important note: if you just run composer require drupal/module_name you’ll automatically get the latest version of the module. The Upgrade Status module does a great job of listing out all of the deprecations in your various custom and contrib modules and provides both a UI and drush commands. Next you’ll want to figure out the code changes you need. Drupal 8 will still work with all of these settings, and having them in your repo before moving to the next step in the process will make the whole thing much easier. Once you’ve figured out what you need, make a PR that upgrades all of this for both your local and live environments. It will run much faster and be far less painful to work with during the upgrade process. Upgrade to Drush 10 and install it with composer if it’s not already: composer require - dev drush / drush.At time of writing it has the most consistent compatibility with contrib modules. Depending on your situation, I’d suggest the following addendums to this list: I recommend starting with the environment requirements in the official docs which lists Apache/Nginx, PHP, Database, and Drush. Also, it’s much easier to QA several small PRs than one enormous one. Given how many different systems you’re going to mess with it’s really easy to get stuck in various composer or git knots and end up having to redo a lot of work. It’s tempting to do all of these things in one fell swoop, but I recommend against that. The main things you’ll need to consider are local environment requirements, live environment requirements, deprecated contrib/custom code, and composer changes. Make a plan, take it slowįirst, you need to figure out what changes need to be made to the site for D9 compatibility and then build a plan around those requirements. This blog post isn’t a complete guide on how to upgrade to D9 it’s supplemental to the existing documentation found here. If you’ve found yourself in the middle of one such upgrade then you’ve come to the right place. While that usually is the case, some sites have their own set of hacks, oddities, and technical debt that make the upgrade process a lot more arduous. When using cweagans/composer-patches it's easy to include patches in your composer.One of the major selling points of Drupal 9 is that the upgrade is really easy: fix your deprecated code, update your contrib modules, run some composer magic, and you’re done.
0 Comments
Leave a Reply. |