It is hard to believe that almost 6 years passed since Drupal 8.0.0's release on November 19th 2015. What feels like it was just yesterday, Drupal 8 brought lots of amazing new things to the platform. Near and dear to my heart was full multilingual support that I worked on with over 1600 people for several years. Also stars of the Drupal 8 show were content authoring with the bundled CKEditor, the vastly improved configuration management system, Views in core, built-in web service support, more semantic markup, in-place editing, PHPUnit integration, better caching, improved accessibility, even aural announcements for page changes, and so on and on. Drupal 8 embraced collaboration within the PHP ecosystem and beyond with our use of Symfony, Twig, Guzzle and gradually embraced application of Composer.

But I think even more profound was the change of innovation models, where Drupal 8 started to allow feature additions in a backwards compatible manner and thus the inclusion of amazing new features like Layout Builder, Media Library, BigPipe, Settings Tray, Content Moderation, Inline form errors, JSON:API and even the Umami demo all after Drupal 8.0.0 shipped. Some of these were developed in stages thanks to the possibility to include experimental projects in core as well. This allowed us to make Drupal 8 itself much better without needing to do a new major version. In fact the major version bump turned to be a technicality where being on Drupal 8.9 or 9.0 was not giving you shiny benefits anymore, other than keeping you on the train of innovation.

So today Drupal 8's life ends as innovation continues on the Drupal 9 train.

In the past 8 days I did a countdown post series to give short tips for dealing with this end of life. I suggest you look back if you did not read them yet:

8. Adoption drive to get projects new maintainers that did not yet update to Drupal 9. If you can adopt a project or two, that would be greatly appreciated!
9. Use composer to at least check for Drupal 9 compatibility, ideally convert your site to it. If you did not try composer recently, version 2 is leaps and bounds ahead of version 1 and its worth a try!
10. For modules that are not compatible you still need to use workarounds. The recently introduced lenient composer endpoint provides the most consistent solution for all projects.
11. For your own code and your drupal.org projects, automated code fixes are the way to go towards Drupal 9. No need to find and fix problems manually when you can automate most of it.
12. If you need to use an older MySQL/Percona/MariaDB database, there is a way. This should make it easier to adopt Drupal 9 if you were holding off updating your database backend.
13. If you are on Drupal 8.8 or before, you are already on end of life software. The key to a fast Drupal 8 to 9 upgrade is to keep your Drupal 8 site up to date.
14. How soon do you need to do this update again? Drupal 9 end of life is in 2023. And Drupal 10 end of life will depend on its componens' end of lives as well.
15. So you are still on Drupal 8, what happens now? Nothing will break immediately, but its best to keep moving forward on your upgrade plans.

I hope this series of tips were useful to read. It was certainly an eventful 8 days to write and post them. See you on Drupal 9!

With one day 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.

Given that there is only one day left, you will highly likely not be on Drupal 9 tomorrow. So what happens to your Drupal 8 site once the core software is end of life? As I wrote two days ago, unless you are on Drupal 8.9.x you are already running on end of life software. As prior versions of Drupal 8 don't stop running, Drupal 8.9.x will also not stop running tomorrow. There is no expiring license key that will stop the site from functioning. There will not be a banner at the bottom of the page that the site is insecure. In fact the site will not even be insecure immediately. However, there will not be security fixes to Drupal 8 anymore. So the next time a fix comes out for Drupal 9 that may be applicable to Drupal 8, that fix will not be made anymore to Drupal 8. Depending on the nature of that security problem, you site may be in no trouble or big trouble, but the distinction will be left to you to decide.

Using Upgrade Status and Drupal Rector automated code fixes, the upgrade from Drupal 8 to 9 is still the easiest in the last decade (assuming you are already on Drupal 8.9), so I would highly suggest to plan to do the upgrade soon and don't risk staying on Drupal 8 for too long.

There are also various changes to drupal.org projects and issues. These will likely not happen immediately tomorrow, but will be done soon. For contributed project maintainers on Drupal.org, releases that are only compatible with Drupal 8 will be marked unsupported as well, much like the same process that happened to Drupal 6 last time. Testing setups that are against Drupal 8 will be removed. Issues submitted against Drupal 8 will automatically be moved to Drupal 9.2.x (where bugfixes are still possible). If they are not applicable to Drupal 9 anymore, the issues will later be closed by people.

With two 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.

Drupal 8 was released on November 19th, 2015. The end of life comes on November 2, 2021, after almost 6 years of support. Is this too soon? I think the answer will be different from situation to situation. But why do we need to end of life Drupal 8 in the first place?

Drupal has been dependent on various third party components for a while. jQuery was added to Drupal 5 and has been in core since January 2007. However, Drupal 8 depends on a lot more third party libraries, several more on the frontend (CKEditor, Backbone, jQuery UI, Joyride, etc) and even more on the backend (Symfony, Doctrine, Guzzle, etc).

On the one hand, this is great because Drupal core developers don't need to reinvent the wheel, ensure the security of these packages and maintain them. Also, Drupal developers can contribute to and make these libraries better for the benefit of the whole PHP ecosystem, rather than just Drupal. This was particularly shown recently with the work on PHP 8.1 compatibility in Drupal 9 where Drupal core developers contributed to more than a dozen major upstream dependencies and made PHP 8.1 adoption easier across the whole web community. Similarly, the Drupal automated updates team is working with other open source projects (Typo3 and Joomla in particular) on the PHP-TUF implementation, and our work there benefits users outside of Drupal as well.

On the other hand, this means that Drupal needs to align our release schedules with schedules of other third party libraries. We did a Symfony major version update within Drupal 8's minor releases, and it was a bad idea. Symfony 2 to 3 was breaking various contributed projects and it questioned our commitment to stability of major versions. For our Symfony 3 to 4 update, we did a clean break from Drupal 8 to 9.

Looking into the future, when projects like jQuery UI go end of life (as it happened), we need to work to make a peaceful transition to other libraries and have an opportunity to actually remove jQuery UI from Drupal. When major dependencies like Symfony 4 and CKEditor 5 go end of life (both around end of 2022), we need to have a transition to the newer versions. The updates and replacements of these libraries will not provide identical APIs and user interfaces, so we need to increase the major version number of Drupal itself to signify the updates. This is why we are working on Drupal 10 for release next year to upgrade Symfony 4 to 5 or 6, update CKEditor 4 to CKEditor 5, and so on.

As Drupal 9's lifetime is bound by the end of life of Symfony 4 and CKEditor 4 (around the end of 2022), Drupal 10's end of life will primarily depend on the end of life of its components too. I don't think the frequent end of life of major versions is a problem as long as we can make the transitions as easy as possible, which is what I dedicated most of my previous posts in this series to. Do you have ideas to make the transitions even easier? Let me know!

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.

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.