Fieldgroup depedency logic is quirky [#838726]

One round in populate:
If a content type is added, it's fields get added
next round in populate:
If a field is supplied by another module, module is added a depedency

    // If this field is already provided by another module, remove the field
    // and add the other module as a dependency.

This seems quite reversed. $field in this case are per content type, $field is attached to a specific node type, node type needs to exist for field to exist.* So module now has a dependency to a module supplying a field for it's content type, but the content type needs to exist for the field exist, ie the other module should have the dependency if anything, even then if the module is dynamically creating fields based on content type existing, nope.**

* though, on that, features rebuild never checks if content type exists before trying to add field, but that's a different bug altogether
** I am with increasing frequency doing this, ie using the hooks and dynamically add a field to x, y, z content types.

Comment	File	Size	Author
#8	features_838726_fieldgroup_logic.patch	1.13 KB	hefox
#6	838726_features_fieldgroups.patch	1.12 KB	hefox

Comments

Comment #1

yhahn commented 30 June 2010 at 14:38

Status:

Active

» Postponed (maintainer needs more info)

Could you explain a little bit more clearly what you're requesting here? Perhaps with some concrete examples?

Comment #2

hefox commented 30 June 2010 at 14:55

Feature 'cat_base' has content type 'cat'
Feature 'cat_colour' has field_fur_colour for content type 'cat' (and likely a dependency to 'cat_base')
Features-update feature 'cat_base' and it gains a dependency to feature 'cat_colour'.

So now two features are in an weird depedency loop.

in features.node.inc, all fields are added if a content type is included in the export.* Then when those fields are checked, if their handled by another module, a depedency is added. This works nicely when exporting 'cat_colour' as user selects cat, then the new field field_fur_colour is added as a field as it's not defined by any other module.

However, this breaks down on when updating cat_base. As 'cat_base' includes 'cat' content type, all fields are added to the pipe. It sees that field_fur_colour has been added, but it's supplied by another module, so it adds 'cat_colour' as a dependency.

Basically the base module gets dependecies to submodules, which depedent on it in some cases! XD

I'm thinking basically this lines needs to be addressed, but I'm not sure if it needs to go away or be re-logiced somehow.

    // If this field is already provided by another module, remove the field
    // and add the other module as a dependency.
    if (isset($map[$instance]) && $map[$instance] != $module_name) {
      if (isset($export['features']['content'][$instance])) {
        unset($export['features']['content'][$instance]);
      }
      $module = $map[$instance];
      $export['dependencies'][$module] = $module;
    }