Configuration Management – Drupal

May 31, 2012 · Comments
CMSDesignDevelopmentDrupalFail

Bring the Pain…

The area of most frustration for me with Drupal is the configuration management system, or rather the complete lack of any configuration management system that works with version control software. It’s really a shame that this one area drags down the entire experience, because so many of Drupal’s components are light years ahead of what other systems have.

Things Like:

• hook_anyThingYouWant(){ The Drupal hook system is really second to none, you can create anything you can imagine… But with great power comes great responsibility…}
• Theme System: Drupal’s theme system give you as much control over the output templates as the hook system give you over the application logic. It’s really amazing…
• Module System: Coupled with the theme system and the hook system, Drupal’s module system completes a trifecta that let you do so many amazing things that you simply can’t with less flexible systems

Throw in tight integration with the git distributed version control system and you’re in heaven… or are you?

But…

If you have ever tried to migrate a Drupal site that uses a lot of modules that require configuration you know what a pain in the a$$ this can be. If you use Views, Panels, CCK, or any of the other configuration intense modules out there know what I am talking about. This means everyone knows what I am talking about. Imagine the following scenario…

1. You plan to build a cool new content type for you drupal website.
2. You make a copy of your production code base by cloning your git repository to a test location and load a copy of your production database in for use.
3. You make your awesome new content type.
4. You make some views to look at it.
5. You make some blocks that have views in them that show the new content type
6. You make some custom panels pages to put all these things where you want them to go
7. Time passes and your users continue to use the production website
8. Now you have completed your testing and are ready to roll the new content type out to the production website.
9. The code base is easy to merge back (in case you made some changes I don’t know about) using git
10. Now you just have to merge your new content type and all its associated data back in to the database. The easy way to do that without disturbing new user data is to… um… well…

And this is the problem. All these modules were created to make it easy for people who felt uncomfortable creating Themes and Modules achieve some of the same functionality that you could get by rolling your own code, but (I imagine) when Drupal was first created no one could have for seen how much site structure would end up in the database. It was all supposed to be in modules, templates, and CSS.

There are some hacks things like Features that try to ease the pain by exporting a lot of the structure information out of the database and into php files. That way you can include them in your version control. A version is still in the database “over-riding” the code, but when you push the “Feature” back to the production site you can clear your “cache” of Features settings and reload the new structure information from the generated php files. This isn’t horrible, but it’s not optimal either.

So what to do?

One of the very most awesome-est projects that will contribute to Drupal 8 is the aptly named Drupal Configuration Initiative. This intrepid group is on a mission to tame the configuration management beast and they just might do it.

They plan to move the configuration data into XML files housed in a new ‘/config’ directory that would function similar to how the ‘/modules’ or ‘/themes’ directories work currently. I like it!

All you have to do is “Flush” the cache and reload the new configurations. Any individual module could employ as simple or complex a config as needed.

I’ve Been to the Mountaintop…

So I have to say I’m excited about all that is going to happen with Drupal 8! But, we are still a pretty long way off from seeing a production stable build of Drupal 8, so for now (sigh…) we stick with Features.