It doesn't make a lot of sense for spaces to depend on features. After all, features is a way to package several types of objects (views, content-types, etc.) together, it shouldn't also have to define the concept of "a consistent set of stuff that you can use in a space".

This is a critical architecture short-coming, as it prevents you from defining "space features" outside of the features module.

Comments

mikemccaffrey’s picture

Category: bug » feature
Priority: Critical » Normal

I think this is one facet of an underlying circular dependency issue with Context, Features, and Spaces. Contexts are included in Features, and Features are enabled by Spaces, and Spaces activate Contexts. Feels kinda like an incestuous relationship.

Anyway, it seems like the role of Spaces needs to be clarified. Either it is just primarily a tool for activating Features, in which case it shouldn't be used for as many other random things. Or else it is a multi-purpose tool, in which case the explicit dependency on Features should probably be removed.

Removing "critical" since worse comes to worse, you can just enable the Features module for the time being even if you aren't using that functionality.

jmiccolis’s picture

Version: 6.x-2.0-beta6 » 6.x-3.0-beta4

The Features project's self-stated goal is to capture configuration components that, taken together, satisfy a certain use case. From a pragmatic perspective, this is exactly what you want to be able to enable/disable per space. I hear what you're saying that it would be nice to define a "space feature" else where, but how different would that be from doing so in a feature module? What would adding a new class of entity get us?

mikemccaffrey’s picture

I think Damien's "space features" was bad wording.

A better example would be if you wanted to use spaces to turn on a context that would make changes to the template or such. No need for Features in that case.