Faciliatate customization of reports, e.g., distinguishing edits from extension changes

That is way beyond the scope of this module and not something I'm willing to add. This module is not going to be Features. Site owners or developers will need to make their own decisions on what the differences mean and whether they want to upgrade, and module developers will need to make their own decisions on whether config changes and additions are essential (in which case they'll need to make an update function that would update it) or not.

By the way, I think that the tools in this module should hopefully be modular enough that another module that wants to be Features should be able to use for instance the ConfigDiffer class/service to help. And I'd be happy to add a hook to this module that would let other modules extend the list of operations available in the reports, and things like that, if that would help.

But I really think that storing the contents of config files is not a road I'd like to go down. That is a good use case for storing the config in files and using git diff. Making decisions about where differences came from is just not something the Config system is equipped for.

OK I'll open this back up as "needs more info". If you think of a hook that should be added, post here.

Um. Are you talking about #2407609: Coordinate configuration development?? You linked in #5 to this issue here. Oops. ;}

I would recommend that people look at diffs to decide themselves if configuration can be reverted, rather than trying to "lock down" some config. It just seems like locking things would introduce complications in trying to maintain a site.

However, if someone did want to lock things down, I could envision that this module would have a hook something like hook_config_report_actions_alter(), which would ask modules "Here's the list of actions for each config item in this section of the report. Do you want to modify the actions?" and let them either add or remove the actions. That would allow the "lock down" module to say "don't allow revert", and the Foo Bar module to add its own action.

I'll take a look at that. Obviously, not something I was aware of. Thanks!

I took a look at the snapshot subscriber.

What it actually does is that each time config is imported, it clears out the previous snapshot in the "snapshot" config storage, and then saves a complete snapshot of all the current config.

I don't think this will acually help to figure out the reason that particular config has been updated. Consider this scenario:

a) On Monday, I install the Views module. Snapshot is created.

b) On Tuesday, I edit a View.

c) On Wednesday, I install the Foo module. New snapshot is created.

d) On Thursday I go to the config report from this module. It tells me this view differs from the version that is currently being provided by the Views module. However, the current config is the same as the latest snapshot. So, all I know is that it hasn't been edited since the last time a snapshot has been created. Which does not tell me the truth in this case, which is that the reason it's edited is that I edited it. In fact, it would lead me to the opposite conclusion.

So... I fail to see how this helps.

Actually, it's even worse: it looks to me as though these snapshots are only created during a Config Synch operation. So they may not even be made when you update a module.

I think I should really rename this module, actually. To call it "revert" is not really right... It should probably be "Keep track of config updates" or something. Maybe I should also call the links "Update to source" instead of "Revert to source", just like the report is titled "Config Updates", because it's probably usually about updating to the latest version provided by a module rather than reverting your edits, although it could be used for both.

But in any case, I really do think that human judgment is always going to be needed in order to decide whether some particular config object that differs from the module-provided value is something you want to update/revert to or not.

I do not think that this is going to be possible. Have you looked at the report, even just after doing an install with the Standard install profile? Even before you start configuring the site, there are a lot of config items that have been updated by the profile or the install-time settings. Sorting this out programmatically is not something I think is even possible. There are too many reasons it could be changed (module did something at install time, user edited it, module put out a new version, a different module changed it when it was installed, a module changed it when it uninstalled, etc.), and software is never going to be able to sort it out. At least, I don't think so.

Which is why I decided that the only real feasible thing was to at least provide a tool so that a knowledgeable user could figure out what was going on and do something about it. Yes, a user would have to be "advanced" in order to use it, but without this module that user doesn't have any way to manage this situation.

I think you meant to add the comment above to your "do bulk" feature request issue, not here? Or were you just saying "thanks for making your classes usable"? :) If so, you're welcome!

OK, keep me posted.

After may years, still won't fix.