Those of us who have experience traveling the long dark roads of migration projects between Drupal’s previous major version releases may, understandably, be feeling some trepidation at the impending release of Drupal 9 (potentially as soon as June 3, 2020).
The journey from Drupal 7 to Drupal 8 in particular was a major challenge for many developers, with massive API changes, a completely new theme layer, and a fundamental OOP architecture.
The investment in these massive changes, however, is paying big dividends as we approach D9. This journey is going to be a lot easier in comparison. In fact, for many of us, the journey is nearly over before it begins.
D9 is D8 (mostly)
Here is the big takeaway: if you are on Drupal 8.8+, you are already fully API compatible with Drupal 9. Drupal 8’s OOP structure and its core Symfony foundation have made it possible for the Drupal API to be more stable and continuous between major versions. In fact, the major differences between Drupal 8 and Drupal 9 are the removal of deprecated code and the update of core dependencies so that they remain on supported versions.
If D9 is D8 (mostly), then why should I go through the trouble?
Drupal depends on third party libraries and frameworks, and those libraries and frameworks must be updated over time to maintain support and security updates. Sometimes, it’s impossible to maintain backward compatibility with older versions of these dependencies. Drupal 8 adopted semantic versioning, which made it possible to introduce major new features and backward compatible third-party dependency updates in minor releases, while also making it easier to adopt backward compatibility breaking changes in a clear and predictable way.
Drupal 8’s central core dependency, Symfony 3.4, will stop receiving bug fixes in November 2020, and stop receiving security updates in November 2021. Drupal 9 will depend on Symfony 4.4, which is not fully backward compatible with Symfony 3.4.
Your site needs to remain secure, so you need to adopt Drupal 9. The good news is that even though Drupal 9 is planned for release June 3, 2020, Drupal 8.9x will remain supported until November 2021. This time around, we have a much lower level of effort to transition, and a long window of time to make it happen.
Dealing with deprecated code
In most cases, removing instances of deprecated code from your custom code is a simple process. Matt Glaman’s drupal-check tool can scan your code and return a report of any deprecated code in use. Many changes will be as simple as changing a call to:
file_unmanaged_copy() to \Drupal::service(‘file_system’)->copy(). Some changes may require a little more work, but that work is being done within the same Drupal 8 API you’ve grown accustomed to.
For contributed code, identify the modules you rely on that use deprecated code, and use this as a great opportunity to contribute back to the community by testing and submitting patches.
The bottom line, however, is that you must deal with your deprecated code. It will not work in D9.
Dealing with core dependency updates
Here are some of the most important core dependency changes that may impact you.
Symfony 3 to Symfony 4.4: If you are making direct use of any Symfony code, you may need to update that code to its Symfony 4.4 equivalent
Twig 1 to Twig 2: There are a few changes and deprecations in Twig 2 that may require code updates in your templates. See Preparing for use of Twig 2 in Drupal 9
jQuery UI: Most of the world has moved on from jQuery UI, and in Drupal 9, so follows Drupal. Most jQuery UI components are being removed from core, with a few exceptions. If your project requires jQuery UI components, you will need to bring them in as contributed code
There are of course other core dependency changes. See Drupal.org’s Drupal 9 documentation for more information.
Are contributed modules ready for Drupal 9?
The state of contributed modules is much better compared with the transition from Drupal 7 to Drupal 8.
Most Drupal 8 compatible modules are either fully code compatible with Drupal 9, or require a few deprecated code updates (and a very minor yml file change). The burden on module maintainers is much lighter, and the low level of effort presents an excellent opportunity for the Drupal community to contribute back deprecation changes and test patches.
The transition to Drupal 8 was a tough one, but the architecture and strategy changes that the core development team adopted are paying off in a big way as we look toward Drupal 9 and beyond. The stable, gradual, and predictable advancement of the API creates an environment that promotes best practices, and provides teams with a more predictable landscape with less risk.