Skip to main content

Drupal 8 configuration management: what about small sites and distributions?

Authors
January 23, 2015
Body paragraph

In a recent blog post, Drupal 8 co-maintainer Alex Pott highlighted a seismic shift in Drupal that's mostly slipped under the radar. In Drupal 8, he wrote, "sites own their configuration, not modules".

To see why this change is so far-reaching, it's useful to back up a bit and look at where exportable configuration comes from and what's changed.

In Drupal 7, a lot of site configuration (views, rules, and so on) can be exported into files. There are two main use cases for exportable configuration:

  • To share configuration among multiple sites.
  • To move configuration between multiple versions of a single site.

By and large, the two use cases serve different types of users. Sharing configuration among multiple sites is of greatest benefit to smaller, lower resourced groups, who are happy to get the benefits of expertly developed configuration improvements, whether through individual modules or through Drupal distributions. Moving configuration between different instances of the same site fits the workflow of larger and enterprise users, where configuration changes are carefully planned, managed, and staged.

In Drupal 7, both use cases are supported. An exported view, for example, can be shared between multiple sites or between instances of the same site. The Views module will treat it identically in either case.

If a site admin chooses to customize exported configuration in Drupal 7, the customized version is saved into the site database and overrides the module-provided version. Otherwise, though, the site is on a configuration upgrade path. When the site is upgraded to a new release of the module that provided the configuration, it receives any changes that the module author has made--for example, refinements to a view. At any time, a site admin can choose to toss out changes they've made and get the module-provided view--either the one they originally overrode or a new, updated version.

If anything, the multiple site use case was a driving force behind the development and management of configuration exports. The Features module and associated projects - Strongarm, Context, and so on - developed configuration exporting solutions specifically for supporting distributions, in which configuration would be shared and updated among tens or hundreds or thousands of sites. Yes, Features could be and is used for staging changes between instances of a single site; but the first and foremost use case was sharing configuration across sites.

For Drupal 8, however, the entire approach to configuration was rewritten with one use case primarily in mind: staging and deployment. The confiugration system "allows you to deploy a configuration from one environment to another, provided they are the same site."

In Drupal 8, module-provided configuration is imported once and once only--when the module is installed. The assumption is that, from that point onward, the configuration is "owned" by the site. Updated configuration in modules that have already been installed is, by design, ignored. Importing them, as Pott notes, might lead to "a completely new, never-seen-before (on that site) state." However, "Drupal 8 does not work this way."

What are the implications of this change? It has clear benefits if you're building a site that will be carefully managed through staging and, in particular, places a premium on locking down and controlling every detail of configuration.

But for most current Drupal sites and for distributions? The benefits are not so clear cut.

On the plus side, much of what previously was unexportable in Drupal core (content types, fields, variables, and so on) is now supported natively. No more heavy handed workarounds in the Features module for so called "faux exportables"--components like user roles, content types, and fields that Drupal 7 core stores only in the database.

But, with Drupal core firmly on the "single site" configuration management side, users wanting to benefit from module-provided configuration updates and developers of distributions may be left fighting core every step of the way.

It's hard not to conclude that Drupal 8 ties configuration management to a (primarily, enterprise-focused) single-site staging model, and in the process, neatly undermines the use cases that largely brought us exported configuration in the first place.

That said, there are emerging initiatives including Configuration Update Manager that may help. More on those in part two of this series.

Updated March 11, 2015. Changes:

  • Removed unintended implied criticism.
  • Updated links.

Also, see the draft Configuration Synchronize module for an initial attempt to address the use case of automated import of configuration-provided configuration updates.