Currently 'drush osub' & 'drush owiz' always enable / set the default theme on the current site even if placed elsewhere. [#1901562]

Say you wanted to create a subtheme in sites/foo.example.com you still get prompted for enabling the theme / setting the theme to default. This is problematic because that currently happens globally. I believe that we will have to implement checks that validate whether the theme can be enabled after it has been created (by checking if it can be discovered by the current drush scope / drush site alias in use). That's the only reliable way. I guess that's enough really.

Comments

Comment #1

fubhy CreditAttribution: fubhy commented 29 January 2013 at 22:07

Title:

Currently 'drush osub' & 'drush owiz' always enable a theme / set the default theme globally

» Currently 'drush osub' & 'drush owiz' always enable / set the default theme on the current site even if placed elsewhere.

Comment #2

fubhy CreditAttribution: fubhy commented 3 February 2013 at 12:13

I just refactored the way omega-wizard and omega-subtheme play together. Originally they both used a shared API function. Now, omega-wizard builds on omega-subtheme instead and invokes it internally after setting the options accordingly.

@see http://drupalcode.org/project/omega.git/commitdiff/acacc0580a91089d2046b...

It would be pretty simple now to add a validation step that checks if the theme that was just created lies in the current scope of the drush command (e.g. in sites/all or the same multisite instance that the drush command was invoked from). Alternatively we could add a check that only allows you to place the theme in either sites/all, the active profile, the active multisite or a theme that is in the current scope (one of the aforementioned three). The last solution sounds like it's the cleanest but it might confuse people when they don't see their site.example.com appear even though they have a directory for it. Thoughts?