Drupal Planet

Managing Shared Configuration Part 8: Summary and Future Directions

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!

Managing Shared Configuration Part 7: Core Configuration

This is the seventh and (promise!) penultimate installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts, beginning with Part 1, Configuration Providers.

In this series we've covered how to create and update reusable packages of configuration in Drupal, otherwise known as features.

In Part 6, we saw how the Features module can be used to package configuration that will be used by multiple different features into a "core" feature. An example is when multiple fields use the same storage. A core feature might provide a field_tags field storage, allowing multiple features to add a field_tags field to different content types. All the features that provide a field would require the core feature.

This approach helps to manage dependencies among different features, but it has at least two major shortcomings.

  • Any site that wants to install even a single feature that's dependent on the core feature will get all the core configuration--whether or not it's needed. For example, if the core feature provides five field storages but only one is required by the dependent feature, all five will still be created on the site.
  • Features from different sets or distributions will have conflicting dependencies. Say we have two different distributions, A and B. An event feature from distribution A requires the distribution A core feature, which provides the field_tags field storage. An article feature from distribution B requires the distribution B core feature, which provides an identical field_tags field storage. The event feature should theoretically be compatible with the article feature. But in practice they can't be installed on the same site, since an attempt to install both core features will raise an exception since configuration provided by the first-installed core feature will already exist on the site when the second is queued for installation.

In this installment we'll look at options for managing shared configuration that's required across multiple features--or multiple distributions.

Drupal distributions, blocks, and subthemes

In Part 4 of a current series on managing shared configuration for Drupal distributions we looked at needs and options for altering configuration provided by extensions (modules, themes, or the site's installation profile). We covered common needs such as altering user roles to add permissions. But when it comes to altering configuration, blocks are a special case--hence this bonus installment!

When you create a site based on a distribution, there may be a requirement to customize the look and feel. The usual solution is to create a custom subtheme for the site; see the drupal.org documentation on subtheming. That way you can get everything the distribution provides but give the site a custom presentation.

Using a custom theme will work fine for most configuration. But it won't work for configuration that includes the theme itself as a dependency--like blocks.

Managing Shared Configuration Part 6: Packaging Configuration with the Features Module

This is the sixth installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts, beginning with Part 1, Configuration Providers.

Our main focus has been updating configuration from distributions--specifically, the question:

How can I update my site so that I have all the latest configuration changes from a distribution--while still retaining any customizations I made?

Updates are well and good. But before packages of configuration can be updated, they need to be produced and managed in the first place. In Drupal 8 as in previous major versions, that task is the domain of the Features module.

The Drupal 8 version of Features is a complete rewrite with major improvements over previous versions. If you're familiar with previous versions but haven't used Features in Drupal 8 this backgrounder will bring you up to speed.

Despite being a development-focused tool, Features is in the top 40 or so most installed contributed Drupal 8 modules. Features is used in building and maintaining several of the more-used Drupal 8 distributions including Open Social, Varbase, Open Church, and Quick Start. It's a key build tool for the Gitlab-hosted Drutopia project.

In this installment we'll cover Features in Drupal 8, including how to use it to produce a distribution.

Managing Shared Configuration Part 5: Updating from Extensions

This is the fifth installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts. To catch up, see Part 1, Configuration Providers, Part 2, Configuration Snapshots, Part 3, Respecting Customizations, and Part 4, Configuration Alters.

In this installment we'll start to pull it all together.

Paraphrasing a bit from Part 1, we described a key problem this way:

How can I update my site so that I have all the latest configuration changes from a distribution--while still retaining any customizations I made?

In Part 1 we mentioned Fabian Bircher's widely used Configuration Split module and its enabling API module, Config Filter, returning in Part 3 to give a more detailed introduction. In Part 2, we summarized the API and accompanying user interface that core provides for staging configuration. Here we'll take a deep dive into how we can merge in configuration updates from installed extensions through an approach that's built on Config Filter and closely parallels core's configuration staging.

Managing Shared Configuration Part 4: Configuration Alters

This is the fourth installment in a series presenting work on shared configuration that comes out of the Drutopia initiative. To catch up, see Part 1, Configuration Providers, Part 2, Configuration Snapshots, and Part 3, Respecting Customizations.

In the next installment we'll start to pull it all together, showing how all the pieces covered so far fit into a solution for merging in configuration updates. But first there's one more piece to add. In this installment we'll be looking at creating and updating configuration alters.

First off, what is a configuration alter?

An alter is an addition, deletion, or change to a piece of configuration.

When we're producing a several packages of shared configuration - what are often called feature modules - sooner or later we need a particular feature to modify configuration that was provided by another feature.

Say I'm producing a Drupal distribution that includes two different features: an event feature and a location feature. Any given site might install the event feature, or the location feature, or both, or neither. (A big part of the point of having distinct features is to make them optional and independent.)

In this example, say the event feature provides an 'event' content type with fields including a required 'date' field. The description of the event content type is: "An event takes place at a specified time." The location feature provides a 'location' content type.

But if I have both events and locations, there's a relationship between them. Events take place at a location. So on a site with both the event and the location features installed, the event content type should get an additional required field, "Venue", that's a reference to a location. When that happens, the description of the original event content type should change accordingly. Now it should read: "An event takes place at a specified time and place."

To make this happen, the location feature (or, possibly, a third feature) is going to have to alter the event feature's configuration.

Managing Shared Configuration Part 3: Respecting Customizations

This is the third installment in a series presenting configuration management work that comes out of the Drutopia initiative.

  • In part 1 of this series, Configuration Providers, we introduced the problem of managing shared configuration in Drupal, starting with how to determine what configuration is available.
  • In part 2, Configuration Snapshots, we covered creating snapshots of configuration to facilitate comparison of different configuration states.
  • In this installment, we'll look at another key issue when updating shared configuration: how to handle customizations.

To help clarify the problem, take this scenario:

  • You install a site from a Drupal distribution.
  • One of the pieces of configuration that distribution provides is an event content type.
  • You edit the content type to tweak the help text that appears when a user creates a new piece of content.
  • Now a new release of the distribution is available.

You want to update to the new version and get any updates it provides, including any changes that were made to the event content type. But - and here's the tricky part - when you update, you don't want to lose the customization you made to event the content type's help text.

Managing Shared Configuration Part 2: Configuration Snapshots

This is the second installment in a series presenting configuration management work that comes out of the Drutopia initiative.

In part 1 of this series, Configuration Providers, we introduced the problem of managing shared configuration, starting with how to determine what configuration is available.

But knowing what configuration is available is only part of the picture. To import configuration updates, we also need to answer the question: what's changed since the configuration was originally installed? That's where snapshotting comes in.

Managing Shared Configuration Part 1: Configuration Providers

At the Drutopia project, one of our big focuses has been improvements to configuration management in Drupal 8. In this series, I'll be covering our work to date along with related efforts and contributions.

Drutopia is a platform cooperative initiative, building out cooperatively owned and hosted Drupal distributions. In our 2016 white paper, we recognized that the Configuration Management Initiative (CMI) in Drupal 8 "produced a lot of improvements in configuration handling" while noting that these "mainly addressed the use case of 'staging' configuration from one version of a site to another, a site-building technique that lower budget sites often don’t have time or money for." We committed to focus on "the free software use case left out of Drupal core: reusable configuration that can be shared across multiple sites". For background, see Drupal 8 configuration management: what about small sites and distributions? and sections on Drupal 8, corporate influence, and the CMI in this interview.

There's a current initiative to improve configuration management in Drupal core. Dubbed "CMI 2.0", the effort comes out of a similar conclusion that limitations and missing use cases in configuration management are a major barrier to Drupal 8 adoption; see Angie Byron's post proposing the initiative.

In the past three years, we at Drutopia have contributed to a growing collection of Drupal plugins that together address some of the tricky problems involved in managing shared configuration. As well as in kind contributions by Chocolate Lily, some of our work was sponsored by Agaric and the National Institute for Children's Health Quality (NICHQ) to meet their needs for an in-house platform of community sites.

Just what do we mean by managing shared configuration?

Say I have a site built on a Drupal distribution that's for community organizing. I installed the site a month ago and got groups-related configuration such as a group type. Then I made some modifications of my own. I've just downloaded a new release of the distribution, including enhancements to the groups-related configuration. How can I update my site so that I have all the latest changes from the distribution--while still retaining any customizations I made? That's the key question we've tried to tackle.

A more abstract way of putting the problem is: how can we provide packages of shared configuration in a way that lets site administrators both customize their sites and merge in configuration updates?

This series will cover distinct aspects of the problem of managing shared configuration packages and, along the way, highlight specific solutions we at Drutopia have sketched in. Our efforts are very much works in progress. We're not sure we've even got all the problems right, let alone fully addressed them ;) But have we made progress? Yes, we have. By sharing it here, we hope to raise the profile of these problems and solutions and invite further perspectives and contributions.

Pages