Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
From @alexpott in #1735118-113: Convert Field API to CMI :
FieldInstanceStorageController():
+ * Note: the class take no special care about importing instances after their
+ * field in importCreate(), since this is guaranteed by the alphabetical order
+ * (field.field.* entries are processed before field.instance.* entries).
This comment proves we need to refactor the config import process so we can implement a way for config providers to say that this config needs to be imported before this other piece of config. Relying on the alphabet is smelly :)
Comments
Comment #1
swentel CreditAttribution: swentel commentedBetter tag (I think)
Comment #2
gddWhen we originally had this discussion like a year and a half ago we talked about using the module dependencies graph as an ordering mechanism. This seems like the simplest solution to make happen?
Comment #3
xjmI'd call this a bug. I'm tempted to cal it a major bug. That seems pretty fragile. :)
Re: using module dependencies, I don't think that solves the problem. A module should be able to declare an arbitrary import order for its own config data depending on its internal needs. Like the field/field instance example.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedi suspect we'll end up wanting something like what we implemented after discussions at badcamp aaaaaages ago?
that is, allowing multiple cycles over the import list, and a mechanism for modules to say 'hey, call me again'.
or something else, if the current import code can't be made to work that way any more.
Comment #5
xjmPossibly related: #1969698: ConfigEntity::save() should disallow saving ID/UUID conflicts (Field UUID changes can badly corrupt field data)
Comment #6
xjmComment #7
xjmClosing as duplicate of #2030073: Config cannot be imported in order for dependencies.
Comment #8
xjmComment #8.0
xjmBetter link