Work is underway on a Drupal 8 version or equivalent of the Features module.

Given that Configuration Packager covers some of the territory of Drupal 7 Features, there are various scenarios:

  • The two are independent projects.
  • Features depends on and enhances Configuration Packager. Possibly, Features provides a front end UI for Configuration Packager.
  • Features is replaced by Configuration Packager, and work towards a D8 Features takes place in Configuration Packager.
  • Configuration Packager is merged into a Drupal 8 branch of Features and further work takes place there.

The first of these would be a bunch of duplication, so let's avoid it. The others are all worth considering.

As part of this discussion, here are design principles for Configuration Packager; see the project documentation. For familiarity, this list uses Features vocabulary. Before merging, we should agree on a set of principles that will guide all subsequent work.

  • Interoperability baked in. Interoperability between different features and feature sets is not an add-on or option but a core principle reflected in the basic design of the project. The default settings of Configuration Packager should facilitate creating and maintaining interoperable configuration modules and distributions. See the page on interoperability features.
  • The site/feature set as a whole. The primary unit of interest is the site as a whole as it maps to a feature set. Creating and editing individual features is also of interest, but is a derivative problem.
  • Work with core. Wherever possible, we should work with Drupal core. This includes working directly with core's configuration management API. Overriding default core patterns should be reserved for scenarios where doing so satisfies a critical requirement and is absolutely unavoidable. For example, the installation of configuration from features-type modules should work out of the box with core's default configuration installer without any non-core dependencies.
  • Packaging problem only; best shared solutions. Effort and functionality should focus narrowly on the problem of "packaging a collection of Drupal entities which taken together satisfy a certain use-case". Wherever feasible, solutions should be moved out of the project into more generic solutions that address configuration management needs beyond those specific to the packaging problem. This solution or solutions should be added as dependencies. Where functionality is added that is potentially generic, it should be done on an interim basis with the longer term aim of moving it to a generic solution.
  • Comprehensive test coverage. Despite its current state (testless!), code should include comprehensive test coverage. Primary reliance should be on unit tests, with Simpletest-type tests used only when a unit test is not feasible.
  • Core-worthy quality. All proposed changes to the code base should be assessed on the criterion: is this code worthy of Drupal core in terms of quality and elegance? In particular, rather than introducing dubious workarounds with the hope of later refining, it's preferable to leave a feature out.
  • A issue for every change. All changes, even relatively trivial ones, should be done through the issue queue.
  • Maintained on The project should be maintained on rather than some external site (e.g., GitHub).
  • Developer-only toolset. The focus should exclusively be on the use case of developing features extensions and should not introduce a dependency. That is, the module should never be required on any client site in order for the functionality it packages to be available.

Proposed resolution

Depends on the solution selected.

If it's to merge into Features:

  • Create a new branch of Features and create an (initially, empty) dev release, so that the issue system will include that branch.
  • Move all tickets (including closed ones) from Configuration Packager to Features, ensuring they're tagged to the correct release.
  • Move all Configuration Packager documentation pages to a new section of the Features documentation book section, updating as appropriate (e.g., "Configuration Packager" to "Features", "package" to "feature").
  • Assign nedjo commit access to Features.
  • In the Features repository, check in all current code from Configuration Packager as is. (TBD: is it possible to carry forward the git history?)
  • Rename all files and their included code to use the Features namespace and also to adjust code comments and strings as appropriate (e.g., package to feature).
  • Update the Configuration Packager project page, pointing to the new home.

Remaining tasks

User interface changes

API changes


mpotter’s picture

Of course I'm a bit biased, but given that we have discussed this I have no problem inviting comments from others:

I prefer the last approach. The more I've worked on this the more overlap I am seeing. Features could just be a UI, but I'd like to maintain some drush command functionality and just having duplicate drush commands with what config_packager already provides just seems like duplication.

I think all of this work will get more attention over in the Features issue queue, and I think users migrating from D7 will be more comfortable if there was a Features module that worked mostly like they expected even if all of the backend implementation is completely different. Features is already a "known" module and we don't want to waste that visibility it has with the community. Even if some people have said publicly that "you won't need Features in D8", I think we all know that Features is still needed for many things.

My second choice from #4 would be #2 where Features just depends on config_packager. But then config_packager would need additional refactoring and would need to be split into lower-level pieces. For example, Features needs an "existing" assignment plugin (#2401589: "Existing configuration" assignment plugin) but doesn't really need the other assignment plugins for "auto-generating" packages. I would want that moved into an optional module so that Features wouldn't need to include it.

With #4 I would refactor some of the optional stuff in config_packager into submodules within Features that could be turned on/off. Using the assignment plugins is a great concept for helping people initially create packages. Features would add a UI for adding/removing config items as in #2446805: Add "required" components for a given feature as another assignment plugin. So certainly the base classes of config_packager (Manager, Generators, Assignments) would be best as the core part of Features.

Also with #4, I have no problem making nedjo a full co-maintainer of Features to facilitate getting the best work together on this. I know nedjo and I are both open to working well together. But we welcome comments from the community.

nedjo’s picture

Issue summary: View changes

I'm leaning towards merging this work into Features, but I want to pause first and explicitly discuss project principles.

I've had a crack at capturing in the ticket body (and in the documentation) the principles I've brought to Configuration Packager. Mike, it would be great at this point if you could comment on each one. How good a fit is it with what you have in mind for Features in Drupal 8? Are there principles you have in mind for Features that aren't captured here? This should help us focus in on just what we need to work through.

I've also begun to sketch in some idea of the steps that would be involved in merging this into Features.

nedjo’s picture

Issue summary: View changes

Updating the list of principles.

nedjo’s picture

Issue summary: View changes

Add principle "Work with core".

mpotter’s picture

I think this is great! Getting the principles into the open like this isn't something I've seen before, but I'm all for it. Here are my comments on them:

  • Interoperability baked in. I'm honestly not sure I fully understand this one, so maybe elaborate?
  • The site/feature set as a whole. Yes. Existing exported "feature modules" are being detected with a new Assignment plugin (AssignExisting). All site config is accounted for and only lives in one place. Packages not exported to a module are still shown in the package list (as "not exported"). However, creating and editing individual features are still a primary focus of Features, which is ultimately what is being added to config_packager.
  • Work with core. Yes, I agree. A "feature module" should be able to be installed on a site without the need for the Features module just using the core installer, assuming the site doesn't yet have the configuration from the Feature. So either it is installed on a clean site, or as part of an install profile. Any workaround to the config installer within Features is only for working on the dev site where the feature is created to get around limitations of core (since the site already contains the config). However, I can forsee a need for a way to override existing config that might require a module other than core. But this needed module should not be the full Features module.
  • Packaging problem only; best shared solutions. Yes, the core Features module should be focused on this use case. However, there might be optional submodules that add other functionality or encapsulate modularity. Such as putting dev-only functionality into a features_devel module. (see modularity below).
  • Comprehensive test coverage. I'm all for it, but we will need community help on this one. Like you, I'm not the greatest at PHPTest (no Simpletest here). This should be required for a stable release but not for initial dev work. Typically I like to see unit testing when a project gets into Beta status.
  • Core-worthy quality. Absolutely. Although while in dev I don't agree that we need to leave out all experimental code. There are many tough problems to solve and we need to get them into proposed code for people to test, refactor, etc. If it's not in the code then people can't help refine it. Assuming the functionality being addressed has been agreed to be needed as part of Features. We can also use other branches for "big experimental things" if the need arises.
  • A issue for every change. Ultimately yes, but things are going really fast right now and I have a very limited timescale to help out with this. I will try my best to work in the issue queue, but I won't be waiting for every trivial change to be approved as a "patch" before committing. This might be the main point of contention in terms of our workflow: If you are not comfortable with me or you both committing code quickly to this project then it might be better to work separately. I literally have 2-3 weeks to get this all working.
  • Maintained on Yes, definitely.
  • Developer-only toolset. Well, I see it as a "site-builder-toolset". To me a Developer writes PHP code and a Site Builder just uses the Drupal UI to do stuff (Views, Content Types, etc). Any dev-only stuff, like drush commands will go into a features_devel module. The Site-builder UI will be modularized into a features_ui submodule. None of these modules will be required to use a package on a client site unless we start getting into the realm of overrides and such or unless there is a real blocker in core we can't get around.
  • NEW PRINCIPLE: Modularity. I'm adding this one. I want to keep things as modular as possible via submodules. For example, there is functionality in config_packager that not every site will need (auto-assignment, archive generation). The core module should provide the plugin classes and any required methods and leave submodules to implement the optional methods. For example, the interface for generation plugins should be in core Features, but the "write" method should be part of features_devel and the "archive" method should be in an optional features_export (name?) submodule.

So, I think we are on the same page. The question remains as to how fast we can work together on this. Honestly, I am already past the initial refactor stage so I'm going to need to step back a bit to adhere to your proposed migration plan. I can talk more about that in a separate Migration to Features issue. I agree with the philosophy of the steps even though the reality of the conversion has been a bit rockier.

mpotter’s picture

I actually thought of another principle that I just realized is driving my work:

  • Some "compatibility" with Features 7.x. I don't mean true compatibility here, but I'm talking more about translation of concepts. In Features D8 I still want to have the following concepts (and corresponding drush commands):
    1. Features List. Shows a list of packages/features. Makes it clear which ones have been exported and which of those exported are enabled. Be able to see what config is within each package. For later extension: show which config has been changed compared to the exported code and provide a revert option (via config_update?)
    2. Features Export. This was "drush fu" features-update in D7. This is the "package generate" in config_packager. I prefer to use the terms "import" and "export" in Features D8. I want to get away from the "update" and "revert" terminology in D7 that came from Views/Ctools since it was confusing. I think import/export make more sense to people. config_packager is doing the export. config_update is doing the import.
    3. Features Import. This was "drush fr" features-revert in D7. It's the config_update in D8. Updating the config active store with the new state of the module config.
    4. Features Diff This is also provided by the config_update API. The current UI for reports is highly confusing and I will likely recommend the report UI page be made optional in config_update. But Features should wrap that in it's UI and drush commands
    5. Features Add The ability to add a config to a package, currently in the config_packager API but not in the UI or drush.
    6. Features Remove Removing a config from a package. Again, in the current config_packager API

My main principle here is providing a single interface (UI and drush) for accessing the package system. A "wrapper" over other modules such as config_update. If config_packager was kept as a separate module, Features D8 would still do the above and call config_packager commands. The advantage of merging the projects is reducing the duplicate commands and UIs and giving site builders a consistent config interface.

The mapping between Features functionality in D8 back to D7 will help people from D7 understand how to do Features in D8. In fact I think there is even the possibility of pasting a D7 file and having D8 create the equivalent package pretty closely (might be another Assignment plugin)

nedjo’s picture

Issue summary: View changes
Status: Active » Reviewed & tested by the community

Thanks for your detailed response here Mike. Further discussion is very welcome and there are still some details we can work through. Overall, though, I'm satisfied that we have what we need to move forward. Marking RTBC. Let's move ahead!

Some selective comments.

Interoperability baked in. I'm honestly not sure I fully understand this one

I've updated that principle to include a link to the relevant documentation page. Does that help?

Core-worthy quality.

Everything you put here works for me.

A issue for every change

I partly mean, broad issues that speak to a whole area of refactoring. The key point is (a) we can see what commits go together (they refer to the same ticket) and (b) we can put a summary in the commit message but have a ticket where more details can go, even if that's as possible followup after the fact.

Developer-only toolset. Well, I see it as a "site-builder-toolset"

Yes, that's what I mean too, and it's a lot clearer than what I had. I'll change that in the documentation page.

NEW PRINCIPLE: Modularity.

I agree with the principle. Just how to structure the modularity will take careful thought. I'm inclined to think that, in the short term, given the time crunch, we should keep the structure as it is and refactor only if we're making significant changes that trigger or require a specific type of refactoring. Then, when the basics are in place, we'll be in a better position to work through how best to design modularity while respecting the other principles captured here.

Some "compatibility" with Features 7.x.

Agreed. Because Drush supports multiple aliases per command, we can consider keeping some legacy commands or their aliases without preventing changes.

TBD: any integration with

nedjo’s picture

Status: Reviewed & tested by the community » Fixed

I merged the additional principles into the Features 3.x documentation page at

We're done here--great work!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.