Jump to:
| Project: | Features |
| Version: | 7.x-1.0-beta6 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I have created two new Feature modules and moved them to a new dev. site. Each Feature is based upon a content type and includes menus, views, etc related to the content type. Both content types use a common taxonomies and fields, so I am getting conflict messages. I am uncertain about which way to resolve this situation. I see the following options:
- Package the content types together in a single feature. This is not so desirable since new sites may need one or the other content type and not both. There is also the possibility of other content types/Feature modules being added.
- Extract the field and taxonomy from both Feature modules, making it a separate module. This seems like poor design since these elements are needed specifically for these content types and it makes sense for the fields to be included in the Feature package.
- Ignore the conflict and proceed anyways.
Question 1: What are the repercussions of ignoring the conflict? If one of the modules is disabled on a site, will Features remove the vocabulary and fields or recognized that they are required by another module and leave them be?
Question 2: Is there a better strategy? With taxonomy fields so ubiquitous on a site, it would seem that a Feature collection of anything less than the whole site would often raise conflicts.
Comments
#1
same issue regarding body field on all content types, right? What can be done until this is worked out(I know there are several issues trying to address this regarding features that build off of other features)? Should the core body field be removed and and a custom long/summary field be added to each content type? Views would have to be updated as well.
#2
I haven't tested this but can't you just export the taxonomy in 1 feature and have the other feature depend on it?
AFAIK having the same field exported in multiple features should not cause conflicts. My brain may be rusty however.
#3
I found this issue discussing the problem. The patch at the end worked to distinguish between the field and the contents. I did not try placing them in the same feature, but created a separate feature to establish the database fields.
#4
After trying different variations, patches and features_* modules I can conclude that using conflicting features in the way specified on http://drupal.stackexchange.com/questions/22174/how-do-i-resolve-this-co... is the most intuitive and stable way until Features would start automatically understand conflicting dependencies.
Also, the important point - always create feature with common fields (such as taxonomy) first, and then - depending features. Otherwise, Features dependencies auto-discovery mechanism will not allow you to deselect common field and it will be added to the dependency feature.