16

I have two content types with various menus, views, menus, etc. which I have packaged as two Feature custom modules. The two content types both use a taxonomy and use several of the same fields in the database. When I load these Feature modules in a new site, they show conflicts with each other over these common fields and vocabulary and I am not certain what would be the best way to resolve the conflict.

Although the Feature modules are intended to work together, they do not need to both be present on the same site. Each may also work with other different features as well. They both use the taxonomy and fields for views filtering etc so it makes sense that they each include these components in their Feature definition. Should I:

  • Remove the fields and taxonomy from one of the modules, and declare a dependency to the other? This is not desirable since each can work without the other.
  • Make two versions of the features, one for independent use, and one for collaborating.
  • Define the fields and taxonomy as a separate feature?
  • Ignore the conflict and enable the modules? (If I do, will they both share the field?)
  • Another solution?

I have not yet tested this, but will disabling or uninstalling one of the two Features modules remove the fields from the database even though the other module requires it?

16

Create a third Feature defining the components(*) used by the other two independent Features.

In the other two Features, remove the components which are now claimed by the third Feature, and instead, list the third Feature as a dependency.

echo 'digraph G {label="Dependency Graph";  structural [label="Structual Feature\n(Fields, Taxonomy)"];  "Feature A\n(Content Type)" -> structural;  "Feature B\n(Content Type)" -> structural; };' | dot -Tpng > dependency.png

(*) In Features for Drupal 7, however, this functionality isn't yet committed — see http://drupal.org/node/1064472, and help review the proposed code there. — This patch has been committed to Features 7.x-2.x.

  • 1
    Yeah, that would certainly work. Although if that is what Features forces users to do, it is an inelegant solution. Features provides the ability to package a Feature, and then doesn't let us do it completely. Shared fields between separate Feature modules should not be a problem. Thanks – Ashlar Feb 11 '12 at 19:28
  • 3
    @Ashlar: But what if the definitions of the Fields in each of the first two Features differ — how would the conflicting definitions be resolved? Also, in general, having multiple authoritative definitions of the same information is problematic. Sharing Fields isn't a problem, but having multiple authorities specifying what those Fields are is a problem. – smokris Feb 11 '12 at 21:07
  • 2
    No, I'm saying that you should define the field once (and thus define the field's possible values once) in the structural Feature — and reference that field in each of the content type Features. (Ack... I just realized that what I proposed assumes the patch on drupal.org/node/1064472 has been applied, which I forgot to mention. Edited answer.) – smokris Feb 13 '12 at 6:04
  • 1
    Thanks smokris. The link was very helpful. I had a wrong assumption about how the field/instance were handled. Your answer now makes sense to me, and the link to the patch will save me from pulling out hair :) – Ashlar Feb 13 '12 at 14:46
  • 1
    The mentioned patch for D7 Features has now been committed to dev drupal.org/node/1064472#comment-7235792 – danbohea Apr 4 '13 at 11:30
1

This solution on d.o worked great for me, far more robust to be exported to various sites than creating a third feature, which would create orphaned fields in another unrelated site.

http://drupal.org/node/1698290

0

One solution that worked for me was to attach the two Features into one bigger feature.This solved the conflicts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.