Configuration Management in Drupal 8


Drupal 8 is pretty exciting for many reasons: decoupled templating system, built-in internationalization, views in core, and Symfony are some of the highlights. But one of the most exciting Drupal 8 advancements is a little difficult to understand – the Configuration Management Initiative (aka CMI). CMI was one of the main initiatives identified when Drupal 8 was in its planning stages, and through the hard work of many core developers and contributors like Greg DunlapDavid Strauss & Alex Pott (pictured below, photo credit: Angie Byron), it is a core part of Drupal 8 (THANK YOU!!).


First things first, I’d like to clarify what “Configuration” means in this context. Configurations are settings in Drupal’s interface that get stored in the database with the content but actually impact the structure and functionality of the site.

Simply stated, CMI evolved Drupal to have a underlying architecture that facilitates easy saving, porting and moving configuration changes from one environment to another. If you have one site, this is not a huge problem – but if you have more than one let’s say several hundred or even 10, this can improve process and stability in huge ways.

Drupal 5 & Drupal 6 – Configuration management by process

My experiences in Drupal 5 and Drupal 6 revolved around managing configuration changes through process, communication and documentation that existed outside of the core system. While there were some early adopters experimenting with other solutions (eg.  Features) the main ways of managing configuration between environments that I was familiar with in the early Drupal Days were process based and centered around communication with team members to make changes.


Here is one “sample” process practiced by some of my Phase2 co-workers in the “phase 1″ days when we needed to reskin or redesign any music websites on a Drupal 6 platform:

  • Step 1 – Make your changes on stage or dev site for content or configuration.
  • Step 2 – Push your code up that might change themes or colors or modules.
  • Step 3 – Enter in your *new* content in the live site but make sure it’s unpublished
  • Step 3 – Get the client to take a look at the stage site, have your QA team sign off
  • Step 4 – Get launch approval
  • Step 5 – Prepare for launch
  • Step 6-  Review the txt files or checklists of configuration changes
  • Step 7 – Start exporting views
  • Step 8 – Put the site in maintenance mode / turn off user logins (maybe you are freezing the database)
  • Step 10- GO CRAZY FOR .5-6 HOURS depending on how the site was different updating all the configuration – the views, the checkboxes, the new blocks that need to go in a newly specified theme region
  • Step 11-  Double check work
  • Step 12 – Pull back the curtain & cross your fingers

What could go wrong in a 12 step process with multiple handoff points? I like to call this the checkbox problem. If anyone has ever gotten into administering, site building, or managing a Drupal site, you might know that there are lots of checkboxes. These checkboxes are settings that make for a  very powerful, extensible, and flexible CMS. The gray area between content and configuration is not always clear to folks when they have a CMS. The ability to change anything does not always mean that you should.

Drupal 7 – Features and Automation

Next came Drupal 7 and automated builds, when Features connected with continuous integration solutions like Jenkins. When this became an issue, the Drupal community did its best to find a solution. Features, originally designed to be a packaging module for site features, ended up being the de facto way of managing configuration in Drupal 7.

Developers set up elaborate features in code and then pushed them through the environments. Configuration changes while site building was definitely an ideal workflow for many developers, especially as automated builds became more regular.  Although this worked out well, it still felt “bolted on” and issues with overrides were common.

Mike Potter recently wrote about Features in Drupal 8, and he spoke on the issue at DrupalCon. Mike envisions a world where Features is not for stable deployment but used as originally intended alongside CMI.

Drupal 8 – it’s YAML time

Drupal 8 configuration management is rooted in what is essentially a re-architecture of the way in which configuration files are stored and managed. Modules store their configuration settings in YAML files which is a core standard that is applied to all modules and this baseline architecture creates flexibility for solutions.

My work on a recent Drupal 8 project with the Memorial Sloan Kettering team would not have been possible without underpinnings of CMI.  When I spoke with the team, one of the key sound bites came from Drupal lead / CMS consultant at MSK, Jacob Rockowitz: “It just works.”

In fact, the solution pioneered by MSK Tech Lead Jacob Rockowitz for webform management was based in YAML.  We had a chance to discuss the YAML forms approach with some key community contributors at a BOF in DrupalCon. One of the exciting places of expansion is seeing how the innate architecture of CMI in Drupal8 will be extended for innovative solutions like YAML forms.


DrupalCon D8 & CMI

Want to hear a little more historical context & see the D8 CMI in action with a real life example workflow? Watch the recording of CMI on a Managed Workflow session from DrupalCon Bogota where I presented with on Matt Cheney of Pantheon on the Latin American leg of his CMI world tour.  More CMI wizard tour highlights include an architectural bent from Amsterdam & beta 10 live demo from DrupalCon LA.

Wondering where features is in the mix of the configuration landscape in Drupal 8? Watch the features guru, fellow Phase2er Mike Potter breakdown the Features in Drupal 8 story at DrupalCon LA.

Curious to hear about the adventure of building a site in Drupal 8 on top of a configuration system that “just works?” Read our case study, or watch the panel in the DrupalCon Business showcase to hear the story from Memorial Sloan Kettering, Digitas and Phase2 team members as we talk redesign strategies, community showcase, D6–> D8 migration, front end integration, and more!


Want to stay up to date with the latest in Drupal 8 and beyond? You can hear about all our Drupal 8 adventures in Phase2’s newsletter.