Drupal 9: What We Know So Far

Drupal 9 Release Date

Drupal 9 is almost here. By almost, we mean little over a year away. As far as development cycles go, that is fairly close.

Drupal 9 Release Date

The official Drupal 9 release date is June 3, 2020.

What does this mean for all those Drupal users out there? It means the winds of change are blowing. And hard. Which is a good thing.

Drupal 9 is, in a very technical sense as much as an essential one, an upgrade in true spirit. Dries Buytaert – the original developer of Drupal – has made it clear that Drupal 9 will be a cleaner version of Drupal 8, due in great part to the fact that the former is being built on top of the latter, essentially adding new functionality as backward-compatible code. This is very significant because it means migrating from Drupal 8 to Drupal 9 will be a very smooth and easy process.

Drupal 9 API illustrated

The developers have explained that the reason they have announced the Drupal 9 release date so far ahead of schedule is to give people time to prepare. Upgrading from previous versions to Drupal 9 will not only be easy, it will also be necessary if you wish to acquire full functionality and retain the ability to receive security updates within the bi-yearly cycles.

Drupal 7 and Drupal 8: End-of-Life

As of November 2021, both Drupal 7 and Drupal 8 will reach end-of-life status, which means updates will no longer be available to either. By announcing the release of Drupal 9 over a year before it happens, and two and a half years before the older versions are no longer part of the developing cycle, the people at Drupal are giving users enough time to fully prepare for the migration, with enough warning to be fully upgraded by that time.

The wide release window also provides core contributors with time to work on their modules and adjust to the upcoming changes, not to mention that it gives the Drupal team time to iron out any kinks.

What About Symfony?

As for Symfony 5, it will be shipped with Drupal 9, but it will also be compatible with Drupal 8 while the developers identify and fix any potential issues, giving users enough buffer before S5 is required for D9.

As of yet, not much is known about which third party dependencies will be updated, or even which modules will survive or be removed.

The most important thing to remember about Drupal 9 is that it is not really about new features, which developers have claimed will be few if any at all. The entire point of the upgrade is to ensure a general migration from older versions, which will not have any security updates going forward past 2021.

If you or your company use Drupal, be sure to keep checking the O8 blog for more updates on this release as they become available.


Tips from the Dev Team: Using Config Split and Config Ignore to Fine-Tune Your Configuration Management Process

O8 Config Drupal

One of the many great features introduced in Drupal is configuration management. This enables developers to easily push configuration changes from their development environment to staging, then production environments. It is a robust way to ensure that all of our content types, views, menus, and other settings are correctly deployed with minimal manual work.

What is configuration and what is content?

One of the challenges with configuration management is that there can be a fuzzy line between what is content and what is configuration. Content should not be exported as configuration: Editors should be free to change that content without it being overridden when the configuration is imported again.

Some elements are easy to divide into configuration and content: A menu is a configuration, but menu links are content. Block placement is configuration but custom block content is content. A taxonomy vocabulary is a configuration, but the term items are content.

But there are some types of elements that are a little fuzzier. Take, for example, a webform. A form is a configuration, but it also has content fields such as an instructions field and thank-you message. 

On the O8 website, we found that there were some configuration items that changed often on production while the marketing team did their work. Every time we pushed new configuration to production we would have to make sure to export these changes and commit them to git without accidentally overwriting the new configuration we were trying to deploy. We needed a better solution.

Developers also commonly use several utility modules while doing their work: we also need to make sure that this configuration is not enabled on production.

Luckily, there are a few additional modules we can use to solve these problems: Config Split and Config Ignore.

Using Config Split for development configuration

Config split is an excellent way to create a set of configuration that should only be enabled in certain environments. The classic use case for this is for modules and settings that are only needed for development work.

Follow these steps to implement a development-only config split:

  1. Download and install Config Filter and Config Split modules
  2. Move your main configuration directory to a subdirectory if it isn’t already in one (e.g. config/sync). Edit your settings.php file and change the update the main config directories path to the new subdirectory:

    $config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync';
  3. Create a directory for your new config split (e.g. confg/dev)

  4. Set up the config split:

    Screenshot showing the Config Split settings screen

    Make sure the machine name of your split matches the name of the folder you set up in step 3.

  5. Add your development modules to the config split settings. In this case, we are going to completely split the configuration for Database Logging, Devel, Kint and Stage File Proxy modules.

    Screenshot showing the Config Split settings screen, where config items are added to the split

    As you can see, it is possible to export individual configuration items here, or even use wildcrards to select sets of configuration.

  6. To enable this split on your development environment only, add the following line to your settings.local.php file:

    $config['config_split.config_split.dev']['status'] = TRUE;
  7. Export your configuration using drush csex.

You should see that your development modules have been exported to the dev directory set up in step 3. A normal config export using drush cex should respect your config split, but there may be a bug with some versions of drush that prevents this from working. Always make sure to check the unchanged files list in git to make sure your dev config hasn’t accidentally been exported to the main sync directory. If it has, just run drush csex again.

More detailed instructions can be found in the Drupal documentation, including an explanation of when you could choose a Conditional Split instead of Complete Split as described above.

Using Config Ignore for items that change on production

We could have used a config split for our webforms as well, but this presented a few logistical issues. We really don’t need to enable or disable this config in certain environments - we just need to prevent it from being overwritten on production. Config Ignore is a much better fit for this purpose.

Config Ignore simply prevents configuration from being imported. The process for setting this up is simple. 

Follow these steps to implement a development-only config split:


  1. In your development site, download and install Config Ignore module.

  2. On the config ignore configuration screen, add the entries that you don’t want to ignore on import:

    Screenshot showing the Config Ignore settings page

    These machine names match the names of the yml files that are normally exported in a config export and displayed on the Configuration Synchronization screen when there are changes to import. As you can see with the web form example, you can use wildcards here.

  3. Export configuration and deploy to production. 

  4. If changes are made to the ignored configuration items, you’ll see something like this when you try to import configuration:
    Screenshot showing how ignored items appear on the Configuration Synchronization screen

What’s next for Configuration Management

The Configuration 2.0 initiative is a new effort to improve configuration management in Drupal core. Some of the work going on in that initiative will integrate functionality currently provided by config filter and config split (planned for Drupal 8.7), along with fixes for some other ongoing headaches for developers. Find out more about the Configuration Management 2.0 initiative here and here.