I have 2 features on my site.
feature A contains a content type and some cck fields.
feature B contains no content types, but it contains a context which uses a content type as a condition to set the context.
when feature B is exported, strongarm exports the content type variables for the content type included in A (since its used in feature B's context)
variables such as:
features[variable][] = "comment_anonymous_type_a"
features[variable][] = "comment_anonymous_type_b"
are exported with feature B
when the type_a variables should only be exported with feature A
this creates a conflict with the 2 features.
Comment | File | Size | Author |
---|---|---|---|
#34 | 904558_34_features_multiple_conflicts.patch | 1.58 KB | jgraham |
#29 | 904558_features_multiple_conflicts_29.patch | 1.59 KB | Raines37 |
#28 | 904558_features_multiple_conflicts_28.patch | 1.56 KB | hefox |
#18 | 904558_features_multiple_conflicts_18.patch | 1.57 KB | hefox |
#15 | 904558_features_multiple_conflicts.patch | 1.58 KB | hefox |
Comments
Comment #1
bsnodgrass CreditAttribution: bsnodgrass commentedThis is possibly the same issue as http://drupal.org/node/929246
Comment #2
ccardea CreditAttribution: ccardea commentedNo, this is a different issue. I experienced this same problem. I exported all of my content types in Feature A, but I had contexts set on node types in Feature B. Features detected that the node types were exported by Feature A, and removed them from the dependencies in Feature B, but the Strongarm variables were not removed. This created a conflict and I had to work around it by setting my context based on paths instead of node types.
Comment #3
ptrl CreditAttribution: ptrl commentedSound like the same problem I have. I have node types in one feature and contexts in another. When I recreated the feature with the contexts in It auto detects and add the strongarm settings for that content type (which is exported to the feature with the node type) in the context feature.
#2 Temporary solution solves the problem.
Could this be a problem with the naming of the module? Because this seems to only happens to context feature that the node type feature has a "higher" letter. For example this only happens when node type is in feature_a and context is in feature_b.
Comment #4
ccardea CreditAttribution: ccardea commented@ptrl
No. If you have a context set on a node type, and then include the context in a feature, Features will export the node type and strongarm variables along with the context. But if those node types are already included in a feature that is enabled on your site, Features detects that (somehow, wow!) and will not export them again. But apparently this behavior is not present in strongarm or is not communicated to strongarm. Somehow the two need a little tighter integration.
Comment #5
jstollerI'm having the same problem. In fact I just submitted an issue of my own before finding this one (I've marked it as a duplicate). I had to edit my feature by hand to remove references to the node options and comment variables for content types referenced in my context. This is not a sustainable solution.
Comment #6
jstollerI should also mention that when I manually remove the variable references like this, Features now always reports that my feature has been overridden.
Comment #7
voxpelli CreditAttribution: voxpelli commentedI can confirm this - and here's a patch that fixes this in Features itself. Another patch has to be applied to Strongarm.
Comment #8
bleen CreditAttribution: bleen commentedvoxpelli - is the strongarm patch needed to test this? if so, can you link to that issue and/or include that patch too
Comment #9
bleen CreditAttribution: bleen commentedthis patch along with the patch at #1078478: Multiple features and strongarm conflicts seem to fix the issue for me...
Comment #10
tim.plunkettThis works for me, used the same method for #881170-18: Add Features support to Automatic Nodetitles.
Comment #11
hefox CreditAttribution: hefox commentedI believe multiple modules are already implementing the hooks as seen in strongarm and the auto node title patch, so those modules would have to be updated.
Considering that, I highly suspect features should prevent the conflict instead of patching every module (ie shouldn't features being looking at the variables defined and converting them to dependencies if another module defines the variable already?)
Comment #12
jstollerYes please!
I'm having what I assume is a related problem right now with the Custom Formatters module. Every feature with a CCK field that uses a custom formatter tries to include it in the feature, event thought the formatter is already included in another feature. If this is not related, then let me know and I'll open up a new issue.
Comment #13
hefox CreditAttribution: hefox commented> Considering that, I highly suspect features should prevent the conflict instead of patching every module (ie shouldn't features being looking at the variables defined and converting them to dependencies if another module defines the variable already?)
Going to act on this and put this as needs work.
Comment #14
hefox CreditAttribution: hefox commentedMaybe I'll actual set it to needs work this time.
It's on my list to look at this as soon as get some real time to figure it out (and set up features that'd end up producing the issue)
Comment #15
hefox CreditAttribution: hefox commentedI wasn't actually able to reproduce this despite multiple trying, but am trying to patch it... :O
Could people take a gander at this patch against unpatched strongarm?
What it does is add a step into populating the the export which looks at the current export and resolves the current exported items into dependencies if they already. Various exports hooks (ie node_features_export) is doing similar logic to this, but this patch makes it standardized place; I haven't changed the other places yet (Not sure how it'll effect those places, ie if those hooks are ever called independently it could present a problem).
Comment #16
tim.plunkettTrailing full stop
Needs isset() or !empty()
Comment #17
tim.plunkettAlso, I agree with this approach.
Comment #18
hefox CreditAttribution: hefox commentedI changed the comment a bit to try and make it more sensible, and added a period + !empty
Comment #19
attiks CreditAttribution: attiks commentedsub
Comment #20
hefox CreditAttribution: hefox commentedComment #21
mpotter CreditAttribution: mpotter commentedReviewed the patch in #18 on a site (in D7) that was having this problem (strongarm variables added when using a context with a Node condition). Seems to have fixed the problem.
So +1 to this patch.
Comment #22
tirdadc CreditAttribution: tirdadc commentedThis issue is definitely in 7.x as well, and going through the test scenario described in the original post allows you to see that. #18 works great. Which one is the latest D6 one?
Comment #23
hefox CreditAttribution: hefox commentedA lot of patches apply both to d6 and d7; this seems to be the case here. I rolled the patch against 6.
Comment #24
tirdadc CreditAttribution: tirdadc commentedI am noticing one weird issue when I'm using this patched version though : the info file in the resulting feature ends up removing my view that's exported in feature B:
-features[views_view][] = "some_view"
but the view is still present in feature_b.views_default.inc
Can someone confirm this on their side?
Comment #25
attiks CreditAttribution: attiks commentedsmall typo dependencies
Comment #26
mpotter CreditAttribution: mpotter commented@tirdadc: tried it with some features here with views and the views were maintained when exporting.
Comment #27
tim.plunkett#18 here applies cleanly, and makes the old patch at #881170-18: Add Features support to Automatic Nodetitles work great.
Comment #28
hefox CreditAttribution: hefox commentedThis patch should fix the dependencies typo
Comment #29
Raines37 CreditAttribution: Raines37 commentedI tested this successfully against a site where I was having originally reported issues, and also tried (and failed) to reproduce the side-effect reported #22.
Attached is a re-roll against current 7.x-1.x HEAD. Just in case, I added a quick check to skip crawling/modifying $data if $module_name is an empty string.
Comment #30
tim.plunkettComment #31
febbraro CreditAttribution: febbraro commentedFantastico! Thanks for this one everybody, what a PITA!
Committed to 7.x.
http://drupalcode.org/project/features.git/commit/1204a26
Comment #32
tim.plunkettWow, what a coincidence, I JUST assigned it to you. I'll double check this, but I think I can straight up commit this.
Comment #33
mpotter CreditAttribution: mpotter commentedNeed to double check this.
The patch in #29 contains an extra check for an empty module_name that actually causes this patch to stop working on my sites. So it's the patch in #28 that is the good one.
Looks like the correct patch is in Features, but be careful if revisiting this.
Comment #34
jgraham CreditAttribution: jgraham commentedAttached is a patch against 6.x-1.x this is a straight port with no adjustments and seems to resolve the issue for me.
Comment #35
hefox CreditAttribution: hefox commentedIs this RTBC?
Comment #36
tim.plunkettAlright, committed! Thanks.
http://drupalcode.org/project/features.git/commit/bba147a