META: Required functionality for Drupal 8 distributions

Configuration management in Drupal 8 is built primarily around the single-site staging or deployment problem rather than the requirements of distributions. Back in 2012 a discussion tried to assess what was needed to make Drupal 8 distribution-friendly, but it didn't get far.

While there are good beginnings, significant barriers remain to distributions in Drupal 8. This meta issue aims to inventory them. Although this issue is assigned to Configuration Packager, the needed solutions will be scattered across several projects.

Extend the configuration development toolset

Much of the toolset needed for authoring Drupal 8 configuration modules is not specific to the needs of distributions but is common to anyone managing configuration in an extension. Therefore, much work needed for features/packages/distributions should be generic and applicable to any module development task working with configuration.

Some good starts exist within Configuration Development and Features 8.x.

Still, missing functionality runs the gamut from handling of info file updates when configuration is added #2392929: Add a Drush command for updating module info files) to bulk refreshing of a module's configuration (#2405275: Add method for exporting a module's configuration).

This task is made more complicated by the fact that seemingly applicable tools available in core are too hard-wired to the staging use case to be usable.

For example, the StorageComparer class seems to offer the ability to detect differences between different sets of configuration files, but internalizes staging assumptions that lead to barriers if it's to be used for a different purpose, see #2410995-2: Use StorageComparer to determine config changes.

Similarly, the events associated with configuration import via ConfigImporterEvent are tied to the staging system and not (as one might naively assume) the import of configuration from extensions; see #2410985: Update configuration snapshot on reverting.

Support bulk updating of extension-provided configuration

The Drupal 8 model that sites, not modules, own their configuration creates significant issues for distributions; see the blog post Drupal 8 configuration management: what about small sites and distributions?

Good work is going on within the Configuration Revert sandbox project. However, for updatable distributions, we still need an approach to manage mass updating as opposed to manual reverting of individual overrides. Relevant issues:

• #2406059: Faciliatate customization of reports, e.g., distinguishing edits from extension changes
• #2408927: Support bulk operations on reports
• #2406685: Provide summary report modeled on Update

Accomplishing this task will require some way of determining what configuration can safely be updated without losing customizations. Possible approaches include:

• Build on the configuration snapshot system that currently takes a snapshot of configuration when it's installed or synchronized via the staging system. Also snapshot config as installed or updated from extensions, then compare those snapshots to the active configuration to determine whether customizations were made; see #2406059: Faciliatate customization of reports, e.g., distinguishing edits from extension changes.
• Capture all customizations as overrides on client sites (see "Enable capture and export of configuration overrides", below), then add them back in through the override system, leaving the active configuration storage always in a state ready to be updated. Such a solution would need to address many issues, such as how to introduce the captured overrides into configuration entities prior to editing, to ensure previously captured overrides were retained.
• Implement some form of explicit tracking of the customization status of specific configuration items. This could include locking all items by default (see #2407601: Support locking of individual configuration entities) such that a site admin wanting to customize a configuration item would first need to explicitly unlock it. On update, synchronize all non-customized configuration with the current extension-provided version.

See the Configuration Synchronizer sandbox module for a beginning on the first of these approaches.

Enable capture and export of configuration overrides

Certain configuration data can't be exported directly into modules.

For example, by default Drupal 8 stores all permissions assigned to a given role with the role itself. Since the permissions to assign will be specific to a given extension's use case, permissions will need to be added per configuration package; see #2383439: User permission handling. Similarly, simple configuration (Drupal 8's version of settings variables) should be installed by the module that owns them and any customizations made on top of that; see #2409319: Review handling of simple configuration. While both of these use cases could be handled through module updates, it would ease development to have some sort of exportable overrides.

One option would be to use the configuration override system, see #2120949: [META] Configuration overrides and maintaining distributions. This might be roughly analogous to the Drupal 7 Features Override approach. The draft Domain Config module includes some potentially useful pointers on how the override system might be used.

Standardize approach for modifying configuration on export

Configuration contains site-specific data that needs to be removed before being exported into extensions, see #2407609: Coordinate configuration development?. This includes UUIDs but may extend to other data like user permissions.

Handle theme-specific configuration

Drupal 8 block configuration is exported in theme-specific files that limit portability; see #2393113: META: Handle theme-specific configuration.(https://www.drupal.org/node/2393113)).

Provide methods for packaging configuration meeting a use case

Existing initiatives:

• Features 8.x
• Configuration Packager

Barriers include: #2418961: Packages can't be enabled on originating site.