Revert all features in D8

That was an intended omission.

In D8, you aren't really "reverting" a feature, you are importing config from a module and overwriting the active config. A Feature is no longer anything special...any module can have config. The concept of "revert all" was always very dangerous in D7.

In D8 when you are working with your entire site config, you are supposed to use the D8 CMI system to sync your config to the file system and perform full imports and exports. That's how you *DEPLOY* config in D8. You no longer use Features to deploy config. You just use features to package your config into normal modules.

CMI already provides drush commands for doing full export and full import of config. You might also check the config_update module that is used by Features since it also has some drush commands. But we removed "feature-revert-all" from Features specifically to encourage people to use CMI for config deployment and stop using Features for that.

To be a bit clearer, here is how the workflow should be in D8:

Creating initial config:

1) Use Features to organize your config into modules.
2) Push feature module code into git repo
3) On Staging server pull the repo, enable all the modules. Initial config will be loaded.
4) On Staging, use CMI to export all config
5) Pull both code and config export to production
6) On Prod, import all config.

Making a change to Feature(s)

1) On your Dev, update the feature code, push to your repo
2) On Staging, pull the code and import/revert the feature
3) Once tested, use CMI to export all config
4) On Prod, pull code and config
5) On Prod, import all config

So you are only using Features on your Dev and Staging server, not on Production. On Staging you are importing/reverting just the features that have been changed. You don't necessarily want to import/revert everything because you are testing specific changes like pull requests etc.

I was going to do a DrupalCon session on all of this, but it didn't get accepted :(

Or you can also write an update hook to import that specific config that needs to be changed.

Again, doing a revert-all was very dangerous and led to people losing other changes to other features/config on the site. If you only changed a certain feature then you should only be reverting that specific feature, not doing an "fra"

This is probably a bigger discussion for the CMI people. The whole design of CMI in D8 says that your site owns the config, not the modules. Features is making an exception to that. And while it might be convenient, we'd like to get away from having Features module enabled on Prod servers.

So are we saying that CMI missed the important case of multi-site where doing the recommended CMI export/import deploy is too cumbersome? Are we just using Features because that's what we are used to doing in D7? Or are we missing the "D8 CMI way" of doing this?

Configuration Synchronizer is a small step in the direction of reverting all features (and other extension-provided configuration). I've got ideas of how to expand the start I made but haven't dug into them yet.

I can see how this could be useful.

While the fra alias can be retained for backwards compatibility, this new command should be parallel to the existing features-import, and named features-import-all.

We'd need to clarify what's meant by "all". All features in the current bundle? All installed features in all bundles? Likely we should have a bundle argument. Should also support the 'force' option like features-import.

Dane: I guess I'm still missing something here with your use-case. How is doing a "drush fra" any different than doing a "drush config-import"? You say that with config-import you have to do it for each site, but don't you need to do it for each site with "drush fra" also? A "drush fra" is essentially doing the same thing as config-import. The only difference is that fra is reading config from modules and config-import is reading config from the wherever the config-sync directory is located. If you put the config-sync directory into your repo it seems like that's the same thing as loading config from modules in the repo.

In any case, I can see the connivence of this if bundle support is added. Then you could put features you want to revert into one bundle and put features you don't want reverted into a different bundle. What I'm trying to stay away from here is the mess we got into with D7 where people complained about drush-fra and then added the ability to "lock" certain features so they couldn't be reverted, and then people wanted to export that "lock list" as yet another feature.

I think this is a good start, but I'd still love to see a --bundle option that only loops through packages within a certain bundle instead of all packages. I think that would go a long way to alleviate some of the past issues with features-revert-all losing config changes.

OK, I've gotten several other requests for this, so going to RTBC this. Will look at bundle support in the future as a separate enhancement.

Committed to 30d793a.