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

fubhy’s picture

fubhy commented
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.
fubhy’s picture

fubhy commented

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?

fubhy’s picture

fubhy commented

Yeah, we still need that check ;)

jimmyko’s picture

jimmyko commented

Omega 4.1 is still having this problem.

And also the other omega drush commands cannot work as it always show omega not enabled.

================

Update: It is fixed after re-start the terminal.