$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: 2
Hint: '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
| 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) 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) 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 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").