In Drupal 7 it isn’t always clear-cut whether something belongs in the “configuration” or “content” realm. Are vocabularies configuration? Are taxonomy terms configuration? And what about a taxonomy term whose ID is used as a contextual filter in a View?.
Another annoying issue with Drupal 7 is that modules are free to set their own standards for storing configuration, so it is common to find sites where configuration is scattered among variables, database tables, objects exported via CTools, Features, and other places. Modules like Features at times need some “black magic” to guess where and how relevant configuration is stored.
Inspired by this issues, Drupal community started an initiative, specifically the Configuration Management Initiative that have been working to solve them and thanks to this we have now an easy way to work with a great configuration system.
In Drupal 8, configuration is less subjective: Drupal has an “Export Configuration” function that exports all the site configuration (and of course you can “Import Configuration” to deploy them in another site easily); if something is not there, it is not considered to be configuration. And with this, it’s clear what is configuration and is not. 🙂
In this article I don’t want to make the 1001 post about what Drupal Configuration management is, I would like to focus more on the initiative itself. However if you like to know more about the Configuration Management, here is the documentation page, and this is an excellent video about it.
- There was no good way to move Drupal configuration information between environments because this data was scattered throughout the database in a variety of formats, oftentimes intermingled with content.
- This also made it impossible to version control this information, to store history, and to be able to rollback changes.
- Every module stored their configuration data in a different format, there was no standardization at all, even within core.
- There was also no standard API for saving this information (aside from the simple case of the variables table) so developer often implemented their own solutions.
- The entire contents of the variables table was loaded on each page request, even for rarely-accessed data, leading to memory bloat.
- It was cumbersome to manage information that is different between server environments for the same project (database information, api keys, etc.).
At DrupalCon Chicago there was a ton of energy around Drupal’s staging and deployment problem. At his keynote, Dries identified this as one of the major initiatives for the Drupal 8 cycle, and following the keynote three Core Conversations were given on the topic by myself, David Strauss, and Howard Tyson. Those talks sparked conversations which continued through the week and generated a lot of really cool ideas.
The organizers of this initiative are:
Would you like to join? Here is its Drupal Group. The official IRC channel #drupal-cmi is there to help anyone who want to contribute. They have also a site where they publish some documentation and issues about the initiative.
My little contribution
In this part I would like to show you some things I have made that have a relationship with this initiative. One of them is the series about how to port a Drupal 7 module to Drupal 8 where in the chapter 3 we talk about how to save configuration settings through the configuration management API. There is also a video of this series, so here is the link.
To finish this I would like to invite you to involve in the initiative if you think you can and I know you can. 🙂