This session is a proposal, and a proof-of-concept how-to, for moving Features from Drupal distributions (packages defined by installation profiles like COD) to implementations (sites built from those distributions like nyccamp.org!).
Who is this session for?
For developers involved in either writing distributions, or extending/implementing them with a team.
Why do Features suck in distributions?
When writing distributions, Features makes it easy to export configurations assumed to be good defaults for sites implementing the distribution. It can also make it too easy to build too-tightly-coupled functionality, which only works well with certain combinations of configurations (but that rarely happens, right?).
Even when that's not the case, the biggest problem with Features in distributions is they make it a nightmare for developers to use Features effectively in their own implementations. Especially if they want to:
- Build a site with more than one developer
- Change any of the default configs in the distribution's features (this never happens!)
- Use Features to deploy changes between environments (from local dev, to staging, to production, etc)
There are ways to overcome this - one is using the Features override module… but it has serious limitations:
- Certain overridden components can be brittle, if their base component were to change upstream (common example: if an override adds a field to a base feature View, if a relationship that field relied on was removed or changed upstream… PDO exception)
- An overriden feature's overridden components list can quickly become overwhelming, and the exported diffs are even less readable than the original component exports due to lack of context (ever tried manually reading over an exported overridden Views diff?)
- Overriding features often takes a lot of finesse to get all features back to their default states (and without that, there's little point in even bothering to use Features)
- So site builders often avoid this problem by rebuilding their own variants of the defaults, but which are now not tracked by the base feature (effectively side-steping the distributions defaults anyway)
Developers can also get around this by manually writing the same alter hooks Features override creates programmatically… but the more this is done, the more difficult it is to manage the code as a team, and work with Features effectively at all.
How did this happen?
In 2009, Open Atrium redefined what a Drupal distribution could look like. Since then, most major distributions have started shipping with default features.
But over time, many people implementing distributions as a team have realized this causes more pain than gain.
Features can still be a good idea for deploying configuration changes in a team - they should just be moved from distributions to the implementations themselves.
What can we do now?
- Distributions can create a new branch, removing features from their base
- The defaults currently created by features can still be added on installation using different methods, but they should no longer be tracked by the Features module
- BTW I'm having fun working on a new tool, called Unfeaturize, to help distributions with this task
- This will allow implementation teams to build their own features, without having the infinite pains of overriding the base distribution defaults