18

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?

Improve this question

3 Answers 3

Reset to default
17

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.

Improve this answer
7
  • 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, 2012 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, 2012 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, 2012 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, 2012 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, 2013 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

Improve this answer
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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