Allow synchronizing config entities from default config when modules are updated

Related/duplicate issues:

#1398040: Detect if default configuration of a module has been changed, and allow to restore to the original
#1515312: Add snapshots of last loaded config for tracking whether config has changed
#1497268: Add revert functionality to Config entities

The current configuration system does not have any knowledge of whether a config object is "overridden" or not.

Since there is no "overridden", this issue doesn't really make sense right now and can only be postponed on whichever issue that may or may not introduce the concept in the first place.

#1515312: Add snapshots of last loaded config for tracking whether config has changed is the issue this is postponed on.

really, this isn't even a question of 'overridden'. it's more complex than that. this is a question of how we reconcile upstream config changes that are potentially divergent from local changes made by a sitebuilder on his or her own site.

certainly, the notion of overridden vs. code vs. db-only that ctools formalized is a good distinction, and one that's helped us come a long way. but it's a concept that is suited to a single, conceptually linear scope. most of the time, that means one Drupal installation, potentially across multiple instances/versions of that install (e.g. dev, stage, prod).

different user action is often needed when updates are received from upstream vs. from colleagues. but because there is no concept of where the changes originated, only that there ARE inconsistencies between one or another of the storage formats, the tool does not expand well (at all) into covering multiple scopes at once. and while it's been sorta-ok-enough with features (depending on how invasive they are), i think that with Views going into core (and Panels effectively, too, which has even more subtle needs in this respect) we'll turn the corner into really problematic territory if we don't provide the capacity for reconciling these divergent revision histories.

plus, life will continue to be hell for people who make AND customize distros, as they are already trying to straddle this multi-scope config gap.

i think it's probably a good thing that the config system isn't directly concerning itself with this question of ancestry. strikes me as something that belongs in a separate layer, anyway.

of course, that's said with only a cursory understanding of the config system. i have no idea if it's designed in such a way that'd make doing it in a separate layer feasible.

regardless of where it's done, though...maybe i need to figure out how to explain the problems better, because i see this as something that if we don't have at least a clear path forward for, we'll find ourselves seriously choking on it in a couple years.

strikes me as something that belongs in a separate layer, anyway.

Absolutely. In fact, we're exclusively talking about Configurables thus far. I haven't seen anyone mentioning a need for tracking/syncing the state of static config objects (à la settings) yet, and I doubt that there are many use-cases for that.

Which, in turn, brings us into the ConfigEntity scope (which is == Configurables, I just still like that name more in communication), and one way to approach it would be to create a new OverridableConfigEntity that extends ConfigEntity and implements something alone the lines of Config\InstallStorage — i.e., built-in support for looking up config objects in the ./config directory of the owning extension, additionally taking installation profile overrides into account.

How and where to get the info for as to what config objects are to look up in which extensions though, I don't know. We certainly can't do a full filesystem scan in all extensions for a default config object on every lookup. (OTOH, results are cached, so perhaps we can.)

What this inherently breaks though is the staging/import mechanism, since that can only reasonably be aware of config that lives in the active/staging config directories.

So it might further leverage the config system's ability for contextual overrides; i.e., the same mechanism that is applied for localized/multilingual configuration (overridden config objects being stored in a ./overridden subdirectory). Though I'm not sure whether that's a good idea, just throwing it out there for now.

I did not think this was something we were going to support. Especially given #2233787: Move default configuration into extension/config/install to clarify its purpose, it would seem confusing to have updated config come from the config/install directory. Adding a config/update would be even more confusing.

Perhaps I'm missing the point, but it seems to me that if a module really wants to change it's config it should happen in an update hook.

@mtift: Yes, that's whole point of this issue. The issue summary only talks about module updates.

There is no facility that would allow a module to actively read (or sync) from its default/install config directory in module updates.

At this point, you are forced to manually re-create your default/install config in the PHP code of your module update function (unless you figure out a complex one-off hack to read your module's default/install .yml config).

But more importantly, there is no "overridden" flag for config entities currently. Therefore, if your module update intends to perform a change to improve sensible defaults, or perhaps even to change a bad configuration value to fix a security problem, then it has no knowledge at all whether the current active config still represents the original defaults, or whether something has been explicitly + intentionally customized.

IMO, this should be bumped to a critical beta blocker. But apparently there's heavy disagreement on who's eligible to tag an issue as beta blocker.

Thanks for clarifying. I agree that sounds like a big problem. So it seems like this issue, or one/more of the related issues, should be part of #2187339: [META-0] CMI path to beta.

I do not think this is a different issue from #1398040: Detect if default configuration of a module has been changed, and allow to restore to the original, so I am provisionally marking this as a duplicate.