Hi guys,

This ones been bugging me for a while now, and I finally decided to look into it.

Currently, if I type drush @alias dl [module] it will download it to the the platforms sites/all/modules directory, whereas it should download it into the @alias site directory just as it would if I where to type drush dl [module] inside /sites/[@alias].

It's a simple fix, the following code just needs to be set in each drushrc.php:

$options['use-site-dir'] = TRUE;

In the case that you don't deem this to be a bug report, but a personal preference, then I would recommend at least making it an option somewhere, because this does really bug me.

Cheers,
Deciphered.

Comments

Anonymous’s picture

Anonymous (not verified) commented

Be aware that if you place modules / themes / libraries in the site-specific directory, you can *never* apply an upgrade of those through the Migrate process (which is the recommended way to upgrade codebases on sites: moving them between platforms).

This is because the entire site-specific directory gets tarballed up and moved onto the new platform, so those modules/libraries/themes are carried across to the new platform, and because the site-specific modules take precedence over those in /profiles/ or /sites/all, they'll always be used over anything else.

For this reason I'm not comfortable with this being the default. If you don't want things 'public' to other sites by putting them in /sites/all, you should make a separate install profile for your site, and put the modules in the /profiles/$yourprofile/modules dir. Only sites using that profile will then see those modules, and you can then maintain the recommended 'platform to platform upgrades' approach (since your modules etc are detached from the site itself).

deciphered’s picture

deciphered commented

Hi mig5,

That's a fair comment, in which case I would suggest the possibility of it being a site by site setting as I only personally plan on using this for development purposes on my local setup, which the migration/upgrade path wouldn't specifically be applicable in the majority of cases.

 

However, a flipside to that is that if you want to download to a 'public' location, you can do that currently with the @platform_alias, but if you don't want it to be 'public', the only way to currently do that is by being in the sites directory itself.

Why have two remote commands for the platform and no remote command for the site?

charos’s picture

charos commented

As Deciphered says, I also find it rather confusing to download modules in the platform when the alias is for a specific site. If I need the module to be available for all sites , I can always use the platform alias.

The way I see it and excuse my ignorance in case this contradicts the Aegir concept, modules that are stored within the module directory of a site (site_a/modules) are static and are not overwritten by any changes during the migrate. This is a way to keep modules intact (eg. applied patches that are specific only for site_a) during a migrate. Module upgrades that are platform -wide can stay in the /platform/sites/all/modules.

Here's an example : site_a needs Views 2 , while the rest of the sites in the same platform need Views 3. The way I think is logical is to use drush @site_a to download Views 2 and drush @platform to use Views 3.
I can't see how this breaks the upgrade during Migration.

I'm a newcomer with Aegir so if my logic is flawed, sorry in advance :)

omega8cc’s picture

omega8cc commented
Category: bug » feature
Status: Active » Closed (works as designed)

The real world experience confirms what mig5 wrote above.

You may want to read also: http://community.aegirproject.org/content/best-recipes-disaster-and-how-...

Besides, it is related to Drush behavior, so there is nothing Aegir specific here, other that using sites/domain space is a recipe for disaster, sooner than later.

I'm closing this as 'works as designed'. Feel free to disagree.