Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
At the moment, Inkribbon is probably the only theme with Drush support (not sure). It wouldn’t suprise me if Zen or other popular base themes would start supporting it in the near future, though.
Drush doesn’t look in sites/all/themes for *.drush.inc files by default, so people need to change their config to be able to use commands provided by themes.
Would it be a good idea to add sites/all/themes to the list of default directories?
Comment | File | Size | Author |
---|---|---|---|
#27 | 535788-27-theme.patch | 564 bytes | JohnAlbin |
#17 | theme-535788-17.patch | 894 bytes | greg.1.anderson |
#7 | 535788.patch | 1.5 KB | jonhattan |
#3 | drush-535788.patch | 1.06 KB | jasonn1234 |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commented"Create a new Inkribbon sub theme.". Nice command!
Yes, we should add themes to the search path for commands.
Comment #2
jasonn1234 CreditAttribution: jasonn1234 commentedFYI - This feature is patched here: #537280: D7 compatibility
EDIT: ^^ *not* see next comment for patch.
Comment #3
jasonn1234 CreditAttribution: jasonn1234 commentedPatch attached. With this patch applied I was able to see the command with "drush help" and create a couple of inkribbon subthemes.
There might be some additional work required. Honestly - I don't really understand all the dependencies / possible conflicts / issues related to this, but I thought I'd submit what I came up with just to solicit feedback and keep the ball rolling.
From irc:
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentedsystem_theme_data() does not exist in D7. needs to support all d5/d6/d7 ... i'm not too worried about duplicate drush files/commands coming from theme. they will be true dupes so it is OK that they trample on each other.
Comment #5
jonhattan`drush_get_modules()` and `drush_get_themes()` were recently introduced by `port to D7` patch.
Comment #6
moshe weitzman CreditAttribution: moshe weitzman commentedpretty trivial now. anyone care to reroll?
Comment #7
jonhattanlist_themes() return all available themes unlike module_list() that do only for enabled ones. So I switched to use drush_get_projects() and explicitly check status.
Comment #8
jonhattanComment #9
moshe weitzman CreditAttribution: moshe weitzman commentedCommitted. Thx.
Comment #10
jonhattanThere're several reasons to reverse this patch:
Author of Inkribbon has told me he dropped drush support. So there's no theme with drush support at present afaik.
In addition I can't think of distinct use case for a theme command than creating a subtheme. Perhaps I'm not imaginative enough but actually they're not already coded out there....
If the only use case is creating a subtheme,... if there is a general algorithm for subtheming... it may be created for drush core or as a contrib module.
In case there's no general algorithm and a theme provide its own command... in this case it shouldn't be necessary to enable a theme in order to create a subtheme...so themers could instruct users to move a file to ~.drush
And last but most important, the solution provided in #7 is based on a unnecessary overhead. To solve the issue it is only needed a list of names of enabled modules and themes. There're faster ways to obtain this than calling
drush_get_projects()
(that does a rebuild of system table) and iterating over it.So I bet for reversing the patch as I think commands for themes is unnecessary. If you feel this necessary, I can provide a more efficient patch if you prefer.
Comment #11
moshe weitzman CreditAttribution: moshe weitzman commentedI'm good with reverting this. If anyone objects, please speak up soon.
Comment #12
greg.1.anderson CreditAttribution: greg.1.anderson commentedThere are already a couple contrib modules for creating subthemes, so I'm in agreement.
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedrolled back.
Comment #15
JohnAlbinThere is not general algorithm for sub-theme generation. And it isn't necessary to enable a theme in order to create sub-themes. And I'm missing the logical conclusion part of “so themers could instruct users to move a file to ~.drush.” Why?
The problem with having themers move a file to ~/.drush is it requires the theme developer to maintain drush commands that will work with all past and future versions of their theme. Zen just opened up a 4th major supported branch (2 in D6, 2 in D7) and I'd rather not deal with support problems because someone is using the wrong version of the drush commands. :-p
I don't see a reason why any installed theme can't have live drush commands. Drupal core already runs the code of disabled base themes of enabled sub-themes.
Comment #16
greg.1.anderson CreditAttribution: greg.1.anderson commentedHi John, thank you for your comments. If you would like to support zen subtheme creation via drush in zen, I for one am strongly in favor of supporting it. Part of the background for the discussion above is that
_drush_find_commandfiles
recently changed so that only enabled modules are searched for .drush files. This made things work a lot better in several instances--for modules, at least. For example, by not including disabled modules, it meant that the sanitize options for disabled modules would not be added to the list of options in sql-sync -- and there are other examples where running the drush hooks would just do the wrong thing (their code would not run) if their associated module was disabled.It seems to me that all we would need to do to support this is add:
to
DRUSH_BOOTSTRAP_DRUPAL_SITE
outside of theif ($phase_max < DRUSH_BOOTSTRAP_DRUPAL_FULL)
. Then we'd get theme .drush.inc files at bootstrap_site and higher for all themes, disabled or not. Most users should not have too many themes installed, so I don't think there would be a big performance hit for including them all. I also agree with your point that themes behave differently than modules, and there would be no harm in including them all. I don't expect that theme .drush files would attempt to hook drush in the same way that a module .drush file would, so I think this should be safe enough.Comment #17
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis works well for me, and is very simple. If there are no issues with it, it would be good to commit to HEAD and to the upcoming 4.3 release.
Comment #18
moshe weitzman CreditAttribution: moshe weitzman commentedI'd like for jonhattan to review this as he wanted to roll back the original patch.
Comment #19
greg.1.anderson CreditAttribution: greg.1.anderson commentedI agree that jonhattan should review, but I think that the issue with #7 was with drush_get_projects in BOOTSTRAP_FULL, which I do not think is necessary.
One thing that #7 does that I do not do in #17 is include
$searchpath[] = conf_path() . '/themes';
in BOOTSTRAP_SITE. This allows Drupal core themes to provide drush.inc files; I am neutral about putting that back in.Comment #20
jonhattanGreg's approach is different and lightweight. I'm aligned with #16.
Comment #21
jonhattanFor clarification, a quote from #10:
Comment #22
greg.1.anderson CreditAttribution: greg.1.anderson commentedCommitted; thanks!
Comment #23
greg.1.anderson CreditAttribution: greg.1.anderson commentedOh yes, I suggest that we also put this back in 4.x so that zen can use it in the not-too-distant future.
Comment #24
danillonunes CreditAttribution: danillonunes commented#17 sounds great, but it will works with themes living in /sites/exemple.com/themes too?
Comment #25
greg.1.anderson CreditAttribution: greg.1.anderson commentedOh, yes, I misspoke in #19; conf_path() is sites/example.com, so we should probably add that one back in too.
Comment #26
greg.1.anderson CreditAttribution: greg.1.anderson commentedCommitted http://drupalcode.org/project/drush.git/commit/a294614 to master; would be good to get this in drush-4.3 too.
Comment #27
JohnAlbinHere's a patch that applies to the 7.x-4.x branch. That's the right branch for 4.x, yes?
I've also committed a zen.drush.inc file to Zen's 7.x-3.x branch. So you can test this patch against the latest Zen 7.x-3.x-dev release.
Comment #28
jonhattanThanks John for the patch, yes, 7.x-4.x is the branch.
Patches to 4.x usually get commited when we plan a new release (Mark is the maintainer for 4.x). Issue version, status and assignment were ok.
Comment #29
msonnabaum CreditAttribution: msonnabaum commentedBackported to 4.
Comment #30
JohnAlbinyayz! :-D