You've probably seen the stats Dries Buytaert cites in his State of Drupal keynotes, and some of my earlier blog posts where I call for deprecated API removal automation and fixing drupal_set_message() calls all around in particular. You might have been wondering where is all that data coming from and how can you get a better sense of where Drupal projects stand and how can you help make progress. Well, I had a lot of fun recently building a new tool (with help from Matthew Grasmick, Shannon Vettes and Angie Byron) for dev.acquia.com that does exactly that! Check out this demo and head over to dev.acquia.com/drupal9 to try it out.
In his State of Drupal keynote at DrupalCon Amsterdam, Dries Buytaert showed once again some tools to use to prepare for Drupal 9 including the Upgrade Status module. To me the process is even more interesting than the tools, because it is entirely different from the last upgrade. As I wrote last week, you now make a lot of incremental improvements on your existing Drupal 8 site that makes the gap to Drupal 9 significantly smaller.
It is a new mindset to look at your Drupal 8 site to improve in preparation for Drupal 9 and we have tools to identify those improvements to make. However Dries also mentioned that we are not quite there to automate those improvements. Back in May Dezső Biczó of Pronovix built out a proof of concept integration with Rector that implements a sample set of refactors, including changes for global constants and best effort solutions to some
EntityManager uses, a
UrlGeneratorTrait and a
drupal_set_message() rector. While the extent of impact of the global constant rectors are not yet known due to limitations in our tools not finding them yet, the rest of the implemented rectors are definitely tapping into the top list of deprecated APIs.
Unfortunately slightly after he posted his blog post about the proof of concept, Dezső did not have time for this project anymore. I think this tool could be of huge help in removing deprecated API use in your projects and thus making them more modern Drupal 8 projects (while being more if not already entirely compatible with Drupal 9). However, we need contributors to cover more of the deprecated APIs, especially around
db_*() functions. If we can figure out rectors for most of the top 15 errors (and Dezső already did some of them), we could cover over half of all deprecated API use in contributed projects:
To top that off, I also think a simplytest.me style online service would be very useful to run drupal8-rector on your drupal.org project and suggest a patch to apply to remove deprecated APIs. Even better if it allows custom code to be uploaded so people can use it for that too. The more we can automate these tasks the easier the transition of Drupal 8 to 9 will be.
Submit issues and pull requests in the drupal8-rector project to improve API coverage. Look for me on Drupal slack if you get stuck and I'll try to help. I'd also love to talk to you if you want to set up an automated service. Let's do this!
I've had various deep discussions with contributed module maintainers recently about their process to update code to Drupal 9 and one point struck me. We are so attached to "Make it ready for Drupal 9" that a key point of the message may be lost. Check out this section of the State of Drupal keynote from DrupalCon Amsterdam 2019 where Dries Buytaert showcases Johanna's relatively simple site that she prepares for the Drupal 9 upgrade entirely in Drupal 8. Notice that she does all the steps in Drupal 8 other than the final Drupal 9 upgrade itself:
This is the base principle of the process towards Drupal 9, making your Drupal 8 site better and more prepared, so the move to Drupal 9 itself at the end is a relatively small step and you got a better Drupal 8 site in the meantime. You are not jumping over the fence all at once, but in gradual steps. I thought a comparison with Drupal 6 to 7, 7 to 8 and 8 to 9 would help, since people may have assumptions or prior experiences with those, so its worth looking at how our new process compares to the two previous transitions.
Join the team making Drupal 9 as part of the contribution events in person at DrupalCon Amsterdam and remotely! We'll be spending the last day of DrupalCon Amsterdam working on three things.
- Removing deprecated API use from Drupal 8 contributed projects to get them ready for Drupal 9.
- Updating core dependencies and removing deprecated APIs from Drupal 9 itself.
- Improve the tools and documentation that help people prepare for Drupal 9.
On October 31st, join on Slack even if you are there in person but definitely if you are remote. We'll meet in the #d9readiness channel on Drupal Slack. If you’re at Drupalcon Amsterdam, come to Europe 2 Forum!
To remove deprecated API use from contributed projects:
- Tools: Pull up the getting started info at https://tiny.cc/d9readiness and get set up with the drupal-check tool to check your code for deprecated API use.
- Help people who want to learn how to remove deprecated API use from projects, or remove some deprecated API use yourself! In minutes, you too could help make Drupal 9! Here are tips and tricks for the most common deprecated APIs: https://github.com/mglaman/drupal-check/wiki/Deprecation-Error-Solutions.
- Pick an issue: Check the list of issues tagged Drupal 9 compatibility + Amsterdam2019 (or use your own module!).
- If you're a module developer who would like to get a better chance to having your module reviewed / patched by a new contributor there, please create (or tag an existing) issue with the Drupal 9 compatibility + Amsterdam2019 tags!
To remove the deprecated APIs themselves, update dependencies in Drupal 9 or improve the deprecated API checking tools and documentation, please ask for specifics in the Slack channel or in person. The Drupal 9 tables will be easy to find!
You can also help spread the word by retweeting this:
— Gábor Hojtsy (@gaborhojtsy) October 16, 2019
1xINTERNET will even supply a limited amount of stickers to proudly present that you made a difference!
Thanks everyone for contributing to making Drupal 9!
Drupal 8.7.7 expected later this week is the first Drupal release to support extensions compatible with multiple major versions of Drupal. This is huge!
Drupal 9 is planned for June 3, 2020 and we are aiming to make the transition as smooth as possible. In fact we build Drupal 9 in Drupal 8 with API deprecations and optional support for new dependencies (Symfony 4.4 is getting very close, while Drupal 8.7.0 was already Twig 2 compatible). Extensions following these deprecations and making sure they are compatible with the updated dependencies could have codebases that are both compatible with Drupal 8 and 9 at the same time, meaning less support burden and earlier Drupal 9 compatibility. In March 48% of contributed projects on Drupal.org were already "Drupal 9 compatible" (as we could detect at the time), and that increased 54% by July (highfive!). These projects will now have one more thing to do, a one line
info.yml file addition, to allow their existing codebase to also run on Drupal 9.
✋Drupal contrib maintainers, thank you! You are already contributing a lot to a successful Drupal 9. Projects that are "compatible with Drupal 9" (as much as we know now) are up to 54% from 48% since March. Deprecated API use is decreasing overall.
You are awesome, keep it up! pic.twitter.com/mHpw4ET0P4
— Gábor Hojtsy (@gaborhojtsy) August 2, 2019
The core: 8.x key did not cut it anymore
Drupal 8 looks at extension
.info.yml files and checks for the
core: 8.x key to check if the extension can be used with Drupal 8. Unfortunately this was not adequate already due to API additions in Drupal 8 minor releases. You could not specify an extension was only compatible with Drupal 8.4+. People devised clever tricks with dependency on certain versions of the system module, but that was still limiting due to inability to depend on specific patch releases. In case your extension depended on a bugfix being present, you cannot set a dependency on Drupal 8.4.1+ in any way.
Introducing the core_version_requirement key
While solving this issue it became apparent that solving it with the existing
core: 8.x key is going to cause backwards compatibility problems with existing Drupal 8 sites. The format of the value could not be changed without causing issues, so a new
core_version_requirement key was introduced. This now allows to depend on major and minor versions of core as well as specify multiple version requirements even between multiple minor Drupal versions. For example if you would need a bugfix that is to be included in both Drupal 8.7.23 and 8.8.3 (imaginary future versions) but you wouldn't care for the minor version, then you would use the following, making your module incompatible with versions before the particular bugfix you need on both minor branches, as well as incompatible with all older Drupal 8 branches:
name: My Module
core_version_requirement: ~8.7.23 || ~8.8.3
Such precision was never possible before!
The new feature is made available in 8.7.7 to help prepare for Drupal 9, as this makes it possible to also declare Drupal 9 compatibility with the existing codebase you already have. Drupal 8.7.x will get security support up until the planned release of Drupal 9 on June 3, 2020. For extensions that only support Drupal 8.7.7 and later you can now exclusively use the
core_version_requirement key. If the extension is also Drupal 9 compatible:
name: My Module
core_version_requirement: ^8.7.7 || ^9
For extensions that also support older versions, you should keep the
core: key as well. The
core_version_requirement key will be ignored by older Drupal versions, and new versions will validate that you specified non-conflicting requirements in the two keys (with regards to Drupal 8 support) so for extensions supporting older core versions,
core_version_requirement also needs to be permissive, but could also allow compatibility with Drupal 9 too:
name: My Module
core_version_requirement: ^8 || ^9
Read more about this change in the change notice. There is also work ongoing to support dependency metadata from
composer.json to drive Drupal's dependency resolution as well. That will coexist with this simpler approach and will provide a more composer-native solution for those who already adopted composer for their extensions. In the meantime at least
core_version_requirement will limit what Drupal would install while
composer.json requirements will limit what composer will download. Because both Composer and Drupal use the term install, but those don't mean the same thing, here is a comparison chart:
|core: 8.x||system module dependency||core_version_requirement||composer.json dependencies|
|Can be used from||Drupal 8.0.0+||Drupal 8.0.0+||Drupal 8.7.7+||Drupal 8.0.0+|
|Allows minor version precision||No||Yes||Yes||Yes|
|Allows patch version precision||No||No||Yes||Yes|
|Allows multiple constraints||No||No||Yes||Yes|
|Limits composer install (download)||No||No||No||Yes|
|Limits Drupal 8 install||Yes||Yes||Yes||No, unless explicit support is added.|
|Allows Drupal 8 and 9 install with same codebase||No||No||Yes||No, unless explicit support is added.|
What happens to Drupal.org project version numbers then?
8.x-1.3 version of an extension on drupal.org may only be compatible with a subset of core, but that was already the case earlier. Now an
8.x-1.3 version of an extension on drupal.org may also be compatible with Drupal 9. How will this work? Drupal's composer integration already ignores the 8.x prefix from version numbers and only cares about the project specific version. Drupal core already only installs extensions where the core compatibility requirements are met regardless of which version number was the package you used to download (8.x modules may be only compatible with 8.4+ already). So the ultimate plan is to do away with the 8.x prefix in extension numbers entirely on drupal.org and support semantic versions for contributed extensions instead. In the short term, the Drupal.org project browser also needs to be updated to take the dependency metadata and use that to power compatibility filters, instead of merely using the version number prefix.