Add a new method to the DrupalConfig class that allows you to revert to the default provided by the module. This basically replaces variable_del from Drupal 7 where variable_del was being used to revert back to the default provided by a variable_get.

Sample usage:

  $config = config('aggregator.admin');
  $config->set('aggregator_fetcher', 'test');
  $config->save();
  $config->revert('aggregator_fetcher');
  $config->save();

This patch requires that a config object / file is named module_name.config_space.xml so that we can work out which module is providing the defaults.

Comments

alexpott’s picture

Patch now has tests and fixes a php warning it was causing.

This approach might not correct as it introduces a dependency on the name of the config file and module. The better option is probably to scan the directory for the file.

sun’s picture

Issue tags: +Configuration system, +VDC
vlad.ilyich’s picture

possibly stupid comment - don't we need to be mindful of the fact that not all default configuration at module install time is not convered by what's in the file? any module that checks the state of say, installed views, or content types, or roles, or image styles, or ..., and provides a different install time default based on that?

checking files to revert to a default will surely cover some cases. perhaps we need to fire some code here?

tim.plunkett’s picture

Status: Active » Postponed

I'd think this would be better served using whatever comes out of #1515312: Add snapshots of last loaded config for tracking whether config has changed

sun’s picture

I may be mistaken, but I think that the Config class is the wrong place to add a revert method.

We already discussed the sense and nonsense of a revert functionality in:
#1398040: Detect if default configuration of a module has been changed, and allow to restore to the original

So I think that, if at all, then a revert method belongs onto ConfigEntityBase. (which sorta ties into #1642062: Add TempStore for persistent, limited-term storage of non-cache data instead of reverting to default config)

jibran’s picture

Status: Postponed » Active

as per #4

heyrocker’s picture

I talked to timplunkett some time back when we were working on #1515312: Add snapshots of last loaded config for tracking whether config has changed. So one thing is that not everything can be reverted. For instance many field-related changes can not be undone (they change data irrevocably.) This means in order for revert to work at all, we need to add the concept of things that can and can't be reverted. We both agree with sun that this should be added on ConfigEntityBase, then the individual implementations can decide whether to use it or not. This would be similar in approach to #1826602: Allow all configuration entities to be enabled/disabled. I know he planned to work on this for Views so I'll check in with him to see what his status is.

tim.plunkett’s picture

Assigned: alexpott » dawehner

I'm pretty sure dawehner had code for this in a sandbox, I'm not sure how functional it was. But yes, what @heyrocker said is accurate.

dawehner’s picture

I know damian started on #1790398: Re introduce revert functionality for views using the config system but now I'm currently working on a generic functionality for the config entity, not specific for views.

dawehner’s picture

FileSize
3.85 KB

Just some basic outline what tstoeckler and I have in mind:

  • Add a revert method on the ConfigEntityInterface
  • Add a RevertableEntityStorageControllerInterface which allows to revert() and find out whether a certain entity is overridden().
    You don't want to couple that directly to the ConfigStorageController, as this is not what we want all the time.
  • To find out whether something is overridden, we can use config_get_changes, though in order to have this loaded lazy/make easy, we could store this information in the manifest file, during save, and use that information.

What do you think about that in general? Just posting random code.

ianthomas_uk’s picture

I have been advised that for configuration sets with variable names (e.g. \Drupal::config('menu.entity.node.'.$content_type')), defaults should be provided via hooks (in the case of the example by implementing menu_content_type_insert and menu_install).

If this is best practise, then any patch for this issue needs to take that into account.

pfrenssen’s picture

We now have StorageComparer which we can use to check if something is overridden.

beejeebus’s picture

Title: Add revert function to the DrupalConfig class » Add revert functionality to Config entities

there is no DrupalConfig anymore.

if this really is for Config, then i don't think we want it.

if it's for ConfigEntities, meh, i don't have strong opinions.

mtift’s picture

jhodgdon’s picture

Issue summary: View changes

Is this still on the table?

dawehner’s picture

Assigned: dawehner » Unassigned

I don't know to be honest. (unassign from myself)

Note: For some usecases of revert you can use config_devel, which reverts all the changes to the config files for you.

jhodgdon’s picture

See also https://www.drupal.org/sandbox/jhodgdon/2391835 - a sandbox module that has config revert functionality.

jhodgdon’s picture

Version: 8.0.x-dev » 8.1.x-dev
Category: Task » Feature request

I was looking at this issue and other Core issue to see whether my sandbox (see previous comment) should/could be added to Core to resolve them. But the others, and I think this one too, are really feature requests. So given where we are in the cycle, I'm afraid this is 8.1.x... "Add functionality" to me sounds like a feature request?

tkoleary’s picture

Added to config management usability meta #2642404

tkoleary’s picture

jhodgdon’s picture

By the way, if anyone wants to pursue this issue further... the (currently contrib) Config Update project has some code to manage diffs and revisions in it:
https://www.drupal.org/project/config_update

It is fairly well developed, and has an 8.x full release now. There are services for diffing and reverting in the base module, which is being used by several other contrib modules like Features that are related to config management. There is also a UI module in the project that has UI for reports, diffs, and reverts.

xjm’s picture

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.

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.