The Features module is not deprecated by the configuration management system introduced in Drupal 8, but it is significantly enabled by it. As the project description has long said:

A feature is a collection of Drupal entities which taken together satisfy a certain use-case.

This issue is dedicated to exploring what should be done to reach this goal on 8.x. Many people have been noodling on this, but I don't see a central conversation, and it's time one started so the maintainers can more easily get as much raw input as possible before an 8.x upgrade becomes necessary.


Grayside’s picture

I see a couple ways forward. Option A describes a status quo approach to the design, Option B struggles toward a new fundamental concept for how Features works.

Note: As a reminder, I am not a Features maintainer. This is a couple proposals I am lobbing in to get the discussion started.

Option A (Status Quo)

CMI has already introduced mechanisms to export configuration for a site en masse. An 8.x-2.x version of Features might pull the UI forward for the most part, and replace the guts with something as follows:

  • Features Pipe Logic (the thing that takes the .info file records for features, runs some alter hooks, and identifies component "ownership") might be replaced by Features config entities.
  • Extend the export mechanism to whitelist elements by the Features pipe logic
  • Create a new under-the-hood element of the Features UI that takes the whitelisted subset of site configuration and sets it as the default installation configuration of a new or existing module.

The upshot of these points is a refactored Features module that retains all the known patterns of Features Export, Features Update, and possibly Features Revert for development purposes. Downsides are preserving these concepts, which are well-understood but an outgrowth of Drupal's former limitations.

Option B (Revolution)

This approach is still a bit hazy on account of my still incomplete understanding of the configuration system. The point here is not to sit Features on top of it, but to work with it from the inside to make it a better facilitator for the kinds of things Features does. I think of this as the 8.x-3.x approach to Features, but I suspect I'm describing multiple modules or even projects.

The layers I'm thinking of are as follows:

  • Configuration Storage Splitter: Whenever you save a form, it stores the change to the configuration cache and to the permanent record that is the configuration files. Extending this concept further, make it possible for any configuration storage engine to be used simultaneously, and provide some tools to manage comparison.
  • Configuration Change Subscription: Modules may "subscribe" to the changes associated with configuration namespaces. As such changes happen, their own configuration defaults are updated to match. This only happens in a site set to some sort of developer mode.
  • Features "Use Case" UI: A UI that allows the definition and management of module subscriptions, focusing on helping pull together related configuration components (fields with a bundle, etc).

The general effect of this concept is to configure modules that automatically pick up on configuration changes made throughout the site. The goal here is to keep the purpose of Features intact, but streamline the development process by using Configuration Management internals instead of creating ever-more-convoluted ways to run an export.

mpotter’s picture

Good topic!

I personally tend towards an "Option B" where Features 8.x uses the CMI internals and provides a UI for collecting related configuration. Features 8.x should certainly utilize the CMI data export formats and should no longer export configuration as PHP code, or at least modularize the export mechanism/storage engine as Grayside mentions.

I still need to do a *lot* of work to play with D8 CMI and really understand it, so I'm definitely behind the curve on this and welcome community input.

But Grayside has summarized this well and I'd like to return Features to it's original use-case of collecting "configuration" needed for specific functionality rather than the dumping ground for all configuration data that is has become (and which CMI should alleviate).