Drush update/recreate (add components)

Seems I'm not the only one wanting to dump from the commandline. I've attached my take.

It's also my apology for not reading the docs.

Fixing stupidity...

@xen nice looking patch, I'll test that soon.

I do this all the time by hand, so I definitely see the utility.

The other thing I do by hand is start coding a module then start adding features components. I will experiment with removing the limitation to only features. There's no need for it with drush features-update. Wrong. There is a need for it. But this should still be the command to feature-ize a module. Will take further thought, and this should be a followup issue.

EDIT: Bah, a features-components command is dumb. But a fallback if a component type is correct but a bad component name is put in place, a la drush variable-get, would be very fine.

Core functionality of adding new components to an existing feature works well.

The attached patch throws a trim() around the component arguments since the current UI calls for occasional bits of cut-n-paste in the command-line.

Also added _drush_features_component_list() to try to make some recommendations about which component the user might have meant, instead of simply reporting failure.

I'm not sure about this, so while I added the function for features_add where I thought it would make sense, I did not refactor any existing component listing code to make use of the new function.

Okay, further work and further testing, there is a bug that seems to prevent components like Variable and Node from working successfully. However, user permissions do work. This bug also appears to be present in #2.

The attached patch stabilizes and upgrades the recommendation system. It is now possible to enter a component fragment and get a list of options to choose from.

However, with that bug, this is a Needs Work. I do not have further time right now to debug.

subscribe

I've just tested the #5 patch, and I have no difficulty dumping vars nor node types.

I do get a "Missing argument 4 for strongarm_features_pipe_node_alter()" warning, but it seems harmless.

Anyone else tested with/without success?

As i did this last DrupalCon, it only seems fitting that I revisit it.

This is just a reroll of #5 against head, with some whitespace fixing.

I still don't have an issue with dumping node types or variables, so I can't reproduce Graysides problem.

Thank you, but moving feature requests like this to d7 XD

Well, I just tried cherry-picking the above patch to 7.x, and it still seems to work. Patch attached.

Now, if people would try to break it...

Cool, setting back to needs review. (I've had several patches work on d7 also)

First off, I totally love this functionality, the main stuff seems to work very nicely. Great job!

I have tested the patch with variables, permissions, views and panel pages so far, and it seems to be working flawlessly.

One thing worries me though. Should we really list all components even though many of them already exists in other features? The Features UI doesn't show components that are already exported in other features, so we should be able to this here as well?

I didn't get around to screening them out, but it would be a worthwhile dovetailing command or option to be able to identify similar components, already exported, and where they are. There is often a need to reshuffle your feature components, especially when still working out a personal approach to Features structuring.

In another export dumping project, I found it handy to have pattern matching in the component arguments, which made it possible to dump all the fields of a content type or a row of similar variables, without having to list them all on the command line.

Also, it feels wrong to have to attempt a dump without any components, in order to get a listing of components. We should have a listing command with switches for listing specific types and what specific feature modules define.

Both should default to considering only components that's not already part of a feature, but with switches to override.

I'd cut some patches, but I have a busy week before me, so I thought I'd air the ideas first.

Great stuff, I would gladly review any improvements! However, it might be better to get a simpler patch in from the beginning, and then create separate patches to improve on it? It's up to you of course, but it's easier to review smaller changes.

Either way is fine by me, if the current patch still needs some work, I might as well...

I can always keep the patches separate in my local repo, then it's easy to split out the additions.

Looks sweet, assigning.

Here's a quick re-roll of #10 against 7.x-1.x-dev. . . I'm taking a look at this today, but not sure if I'll be able to wrap it up.

EDIT: Doh! Just ignore this patch. I should have been working off of #8

OK... So here is a re-roll of #8 against 7.x-1.x-dev.

EDIT: Which is magically 0 bytes. Doh! Thanks d.o;)

OK... So here, for real this time is a re-roll of #8 against 7.x-1.x-dev. Sorry for all the noise:)

This reroll is only to fix the spacing of the @param docs, so I don't feel bad about RTBCing as well.
Works as advertised, it is a HUGE time saver.

No patch credit for me, please.

Once it's committed, please mark as "patch to be ported", not "fixed". Just in case I can backport it :)

My favorite patch ever? Maybe. Committed to 7.x, we can tweak later as needed.

http://drupalcode.org/project/features.git/commit/bbaaad0

Patch applies cleanly and works against 6.x.

However, marking as postponed due to #1331278: Drush features-add and features-export are confusingly similar, and overly verbose.

@hefox:
Also note that I experienced it failing hard when hacking around with the features_override stuff. We should remember to test that along the way.

Patch applies cleanly and works against 6.x.

Why is it only committed on 7.x branch? I keep on trying to "drush fa" on my D6 sites and failing/flailing. I understand that some refactoring may occur (as discussed in #1331278), but can't we commit to the 6-dev branch?

Edit: Just verified independently that the patch does apply cleanly and works against 6.x

Looks like this is unblocked now.

Rerolled.

Am inclined to mark this RTBC and to leave any Features_Override issues for later.