Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Patch to follow...
Comment | File | Size | Author |
---|---|---|---|
#26 | drush-conflicts-1349608-26.patch | 2.68 KB | undertext |
#19 | features-1349608-19.patch | 2.47 KB | ericduran |
#12 | features-drush-conflicts.diff | 2.48 KB | ericduran |
#11 | drush-fc.png | 18.2 KB | ericduran |
#10 | features-drush-conflicts.diff | 1.24 KB | ericduran |
Comments
Comment #1
ZenDoodles CreditAttribution: ZenDoodles commentedComment #2
ZenDoodles CreditAttribution: ZenDoodles commentedAnd one for 6.x-1.x
Comment #3
mikebell_ CreditAttribution: mikebell_ commentedTested the Drupal 6 version and works well. Couldn't apply the patch using drush make though (even though it said it was fine) so applied manual. Could be down the fact I'm already patching features as it is.
When I resolved the conflict and ran drush fc again it still showed up as conflicted, not an issue with the patch but more an issue with features.
Comment #4
febbraro CreditAttribution: febbraro commentedComment #5
scottrigbyHow about changing this function to drush_features_conflicts_all(), and reserve drush_features_conflicts() for more specific conflict info.
It could behave like this:
Then we could drill down with drush "Features conflict FEATURE_NAME":
Edit: simplified.
Comment #6
mpotter CreditAttribution: mpotter commented@scottrigby: I'm not sure that specific details conflict information is available. You are welcome to submit a patch to add this additional info. But for now I think the original patch is useful. And it doesn't preclude adding an optional argument to fc in the future (no need for 2 separate commands).
Patch in #1 applies correctly to 1.x D7 features and seems to work, so marking this as reviewed.
Comment #7
scottrigby@mpotter I was thinking about consistency with existing function/drush commands like fr & fra, fu & fua…
Comment #8
mikebell_ CreditAttribution: mikebell_ commentedI agree with @scottrigby. At least changing the function name will allow for the more specific "drush fc" later. It's also good to keep consistency.
Comment #9
hefox CreditAttribution: hefox commentedRows is never initialized as array to begin with? Also, extra space array( dt(
isn't that just =>
Doing the foreach doesn't seem to be doing anything and foreaches are slow.
Also: agree with others about renaming the function
Comment #10
ericduran CreditAttribution: ericduran commentedI needed this on a project and I wrote the code before even looking in the issue queue :-/ and now that I was about to post the patch I search for it and found this issue :-/
So here's my patch, is completely different then the other patch and also doesn't take into account anyones comment because again I wrote it before looking in here.
:-/
I took a couple of different approached I list the feature name, the feature is conflicting with, the component and then the individual component name.
I attached a screenshot of what it display. Lol sorry for the blackout I was wayyy to lazy to set up a environment with conflicting features instead of just demoing what I already have.
Comment #11
ericduran CreditAttribution: ericduran commentedActually here's an appropriate screenshot.
Comment #12
ericduran CreditAttribution: ericduran commentedHere's an updated patch with the recommendations mention above.
Note:
- I rename the function to drush feature-conflicts-all and shortcuts fca.
- I have it throw drush errors when there's conflicts. This helps if you run this command on a CI environment like Jenkins so the build can fail if someone commits conflicting features.
- I didn't make it take a parameters because this essentially shows everything you need to see in one screen.
- I know the foreach look horrible especially since I think is like 4 or 5 level deep but sadly this is because of the values return from features_get_conflicts. If someone knows away around that please let me know. Other wise I think this is good.
Changing the status as needs review as I think this last patch should be pretty good or at least close to done.
Comment #13
ericduran CreditAttribution: ericduran commentedComment #14
mpotter CreditAttribution: mpotter commentedApplied to latest 7.x-1.x-dev version and seems to work fine. Marking this as Reviewed.
One enhancement to think about for the future is an option --enabled that only shows conflicts with enabled modules. When I clone a Feature and then disable the original, I know that it's going to cause conflicts, but I don't care about seeing them (and wouldn't want them to generate any errors)
Comment #15
mpotter CreditAttribution: mpotter commented@ericduran: Also, please review this: http://drupal.org/patch/submit for patch file naming conventions.
Comment #16
ericduran CreditAttribution: ericduran commented@mpotter, ha thanks for the heads up. I had no clue that patch naming format was an actual standard. I guess it does make sense for people using things like drush make. :)
Comment #17
Grayside CreditAttribution: Grayside commentedWhy not just
features-conflicts
? features-conflicts-all is a fairly long string, and a more specific use case (if currently the only use case) than we necessarily need to codify into the command name.Mismatched pluralization.
Comment #18
scottrigbyYeah, if it's showing component & component name already i can't see any reason why we wouldn't just stick with features-conflicts like zendoodles initially suggested. I just wanted to leave open the space for that kind of detail.
Comment #19
ericduran CreditAttribution: ericduran commentedOk, now we have both patches one with feature-conflicts and one with feature-conflicts-all :)
So this should be good to go.
Comment #21
hefox CreditAttribution: hefox commentedHah, this works and applies (mostly, the help got rejected) to d6.
Using it on a code base that has many conflicting features, having an option to specify what feature would be quite nice (and could go into a separate feature request after this is committed, but it'd prob be easy to quickly add it here). I'd imagine drush features-conflicts by itself list all features, and drush features-conflicts [feature] would show just that feature's conflicts (not sure if drush features-conflicts [feature_a] [feature_b] would show conflicts between feature_a and feature_b or all conflicts for both features.. huh).
Comment #22
hefox CreditAttribution: hefox commentedDrush fc got taken by drush features-components :-/
Comment #23
Grayside CreditAttribution: Grayside commentedfcon?
Comment #24
Kristen PolI just applied #19 against 7.x-2.0-rc2 and got errors:
Comment #25
mpotter CreditAttribution: mpotter commentedPatch needs to be re-rolled against latest -dev version to get reviewed and tested. When it's re-rolled, remember to switch the Version to 2.x-dev so the automated tester finds it.
Comment #26
undertext CreditAttribution: undertext commentedReroll