Auto-detection over context(s) causes conflict (doubled info) between two features

We're doing something very similar; we have a "User Interface" feature that provides the contexts for several smaller features (a "Bio" feature, a "Posts" feature, etc.). We would like to package the "Bio" views with the Bio feature so that it can be used as a standalone application. This also avoids potential bloatware if a user wants the Bio functionality but not the user interface blocks and layouts we provide. Currently, however, we have to include all these views in the User Interface feature because there's no way to add the contexts to the feature without them.

Is it possible to have this type of "wrapper" feature depend on a view (instead of bundling that view with the feature)? Or would you be interested in adding this type of option to Features? If so, we might be able to start on a patch if that would be helpful. Sorry if this is confusing!

This is still an issue as of 6.x-1.0-beta12

I'm having this issue with features, contexts, and boxes.

if a box is included in multiple contexts, and two or more features are created. each one including one of the contexts, features makes the common box included by dependency for each feature. This creates a conflict for the two features.

I can confirm this issue with a feature reacting on certain content types. so all fields are getting included as a context's auto-detection, but the content types (and the fields) were actually created with another feature. So both features would cause a conflict because of doubled configuration content.

Changing title to something more general: Auto-detection over context(s) causes conflict (doubled info) between two features

Just trying to get some (maybe stupid) ideas around this issue:

Should features, in general, be tolerant for doubled configuration? I think this would make the problem much more complicated. Because it'd have to decide which information is more important than the other... And, eh.... no, this might not a good idea.

A nice feature could be to include other features, so that auto-detection could take these as a base and wouldn't include twice the same information. This doesn't seem too trivial to me, but at least it might be possible...

This seems problematic to me as well.

I would rather the context just keep a record of a view or block created by a view instead of exporting the entire thing. In that case though the feature could create an error if it was enabled and that view wasn't installed. Personally I don't expect each feature to be a self-contained entity.

The suggestion above would make sense to me as a way to export contexts without grabbing the entire view as well. I'd be willing to work on it if the maintainers agree.

subscribing

This is also happening with 7.x-1.x and is causing a real mess when creating features with contexts that reuse a view. I'm moving this to major since the only way to solve it is by creating Features that are really huge.

My question is, did a recent patch committed caused this? Maybe we could just revert it, I don't remember having this problem before.

The Features Plumber looks promising, just wondering how stable it is ...

None. At least for 7.x is totally broken and seems like is not maintained anymore.

Summary: Before adding auto-detected components, Features should check if those components are already exported.

I'm somewhat surprised the auto-detection can add components that a user cannot do by hand. (Exported components are no longer available in the UI.) So if this functionality is already in place, it implies that, while you've Exported the View with the first Feature, you had not yet reverted the View in the database to run off code.

sub

Duplicate of #904558: Multiple features and strongarm conflicts?