From @alexpott in #1735118-113: Convert Field API to CMI :


+ * 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 :)


swentel’s picture

Issue tags:+Configuration system

Better tag (I think)

heyrocker’s picture

When 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?

xjm’s picture

Category:task» bug
Issue tags:-CMI

I'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.

beejeebus’s picture

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

xjm’s picture

Priority:Normal» Major
xjm’s picture

xjm’s picture

Status:Active» Closed (duplicate)
xjm’s picture

Issue summary:View changes

Better link