When a module/theme/profile (extension) is updated, sometimes it may update/add/delete its default config items in the config/install directory.

Currently this has no effect, because config/install is copied into your active config at install time (or possibly when another module it depends on is installed), and never looked at again.

However, it may be useful sometimes to update config, "revert" to the provided config, or add new provided config. Use cases:
- Views UI - in 7.x it had a "Revert" button that would revert a view to its code-provided value. See #1790398: Re introduce revert functionality for views using the config system
- Tour - if a module you already installed adds or updates a tour because it added/changed functionality, you'd want the new tour probable. See #1924202: Provide a method for end users to be notified on new/update tips.
- The proposed Configurable Help Topics in the currently-sandbox contrib module (didn't make it to Core) also need this, for similar reasons to Tours (they are documentation provided by the module/theme):

Proposed resolution

End goal

a) Users at need to be able to tell that an extension has changed, added, or deleted default config that it at one time provided for import into the site config.

b) In the case of changes, there should probably be a way for them to view a diff between the config currently in their active config and the version in config/install of the extension, and there should be a way to import the new version. Or they can do nothing and keep their configured version.

c) In the case of additions, there should be an easy way to import the new config.

d) In the case of deletions, they probably just need to be able to discover this, since they can delete config items using the providing module's UI presumably.

How to do it

#2371439: Figure out what to do when module updates configurable topic in the issue summary suggests several approaches.

The only really viable one, I think, is to make a report that will check for differences between config items on your site and config items in config/install directories.

It would tell you which items are different from the ones on disk, if there are ones on disk that are missing from active config, and if there are ones in active config that do not exist on disk.

Then it would give you a way to import the missing ones, and view differences and/or import/replace the different ones.

Remaining tasks

Get this into Core eventually? For now the report approach exists as a rough contrib/sandbox at

User interface changes

Admins will be able to discover config updates and choose what to do about them.

API changes


Original report by @heyrocker

In order for this to work, we will need to link live config files back to their module-supplied defaults somehow. This will be a followup issue when the original patch lands.

#18 config_revert.patch25.39 KBjhodgdon
Members fund testing for the Drupal project. Drupal Association Learn more


sun’s picture

Title: Create ability to detect if a module-supplied config file has been changed, and ability to restore from that original » Detect if default configuration of a module has been changed, and allow to restore to the original
Project: Configuration management initiative » Drupal core
Version: » 8.x-dev
Component: Code » configuration system
Issue tags: +features, +installation profiles, +distributions, +Configuration system

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’s picture

just a note that this assumes a static default, so will not cover any module that inspects the state of Drupal (like, say, the list of filters, node types, views etc) and adds a default for each (or any variation on this theme).

so, while this is worth doing, we need to be clear that there is no such thing as 'restore to default' that will work for all modules just based on some files.

sun’s picture

@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. ;)

beejeebus’s picture

actually, #2 is pretty stupid now that i reread #1. i was trying to make the point that files in 'mymodule/config' will not cover all the default configuration installed by modules.

so any scheme that relies on the files in 'mymodule/config' will be incomplete. but, you seem to have a more limited scope in mind for this anyway.

xjm’s picture

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.

gdd’s picture

Status: Active » Closed (won't fix)

I think I've come to the conclusion that this doesn't really make any sense, as echoed by some of the other comments above. Marking won't fix but happy to listen to other arguments if anyone disagrees.

David_Rothstein’s picture

Category: feature » task
Priority: Normal » Critical
Status: Closed (won't fix) » Active

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.

gdd’s picture

Priority: Critical » Major

This was removed as part of the initial CMI patch (#1270608: File-based configuration API), which did the first conversion of image styles (before they were again converted to Config Entities.) I had thought there was discussion of that in the issue, and that it made it into the initial change notice, but it appears that neither are true. Basically, the old 'revert' functionality was very much tied into the old 'overridden' functionality, neither of which made sense in the context of the new API.

I still don't think revert to default is highly important, and we don't have a way to really differentiate between 'module-supplied' configuration (which you could revert) and configuration created through the UI (which you can't.) I downgraded this to major to split the difference.

mikeryan’s picture

Issue summary: View changes
Issue tags: +DX

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?

brantwynn’s picture

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.

YesCT’s picture

Issue tags: -DX +DX (Developer Experience)
jpalala’s picture

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.

jhodgdon’s picture

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.

nedjo’s picture

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

jhodgdon’s picture

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.

jhodgdon’s picture

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:

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.

jhodgdon’s picture

Version: 8.0.x-dev » 8.1.x-dev
Component: configuration system » config.module
Category: Task » Feature request
Issue summary: View changes
Status: Active » Postponed

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 ). 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.

jhodgdon’s picture

25.39 KB

@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.

jhodgdon’s picture

The sandbox module has matured quite a bit. It's still at

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.


jhodgdon’s picture

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. 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.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jibran’s picture

Status: Postponed » Active

Should we move this as a experimental module?

james.williams’s picture

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?

jhodgdon’s picture

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... ... 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.

catch’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: config.module » Idea

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.

yoroy’s picture