Best practices for managing customizations to Commons [#1454430]

I want to start by saying that Commons has been a huge help to me and I am very appreciative of the work that has been done.

At the same time, as I have been wondering about how to manage Commons features, updates, and customizations to my Commons site such as:

added roles and their permissions
additional modules
additional views
modifications to existing views
additional contexts
changes to existing contexts

I have begun wondering if there will come where Commons updates will create more effort in terms of deciding which features to revert and override than the value they will add.

This has led me to wonder if it would be at all feasible to imagine a path where developers could start with the full Commons distribution as a way of adding appropriate modules, views, roles, contexts, etc. but would be able to wean themselves from future Commons updates (or being able to pick and choose new features) and move closer to a more independent Drupal update path.

Is this idea at all feasible? Are there too many patches and interdependencies for this to work? It seems like the alternative is potentially to have bigger and bigger headaches with each wave of customization and future releases, or is there a better way to manage this?

I am new to the world of distributions, and I imagine that this is one of the trade-offs when using a distribution. Are there already best practices in how to manage issues related to customizations and upgrade paths?

Comments

Comment #1

ezra-g CreditAttribution: ezra-g commented 2 March 2012 at 18:35

Title:	Moving Commons closer to mainstream Drupal	» Best practices for managing customizations to Commons
Component:	Miscellaneous	» Documentation
Category:	feature	» support

Thanks for this question.

The problem of managing customizations to a distribution is large in scope and something that the Drupal community in many ways is still trying to figure out and make easier.

This is an area where I'd like to develop some documentation on the best approaches, which would be helpful for Commons as well as other distributions.

Broadly:

Features, CTools and other contributed modules provide APIs that allow developers to alter exports defined by other modules by writing code.

Projects like http://drupal.org/project/features_override make it possible to define overrides to components such as views through the UI. It's currently in beta status but my sense is that it's advanced a great deal since the ~year that I last used it.

Specific to Commons, one priority that I'll be working towards with the Drupal 7 version is reducing interdependencies so that Commons is easier to customize and a more flexible tool for site builders.

I'm leaving this issue open as a stub for creating a documentation page.

Let me know if I can provide any more specific answers - Your feedback here is helpful to making this documentation useful :).

Thanks!

Comment #2

jsibley CreditAttribution: jsibley commented 2 March 2012 at 19:52

A few thoughts:

When there are choices in how to customize, what are the best ways to do so?

For example, is it better to clone views and customize them or to customize the existing views? I can see pros and cons to each approach when updating.

Is it best to put added modules in sites/all to keep them separate from the distribution's modules? Is there a risk to this if the same module gets added to a future version of the distribution?

If we override a feature,then upgrade, do we need better tools to understand which features it is safe to revert? Would it make sense to have an easy way to revert, see the changes (and if anything breaks) and to undo the revert if necessary (would taking a demo snapshot serve this purpose?)

This may not be specific to distributions, but it can be particularly difficult to understanding what is being handled by contexts, particularly ones that apply to anonymous users. A report documenting contexts and their actions could be quite helpful.

Overall, I think it would be great to think of a distribution as a Drupal installation with training wheels that can come off at some point. There might be patches that are required initially, but it would be great to plan a transition away from patches so that users can be one independent of the distribution upgrade process, in exchange for giving up (probably) new features included in distribution updates.

Comment #3

Sarenc CreditAttribution: Sarenc commented 3 March 2012 at 00:36

We've decided to use features' hook_COMPONENT_alter() functions to modify commons default features.

We are also now using rules_defaults_alter() to store our modified activity_log templates.

As to what is the "best" practice, I think that depends a lot on the site and how different it will be from Commons OOTB.

Using alter() functions helps a lot in discerning what has changed in commons features through upgrades and is appropriate if you are using the features extensively.

For a very customized site it might be better to create most of your views from scratch rather than modify existing ones. You can even disable the included views and/or remove them from their features with the alter() functions.

Another hint: Features' use of diff is handy but it doesn't beat recreating a feature (re-downloading it) and comparing it with your favourite diff viewer like winmerge. This makes setting up your alter functions a lot easier.

Comment #4

Lammert CreditAttribution: Lammert commented 11 May 2012 at 11:48

We've recently been doing some testing with the "Features Override" module on a customised Commons install (with 80+ customised feature components) . It takes quite some time to set up properly the first time, but after that it works really well and all our work was very easily exportable from a test environment to production. Where I was a bit worried about the whole update-procedure before (and let's be honest, we've all seen easier upgrade methods than drupals'), I'm quite relieved now...