Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
- This stack of operations breaks the originally intended goal of being able to diff configuration files via git/$vcs:
$config = config('image.style.foo'); # yields: # name: foo # effects: # flow: # upsidedown: 2 # slide: # left: yes // Remove the flow effect. $config->clear('effects.flow'); $config->save(); # yields: # name: foo # effects: # slide: # left: yes // Decide to re-add a flow effect. $config->set('effects.flow', $effect); $config->save(); # yields: # name: foo # effects: # slide: # left: yes # flow: # upsidedown: 2Hint: 'flow' was in a different spot before. Thus, this produces the diff:
--- image.style.foo.yml +++ image.style.foo.yml - flow: - upsidedown: 2 slide: left: yes + flow: + upsidedown: 2 - Most of the configuration cannot rely on the defined order in config objects, because the order is arbitrary, so we're using 'weight' properties in sub-keys either way when data needs to be used in a certain order at runtime.
Goal
- Find a solution that prevents the config files from being different, while holding identical data.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | config.next_.sortkeys.9.patch | 2.66 KB | sun |
| #2 | drupal8.config-file-diff.2.patch | 699 bytes | sun |
Comments
Comment #1
sunComment #2
sunThis would be one way to approach it.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedyeah, that could work. though i'd prefer we recurse into $data, rather than stopping at 2 levels.
Comment #4
sunSafely recursing into all nested keys that are arrays and sorting them by key (retaining keys and indexes/associations) is a typical question for @chx ;) (I wasn't able to figure out how that could work without a lame helper function)
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedthis sort of lame helper function?
Comment #6
sunyeah ;)
All of that being said: Doing this in FileStorage only means that we're adding a constraint to the config system, basically telling that no developer should rely on the order in which keys are returned, because the actual order of keys is different between FileStorage and DatabaseStorage.
This inherently means that a strict comparison like the following will never be TRUE:
Of course, we could move the sorting into DrupalConfig::save(), so it applies to every storage. However, I almost guess that that would be kinda incompatible with the idea of clustering/splitting keys into separate records (if that's going to happen), since those multiple records would simply be retrieved/collated into one item/object, and any particular order wouldn't be retained.
Comment #7
catchCouldn't we make the database backend to order by key ASC or something when it retrieves them?
Comment #8
sunheh. That indeed sounds like the direct equivalent to the nested key sort! :)
So, let's move this into DrupalConfig::save() ?
Comment #9
sunExtracted from #1626584: Combine configuration system changes to verify they are compatible
Comment #11
sunResolved as part of #1605324: Configuration system cleanup and rearchitecture
Comment #13
sun#1785560: Remove the sorting of configuration keys reverted this entire patch.
It's possible that we might be able to resolve a part of the problem via #1601168: Orphan/obsolete keys and sub-keys *within* configuration objects are retained *forever*, but certainly not for all config objects.
I'm therefore re-opening this issue to make sure the topic is not forgotten.
To quote myself from http://drupal.org/node/1785560#comment-6569464:
Comment #14
mtiftcore/lib/Drupal/Core/Config/ConfigObject.phpno longer exists (or was renamed). And I think we are solving this problem in #2227731: Normalize configuration data during config writes.So I think we can close this issue?
Comment #25
larowlanIs this still an issue now we sort all keys according to their defined order in the schema?
Comment #27
quietone CreditAttribution: quietone at PreviousNext commented8 years @mtift suggested that this was fixed and does @larowlan in #25. More information was asked for 7 months ago and none has been supplied to confirm that this is still an issue. Therefor, I am closing this.
If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").