Dear uuid_features-Maintainers,
everytime a node is integrated into a feature, uuid_features add's the node type's config variables into that feature, too.
If now two features contain each one different node of the same type, this behaviour causes a feature conflict.
This effectively causes (unnecessary?!) conflicts in pretty much any more-than-trivial us of this otherwise great module (hence the "major" state für this ... *bug* ?).
I can't see, why these nody type config variables have to be carried along with every single node of that type in a feature - they belong to the node *type* definition, not a specific node instance of that type. On the other hand, i don't know *why* this behaviour exists, and i may be wrong, so:
Could you have a look into and thought about this?
cheers,
daniel
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | uuid_features-resolve-conflicts-935726-8.patch | 9.12 KB | mvc |
| #7 | uuid_features-resolve-conflicts-935726-7.patch | 8.41 KB | mvc |
| #6 | uuid_features-node-type-conflicts-935726-6.patch | 967 bytes | mvc |
| #1 | uuid_features-935726.patch | 959 bytes | chaps2 |
Comments
Comment #1
chaps2 commentedI agree that the unconditional adding of a node's node-type to a feature is unnecessarily restrictive.
Here's a small patch that checks whether the node-type is provided by another feature. If it is, the node type isn't added to the pipe. That should cover most scenarios and you can always create a dummy "node-type" feature for the rest.
Comment #2
chaps2 commentedComment #3
iztok commentedWhat should I remove if I want to modify the feature manually?
I removed line: features[ctools][] = "strongarm:strongarm:1" and all features[variable][] lines from .info file and all strongarm related lines and files.
After feature update all the lines and files get back.
Comment #4
Johnny vd Laar commentedThe same "bug" exists in the 7.x . The changes in the patch works for 7.x as well.
Comment #5
mvcworks perfectly for me too. thanks!
@Iztok modifying the feature manually won't work, that's exactly why you need this patch
Comment #6
mvcOops, spoke too soon. This patch also needs to include the feature which defines the current type as a dependency to ensure that the definition is available. Please test this revised patch.
Comment #7
mvcHmm, this problem is larger than I realized.
I noticed that terms and vocabularies have an equivalent problem, in that each feature which exports a node will include every necessary term and vocabulary, even if these have already been defined in another feature, leading to conflicts unless the user chooses to place all exported terms, vocabularies, and nodes into a single feature. It is necessary to call features_get_default_map('uuid_vocabulary') in uuid_vocabulary_features_export() to check which vocabularies are already defined, and likewise for terms.
However, this raises a larger problem. uuid_vocabulary_features_export_render() and uuid_term_features_export_render() currently generate hook_uuid_features_default_vocabularies() functions which return arrays that are not explicitly indexed, leaving PHP to assign numeric array indices starting with zero. As a result, features_get_default_map() does not include terms or vocabularies in the mapping of Drupal data to exported feature, because line 702 of features/features.export.inc checks is_numeric() before putting something into the map (so that the array can be searched later on). Similarly, uuid_file and uuid_node neither index their exported data arrays nor check whether their data has been already included in another feature, leading potentially to many conflicting features.
This patch solves both these problems for all four data types. It also solves the original problem of exporting node type definitions multiple times.
Comment #8
mvcMy last patch would list a features module as a dependency of itself when rebuilding. Besides being pointless this led to spurious messages stating that a feature had been overridden. This fixes that for files, terms, vocabs, & nodes.