Features pipe workflow to build up a feature is extremely powerful, but also fairly presumptuous. Unless you know how to code and add in a pipe alter hook or or edit the feature by hand afterword, you're stuck with these items. This can be bad as it an lead to conflicts if the thing added is say, the taxonomy tag vocabulary, which is a global type taxonomy so potential for conflict is high (see #1397336: Developing contribable features that have items that may or may not be there on a drupal install for further discussion on that).

Potential ways this feature request could manifest:

  • User is able to veto any addition to a feature
  • Components are added as suggestions to add but not forced in (meh)
  • Some sort of ability to add as a semi-there component (in relation to #1397336: Developing contribable features that have items that may or may not be there on a drupal install , i.e. a 'fallback' type component), or, example, changing dependencies to recommendations (I believe development seed have some sort of module or blog post advocating for recommendations of modules vs dependencies). Very few features actually depend on views, but if they include a view, views is added a dependency (views enhances a feature).

(I'm sure this has been brought up before but couldn't find relevant topic).

CommentFileSizeAuthor
#19 features_1400298_exclude-19.patch18.64 KBmpotter
#17 features_1400298_exclude-16.patch20.21 KBmpotter
#13 features_1400298_exclude-13.patch18.31 KBhefox
#12 features_1400298_exclude-12.patch18.31 KBhefox
#11 features_1400298_exclude-11.patch17.21 KBhefox
#5 features_1400298_exclude-4.patch12.34 KBhefox
#4 features_1400298_exclude.patch8.02 KBhefox

Comments

Grayside’s picture

Grayside commented

I kind of like #1 and #3.

In the Features UI, add a little "x" button on hover over any element---automatic or specifically chosen.

xen’s picture

xen commented

Regarding #1, Grayside http://drupal.org/project/features_plumber already does that. Maybe it should be in features?

I also like #3, complex as it is. It should be up to the feature creator whether views are a recommendation (bad name, providing a default view doesn't mean you're recommending the use of views) or a dependency.

Grayside’s picture

Grayside commented

Xen, agreed, Features Plumber and Features Tools are both a mix of corner case ideas and core concepts. I believe they spun off out of impatience with the long slowdown in movement in Features itself. Fed up with the slow process, I expect it will be up to Features maintainers or other developers to reach out and pull some of that functionality back in. E.g., Features Linking, more sophisticated viewing of components & component status via drush, etc.

hefox’s picture

hefox commented
Status: Active » Needs work
StatusFileSize
new features_1400298_exclude.patch8.02 KB

Beginning of a patch. Works in ui, haven't touched drush, but need to totally redo the .admin stuff

hefox’s picture

hefox commented
StatusFileSize
new features_1400298_exclude-4.patch12.34 KB

Next step in the patch, moves processing into the form definition so that can store information in $form_state.

Here's a simple of info file produced

name = "machineaname"
description = "machinaname"
core = "7.x"
package = "Features"
dependencies[] = "features"
dependencies[] = "taxonomy"
features[field][] = "node-article-field_tags"
features[node][] = "article"
features[taxonomy][] = "tags"
features_base[node][article] = "article"
features_exclude[dependencies][field_sql_storage] = "field_sql_storage"
features_exclude[dependencies][node] = "node"
features_exclude[dependencies][text] = "text"
features_exclude[field][node-article-field_image] = "node-article-field_image"
features_exclude[field][node-article-body] = "node-article-body"

Note

  • Adds a features_base key so can track what the user also exported. This will allow getting rid of orphan items that are were auto-detected and added then later not needed, etc.
  • features_exlude is items exlcuded. I did *not* exclude the dependencies, this is an issue with hidden modules I believe, likely need to show hidden modules so users can choice to exclude or not.
  • the act of excluding is unchecking the item. The submit handles detects what items were unselected, calculates the feature, and if those items were added back in, it then and only then adds them as features_excludes. This is to prevent the features_exclude from getting excessive. For the drush command, will add similar logic when something is removed from a feature, or maybe just add a deliberate thing for adding excludes.

Next I need to redo how the ajax is doing it. Currently features has a bug that autodetected items don't automatically appear as checked, leading to quite a confusing user expierence. This fixes it, but means the input has to be refreshed ever check.. not good. My guess is the quickest way is to add a "preview" button that the ajax is attached to, and remove the on each check previewing. Meh.

Grayside’s picture

Grayside commented

I don't like using features_exclude as the root namespace.

Would it be too much complexity to use something like the Drush Make model, so:

features[node][] = "blog"

or

features[node][blog] = "exclude"

which would dovetail with the idea I was fumbling for in #1397336-1: Developing contribable features that have items that may or may not be there on a drupal install:

features[node][blog] = "fallback"
hefox’s picture

hefox commented

Too much a chance to break existing contrib modules if changing the format of features -- not worth it.

Grayside’s picture

Grayside commented

I'm saying to support both existing and "verbose" versions, as with Drush Make. That should retain compatibility with all existing features.

hefox’s picture

hefox commented

Features has hooks that pass around an array that becomes the info file. Anyone using $export['features'] in those various features will break if the logic is changed. It's not worth breaking all those modules.

Grayside’s picture

Grayside commented

Okay, yeah. That makes sense. Still, not elegant. That kind of compatibility change should be reserved for a 7.x-2.0 upgrade...

hefox’s picture

hefox commented
StatusFileSize
new features_1400298_exclude-11.patch17.21 KB

Still buggy specially on recreate, but getting close.

Had to remove the ajax on the checkbox and add a preview button, cause can't really be changing the checkboxes on every single click cause it refreshes the entire element so noot usable. Would like some eyes.

hefox’s picture

hefox commented
Status: Needs work » Needs review
StatusFileSize
new features_1400298_exclude-12.patch18.31 KB

Fixed some bugs

To go over what and why of this patch:
Adds the ability to exclude; A new key is added to info, features_exclude, that indicates an item should be excluded. By unchecking the checkbox on the features create/recreate form, it removes the item, but only marks as exclude if the item was automatically added (to prevet it from being automatically added.
Changes features_populate function so it takes in information for export array (ie. features_exclude)
Changes the re/create form so that checkboxes don't automatically preview, instead there's a preview button :/. This is due to needing fix the bug that automatically added items are not checked every, making a very confusing user experience (need to uncheck them to remove them, aye!).
Adds a feature_base key that tracks what user has specially added to the export so can tell what was automatically added vs what wasn't, even while recreating. This might be able to be removed, but feel like it's a step forward to making features easier to use. Right now it's hard to tell whether automatically added items were purposefully added or not. If features_base isn't set for a module, features key is used so upgrade path should be fine.

edit: ack, white space got in. Trying to install a trailing white space plugin, but apparently it's freezing my IDE.

hefox’s picture

hefox commented
StatusFileSize
new features_1400298_exclude-13.patch18.31 KB

Okkkay, the "trailing white space" plugin has thrice frozen on me, so removes the white spaces manually. (Weird, used it on other computers before, sigh). I'm sure there's other coding style issues I need to cleanup but dinnertime.

webkenny’s picture

webkenny commented

Marked #1601114: No field granularity allowed when selecting content types for export as the cousin (a.k.a duplicate) of this issue. :) - Happy to help here. I'll review the patches included.

ezra-g’s picture

ezra-g commented
Issue tags: +commonslove

Adding the 'commonslove' tag since this kind of granular exportability is key to making Commons (and other distributions) more extendable and maintainable.

mpotter’s picture

mpotter commented
Status: Needs review » Needs work

Re-rolled this against the latest 1.x-dev release to give it some love.

I like the approach of this. In fact, it took me a while to figure out how it works since it's so seamless with the existing checkboxes (compared with all the extra checkboxes added by features_plumber).

A couple of comments and requests for help:

1) I added a content-type to an export, then unchecked a couple of the fields that were auto-detected. When I downloaded the feature, I had some lines like:

features_exclude[dependencies][] = field_sql_storage
features_exclude[dependencies][] = text
features_exclude[dependencies][node] = node

in my feature.info file that don't seem right. I never explicitly unchecked any dependancies, so wondering why these got marked for exclusion. They are the "auto-detected" dependancies, but seems like they should be handled the same as other components we want to exclude.

2) For people used to the old checkbox UI, I think we need some improvements to remind people to Preview. I'd like to see some simple Javascript that highlights the Preview button whenever a change is made to the Components checkbox list. When the Preview button has been highlighted, I'd like to see the Download button disabled, with a comment "Preview before Downloading" or something like that. I just want to make sure people preview their feature to see what is going to be exported before using the Download function. Perhaps after clicking Preview (which would un-highlight the Preview button) maybe the Download button then gets highlighted? Any UX help here would be appreciated.

3) minor: not sure putting the Preview button on top of the exportable list is the best place...that column is already pretty large. Wonder if the Preview button could be right-aligned next to the Edit Components dropdown selector.

This is exactly the kind of usability improvements that I'd like to make to Features right now, so please help with this patch!

mpotter’s picture

mpotter commented
StatusFileSize
new features_1400298_exclude-16.patch20.21 KB

Oops, here is the patch file.

mpotter’s picture

mpotter commented
Title: Vetoing/different handling of pipped in components to a feature » Removing auto-detected components from a feature (UI update, removing Ajax)
Priority: Normal » Major

When I was going through cleaning up the issue queue, this was the topic that had the most "dups". Lots of issues revolve around the current use of Ajax when you click a selection box for a component. I'm going to actively work on this issue and try to set up the javascript delay to auto-trigger the Preview button. I'm also bumping the priority on this because it tries to address the base cause of so many other issues and deserves more love.

mpotter’s picture

mpotter commented
StatusFileSize
new features_1400298_exclude-19.patch18.64 KB

Oh, and because of the extensive code changes in the latest -dev version, #17 no longer applied, so here is the latest patch. No changes, just building it vs the current -dev release.

mpotter’s picture

mpotter commented

From #16, the issue with the field_sql_storage being added to the features_exclude[dependencies] was because of an older features export. If I exported the feature first using the latest -dev version (which no longer added the field_sql_storage), then this was fixed.

I'm going to take a stab at adding a javascript timer to auto-click the Preview button after a period of inactivity. What I'd like help with (hefox?) is determining if we really need the features_base[] stuff in the *.info file. It doubles the amount of code in that file and some people actually do edit their features by hand and this will really complicate that task. Hefox mentions above that he's not sure if the features_base stuff is needed, so let's see if we can come up with a version that doesn't require it.

hefox’s picture

hefox commented

For the UI changes, I don't think the features_base stuff is needed. The features_base was for tracking what the user actually checked across creations. It'd allow stuff like detecting that dependency "views" was added automatically, and not by hand, and so if a feature features-update no longer auto detects views, it knows it can drop that views depedency. It would mean, to edit .info, instead of editing dependencies[] = "views", features[base][depdenceies][] = views would be edited.

It can be separated into a future issue imo.

mpotter’s picture

mpotter commented

Maybe instead of exporting the "base" stuff (which doubles the number of *.info entries) we should just export the "auto-detected" stuff. This might also help for people who just edit the code file directly since you'd be able to easily tell if something in *.info was added explicitly or whether it was auto-detected (and then also if it was specifically excluded).

features[autodetect][dependencies][] = views

How does that sound?

socialnicheguru’s picture

socialnicheguru commented

why not just use ftools or features plumber?

Grayside’s picture

Grayside commented

Because the pratfalls and weakpoints of a module should be solved within the module if possible, and the solution can often be much better from inside than working around the edges. That is why modules that go into Drupal core often change.

mpotter’s picture

mpotter commented
Status: Needs work » Closed (duplicate)

I have created a new Branch and topic to implement this issue: #1810134: Improve Features UI (featuresUI-1.1 branch)

Closing this issue now as a dup of the new work.

Grayside’s picture

Grayside commented

I understood this as being more an architectural underpinning of features rather than part of the UI specifically. Either way, exciting to see these concepts move forward!