Detect if default configuration of a module has been changed, and allow to restore to the original

Moving into core queue.

1. I guess this hints at "feature modules"?
2. For "regular" modules, I don't think this makes sense. The default configuration is totally irrelevant after initial import.
3. Where it might make more sense is distributions / installation profiles.

   (mainly thinking of update functions and upgrade paths of profiles/distros to figure out whether it is safe to change/replace/update a certain config object to a newer version of default config)

A basic "revert" functionality will have to be a follow-up to #1447686: Allow importing and synchronizing configuration when files are updated but will affect file/active stores only.

@beejeebus: Can you clarify a bit what you mean? Read it twice and tried to wrap my head around it, but didn't understand what you were trying to hint at. ;)

See: #1776830: [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API (Edit: I linked the wrong issue at first.)

For that issue, we need to decide what our expectations are when:

1. A module is installed and provides a default configuration (e.g. a view) that can exist independently of that module.
2. The user makes changes to that configuration.
3. The user uninstalls said module.

Should we be deleting the user's updated view when it differs from what the module originally provided? Edit: The answer might be yes, but it might also be good to inform the user.

I was just looking into #1833028: Impossible to revert image styles when using PHP 5.4 (Drupal 7 bug) and it appear that in Drupal 8, the feature which allows you to revert image styles has completely disappeared?

I don't see a change notification for that, though, or much discussion... but this seems like the issue to discuss it.

A +1 for the ability to revert to a module's default configuration. The lack of reversion means that a module developer testing a configuration change must uninstall and reinstall to see the results, which is a PITA if all you're doing is, say, modifying a label.

Reading here and and #1497268: Add revert functionality to Config entities I see the difficulties in the general case - this would be a power tool, not something exposed to general site administrators. So, suppose the API supported it but no UI in core - leave that to the devel module?

I agree with the sentiments in #9 - this is really a DX issue. It COULD be used for "Features" type deployments of config but I think the main problem is that its really just a DX pain to have to drush pmu and drush en over and over when working on default config for a module.

CMI shouldn't be so very complex - thinking out of the box (if that's allowed) this should be handled by git. It would depend on the philosophy of modules however - which is have everything configurable via interface. If you really want this, you could have an interface to git handled by a separate module or maybe that interface should be drush. Not sure if drush is going to be working on something related to version control yet, as far as i can tell it would be awesome to do something like "drush git restore" or something like that.

I've been thinking about this issue today on #2371439: Figure out what to do when module updates configurable topic. The ability to do something sensible with Help Topic config entities when a module updates its help topic is one of the things that caused my Help Topic proposal to get pushed into contrib for now and/or 8.1.x maybe later.

I came up with a plan there for how to do this for help topics. I think Tour also needs this type of functionality but I'm not sure about that.

Also I just marked #1620140: Allow synchronizing config entities from default config when modules are updated as a duplicate of this issue... at least I am pretty sure they are the same issue.

Configuration Refresh appears to implement some of this. Currently it's marked for merging into Configuration Development.

I'm not sure if either one of those modules is really what is needed here. Based on the project pages, it looks like Configuration Refresh does batch export by module or by config entity type, and Configuration Development does some export/import on every page request and provides some development tools.

What I think we need here is a UI that lets you see which config entities of a particular type are different (or missing) from the versions that are provided by a module/theme/profile, and lets you revert or import them individually if you want to.

I needed more or less this functionality (since there is no issue summary, hard to say if it's actually the same) for the Configurable Help module, so I went ahead and built it today in a sandbox project:
https://www.drupal.org/sandbox/jhodgdon/2391835

The approach I took was to make a report that will tell you about new/updated/removed default config when you update modules or themes. From that report, you can do various actions, like export your current site config, view diffs, and "revert" to the config currently being provided by a module, theme, or your install profile. I think this is much more useful than having some kind of wholesale "accept updates" functionality.

It would not be difficult to convert this to a patch and add it to the Config Manager module, but I think it's probably a feature at this point and therefore non-beta territory, even though this issue has category "Task" right now.

Anyway, if anyone would like to try it out, it does work. File issues if it doesn't. I'm sure the UI could be improved and I haven't written tests for it yet.

And if you want it as a core patch, let me know and I can do that.

I discussed this with catch in IRC just now.

Our conclusion is that this is probably a Feature Request, and therefore should be postponed to 8.1.x (we are in beta, see https://www.drupal.org/contribute/core/beta-changes ). I think it should also be in config.module not config system. So, I'm updating the status etc. of this issue.

I've also added an issue summary outlining the approach of the sandbox module.

@catch also asked me to upload a patch that would add this to Core. THIS IS NOT REALLY READY.

If/when we do want to add this to core:

a) There will most likely be updates in the sandbox (which should become full contrib module sometime), so don't use this patch.

b) Check the issue queue for the module.

c) This should probably be added to the existing config.module rather than being a separate module.

But catch asked me to upload this patch anyway so that there would be a patch here.

The sandbox module has matured quite a bit. It's still at https://www.drupal.org/sandbox/jhodgdon/2391835

I'm still wondering if getting this into Core might be a good idea. If we add it to core, the patch in #18 is not the current code, see notes in that comment. There are a few Core issues that having this in Core would resolve; they're listed in the summary already (adding here as Related Issues as well).

If the sandbox module stays as Contrib, I will need to promote it to a full project soon, and I may also change its short name since it's not really about Reverting so much any more as reporting on what has been updated.

Thoughts?

Since this is currently (and properly) a feature request, and hence postponed to 8.1.x, I went ahead and promoted my sandbox to full project and plan to maintain it until such time as it may be added to the Core config manager module. https://www.drupal.org/project/config_update if anyone needs this.

Thanks to @nedjo, who has been using this module and filing issues, I think it's unlikely to change much from this point on, and it's quite usable now, so I even put out a -dev release. I'll wait to make a real 8.x-1.0 release until 8.0.x gets closer to being 8.0.0. I'm also not going to bother making another patch here until we get to 8.1.x time.

Should we move this as a experimental module?

That would be fantastic, though I don't know what the criteria for bringing new experimental features into core is?

Though there's also interesting discussion in #2413583: Integrate diff and revert into native config listings about actually supporting reverting in core.

To be honest, it feels to me like much of this sort of thing is blocked on #2388833: Pull reusable routines out of configuration import/export form builders anyway though, as core's config API should be improved to be more reusable by other modules (whether they be contrib or experimental core ones). Does anyone fancy reviewing / progressing that ticket first?

The Config Update Manager module has come a long way since the last post here. It now has a base module, which I think Features depends on, and a UI module, which does the reports about which config items has changed.

Take a look... https://www.drupal.org/project/config_update ... if you want it in core that would be fine but I am not willing to be its Maintainer in Core ... just not doing that any more.... You could ask Nedjo.

I'm not sure if this needs to go in the ideas queue, but since it'd probably be an experimental module based on config_update, moving it there - we can always move it back again.