Configuring Drupal 8: several needs and solutions

General notes on configuration in Drupal 8

Drupal 8 has an API in its core allowing configuration export and import, also known as CMI for Configuration Management Initiative. This was not natively possible with previous versions.

In previous versions

In Drupal 6 and 7, the most widely used solution to this shortcoming was the use of the Features module allowing configuration to be exported to files.

Features is intended to allow configuration to be grouped into functional bricks and allow functionality to be reused from one site to another (this is still the case in Drupal 8).

Drupal 6 and Drupal 7 do not have a configuration deployment system, so Features is also used for this purpose, a use not originally intended. As a result, there can sometimes be certain problems that are easily resolved once they have been identified.

The standard case is deleting a field in the development environment, removing its code in the feature and forgetting to make a hook_update_N to delete the field during deployment. Features can create fields during a configuration import because they are in the exported feature code, but cannot delete fields that are no longer in its code. This would mean having to delete all non-exported fields in features!

In Drupal 7, Features therefore makes it possible to manage configuration export and import and is generally unanimously supported by the Drupal community. In addition, other solutions exist such as:

• fully manage the conf with hook_install and hook_update_N
• using modules like Config in Code (I've personally never had a chance to test)
• scripting via Drush commands?
• other?

Advantages with Drupal 8

With Drupal 8, there have been several advances on the topic of configuration management and deployment.

1. Storage standardisation

Where in Drupal 7, there was a " variables " table storing most of the variables and each module added its custom tables to store its more complex configuration, such as Views, Panels, etc.. modules, Drupal 8 now has a " config " table in which all configuration, whether simple configuration (the equivalent of Drupal 7 variables) or configuration entities (views, image styles, content types, etc.), is serialized.

So it's no longer up to each module to provide its configuration storage and integrate with Features to be exportable/importable.

2. The introduction of configuration entities

Discussed in the previous point, when a module now has configuration that can be instantiated several times (image styles, search indexes, contact forms, etc.), it is now possible to create configuration entities with a base class simplifying development.

Furthermore, thanks to the Drupal console for enabling entity type generation (content or configuration) simply.

3. The introduction of States

In Drupal 8, there is also a separation between data to be exported from one environment to another (configuration), from site-specific data on a given environment (state / état). The latter cannot be exported.

This makes it possible to store data, for example the timestamp of the last execution of the Drupal CRON or whether the site is in maintenance mode or not, without the risk of exporting them in features as in Drupal 7. In Drupal 7, this data was generally stored in variables for lack of anything better.

4. Overloading configuration in settings

With Drupal 7, it is possible to force the value of variables by writing the value in the settings.php file. On each run, Drupal will read the file and use the value inside, it will also put this value in the database.

In Drupal 8, it's still possible to do this, with 2 differences:

1. The value overloaded in the settings is indeed used at runtime but is not stored in the database. This has the following consequences:
   1. That the value overloaded in settings does not appear in the configuration forms, which is quite disturbing the first time you test configuration overloading (the issue on this subject).
   2. That the value in database can be used again by removing the overload from the settings. No risk of overwriting the original value with the overload.
2. With storage standardisation, it is therefore possible to overload configuration entity values per environment. Very handy for changing the domain name of a Solr, Redis, Varnish, etc. server from one environment to another.
3. Exporting configuration translations

With the new breakdown of translations between translations:

• interface,
• configuration,
• of content,

it is possible to export and import translations of configurations, which are therefore versioned.

Drawbacks with Drupal 8

With all these improvements, configuration management in Drupal 8 was settled once and for all via the core... Well no! It couldn't be easier.

CMI has quite a few advantages, but also some disadvantages:

• It exports ALL the site's configuration: it's not possible to have configuration by environment and so you end up, for example, exporting the configuration supplied by development modules and having to have them in production... The aim is to ensure the integrity and consistency of the configuration supplied, which is no mean feat either.
• It exports the configuration in ONE folder (+ subfolders for each site language): not very practical for functional breakdown.
• It uses UUIDs to check that the configuration supplied does not come from another site and therefore prevents it from being imported if the site already has a configuration item with the same machine name but a different UUID: in the workflow thought out, you would therefore have to start from a production database. Impossible for a developer to work on a project by recreating a site from the configuration, obligation to start from a production backup.
• It is possible for modules, themes and installation profiles to provide configuration at installation (config/install and config/optional folders), but modification of these files is not taken into account once the module/theme/profile has been installed.

To overcome this, in addition to the Features module port in Drupal 8, there was a large quantity of modules in config_XXX to find alternatives to have development workflows avoiding the problems mentioned.

Here is a non-exhaustive list, modules are grouped together when they are designed to work together:

• Config Actions
• Config Templates

• Config Export Ignore

• Config Filter
• Config Split
• Config Role Split
• Config Ignore
• Config override

• Configuration installer (installation profile)

• Config Importer and Tools

• Config partial export

• Config single export

• Config Suite

• Config Token

• Configuration development

• Configuration Provider
• Configuration Share
• Configuration Synchronizer

• Configuration Refresh

• Rewrite configuration

• Source configuration

• Configuration Tools

• Configuration Update Manager
• I have only taken the main ones and new ones appear regularly...

<troll>Fortunately Drupal 8 was the opportunity to avoid the divergence of efforts to provide fewer modules but better quality...</troll>

Of this mass of modules, those around " Configuration Split " are starting to have a good number of sites using them and are getting quite a bit of press in blog posts about Drupal. But is it THE solution?

I wanted to look into it because it must also be said Features in Drupal 8 has disadvantages :

• More complex than in Drupal 7, which is complicated for beginners (easy to forget to export configuration),
• Doesn't handle configuration translations (issue on this),
• Imports features in alphabetical order instead of rebuilding dependencies between configurations, which causes errors when, for example, importing a new field that is mutualised between several features.
• Themes cannot be managed by Features (the issue on this), outside it would make sense for the theme to provide the configuration for the placement of the blocks it contains.
• Don't compare the active configuration (in the database) with the correct file. For example, for language configuration, Features will detect the French language in a Webform test sub-module or for simple configuration like Cron, will compare with a value located in a kernel module instead of the configuration exported in a custom feature.

The main problem being that with CMI, Features maintainers have expressed that the functional scope of the module in Drupal 8 is configuration packaging. Configuration import/export problems no longer concern the module.

Which solution for which need?

Because Drupal projects are varied, let's see which solution corresponds to which need because reading articles about configuration management in Drupal 8 gives the impression that there is only one solution, I doubt it.

In fact, there can be several types of project:

• Webfactories: operating via installation profiles
• Single site:
  • Predefined configuration that cannot be modified in production
  • Predefined configuration that can be modified in production:
    • all configuration
    • only certain points
• etc.

Installing a site from existing configuration

To do this, you can use the Configuration installer installation profile, which allows you to use CMI, without the need to go through a database backup.

Caution: Configuration installer requires you to have modules and themes outside the installation profile. If the site providing the initial configuration is part of an installation profile, this can be problematic:

Configuration installer requires modules and themes outside the installation profile.

• This is not ideal for the breakdown, it is common for a profile to provide its modules and theme(s) in its folder.
• This prevents the use of community installation profiles that have their modules and themes in the profile folder.

Configuration installer will therefore be used more for a single site project where you can:

1. start from the standard installer profile,
2. modify the configuration
3. export configuration
4. use install profile Configuration install

Making an install profile

With the often related need to factory sites in order to create sites that are functionally identical and identical or close in design.

Passing through an installation profile allows you to add configuration steps during installation and therefore allows more flexibility than importing the entire configuration of a site without being able to modify it.

For this need, Features can be used to package the configuration in modules.

The next question to ask is : once a site has been created, should it be managed with Features or CMI for configuration updates?

If we know that the site factory is designed for 600 sites, it will be cumbersome to version the configuration of 600 sites via CMI once they have been created. In this case, using Features with hook_update to overcome the aforementioned Features problems is a solution.

If the factory is designed for around ten sites, it is then possible to rely on CMI.

Override certain configurations by environment

The standard requirement is to prevent the presence of development configuration and modules on non-development environments.

With the use of Features, it is possible to export this configuration in modules activated only on development environments.

With CMI, this is not possible, but with the addition of the Config split module in the process, there it is now possible to have configuration by environment.

Also with the Config ignore module, it is possible to avoid completely exporting/importing certain configurations.

Be able to add/modify configuration in production

Giving the ability to add or modify configuration in production is a fairly common request. For example, giving the ability to activate languages, modify panels, place new blocks, etc.

With Features, you'll need to exclude the configurations concerned from features, even if it means initialising them via hook_install or a module not managed by Features.

With CMI, the use of Config ignore meets the need here. With this module it is possible not to manage certain configurations by specifying them or using wildcards.

Several points of attention:

1. It is not possible to initialise configuration in this way during a deployment and then allow it to be modified in production. It will then have to be initialised via hook_install or hook_update_N.

   The " graylist " functionality of Config split allows you to have configurations present on each environment but with different values. But still doesn't allow you to have a configuration that is initialized during a deployment and then can be modified in production.

2. Be careful with wildcards, during my tests I put the following configuration in Config ignore:

• views.view.*
• ~views.view.commerce_stores

When installing with Config installer, I only had the whitelisted view.

Conclusion

In Drupal 8 there is not THE solution for managing your configuration, even if great progress has been made on this side, the process must be adapted according to the type of project.

If you see other cases to manage, don't hesitate to leave a comment :), I'll test the possible solutions.

PS 1: When using Config installer, it's best to create an almost empty custom installation profile to avoid modules like Shortcuts being activated and the hook_install of the standard installation profile being executed.

PS 2: After talking to Fabien Bircher about Config Split, it is indeed possible with Config Split to provide initial configuration that can be modified in production. To do this, you need to define a production split that will be used to store overloads made in production.