Raise your hand if the built-in config system in Drupal 8 saved your work life, too! That, of course, until you started to notice a crack here and there... And till you realized that you kind of depend on contrib modules for... filling in those holes. But then, the Configuration Management Initiative 2.0 came about and, along with it, the promise that all your legitimate questions would be answered:
- What about multisite and shared config?
- What about the zip workflow?
- What about config changes on... production?
- What about extending the configuration management system's narrow use case? What about extending the API?
In other words: CMI 1.0 was, indeed, a huge leap forward for the Drupal community, as it addressed critical problems (at that time). And yet, over the years, we just got "needier".
Or maybe we just started to see the current config system's limitations a bit clearer and to long for a better configuration management system.
Now, let's see how it all started, the progress that the team has made, the proposed solutions to well-known issues, and the current challenges they're facing:
1. But First: What Are the Current Config System's Biggest Limitations?
First of all, the configuration management system in core is designed to meet basic needs only:
Staging and deploying configuration on the very same website.
Multisite or distributions weren't being regarded as common types of workflows at that time...
And there's more:
- its APIs ship with missing functionality
- we need to rely on contrib modules for all those (many) types of workflows that the core config system doesn't natively support
- in many cases, we end up with conflicts between the contrib solutions that we use
- there's no standardized set of best practices
2. The Configuration Management Initiative 2.0: How Did It Come About?
Quite naturally, I would say. Dries Buytaert and his team at Aquia wanted to identify:
- the main reasons why anyone would hesitate to use Drupal
- the factors with a negative impact on the Drupal user experience
And, to no one's surprise, Drupal's configuration management system turned out to be one of the main “culprits”.
Now, leveraging the experience of the first configuration management initiative, the team working on CMI 2.0 pinpointed the key questions to be answered:
- What about updates?
- What about all those Drupal developers who use zip archives instead?
- How would the new config system be dealing with translations?
- What about those workflows where one uses database dumb for production?
- What about the “cross-site” type of workflows?
- How would it cope with config changes on production (since the current system supports deploying config on unmodified websites only)?
- How to extend the API?
And they also decided to use their experience with using contrib modules to enhance the current config management workflow in Drupal 8 for creating the new features.
3. CMI 2.0 Highlights
“And what has the team behind the Configuration Management Initiative 2.0 achieved so far?” you might legitimately ask yourself.
Now, let me walk you through some of the project's highlights:
- a new API interacting with the workflow
- an improved Config Filter (see config storage transformation api)
- the config storage transformer, handy whenever a config store is used, for import/export purposes
- simplified Config Split
4. CMI 2.0: Latest Issues and Current Challenges
Now that we've gone through the accomplishments, you might be wondering what are the remaining problems to be addressed.
The challenges and latest issues that the team of contributors working on this project is still dealing with:
4.1. Copying Config Between 2 Config Storages
The challenge:
Setting up a standardized mechanism for copying config between config storages.
It's true, though, that there are tools (see Drupal Console and Drush) that you could rely on for tackling this issue, but in certain cases that lead to... weird behavior.
The CMI 2.0 team's solution:
Adding a utility trait to handle the congif copying part and to look after the collections, as well...
4.2. Finding a Solution for the Lack of API for Configuration Export
The challenge:
Drupal 8 doesn't yet provide an API for exporting the configuration, therefore one such API has to be implemented.
One that would allow us to easily improve our workflows and that should support workflows where zip archives are being used, as well.
The CMI 2.0 team's solution:
Adding a new service: config.storage.export.
Now code exporting configuration should use this service instead of exporting it straight from the active storage.
4.3. Creating a System Supporting Different Modules in Different Environments
The challenge:
Finding a standardized way of dealing with update hooks that change environment specific configuration. Which, implicitely, turns the task of deploying config into a true dare...
The current built-in config system in Drupal 8 doesn't support multisite workflows. Therefore, a new mechanism is needed to withstand structures of different modules installed in different environments...
The END!
Have you been watching how things evolved with the Configure Management Initiative 2.0? Have you maybe participated in the sprints?
Which of the limitations in the current configuration management system have the greatest impact on your own work?