Three days to go until Drupal 8 EOL: you may already be using an EOL version of Drupal 8

With three days to go until Drupal 8's end of life (on November 2, 2021), now is a good time to take stock of your Drupal 8 sites' modules. Use Upgrade Status to check for environment and module compatibility with Drupal 9.

Unless you are on Drupal 8.8.x or Drupal 8.9.x, Upgrade Status will tell you to move to that version first, before you can upgrade to Drupal 9. (At this point it should really tell you that 8.9.x is the only acceptable version to upgrade to). Why is that?

While Drupal 8's end of life in three days may sound too soon, it could easily happen that you are on Drupal 8 and are already on an end of life version. With the introduction of semantic versioning in Drupal 8.0.0, Drupal core went on a path of feature updates in minor versions (8.1, 8.2, etc) and bug and security fixes in patch versions (8.0.1, 8.1.3, etc.). However, bugfixes and security fixes are only released for older minor versions for a limited time. For bugfixes, that is 6 months, and for security fixes that is 12 months after release of the minor series. This one year support window started with 8.5.0, the end of life dates of prior minor versions of Drupal 8 were even sooner after their release.

What does this practically mean? Let's say your site is on some version of Drupal 8.5.x, that release series started with Drupal 8.5.0 in March, 2018. It then received bugfixes until 8.6.0 was released in September, 2018. Finally, it continued to receive security fixes only until 8.7.0 was released, that is March, 2019. In other words, Drupal 8.5.x has been end of life since March, 2019. It did not receive security fixes since then. So if your site is on Drupal 8.5.x, then you are already on end of life software and the end of life of 8.9.x will not materially change your situation.

When Drupal 9 was released at the same time as Drupal 8.9, the only supported versions that remained of Drupal 8 were Drupal 8.8.x (security) and 8.9.x (bugfix and security). No more releases were made to 8.7.x and before. So in case there were some critical issue to fix for the upgrade path, that would not have been possible to fix in earlier versions. Also, by limiting the upgrade potential to these two release series, we could limit the potential upgrade bugs that could happen with unsupported earlier versions. However, to support the upgrade to Drupal 9, and thanks to the early release of Drupal 9, we also made Drupal 8.9.x a long term supported release, which is why it will go end of life an additional five months later, after a total support of 17 months.

At this time we are supporting Drupal 7.x (bug and security fixes), Drupal 8.9.x (security fixes), Drupal 9.1.x (security fixes), Drupal 9.2.x (bug and security fixes), preparing to release 9.3.0 in December, already opened 9.4.x for development and will very soon open Drupal 10.0.x for development and eventual release next year. That is a lot of versions of Drupal to support! While we do everything we can to make the transitions between these easier, it does depend on you too to keep your Drupal sites up to date.

Four days to go until Drupal 8 EOL: use Drupal 9 on older MySQL/Percona/MariaDB versions

With four days to go until Drupal 8's end of life (on November 2, 2021), now is a good time to take stock of your Drupal 8 sites' modules. Use Upgrade Status to check for environment and module compatibility with Drupal 9.

One of the benefits of using Upgrade Status is it will tell you about environment compatibility alongside extension compatibility. It will note if your PHP or Apache or database versions are out of date. Of particular note are Drupal 9's MySQL/Percona and MariaDB version requirements. The MySQL/Percona/MariaDB driver that's included in Drupal 9 core requires MySQL/Percona 5.7+ or MariaDB 10.3.7+. The intention with raising the bar from Drupal 8's requirement of MySQL/Percona 5.6 and MariaDB 10.0 was to utilise some of the newer features in these database versions. There was also the risk of a dependency starting to require the new versions, given the end of life nature of the older database versions at this point. Neither happened yet but we did not know that ahead of time of course.

MySQL 5.6 and MariaDB 10.0 database driver for Drupal 9 to the rescue! If you are on a long term supported operating system and receive security coverage for your database, you might not need to update to MySQL/Percona 5.7 or MariaDB 10.3 immediately after all. Only a few contributed projects utilise the new capabilities, for example the JSON/JSONB field module. If you are certain that none of your modules require the newer versions, keep in mind that core itself can actually run fine with older database versions still. Follow the instructions on the project page to install this driver for Drupal 9. I would still suggest you plan an upgrade of your database, but now it can be decoupled from your Drupal major upgrade.

Looking ahead, some of the Drupal 10 platform requirements are already defined, and MySQL/Percona/MariaDB requirements will not be raised further from Drupal 9's minimum versions. However there are no guarantees that the new features will not be actually utilised then.

Five days to go until Drupal 8 EOL: automated code fixes

With five days to go until Drupal 8's end of life (on November 2, 2021), now is a good time to take stock of your Drupal 8 sites' modules. Use Upgrade Status to check for environment and module compatibility with Drupal 9.

If you took my advice a couple days ago and took on co-maintainership of a project, you may be wondering about the fastest way to get drupal.org projects Drupal 9 compatible. Last year, we introduced the Project Update Bot that submits compatibility issues with patches to drupal.org projects. If it detects all compatibility issues identified are fixed, it will also suggest updating the core compatibility information for the project within the same patch. Committing such patches will potentially entirely fix extension compatibility. Hundreds of those issues have been reviewed and marked as tested by folks in the community and a lot more are waiting for review or are under discussion.

For your own custom code, I highly advise that you use the tools behind the update bot, specifically the Drupal Rector tool funded by Palantir.net. It will attempt to fix as many deprecated API uses as possible. According to our analysis of all contributed projects, almost half of all identified Drupal 9 incompatibility issues on drupal.org are covered by Drupal Rector automated fixes. So running Drupal Rector on your own code first will save you a lot of manual work and time. Upgrade Status will help identify the rest of the problems too and link to documentation to help fix them.

You can and should make all of these changes on your Drupal 8 site, given that the fixed code will keep running fine on Drupal 8. Once you updated contributed projects used on your site, fixed your custom code and ensured a compatible environment, you can upgrade to Drupal 9.

Six days to go until Drupal 8 EOL: use incompatible extensions

With six days to go until Drupal 8's end of life (on November 2, 2021), now is a good time to take stock of your Drupal 8 sites' modules. Use Upgrade Status to check for environment and module compatibility with Drupal 9.

While a lot of Drupal extensions are now compatible with Drupal 9, it can happen that you encounter an incompatible extension. In case adopting the extension fits into your plans, that is the best way forward. However, there may be some delay until you can adopt the project and it may not fit into your plans to adopt in the first place. There are a few solutions to use drupal.org projects that are distributed as incompatible on your Drupal 9 sites.

Obtaining the extension

I do not advise to download the extension as a zip or tar.gz file and add it to your project. As I posted yesterday, it is best to use Composer to ensure all Drupal-specific and third party dependencies are resolved. Manually downloading does not ensure this. But composer will not let you download incompatible extensions!

This is where drupal.org's recently added lenient Composer endpoint comes in. Essentially this is a package repository that advertises only incompatible projects, but it exposes them as compatible instead. Using Composer 2, you can add this additional repository on top of the existing drupal.org endpoint with a higher priority. This way you can transparently add packages that are yet incompatible to your projects. As projects get compatible with Drupal 9, they will disappear from the lenient endpoint and their entry on the standard drupal.org endpoint will transparently take over on your setup.

Making code compatible

Now that you have the codebase on your site, you will still be unable to use the project, as it is indeed still incompatible. If the only patch the extension needs is to its info.yml file where it declares compatibility with Drupal 9, the simplest solution may be to install the Backward Compatibility module. If additional patching is required, or you prefer not to use the Backward Compatibility module, you can install and use the cweagans/composer-patches package for Composer and use it to apply the compatibility fix.

Other methods

The above method is not the only solution to use incompatible projects. Prior to the availability of the lenient Composer endpoint, Damien McKenna wrote a detailed blog post about using the git repository of merge requests to add to your site and Benji Fisher wrote a practical guide about that too. Even before those, James Williams wrote about using the base git repository of projects and applying fixes with composer-patches. These methods require a lot more special case entries in your composer file and would require you to manually track if the project became compatible.

The benefit of the lenient Composer endpoint is that it provides one unified source of projects. For projects you use with Backwards Compatibility, they will seamlessly convert to compatible projects on your site as their drupal.org releases become compatible. For projects you use with composer-patches, Composer will report the inability to apply patches when updates become available, where you have an explicit notification that either the project became compatible or conflicting changes were added.

Seven days to go until Drupal 8 EOL: start using Composer!

With seven days to go until Drupal 8's end of life (on November 2, 2021), now is a good time to take stock of your Drupal 8 sites' modules. Use Upgrade Status to check for environment and module compatibility with Drupal 9.

Various people in the Upgrade Status issue queue are concerned about the module requiring Composer though. While Drupal 8 or 9 do not require Composer to work, getting any extension installed on your site that depends on third party components is a sizeable challenge without Composer. With Drupal 8 core dependent on various third party components, it was inevitable that a dependency manager will be needed to build Drupal sites. Upgrade Status itself does require various third party components to check for deprecated API uses and even to locate your Drupal site root. So you cannot avoid using Composer to even check for Drupal 9 compatibility.

If you are not using Composer yet, the best case scenario is you use this opportunity to convert your Drupal site to a Composer based solution. If you started your Drupal 8 site from 8.8.0 or later, the file structure is already ready for Composer. For Drupal sites started on prior versions, the move is more work, as explained in the guide.

In case you are not ready to convert your site to Composer yet, but still want to get a Drupal 9 upgrade readiness check, you need to set up a separate, parallel site with Composer just for this purpose. Your existing site content or configuration does not matter for Upgrade Status checks, you only need to replicate the enabled projects on the site you use.

Install Composer first. It is best to use Composer 2 because it will be much faster and will use significantly less memory, but you should have no problem installing Upgrade Status with Composer 1 either. After that, run these commands to create a new Drupal site from Composer, add core developer dependencies and add this module as a requirement.


$ composer create-project 'drupal/recommended-project:~8.9' d9readiness
$ cd d9readiness
$ composer show drupal/core | grep versions
$ composer require --dev drupal/core-dev:[copy version above]
$ composer require drupal/upgrade_status


Then, copy all of your custom and contributed projects to the web/modules, web/themes, and web/profiles folders. (You could use Composer to add at least the contributed ones, but since you are not planning to use this build for anything else, this will be the quickest way). Finally, visit /admin/reports/upgrade-status, and run the report.

This should help you get a summary of where your site is at. I would suggest you plan for converting to a composer based setup and use composer for dependency management going forward. You will only need composer on your development environment and can still use your usual workflow to push your fully built codebase from there.