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.

Comments

This is possibly the same issue as http://drupal.org/node/929246

No, 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.

Sound 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.

@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.

I'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.

I should also mention that when I manually remove the variable references like this, Features now always reports that my feature has been overridden.

Status:Active» Needs review
StatusFileSize
new975 bytes

I can confirm this - and here's a patch that fixes this in Features itself. Another patch has to be applied to Strongarm.

voxpelli - is the strongarm patch needed to test this? if so, can you link to that issue and/or include that patch too

Status:Needs review» Reviewed & tested by the community

this patch along with the patch at #1078478: Multiple features and strongarm conflicts seem to fix the issue for me...

This works for me, used the same method for #881170-18: Add Features support to Automatic Nodetitles.

I 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?)

Yes 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.

> 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.

Status:Reviewed & tested by the community» Needs work

Maybe 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)

Status:Needs work» Needs review
StatusFileSize
new1.58 KB

I 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).

Status:Needs review» Needs work

+++ b/features.export.incundefined
@@ -43,7 +43,9 @@ function features_populate($items, $dependencies, $module_name) {
+    // Turn anything to dependencies if already defined

Trailing full stop

+++ b/features.export.incundefined
@@ -43,7 +43,9 @@ function features_populate($items, $dependencies, $module_name) {
+    if ($data && $function = features_hook($component, 'features_export')) {

Needs isset() or !empty()

Also, I agree with this approach.

I changed the comment a bit to try and make it more sensible, and added a period + !empty

sub

Status:Needs work» Needs review

Reviewed 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.

This 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?

A lot of patches apply both to d6 and d7; this seems to be the case here. I rolled the patch against 6.

I 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?

Status:Needs review» Needs work

+++ b/features.export.inc
@@ -59,6 +61,21 @@ function _features_populate($pipe, &$export, $module_name = '') {
+ * Iterates over data and convert to depenencies if already defined elsewhere.

small typo dependencies

@tirdadc: tried it with some features here with views and the views were maintained when exporting.

Version:6.x-1.0» 7.x-1.x-dev
Status:Needs work» Reviewed & tested by the community
Issue tags:+needs backport to D6

#18 here applies cleanly, and makes the old patch at #881170-18: Add Features support to Automatic Nodetitles work great.

This patch should fix the dependencies typo

I 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.

Assigned:Unassigned» febbraro

Assigned:febbraro» Unassigned
Status:Reviewed & tested by the community» Fixed

Fantastico! Thanks for this one everybody, what a PITA!

Committed to 7.x.

http://drupalcode.org/project/features.git/commit/1204a26

Version:7.x-1.x-dev» 6.x-1.x-dev
Assigned:Unassigned» tim.plunkett
Status:Fixed» Patch (to be ported)
Issue tags:-needs backport to D6

Wow, what a coincidence, I JUST assigned it to you. I'll double check this, but I think I can straight up commit this.

Need 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.

Attached is a patch against 6.x-1.x this is a straight port with no adjustments and seems to resolve the issue for me.

Status:Patch (to be ported)» Needs review

Is this RTBC?

Assigned:tim.plunkett» Unassigned
Status:Needs review» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.