Drupal 8: Configuration Management Walk-Through

* This material is now outdated as the CMI system no longer stores to files by default but instead saves to the database in specialized CMI tables. We are working on updated Drupal 8 material and CMI is one we are covering.

One thing in Drupal 7 that people have a love-hate relationship with is the Features module. Features gives you the means to export database-stored site settings in code that you can put into version-control and move from server to server. In Drupal 7, when using Features to make a change to your Drupal site configuration settings, you need to update the feature or make sure the settings are in a feature and (re)create them. When deploying, you revert your features so your site settings match what is in code.

If only things were that straight-forward! Frequent "gotchas" are had because nobody really knows what the best practices are for using Features until some really painful and time-consuming mistakes are made! It's a hard way to learn. But Drupal 7 site settings are stored in the same database as regular ole' content, so relying on database backups to deploy settings and update the live site isn't ideal either. User-generated material can be lost. With no UI-based alternatives, many of us adopt a Features-based deployment workflow, but we kick and scream along the way.

That is...until Drupal 8 ships.

The Configuration Management Initiative (CMI) was created to fix this headache. Although it's still a work-in-progress, a foundation exists and the basics are working. As you point and click around a Drupal 8 site, configuration settings are no longer being stored in the database, but rather in configuration files. Looking at a fresh install of the Drupal 8 file structure, check out sites/default/files and you will see a folder called config_ (note the hash). Out of the box, Drupal 8 stores all configuration settings inside many ".yml" files (pronounced yah-mull). The reason for the hash at the end of the folder name is because the folder must be web server readable. This originally caused security concerns because prying eyes could potentially view information stored in these files, but the CMI team now includes an .htaccess file to mitigate any risk. Along with the hash to stop someone from just attempting to find the directory itself, this security concern is now addressed. This is how things work out of the box because not all servers can handle all methods of security. The final measure is the ability to move this folder out of the docroot via the settings.php which is 100% recommended for everyone.

How does this work with modules?

It is actually quite cool. A module will ship with its own config folder and default configuration settings. When a module is enabled, the system will copy the default settings to the master config_ folder. When the configuration settings are modified,  the new settings are stored with the rest of your site's configuration settings under the same security measures just described.

Now that we have an understanding of how deployment will work in Drupal 8, let me walk you through the process as it stands currently. I have set up two Drupal 8 sites locally. I will make a change to the site name on one and move the setting to the other. Let's take a look:

This is a very basic demo of a very complex feature. I just want to show how deployment has progressed from Drupal 7 to Drupal 8 when it comes to configuration settings.

Note: The config_ folder does contain two sub-folders, active and staging. The active folder contains the current site configurations. Staging is for what will become the configurations. This system is in place for more advanced deployments using version control. I did not cover this because CMI is still a work-in-progress. 

Related Topics: 


And with the config_reset module, the site configuration can be directly imported from original configuration provided by modules, and the original module's configuration can be override directly from site configuration.

I noted in the video you imported config.tar.gz and likely the file you should have imported was config[1].tar.gz, because that was the one created today (in the video).

That is likely why there were other changes and not just the site title. May also explain the error in the import.

Actually I did multiple video takes cause I was having local dev issues. I edited that one in because I had the most luck with it that is why the files don’t matchup. I was having issues during the install of Drupal 8 which I am still working on figuring out. I had a colleague do the same thing and all worked perfectly for him. Good eye though :)

This is one of my favorite things about D8. Thanks for the article.

Thanks for explaining!

But I am wondering how this will work for a multisite setup:
Is it ok to use the config manager to sync config between the sites or will this be impossible with the UUID's? Bad or good practise?

Sorry for such a late reply, I acutally wasn't sure of the answer. So I asked around and am finding that no one is sure of the answer.  I have a few more people that I am waiting to here from so if I find the answer to using the new system with multi-site I will reply back here.

This is now out dated as the active configuration is no longer in the file system but in the data base... for beginners this video is very confusing.

You are 100% correct. We have done our best to let users know that D8 material can go out of date at any moment. Too make this easier I will mention it in the description. We are working diligently on new Drupal 8 videos and we cover the latest CMI.

Add new comment