How we are working on getting Thunder ready for Drupal 9 – and what you might learn from it

Number 9

It is expected to be ready by June – Drupal 9 is coming. In the ideal scenario you won’t even notice. Those of you who have started the new year well prepared, run all updates and do not use older modules are off the hook. But how do you get to this point?

We in the Thunder team have also asked ourselves this question. We are faced with the challenge of making our own distribution with around 60 modules compatible of Drupal 9 – recognising all dependencies, keeping everything running at the same time and ensuring everything is ready by June.

We have developed an approach for systematically going through all modules, recognising any required actions and working together with the module operators. Starting in December, our objective is to get every module onto as current a version as possible so that we can begin with the testing.

We want to show you in the following blog how the Thunder team has proceeded and how we continue to work: How do we establish where we are and which actions are required? How do we proceed with module updates? And what remains to be done?

We are convinced that this overview can help everyone who is currently dealing with the topic of Drupal 9. Our approach can not only serve as inspiration to distribution operators but also to anyone currently operating a Drupal site. We hope we are able to help you to get your sites ready for Drupal 9 and look forward to hearing about your experiences and tips!

1) How does a distribution become compatible with Drupal 9?

First of all it is a question of recognising which modules and which areas have deprecated code in need of removal. Instead of our usual tests, we have put together a git branch for this purpose which checks all modules used in Thunder for deprecated code.

Ideally the modules are completely up to date and don’t even pop up in our test. However: After the first successful run in December we discovered that our current Thunder codebase exhibited depreciated code requiring removal or replacement in 500 different areas.

We have now gone through it all module by module and checked whether an issue for removing the deprecated code was present in the issue queue and what the status quo is:

  • In the best case there are already patches which, although they are yet to be released, have been been committed in the dev branch.
  • In some instances issues had already been created on which we could work by checking patches or helping to develop them.
  • If there was no issue we created it and worked on a patch ourselves.

We collected all of these issues – both those created by us and by others – in a Thunder META issue in order to stay on top of things. That was our to do list for the coming weeks.

As soon as a patch existed or had been committed to a dev branch (by us or someone in the community) we adjusted the pull request above with these patches and dev versions – and ran the test again. The number of depreciations reduced gradually using this approach and the Thunder code base currently shows around 130 deprecations. We are working around the clock on approximately 50 issues in order to remove deprecated code – around 30 of those are already committed.

2) What’s next?

At present it is only deprecations which were marked as depreciated in Drupal 8.7 or earlier which are being removed to ensure Drupal 8.7 compatibility.

The plan of many module maintainers with the appearance of the first Drupal 9 beta is to discontinue the support in their modules for 8.7 and then to remove all Drupal 8.8 deprecations. From this point forward we will pursue the remaining 130 deprecations.

Our objective: To be compatible with all Drupal 9 modules on the day that Drupal 9 comes out.

The first Drupal 9 beta is planned for the beginning of March – the Drupal 9 release can then take place on 3rd June. If it is not possible to keep to this date, two alternative dates have been earmarked for May and August. Drupal product manager Gábor Hojtsy has concisely summarised the various scenarios:

3) How can I help

There are many good instructions in the Drupal community covering the best approaches. This one by Gábor is recommended. It also refers to the necessary tools such as phpstan, rector or drupal-check:

If you want to provide us with some practical assistance have a look at our Thunder META issue where you can find all the issues on which we are currently working.

4) How can Thunder users get “Drupal ready”?

Thunder users are essentially facing the same challenges as we distribution operators: They should also let the appropriate test run in order to check their own codebase including additional modules and their own code for deprecations.

Their greatest benefit is: They will have less work afterwards. This is because we will look after the task of removing deprecations for Thunder and the standard modules. That means that you can concentrate fully on your newly added modules and your own code.