Using and abusing the Configuration Management module for Drupal 7

Just about any Drupal developer these days will be happy to do his or her share of moaning and groaning about the agony that is moving configuration between environments and keeping all of that stuff in code. The Features module has helped tremendously with that, and as a result, it's a whole new world compared to a few years ago. But this really isn't the problem that Features was created to solve (which involves capturing and reusing nice little bundled-up "features" from site to site). As a result, some feel that Features may not be the ideal solution to the problem that it ends up getting used for in practice. A prime example is the Configuration Management ("CM") module for Drupal 7. Having taken some notes from the Drupal 8 CMI notebook, it's specifically built for what many people use Features for--exporting general site configuration to code and moving it between environments.

The "Bucket" List

With that in mind, there are a couple major differences between Features and Configuration. The first and most major difference is that Features is built with the assumption that config needs to be split up into separate, cohesive, neat little packaged modules, and CM just throws it all into one big bucket. There are a number of pros to the big bucket approach.

• No confusion about what config is where
• No tangled web of feature modules that depend on other feature modules
• No chance of one feature module overwriting the config from another

But there are also a couple obvious disadvantages:

• Not possible to toggle individual sets of config for a specific use case ("features")
• As such, not well suited for Drupal distributions that need to offer flexibility/modularity
• Putting that much stuff into one directory can feel a bit dirty

So why bother?

Given that CM is simpler and less confusing but at the cost of modularity and flexibility, it's generally more useful for custom site builds than for general purpose Drupal distributions. If I'm a distribution, I need to be useful to as many people as possible (within reason). A big part of this is giving users the option to turn parts of me off if they don't want them. If I'm using Features, that's easy--just disable the module. With CM, it's basically not possible outside of manually deleting the config items yourself from the GUI item by item or understanding how to edit the config files. However, if I'm a custom website for a client and I don't need any parts of me to be bundle-able or easily toggled (which, if we're honest, is accurate for the majority of client sites) and I'm more concerned with simplifying the development workflow, then I might be best off with CM.

Set 'er up

There's not much to do to get rolling with CM. All you really need to do is tell it where it can find your config directory. By default, this is sites/default/files/config but you can put it wherever you want in CM's Settings tab. Once you have that pointing to a directory that's writeable by the server you're good to do your first export. Remember that for obvious reasons, the setting that controls the location of CM's config directory is the only variable that cannot be exported by CM itself, because doing so would mean that on new installs, CM would not know where to look to find out where to look. Deep, right? So that means that if your goal is to capture all configuration in code, then you'll have to store that single variable another way, such as in the <code$conf</code> array in settings.php or by setting it in a module's update hook. That said, once Drupal knows where to look for config, any and all other variables and settings can be managed by it.

Let's configify some config!

Let's dive in and see how the CM module works. To start, head on over to /admin/config/system/configuration/notracking to view the list of components you can start keeping track of.

This brings up an important distinction in CM: the difference between tracking and exporting. The main thing to remember here is that tracking is what you'll be doing almost all of the time. Exporting creates a little tarball of config for you to send over to someone else, but it's useful day to day as a part of your workflow. Tracking, on the other hand, is where the magic happens. You'll need to check boxes next to things you want to keep track of in config (content types, variables, permissions, etc.). In return, CM will keep an eye on all of those things so that it can easily export them to code on command when they change. With that in mind, let's walk through the specific steps to make it happen.

GUI (non-drush) approach:

1. Go to admin/config/system/configuration/notracking and choose which “thing” you want to start tracking GUI changes to. Note that it automatically selects dependencies.
2. Go make your changes in the GUI.
3. When you’re ready to export and commit the config, go to admin/config/system/configuration/tracking and click “Write Activestore to Datastore”
4. In your config directory, commit the new changes and push them to the remote repo for others to get.

Drush approach:

1. Run “drush config-get-non-tracked” to get a list of all non-tracked components, and find which one you want to start tracking.
2. Run “drush config-start-tracking ” to start tracking it. It will automatically track dependencies as well.
3. Go make your changes in the GUI.
4. When you’re ready to export and commit the config, go to admin/config/system/configuration/tracking and click “Write Activestore to Datastore” (this unfortunately can’t be done in drush)
5. In your config directory, commit the new changes and push them to the remote repo for others to get.

Typically, the non-drush approach is a bit quicker and easier, but the drush approach can be handy, especially if scripting.

Let's import our friends' configified config!

Importing config and updating our active store to match it is super simple.

1. Pull in the latest config code from whatever repo you're using.
2. Run "drush config-sync" to sync the data store to the active store, or just run it in the GUI under the Synchronize tab.

What else do we have here?

All of that describes probably 95% of what you'll be spending your time with if you use CM, but it's not the whole picture. There are a few other things to be aware of:

"Migrate" tab

For times when you just want to let someone else quickly see a chunk of changes you've made without going to the trouble of syncing to the config directory and pushing the changes, you can click on over to the Migrate tab. Here, you can use the Export tool to select bits of config which will dump it all into a tarball. That tarball can in turn be consumed by the Import tool on another site to pull the config into the active store.

Spiffy diffs

If you install the Diff module you'll be able to view diffs comparing the active store to the data store so that you can see what you'll be exporting when you click the "Write Activestore To Datastore" button, or its opposite, the "Synchronize configurations" button. This is helpful in making sure you're not exporting some test field you threw in or accidentally obliterating someone else's config (which, if we're honest, has happened to the best of us in one Features module or another).

Exclude configurations

For any environment specific configurations you don't want to risk exporting and tracking, you can add it to the "Exclude configurations" option under the Settings tab. This is a pretty useful feature that can definitely same some headaches.

Let's wrap this bad boy up

And there we have it--CM is a pretty nice alternative to Features. It's certainly worth a look, wouldn't you say? Check out this sweet guide to solving 6 Drupal "gotchas" by our own Peter cho!