Download & Extend
Issues

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

Posted by heyrocker on January 8, 2012 at 8:36pm
Project:Drupal core
Version:8.x-dev
Component:configuration system
Category:task
Priority:major
Assigned:Unassigned
Status:active
Issue tags:Configuration system, distributions, features, installation profiles

Issue Summary

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.

Login or register to post comments

Comments

#1

Posted by sun on June 1, 2012 at 6:25pm
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:<none>» 8.x-dev
Component:Code» 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.

#2

Posted by beejeebus on June 2, 2012 at 8:32am

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.

#3

Posted by sun on June 2, 2012 at 10:37am

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

#4

Posted by beejeebus on June 2, 2012 at 11:05pm

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.

#5

Posted by xjm on September 6, 2012 at 5:10pm

See: #1776830: 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.

#6

Posted by heyrocker on November 11, 2012 at 8:16pm
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.

#7

Posted by David_Rothstein on December 8, 2012 at 9:27pm
Category:feature request» 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.

#8

Posted by heyrocker on December 9, 2012 at 2:20pm
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.