Major Drupal configuration schema cheat sheet update - 7 years later

I apparently released the Drupal configuration schema cheat sheet 7 years ago (wow!) to help people adopt the then new format to describe configuration structure. I keep getting questions and requests about it, so decided to make a major update to it now and bring it to the present day for Drupal 9.

Updates from 1.5 (April 2015) include:

  • Double the pages, more extensive examples and pointers to core definitions
  • Includes description of config ordering introduced with Drupal 9.3
  • Documents how to pick schema keys for various use cases, such as config entities
  • Documents where to put the schema files and when to use multiple
  • Explains common string subtypes and recent additions to base scalar types
  • Contains a whole section on translatability
  • An entire new section to explain basics of mappings and sequences, the most common request
  • Explains potential of string keyed sequences 4 or so times, so hope it goes through :)
  • Suggests to use common mapping subtypes like mail and text_format
  • Covers ignore and undefined
  • Adds a whole new intro to dynamic typing to make the examples easier to understand
  • Makes all dynamic examples contain all definitions instead of abbreviations for easier understanding
  • Uses the same data to explain the [%parent] and [childkey] dynamic typing, to show the differences better
  • Cites various common core extension points, such as third party settings on themes and config entities
  • Explains advanced properties such as nullable lists
  • Updates test base class names for Drupal 9

I regularly receive feedback about people using the cheat sheet, so I hope this will help make config schema somewhat easier to grok. Improvement suggestions still welcome!

Kudos to Rene Bakx for his most recent questions that tipped me over to update the sheet.

The big Symfony 4 to 6 jump plan in Drupal 10 and potential benefits down the line for future versions

As you may know, we are planning to release Drupal 10 in 2022 (as early as June), because Drupal 9's Symfony 4 and CKEditor 4 are both end of life the year after, around the end of 2023. So we plan go give enough time for people to update to Drupal 10 before Drupal 9 goes end of life. A similar situation happened with Drupal 8 to 9 driven by Symfony 3 to 4. However, moving Drupal 10 from Symfony 4 to 5 would again only give us a couple years of time to move on to Symfony 6 next, so the current plan is to move to Symfony 6 straight.

How is it possible to move Drupal 10 from Symfony 4 to 6? Symfony 6.0 was just released a few hours ago and is stable, so by the time Drupal 10 would be released, it will already be at least on Symfony 6.1.

However, the exact same thing happened with Drupal 8, and we did not do a double Symfony version jump update from Drupal 8 to 9 for two reasons: (a) even though Drupal core minor versions are supported for 12 months, Symfony minor versions are only supported for 8 months other than the last LTS minor version and (b) jumping two versions would mean that scanning for and acting on minor version to minor version all deprecations is challenging. Those two did not resolve themselves so to speak, however we have plans to mitigate them.

Symfony security extension for Drupal-used packages

First of all, Symfony normally supports minor releases for 8 months starting with Symfony 5. On the other hand Drupal minor releases are supported for 12 months, so if there are security fixes to be made, this would not be possible on a non-LTS version of Symfony. However we made arrangements with the Symfony team to have two of the Drupal core committers be part of the Symfony security process and be able to backport security fixes as needed for components used by Drupal even if the given Symfony minor version would be normally out of support. The two Drupal core committers involved are Alex Pott and Lee Rowlands! I don't believe there was an official announcement of this agreement yet, however it was in place since September 2019. Special thanks for the open minded collaboration of the Symfony leads as well!

Bridging the deprecations jump with Symfony 5.4

Second is bridging API deprecations. Nathaniel Catchpole outlined the plan for this recently. The problem is that Symfony 4 deprecated some APIs for removal/changes in Symfony 5 and them Symfony 5 deprecated some APIs for removal/changes in Symfony 6. Jumping through two versions gives Drupal 10 a potentially longer lifetime but with a need to solve identifying all deprecated API uses for both. Now that both Symfony 5.4 and 6.0 are out, the plan is to open the Drupal 10.x-dev branch for development very soon and update to Symfony 5.4 as well as other big dependency updates. Then release a Drupal 10.0.0-alpha1 that is based off of Symfony 5.4, which would allow contributed projects and custom code to check against deprecated APIs towards Symfony 6. And only later update to Symfony 6. This way there is a middle-point that allows to make the necessary updates and check deprecated APIs against.

As jumping two major Symfony versions is not something we did before, let us know in the Drupal 10 issue if you can poke holes at the grand plan. While it looks like this will be entirely possible, it would be best to find any potential pain points ahead of Drupal implementers hitting them.

A proposal with overlapping LTS release versions of Drupal core

Lee Rowlands went even further and presented the potential benefits of this plan down the line with Drupal 11 and Drupal 12. Releasing Drupal 10 on Symfony 6 would allow us to support it longer, up to November 2027. However it does not mean that we cannot release Drupal 11 earlier than 2026 let's say. Releasing earlier would allow us to jump faster to Symfony 7 while it would still give Drupal 10 users a more comfortable, longer support timeline. Then we could take advantage of the full Symfony 7 support timeline.

That would result in Drupal users not needing to update every 12 months to keep security support but needing to update every 2.5 years instead, which would lower cost of ownership of Drupal considerably.

Check out this video where Lee explains the details and discuss in the issue titled Adopt a 2 year major release cadence and a 6 month LTS-to-LTS overlap period for Drupal 10 and beyond. (This is not yet a firm policy, it is under discussion).

Drupal 8 is end of life today: the compendium

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:

  1. 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!
  2. 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!
  3. 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.
  4. For your own code and your 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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!

One day to go until Drupal 8 EOL: what if you stay on Drupal 8?

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 projects and issues. These will likely not happen immediately tomorrow, but will be done soon. For contributed project maintainers on, 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.

Two days to go until Drupal 8 EOL: looking ahead to future versions

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!