available at admin/structure/features/lock, or maybe admin/structure/features/[feature_name]/lock
ui to select from components/items exported to given feature and "lock" them from being reverted/rebuilt on a given site, even manually (via _features_restore()).
Probably can only do it at a component level (e.g. "for feature x, do not revert/rebuild: field bases, user permissions"), and not an item level (e.g. for feature x, do not revert/rebuild user permissions y).
Motivation: less need for default content, by allowing anything the user wants to change to be locked but still able to run such things like fra .
However, this is NOT to replace features override (e.g. this is not to allowing people to disable reverting user permission Y then exporting it to a different feature and having both original and new enabled), though that does present an interesting idea.
Comment | File | Size | Author |
---|---|---|---|
#9 | 2047253-features-lock-9.patch | 16.35 KB | hefox |
#6 | 2047253-features-lock-??.patch | 11.99 KB | hefox |
#4 | 2047253-features-lockunlock-3.patch | 10.97 KB | hefox |
#2 | 2047253-features-lockunlock-2.patch | 11.01 KB | hefox |
#2 | Screen shot 2013-10-21 at 4.01.27 PM.png | 111.43 KB | hefox |
Comments
Comment #1
mpotter CreditAttribution: mpotter commentedHmm, I really like this idea. Would help prevent changes made on a site (like different config on production) from being overwritten by a re-build that does a feature-revert-all.
Rather than adding to the Recreate screen, perhaps a UI can be added to the feature list screen where each included component could have it's own checkbox for lock/unlock and have some sort of obvious color/style change to show which are locked? Not sure we need a whole new menu hook/page since the current View page already has all the needed information.
Comment #2
hefox CreditAttribution: hefox commentedBranch 7.x-2.x-2047253
Defiantly needs some more work, code comments, function names, link titles, explanation, etc. but looks to be working so far.
Can see current ui in screenshot; just added it to the overview page. I figure replace the links with glp complaint padlock graphics.
Comment #3
hefox CreditAttribution: hefox commentedComment #4
hefox CreditAttribution: hefox commentedI sorta want it to say "I'm sorry Dave, I'm afraid I can't do that" when someone fr a locked thing
Comment #5
Grayside CreditAttribution: Grayside commentedOverall, this looks pretty solid. I haven't really reviewed it for specific UI design.
Architecture
As a matter of basic approach, this is providing UI and using variable storage. This means we are putting locking in the hands of a site administrator. This is a bit different slant than focusing on building features as a developer or site builder where some or all elements are locked by default.
The way this is built, site owners have the power to decide which upstream configuration changes to override and ignore. In the alternate way I mention, distribution creators would control which features/components are enforced and which are default.
Practical difference would be cooking the locking into the construction of the features/info file vs. the administration of the feature/variables.
I think both constituencies are valid, just want to make sure we know who we are empowering.
Code & String Review
Extra space
Not sure exactly what differences this is talking about. How about: "Loaded feature object to be processed for component locking."
A specific component to lock.
features_feature_lock_confirm_form
1. Unlock/Lock confirmation message symmetry. Unlock names the feature and component, lock just says "this component".
Also, way longer than 80 chars. Can we multiline this?
"Submit callback to lock components of a feature."
What would it mean to say "Feature Awesome Blog (component none) has been unlocked"?
Also, it might be clearer to read things that could be multiple words to wrap them in single quotes.
I think this should be 'notice' or 'info'. It represents no change, therefore it's probably only of interest in verbose mode.
I can't think of a better description, but I think somewhere in the module README or admin page we need something to explain what locking means in greater detail.
Difference between features_feature_locked and features_feature_lock is too subtle.
features_feature_is_locked and features_feature_lock?
Comment #6
hefox CreditAttribution: hefox commentedPatch done while d.o was down, adding icons to links (not updated for stuff mention above)
Comment #7
Eric_A CreditAttribution: Eric_A commentedSeems that commit a338503 is a slightly modified version of the patch in #4?
Comment #8
hefox CreditAttribution: hefox commentedYep, and that commit is to branch 7.x-2.x-2047253
Should update that branch for #6; I believe pushing was down when I was working on that patch. And I forgot I'd made a branch for this issue
Comment #9
hefox CreditAttribution: hefox commentedAdding component level locking and allow rebuilding mode
7.x-2.x-2047253 is up to date with this patch.
Comment #11
mpotter CreditAttribution: mpotter commentedNice work! Committed this to the main 7.x-2.x dev branch. Did some testing here and it looks pretty good and very useful. Might want to add additional tweaks later, for example in the "drush fd" output to show a component is locked. But people can tweak that kind of stuff by adding new issues/patches.
Comment #13
jaxpax CreditAttribution: jaxpax commentedLove this Features feature!
Comment #14
BillyTom CreditAttribution: BillyTom commentedThe page about reverting features should be updated with this new information about features beeing lockable https://www.drupal.org/node/582680
Comment #15
nedjoI added some basic notes to the documentation page at https://www.drupal.org/node/582680.