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

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.

Feed: 

Comments

Reuse of install actions

It's also important to note that this is the state of Drupal 8 today.  But as Drupal evolves through 8.1, 8.2 and into the future it is possible for additional APIs to be added.  I would be very unhappy to have the configuration system that satisfies the use case you describe if it means waiting another year to use a stable Drupal 8.

Delete / Install

I'm no expert of the API, but wouldn't uninstalling the module that drives the configuration and installing it work in to satisfy your case?  (there isn't a disable action anymore)

Sort of, as a workaround...

Yes, uninstalling and reinstalling would get you the latest configuration, and it's worth keeping in mind as a workaround when you're testing out functionality. But uninstalling every module will cause a bunch of data loss and dependency issues and so isn't really an option on a developed site.

I don't believe that is

I don't believe that is currently true. Uninstalling a module does not delete the config entities it initially installed and re-installing that module will currently cause errors because a config entity with the same name already exists. There is a core issue for this behaviour to change though.

I think your use case for

I think your use case for smaller sites is still a job for the features module. But without the need to handle the export/data in code and database (that is a painfull job). So Features in D8 can much more focus on his main function: The management of the configuration of indiviual functions, aka "features".

From the Features project page:

"A 3.x version of Features is planned for Drupal 8 to integrate with the new configuration management system. If you simply need to export simple site configuration, the D8 configuration management system should be used instead of Features. You will use Features in D8 to export bundled functionality (like a "photo gallery feature")."

More to come....

Yes, Features and related Drupal 8 initiatives are worth attention. I'll be looking at them in an upcoming post.

Sorry but I don't think that

Sorry but I don't think that should be the role of Drupal core.

Features (or a similar module) can be ported to D8 in order to provide the same functionality you are expecting (move config between different sites). That shouldn't be in the scope of Drupal core IMHO.

what do we mean by configuration ?

I am bit confused with term "Configuration" in d8 perspective. Is it the configuration values set for the different entities like

Fields : unlimited value, visibility settings, manage display settings

Site: site name, site email, permissions set for different role, cron settings, file system , image styles etc.

or

Contrib module's settings : webform mail id,  pathauto settings, jquery update version etc.

The premise is a unfair

The premise is a unfair because you're not comparing like with like - in Drupal 7 you can't export any configuration to files without a contrib module. As you say Drupal 8 adds native support for a new use case (a staging workflow), but as far as I'm aware doesn't make the Features workflow any harder. In fact once Features 8.x is released I expect it to be more reliable than Features 7.x, because modules will come across configuration problems with CMI that were previously only a problem once Features got involved. CMI also supports types, so no more 0 changing to "0" when you update a feature.