How Do You CM? 9 Drupal 8 Configuration Management Best Practices to Handle Configurations The Right Way

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.


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


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


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?

Image by Miguel Á. Padriñán from Pixabay