Feature Strategy for Panopoly Child Distribution

Thanks for starting this thread!

With the first use case, what I have built is working great, however with the second I am finding difficulty in maintaining and creating custom features as I have hit a bit of a wall with 'overrides to overrides'. I have most of Panopoly's features (let's call them Tier 1) as dependencies to my own features (Tier 2), and then custom sites which further extend via overrides (Tier 3). Where there are already overrides in Tier 2 that require customising, exporting and maintaining features on the custom sites is very difficult.

Overrides of overrides is a problem that I've encountered too, particularly when doing Open Atrium development. Open Atrium overrides Panopoly - now what if I want to override Open Atrium's overrides?

The problem starts with "export hooks" in Drupal. Basically, there is one hook like hook_views_default_views() which Features created that provides your views. Then you can create a hook_views_default_views_alter() using Features Override (or by hand) and it can change that data. But if you provide more than one alter hook, they might not run in the order you want.

It's possible that Features Override could be changed to help mitigate this problem, but it would be quite tricky. Anyway, I'm hoping that in Drupal 8 we'll be able to find a better solution because there won't be any more "export hooks", but instead only CMI!

But that's the future. :-) Today, what I usually end up doing is writing my "overrides of overrides" by hand in code using the alter hook and hook_module_implements_alter() to control the order that my hooks run in. It's a little messy and requires custom code, however, it hasn't been too bad in practice because usually the big work is done at "Tier 2" and my "Tier 3" stuff is pretty minor.

In my head, refactoring my distribution to use two 'tiers' of features is the solution; have all feature code for my mvp in my own features and making that 'Tier 1' (basic sites with no customisations on my base distribution), this would allow for easier enhancement and maintenance of custom sites in their own features / features overrides (tier 2).

This would require moving all the Panopoly features into my own features, so there becomes only one tier for standard sites.

So, in general, I wouldn't favor this approach, because it means that you won't be able to get any future bug fixes or improvements from Panopoly.

However, as I described on the issue you linked above, I see there being two types of Features in Panopoly: "opinionate" Features and "general" Features.

A "general" Feature in that it makes no assumptions about your use-case and is meant to work with any kind of distribution. In my mind, these are the "general" features:

• Panopoly Core
• Panopoly Widgets
• Panopoly Magic
• Panopoly Images
• Panopoly Test

Maybe there's some of these you wouldn't want to include your distro, for example, Panopoly Magic. Or maybe you're OK with Panopoly's stuff using Panopoly Image's image styles, but you want to make your own for your own for your own stuff. Or maybe there's a couple of widgets in Panopoly Widgets that you want to disable.

But I wouldn't recommend forking any of these. If you find problems with them, you should make overrides, or contribute patches to Panopoly and try to get any problems fixed for everyone, or hide the widget and provide your own replacement, etc.

However, then there's "opinionate" Features which make assumptions about your use case. In my opinion, that's these:

• Panopoly Admin
• Panopoly Pages
• Panopoly Search
• Panopoly WYSIWYG
• Panopoly Users

If you're use case is significantly different than what those Features have in mind, I'd recommend not including Panopoly's Feature and creating your own Feature. For example, if you have a totally different idea about how the default page content types should be or if you want to use a totally different WYSIWYG configuration.

Of course, if your use case is similar enough to use them with only super tiny changes, you can still do overrides. We do continue to improve and fix bugs in these modules, so I'd try to still use them if you can. But just know there is a breaking point if your distro gets different enough!

Anyway, this is my take on this! I imagine other people who have done lots of distro development have their own opinion about this, and I hope to hear what everyone else things too!

Open Atrium is a rich-"Featured" distribution that is built on top of Panopoly. In some cases we override Panopoly Features using Features Override. In other cases we use other hooks. In other cases we have our own Features. There isn't any "one size fits all" solution.

In fact, I wrote a Blog about Overriding Features here: http://www.phase2technology.com/blog/how-to-override-features/

It can definitely be done and Open Atrium is a very successful example of it. But it's not trivial and definitely limited by what you can do in Drupal 7.

In general though, you want to avoid trying to "override and override". While two modules can implement the same alter hook, it can get tricky ensuring that they always run in the correct order.