In A new paradigm for overriding Drupal Features, Mike Potter of Phase2 outlined an alternative approach to capturing overrides.
In #1316014: does not work with rules fago suggested
Maybe, it would be a good idea to allow people to choose whether overrides should behave that way anyway, as if mostly everything changed I'd prefer a complete override-export anyway as it is more stable, i.e. it won't break if the original export changes arbitrarily.
It seems there are valid use cases for both the current implementation - capturing of a diff between an original and an override - and full overriding, of either the component as a whole or a subset of it.
Based on the approach Mike's sketched in, introduce methods to capture an override as a full export of either a component (e.g., a field instance) or a subset of it (e.g., a field instance's display settings). Maybe this includes capturing a method of override:
define('FEATURES_OVERRIDE_DIFF', 1);
define('FEATURES_OVERRIDE_FORK_FULL', 2);
define('FEATURES_OVERRIDE_FORK_PARTIAL', 3);
Then the altering behaviour would be different for each, and each type of component could support one or more methods. Or maybe everything supports forks but only a subset supports diff?
@todo
@todo
@todo
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | ctools_alter.zip | 2.32 KB | scottrigby |
| #2 | views_override.zip | 2.21 KB | scottrigby |
Comments
Comment #1
djdevinWe need this as well, and ended up writing some custom spinoffs such as ctools_alter and views_override (basically allowing for total overrides and not differences).
Comment #2
scottrigby@nedjo following up on what djdevin said…
We made those modules to accompany features_override, for the exact reasons you mentioned - and use them in production (D6 only atm). We've been on the fence about whether those options should be introduced into features_override or remain separate modules, so we haven't contributed them as separate projects yet. But based on this ticket, it sounds like we're not the only ones who need this.
We can work on helping add this functionality into features_override/7.x-1.x (then backport to D6), but first am uploading zips of the custom ones we made - as a point of discussion for how we should (or shouldn't) hendle this in features_override.
About the partial / full forks vs diffs question… it's hard to see how FEATURES_OVERRIDE_FORK_PARTIAL will know how to cover all components… like… how do we determine where to break each features component into subsets?
Comment #3
scottrigbycross-referencing #1419386: Move hook_X_alter's into the .features.inc file and not features.override.inc
Comment #4
djdevinI noticed when selecting a features override item it featurizes all the changes but not the parts that didn't change. Features override is a lot more mature now so maybe this is more possible is 2.x.
We use some full overrides in projects where we know the "upstream" feature is going to change, and the downstream "custom" feature won't be able to apply the changes.
Comment #5
wizonesolutionsComment #6
wizonesolutionsI think full exporting is one issue here, but the other is how we trust export methods on objects blindly. Even a full-export mechanism would try to call
RulesPlugin::export()with today's code. And it would fail because of what happens whenfeatures_remove_recursion()gets called.Comment #7
wizonesolutionsComment #8
scottrigby@wizonesolutions looks like you related this issue to itself. Did you mean to relate a different issue? (i'm still mildly interested)
Comment #9
wizonesolutions@scottrigby: Hahahaha!
I must have meant to link #2020917: Fatal error: Call to a member function stateVariables() on a non-object. Now I have.