Assessing your Drupal 9 Readiness, Part II: Who is afraid of contrib modules updates?

In this series of blog posts, we want to help tech leads and project managers assess how ready their projects are for Drupal 9.

In Part 1, we estimated the possible amount of work it takes to make custom modules compatible with the new major release. If you’ve already done this, then congratulations! …If you haven’t, then start as soon as possible. This is because we’re moving on to upgrade contrib modules and themes – and you can bet this will reveal all your dirty laundry.

Before we start, we need a quick introduction to Semantic Versioning. Although neither enforced nor ensured, most Drupal contrib modules follow Semantic Versioning. So you can assume a decent back compatibility between releases within the same major version of the module. This means upgrading from 5.3 to 5.4 or 5.7 should be fairly safe, while jumping from 5.3 to 6.0 – or even to 7.0 – can come with headaches.

In Part 1, we also introduced Upgrade Status as a tool to assess your projects, and this includes the contrib modules you use. So if you haven’t done it before, now is the time to scan those. If you have a lot of projects, the scan can take quite a while. So grab a cup of tea and keep reading while Upgrade Status does its brilliant work.

Your starting point

If your team is among the ones which like to stay up to date, running automatic upgrades for modules and themes is likely to see your report show a lot of green. If, instead, your team is more conservative and upgrades only for security reasons, then you probably won’t.

We will not be able to use a mathematical function like we did for Part 1. But the amount of green on the page will be your first indicator of how ready you are to move to Drupal 9.

Depending on how many modules require upgrading, I suggest to phase this work in three stages:

1. Upgrade modules within your Composer constraints.
2. Upgrade the remaining modules by requiring a Drupal 9 compatible release.
3. Fix anything which is not already green.

You want to spread the phases in different releases too. Phase 1 should be fairly small and safe, and so release it as soon as it’s ready.

Phase 2 will require more work and may bring many changes. So dedicate a release only to this phase and allow some time before releasing the third and last phase. This way, you can make sure all the potential defects can be identified and fixed properly.

The work around phase 3 will require more resources, attention and dedication. So it’s possibly less likely to produce defects.

For each phase, don’t forget to run database updates and export any updated configuration.

All phases require a thorough Quality Assurance (QA) and User Acceptance Testing (UAT), so project managers need to allocate as much testing time as possible. Developers and tech leads should communicate which feature or section may be affected in each phase, so as not to waste testers’ precious time.

Having a thorough automated testing coverage reduces the need for extensive manual testing and the risk of defects. If your project doesn’t have test coverage, in the following part of this series we will suggest some testing tools. Automated testing is the true indicator of success so be prepared to allocate some budget in order to have a healthier project and happier team.

Upgrades within your Composer restrictions

Estimation: 1 hour

Task: composer update or, if needed, composer update –with-dependencies

This step should be fairly safe, as long as your Composer allows only minor upgrades. In fact, you should always avoid Composer constraints like ‘*’ or ‘1 – 2’. If you have required modules and packages with composer require foo/bar, it’s likely you’ll be fine. This is because Composer defaults to Caret Version Range (^).

Requires newer versions of remaining modules

Estimation: 2 hours for each module

Task: Either on Upgrade Status report or from Drupal.org’s modules pages, find a Drupal 9 compatible version. Then request the new version with Composer.

If you followed the best practices in the previous phase, it will have set you up in a better position for the next (and somewhat harder) stage. This is where you should expect to find the right version needed to upgrade – and also resolve – possible problems related to the major jump. These problems could be down to new dependencies, new or changed APIs, or some incompatibility.

If a module upgrade doesn’t look straightforward, or there is a big version jump, skip this module and move to the next one. You can continue the skipped work at the end of this phase. In the meantime, we learn more from other upgrades. Or, you can move the module to the next phase where a larger portion of time can be dedicated.

Fix what’s left

So far, we have been working with modules ready for Drupal 9, so what’s left is:

• Modules mostly or possibly Drupal 9 compatible
• Modules which are not Drupal 9 compatible

Modules mostly or possibly Drupal 9 compatible

Modules do have a version for Drupal 9.  But it’s in either alpha or beta, or only on the development branch. In some cases, the version is either incorrectly flagged as compatible when it actually isn’t, or the module code is actually compatible with Drupal 9. In this second scenario, no deprecated code is used, but Composer can’t install it due to unmet dependency restrictions.

Modules in this state have, however, received some work from maintainers and the community. This means you can open the modules’ issues queues and see what the roadmap is. It’s a good chance to contribute to Drupal, which I always advocate is the best way to grow and improve your skills.

The goal is to find what’s missing to be Drupal 9 ready, and patch the code. Scan a module’s issues queue to find any Drupal 9 work, or you may be lucky and the module is part of the “Accelerating Drupal 9 module and theme readiness with automated patches” programme. In this case, here’s the list of modules with automated patches from Project Update Bot.

It’s likely these modules will create issues when you’re finally upgrading to Drupal 9, because their composer.json metadata still states the old Drupal 8 requirement. It could even be – at this stage – due to a dependency on a not-compatible Drupal 9 version of another module, i.e. Webform Pardot depending on Webform 5.2.

Drupal.org documentation suggests to use Composer Aliases to fix this issue. For example, if the blocker is drupal core and the error Conclusion: don’t install drupal/core 9, you can composer require “drupal/core:9.0.0 as 8.9.0” –no-update && composer update.

However, because it’s the module(s)’ fault and not Drupal’s, I prefer to take the opposite approach. I handle the broken module(s) as “special” Composer packages.

Using Webform Pardot module as our example again, if I add this snippet to our composer.json repositories section:

        {

            "type": "package",

            "package": {

                "name": "drupal/webform_pardot",

                "version": "1.0.0-beta1",

                "dist": {

                    "url": "https://ftp.drupal.org/files/projects/webform_pardot-8.x-1.0-beta1.tar.gz",

                    "type": "tar"

                },

                "type": "drupal-module"

            }

        }

It will bypass the module’s own composer.json restriction, but still installs its codebase through Composer. So it will let us patch the file normally.

Don’t forget to contribute back to the modules’ Drupal.org pages. The sooner there is a Drupal 9 release for them, the better it is for your team, your site(s) and the overall community.

Module is not Drupal 9 compatible

Although really unlikely, we need to account for some abandoned projects. You may have a module which is so niche that it’s not gathered any attention from the community, nor from the actual maintainers.

The patch itself will require a complete rewrite of the code, meaning you have two options:

1. If you strongly require the module, you need to clone its repo and upgrade it yourself. You can then publish it on Packagist and require it as normal. You can also ask to become co-maintainer for the module.
2. Replace the module with something similar, or with a custom module.

Recap

We’ve covered a lot! But…

At this point you should have a codebase which is still running on Drupal 8.8, or even 8.9, with all modules compatible for Drupal 9. Upgrade Status module should have a lot of green, so congratulations!

You now need to deploy, test and release your changes. Then prepare for the final sprint to update Drupal core to the next major version in the third and final blog post.