Skip to main content

Managing Shared Configuration Part 8: Summary and Future Directions

October 9, 2018
Body paragraph

This is the eighth and last installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts. If you've stuck with it this far, wow! If you haven't seen previous installments, you might want to start with Part 1, Configuration Providers.

The series focus has been meeting the needs of distributions for creating and updating packages of shared configuration, a use case not addressed in Drupal 8 core.

We've seen how configuration can be packaged using the Features module (Part 6). We've covered the ins and outs of updating packages of configuration, including how to assemble configuration as provided by extensions (Part 1), make needed changes to configuration from another package (Part 4), capture a previous configuration state (Part 2), and merge in configuration updates (Part 5). Along the way we've examined the particular cases of preserving configuration customizations (Part 3), working with core configuration required by multiple features (Part 7), and (bonus!) managing blocks when subthemes are in the mix.

The fact we're on installment eight - not even including the sneak bonus episode - in itself suggests a general conclusion: addressing these needs is not simple!

Working with Drupal core

In this series we've seen challenges or regressions when it comes to managing shared configuration in Drupal 8. In Part 1 we noted an issue with core code related to optional configuration. In Part 4 we saw how previously well supported requirements for shared configuration such as adding permissions to site-wide user roles or adding fields to existing content types now require dauntingly complex configuration alters.

These regressions are closely linked to Drupal 8's focus on the configuration staging use case. Progress on these fronts was not helped by what I, at least, experienced as an often boosterist environment in the Drupal 8 cycle in which critical perspectives on use cases that were and were not being addressed were sometimes drowned out. In a parallel Drupal 8 universe in which the use case of shared configuration was fully on par with staging configuration on a single site, solutions to much or all of the problems reviewed in this series might have been part of Drupal core.

At the same time, we've seen various ways that Drupal 8 core, including the configuration management system, helps with the task of filling in missing configuration management requirements. In Part 2 we saw how the configuration snapshot used in core's configuration staging can be a model for extension configuration snapshots, and also how core's LanguageServiceProvider is a useful pointer for how to provide dynamic services for configuration snapshotting.

Then there are key developments in the contributed modules space, especially Config Filter. By modelling how to extend and customize core's configuration staging workflow, Config Filter also opened the way to a parallel workflow for merging in configuration updates from extensions. Again, core's configuration management provides an essential base here. The Config Distro module takes everything that core's configuration staging API provides and, with a few small changes, repurposes it for a shared configuration use case. True, the result is only a framework - hence the many other pieces covered in this series - but the work gets a leg up from core.

CMI 2.0

The Drupal core Configuration Management 2.0 Initiative (CMI 2.0) aims to address "common workflows [that] are not natively supported" and fill in "missing functionality" in core's APIs. For the work covered in this series, major additions to the configuration management API could be a big plus.

But they'll also have their tradeoffs. As a small hint of what may be coming, one of the first CMI 2.0 improvements led to breakage in the Config Distro module. A current big patch in the queue, Add configuration transformer API, looks like a great improvement, but since it would supersede the Config Filter module and our whole approach is built on Config Filter . . . . Yeah, a bit of work there. On the plus side, a compatibility layer between Config Filter and the configuration transformer API could mean it would all "just work" in the interim. Or, more likely, continue to break, but for other reasons ;)


Drutopia is a small initiative. In contributing to configuration management improvements we've been able to lean on contributions from many others including Config Filter and Config Distro maintainer Fabian Bircher, Features and Config Actions maintainer Mike Potter, Configuration Update Manager maintainer Jennifer Hodgdon, and the core configuration work by Alex Pott and many more.

Still, to get from where we are to a polished and solid solution set, we'll need a lot of help. Most of the modules we've contributed are still in alpha or beta. We hope that others will see value in the start we've made and continue to adopt and adapt the tools, making them their own. Recent help with automated testing is particularly welcome.

Beyond shared configuration

In the Drutopia initiative, configuration management is only a small part of our focus. Looking to emerging models of platform cooperativism, we're building a cooperative where members will own, shape, and use the software distributions that drive their sites. The first such distribution is Drutopia, nearing its beta release.

We welcome new participants and contributors. Interested? See our guide to contributing and the many ways to get in touch.

Next steps

This series has had a decidedly technical bent. But how do you actually use the stuff?

Good question. We're working on a follow-up on how to put it all together, including:

  • How to build a distribution using Config Distro and Configuration Synchronizer.
  • How to update sites using Configuration Synchronizer.

Watch for it.