Assessing your Drupal 9 Readiness, Part III: to infinity and beyond
This is the third and final part of a series of blog posts helping tech leads and project managers to upgrade their Drupal 8 sites, to the latest major version.
Part II ended with your codebase still running on Drupal 8.8, or even 8.9, with all modules compatible for Drupal 9. Upgrade Status module should be showing a lot of green now, possibly even only green.
So, you are now ready for the big jump. Which, actually, isn’t that big at all.
Round 1: First require, then update
Running `composer update` won’t work, since it’s likely you’re requiring Drupal 8 in your composer.json. Plus a `composer require drupal/core:^9.0` is not what you want… and won’t work anyway.
Due to mutual dependencies you’ll need to upgrade more packages at the same time, so you’ll need to request new package versions in parallel too, (and make sure cross-dependencies don’t start firing errors).
To achieve this we’ll use the `composer require –no-update` technique, which disables the installation of the listed packages as well as the update of any dependency. So basically it will just update your composer.lock with the new requirements, and won’t process the packages and their dependencies trees yet.
Use this technique with all drupal/core-* packages, to require their 9.x versions.
Go ahead and try:
composer require drupal/core-recommended:^9.0.0 drupal/core-composer-scaffold:^9.0.0 drupal/core-project-message:^9.0.0 --update-with-dependencies --no-update
Also if you require drupal/core-dev package too, don’t forget to also:
composer require drupal/core-dev:^9.0.0 --dev --update-with-dependencies --no-update
When finished you are now ready to update with:
Leave it running, as this command may take a few minutes to complete.
No errors? Lucky you! Pat yourself on the back and jump to the end of the post.
Still some errors? Please continue reading.
Round 2: package “drupal/foo 2.0.0” requires “drupal/bar 3.0.0” but these conflict with your requirements
We still have some packages that don’t like our upgrade to Drupal 9. Since we made sure all – or almost all – our modules were Drupal 9 compatible in Part I and Part II of this series, these errors are likely to be due to version requirements mismatch.
For example, we patched a module to make it Drupal 9 ready, but it’s composer.json information still doesn’t allow Drupal versions other than 8.x. Another example may be module Foo requires module Bar at version 2.x but module Bar Drupal 9 ready version is actually 3.x.
So code-wise all is ready for Drupal 9. Now we have to trick the modules complaining and let them pretend we are still on the version they need… whilst actually upgrading!
For that we can use a Composer technique called Aliases.
If your errors are related to modules being Drupal 9 ready through a patch – and so their composer requirements still need Drupal 8 – you can do this:
composer require "drupal/core:9.1.9 as 8.9.0" --no-update
If, similarly, the errors are about module Foo depending on module Bar with versions mismatch as described above you can do this:
composer require "drupal/bar:3.0.0 as 2.0.0" --no-update
Warning 1: Remember to replace the versions numbers above to whatever you are installing. The versions numbers above are just an example.
Go ahead and run:
Fingers crossed in a few minutes you will have your site running on Drupal 9.
You can now proceed with running Drupal database updates, and can continue with your normal procedure for upgrading Drupal core or contrib modules.
At this point there may be still bits and pieces to align with Drupal 9 practices, i.e. PHPUnit tests may need some more love, but running the tests will give you all the clues you need.
Hopefully it wasn’t that bad? And everything we learned will be really useful in 2023 when Drupal 9 comes to its End Of Life – and we need to upgrade to Drupal 10!
So you better bookmark these posts!