Before Drupal 8, changes in site configuration could only be stored and moved between environments by using the Features module. This practice was less than ideal, as Features was not originally conceived for this purpose.
Since there was no better way to manage configuration outside of the database, this became the standard practice. Inspired by Features’ limitations and the need for a more reliable configuration management process, a Configuration Management Initiative (CMI) was established to devise a solution for Drupal 8 and beyond.
The initiative yielded the Configuration Manager module, a user interface for exporting and importing configuration changes between environments that are now integrated into D8 core. Now that we have a greater variety of options, let’s take a closer look at the best practices for configuration management in D8.
In theory, CM manages all configuration by exporting configuration from one environment and importing it into another, but in some situations, it cannot be that simple. The primary purpose for Features in D8 gets back to the original goal of the module which was to provide an interface for bundling functionality that logically belongs together such as a photo gallery, hence the name “Features.”
It’s still possible to manage configuration using Features, just as we did in Drupal 7 and before. There are some workflows involving multiple simultaneous developers that use a combination of Features in local sandbox environments and CM for conveying configuration betwixt servers.
And then there are overrides. These now reside in the $config variable array (formerly $conf) in a settings.php file. The array is also now organized in a way that is more in keeping with the new CM system ([name of the YAML file][name of the configuration item] e.g. $config[‘system.site’][‘name’] = ‘Overriding site name’;).
There are a few files in which configuration overrides can be placed:
- Possibly version controlled settings.php
- A non-version controlled (or gitignored) settings.local.php
- A version controlled settings_environment directory that contains files for each…you guessed it, environment.
The simplicity of the Configuration Management system in Drupal 8 is its strong suit, however, this comes at the expense of flexibility when there are multiple environments to manage. Managing configuration in Features could be advantageous because Features more clearly organizes configuration and allows custom code to reside along with its corresponding config.
Features is also a great solution when building install profiles for multisites and/or if rapid provisioning is needed. Although the stated goal of using a Features CM hybrid is to reduce conflicts, those conflicts could be avoided on the basis that different CM files contain configuration for different areas. Any conflicts that arise would be there regardless of CM or Features usage.
While the $config variable in settings.php is the most complex, it offers the greatest flexibility. If there is only one environment, it’s possible that configuration management is not necessary. Configuration that is common between environments and does not have security requirements can be placed in settings.php directly.
If there are multiple environments, it may be possible to distil them down into types of environments when considering configuration. For example, there could be a production environment type and a non-production type used for development, testing, and staging. Perhaps there is also a local sandbox type.
Any secure configuration can be placed in a file that is not version controlled, so it will not be in the repository. It is manually placed in each environment and named settings.local.php. This file is included in the settings.php file. One advantage to having this outside of version control is that configuration changes don’t always happen at the same time as deployments.
Finally, there are the settings.environment.php files that reside in a version controlled settings_environment directory. These should be used if access to all servers is not available or if there is a lot of environment specific configuration.
There’s no one way to manage configuration. It depends on the type of environment(s), configuration, custom code, server access, and security needs.
The overall guiding principles are:
- Keep It Simple and use Drupal 8 Configuration Management
- Add Features, settings.php, settings.local.php, and settings.environment.php only if justified.
The key is to understand your needs and identify the right strategy for each project. We’d love to hear your thoughts about and experience with configuration management in Drupal 8. Please share in the comments below.