When modules include config in their module/config directory, this is copied to the primary config store as part of the module install.

However, there is currently no process to repeat this when modules are updated. For Views this is going to be very important.

Let's say I have project.module, and it has a whole host of views. I update one of those views in the module, and then release that module. Users of project.module update. In the current world, if you have modified the view (i.e, it is overridden) then nothing happens. If you have not (i.e, it is "in code") then you get the new view as soon as caches are flushed.

This is a critical feature that allows us to ship views with modules and expect them to behave appropriately if the administrators have not changed them.

Comments

sun’s picture

Category: task » feature
sun’s picture

Status: Active » Postponed

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.

tim.plunkett’s picture

sdboyer’s picture

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.

beejeebus’s picture

Status: Postponed » Active

i'm not sure why this should be blocked on #1515312: Add snapshots of last loaded config for tracking whether config has changed.

that issue has a much narrower scope, and should land independent of the whatever we decide here.

re #5, i'm not sure i understand the issues entirely. we currently don't really support any concept of overridden - we just copy over $modulename/config so the sites config directory - we don't track changes from the module defaults in any way.

also, remember that stuff in $modulename/config doesn't cover all of the concept of default - modules will create config at install time dynamically. like, if a module changes the config for each content type/view etc, or adds a $foobar.thing.yml file for each content type view etc.

sdboyer’s picture

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.

sun’s picture

Title: Allow synchronizing from default config when modules are updated » Allow synchronizing Configurables from default config when modules are updated
Issue tags: +Configurables

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.

mtift’s picture

Issue summary: View changes

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.

sun’s picture

Title: Allow synchronizing Configurables from default config when modules are updated » Allow synchronizing config entities from default config when modules are updated
Category: Feature request » Task

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

mtift’s picture

mtift’s picture

jhodgdon’s picture

Status: Active » Closed (duplicate)

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.