You get to:
- migrate configuration from Drupal 7 to Drupal 8
- move configuration from development to production (or to stag, then to live)
- manage configuration between multiple Drupal websites in a multisite installation
- manage configuration for multilingual websites
But how do you do it... the right way?
What are the Drupal 8 configuration management best practices to incorporate into your workflow?
I've made a list of 9 do's and don'ts to keep in mind when managing and working with configurations in Drupal 8:
Configuration Management in Drupal 8: Key Principles
Why would you use the configuration management system available in core on your own Drupal 8 infrastructure?
Because it makes it so much easier (and effective, especially at an enterprise level) to:
- make
- capture
- review
- test
- keep track of
- deploy
... configuration changes to production environments.
And to move them between multiple development environments.
In short, a Drupal 8 CM workflow enables you and your team(s) to manage configuration between multiple instances of your website. From development to production.
Or even from website A to website B in the context of a Drupal 8 multi-site configuration management workflow.
Drupal 8 Features vs Configuration Management
Yes, you would use the Features module in Drupal 7 to migrate config changes from one development environment to another. And yet, the Drupal config management system doesn't come to replace it.
Because it doesn't work the same way:
- Features enables you to package configuration into a module so you can reuse it on other Drupal websites, as well.
- What the Drupal 8 Configuration Management System does, instead, is synchronize configuration between different instances of the same Drupal site.
You get to make and test configuration changes in one environment of your Drupal site and then deploy them to another instance.
1. Avoid Making Configuration Changes on a Live Drupal Site
And this is the big "Don't" to put on top of your list of Drupal 8 configuration management best practices:
Make your config changes in your local/development environment, then import them to live site.
2. Trigger a Database-Dump Before You Synchronize the Staging and the Active Directory
Trust me: you'll thank yourself later for this precaution if you'll ever need to... rollback.
3. Need to Import a Config Change Before Running Update Hooks? Import the Needed Config from Files First
Take this scenario, for instance:
You need to add a new taxonomy vocabulary using the configuration management system and to enrich the vocabulary with terms by running an update hook.
4. Need to Store Local Variables that Normally Shouldn't Migrate Between Instances? Use the State API instead of Configuration
For all those hidden system values (that you shouldn't move between environments), go for state instead of configuration.
You might lose all state when resetting a system, but not its configuration.
5. Avoid Making Changes to Individual Config Files Manually: One of the Drupal 8 Configuration Management Best Practices
It's the simplest (and most effective) way to make sure that you don't compromise your stored configuration by accident.
With your stored configuration being a flat-file database, you should approach it as such.
A similar situation would be where you need to avoid writing a raw SQL query when you add a content type...
6. Use Drush to Move Config Changes Between Development Environments
No doubt about it:
The UI for configuration synchronization is both easy to use and... effective.
And yet, consider integrating Drush into your Drupal 8 configuration management workflow.
Why?
Because it makes synchronizing configuration much faster: you can skip the login step. There's no need for a web interface when using the command line to import/export your configurations.
With Drush, you just enter a short command:
- $ drush cim to import your config
- $ drush cex to export your config
7. Avoid Using the Configuration Management System to Manage Content Entities
There's a strict line in Drupal between:
- content: files, nodes, taxonomy terms
- configuration
Drupal content gets stored in the database and configuration in the config management system.
That being said, one of the Drupal 8 configuration management best practices is to avoid a situation where you'd have a configuration entity depending on a content entity.
For instance:
You want to export a view configuration, where the view is filtered by a static taxonomy term.
With no actual content there, when you try to export your view configuration, the import process won't work. It'll create a conflict.
The solution?
Before you import your configuration, make sure that the content it references to does exist.
For this, use the Migrate & a custom module or the Default Content module.
8. Need to Update the Active Configuration? Changing Files in a Module's Install Directory Is Not a Good Option
Why?
Because you need to have the module installed for Drupal to read from that config/install directory.
Otherwise, it won't work...
Tip! Use drupal config:edit or drush config-edit if you need to edit live.
9. Update Contributed Modules (and Core) With Caution When Using Any Type of Configuration Management System
Why?
Because if you change your module's schema or configuration when updating your contrib module and you overlook to export your configuration, the next time you import it it'll override the changes resulted from your database updates.
In short: your codebase and database will desynchronize.
The END!
I'm curious now:
What are the Drupal 8 configuration management best practices that you've included in your own workflow?
The ones that you stick to no matter what?