Better isolate Features

Thanks for the links, I'm sure they'll shed some light on this.

I hadn't seen the minimal profile in the Aegir interface. In fact, digging into this a bit more, I see this was accomplished with profile_tasks within the same voicebox_profile.profile. I'll try to grok how you've done this, and why, along with the implications for Aegir-based installs.

For a bit of background here, I've been strongly advocating VoiceBox as the second distro (after Open Atrium, btw) to support on our (Koumbit's) Aegir-based hosting service, http://AlternD.com. We've only recently refocused our Aegir efforts on supporting distros, rather than our bread and butter custom dev work, so there's still lots to be done. However, one of our primary concerns in choosing which distros to host, is the amount of work required to shoehorn them into Aegir. Ideally, this would be "none". So far, VoiceBox has achieved this very well, in that I've been able to build the platform directly from your makefile, through the Aegir interface, with only one notable bug (#1059006: /files/ctools/css permissions broken), which appears to be on Aegir's side anyway.

That said, I don't think interactive profile_tasks are supported under Aegir, though I'll discuss it further with the Aegir devs. Have you considered using Profiler? Besides moving lots of .profile stuff into an easily maintained .info format, it also supports derived profiles, akin to sub-themes. This might be a sustainable way to share configs and code across profiles, while still exposing them explicitly to Aegir. Again, I haven't actually read through voicebox_profile.profile yet, so this is just an initial idea.

Either way, I'll build a site manually with the minimal profile, and see how the Features can be fit together. From my reading of the docs on community.openatrium.com, encapsulation of the tag-clouds example might be achieved with some drupal_alters in the .module's of the features in question. Again, I haven't looked closely enough yet, but I'll discuss it with our "features team" and see if we can't help come up with a good solution.

I agree that a D7 port may make some of the concerns moot.

We'll have a whole contingent of Koumbiteers (8 or 9) in Chicago, so we should definitely try to hook up.

A couple notes from reading through voicebox_profile.profile and the .inc's:
* It looks like the "minimal" profile just turns off (or rather, doesn't turn on) all the UI features. I should be able to achieve something similar with a regular Aegir site build and turning off all the UI features myself, right? Then I should be able to see what dependencies remain between the features themselves.
* A lot of work here appears to be setting up wysiwyg. Have you seen: http://www.lullabot.com/articles/wysiwyg-feature? Apparently, it's feasible to build a wysiwyg feature these days. YMMV.
* Another nifty thing about profiler is that it will recursively activate module dependencies. So, by bundling everything into features, you can just activate those, and don't need to be so explicit about dependencies and their order of activation.
* Profiler also allows for defining themes, roles, terms, variables, &c.

Re: WYSIWYG, I agree that a module requiring a relatively untested patch, and with dependencies on a couple other modules in beta, would have been pretty unstable. Also, non-existent Features support for Better Formats at the time, couldn't have helped.

FWIW, I submitted #1060846: Exportables and Features support for 6.x, hoping to focus efforts on a 6.x solution for WYSIWYG API. Also, #616496: Features integration shows some promise for adding Better Formats to the mix.

As for Features-encapsulation, I've read the articles you linked to, poked around in the VoiceBox features some more, and a couple questions come to mind.

Following your advice (sorta) I deactivated all the UI features, and was then able to deactivate several other features. My goal was to remove Imported Content and Issues, just keeping the Discussion/Channels/Bio/Posts functionality. This doesn't appear possible currently, since Channels depends on Imported Content, and Channel UI depends on Issues, among other things.

This doesn't come as too much of a surprise, as it's well documented in the graphs you provided (here and here). Do you have any suggestions on how to work around this? This isn't for an immediate site-build or anything, but rather trying to understand how you would approach such a project.

I note also, that none of the features in VoiceBox have any code in their .module's, except the UI-generated include (e.g.: include_once('voicebox_homepage.features.inc')). It seems to me that better encapsulation and easier context IA could be achieved by adding something like:

/**
 * Implementation of hook_context_default_contexts_alter().
 */
function atrium_activity_context_default_contexts_alter(&$contexts) {
  // Conditionally add the "Recent Activity" block to the spaces_dashboard-custom-1 context.
  if (module_exists('atrium') && !empty($contexts['spaces_dashboard-custom-1'])) {
    $contexts['spaces_dashboard-custom-1']->reactions['block']['blocks']['views-activity_listing-block_1'] = array(
      'module' => 'views', 
      'delta' => 'activity_listing-block_1',
      'region' => 'content', 
      'weight' => 1,
    );
  }

I think such an approach would remain consistent with the goals you outlined. I'd appreciate hearing your thoughts on the matter.

Oops, cross-posted there...

Thanks jgraham. I'll explore the VoiceBox features further, as time permits. So are you suggesting rebuilding the _navigation and _ui features in order to accommodate arbitrary functional feature combinations?

BTW, all these comments and questions are intended to be constructive, rather than critical. I look forward to meeting you all in Chicago :)

It seems to me that there are basically two uses for distributions:

• turn-key pre-configured websites;
• platforms to bootstrap site-builds.

Since these goals can sometimes (or even often) come into conflict, which of these do you see as VoiceBox's primary objective? From the goals outlined here, I'd have thought the former, but the last comment hints more at the latter.

This is one of the issues Koumbit's features team has been struggling with of late. My personal bias is towards the turn-key/SaaS model, with the self-contained clicky on/off features found in Open Atrium. Since many, if not most, Drupal shops' revenues are heavily weighed towards custom site-building and development work, I'm probably in the minority on this issue.

So, with that in mind, it's easy to see why I prefer the hook_context_default_contexts_alter() kind of approach. I don't think performance would be too negatively affected, as this hook "acts on the collected array of default contexts before they are cached" (ref: context/README.txt). However, I agree whole-heartedly that this approach "requires more careful thought." All the more so, since it would likely require a significant re-working of the architecture of the distribution.

BTW, there's a nicely detailed write-up here.