Currently, CT Plus is dependent on Spaces. However, I don't think this is necessary, and makes things more complicated than they need to be (resulting in confusion like #997094: Access Denied on node/add/ct-plus-task). I'm wondering if it's possible to move the Spaces integration to the OA CT Plus submodule.

I tried simply moving spaces[types] = "all" from ct_plus.info to oa_ct_plus.info, but unfortunately this resulted in the ct_plus icon appearing in all spaces, regardless of whether OA CT Plus was enabled for that space.

If anyone with more experience with Spaces could weigh in and offer their opinion/guidance, I'd appreciate it.

Comments

izmeez’s picture

subscribing, unable to help answer the problem but support reducing the dependencies so it can be used in settings without OA.

Grayside’s picture

Spaces runs spaces_menu_access() and similar access control functionality on Features based on the presence and specifics of the spaces[types][] settings in the .info file.

In order to sidestep that, there are several messy options, my favorite (and one that I've begun to avoid at cost of duplicate code) is to implement hook_system_info_alter(). This hook happens to be in core, but it is also used and cached by Features for a number of operations, including associating exported Features components with Spaces types.

You will want to modify the ct_plus .info file to have a spaces tag by implementing oa_ct_plus_system_info_alter(). Remember that if you run drush fu on ct_plus with oa_ct_plus enabled and implementing this, the spaces type will have be hard-coded into the .info file.

For an example of this, see presentation_atrium_system_info_alter() in a previous rev of my Presentation module. Ultimately I decided it was too complicated simultaneously developing and updating both features using this trick, but it is definitely doable.

Dane Powell’s picture

soulfroys’s picture

Is there anything new about it?