Site-install in multi-site with Drush aliases and Drupal sites.php aliases

Nice one! I've been looking for that context variable! Are they documented anywhere?
Anyhow, new patch attached. It now works regardless of how the site dir is specified!
I like this one much better.

I removed drush_get_option('sites-subdir', ... because I noticed that DRUSH_DRUPAL_SITE_ROOT picks that up.
Also DRUSH_DRUPAL_SITE is not undefined, it just returns the wrong value, as far as I am concerned.

Let's stick with scenario I described in my post. Let's also assume I run the following commands.

$ drush si my-profile -l mysitedir
$ drush si my-profile --sites-subdir=mysitedir
$ cd /path/to/sites/mysitedir && drush si my-profile
$ drush si my-profile --uri=http://a.mysite.com
$ drush @mysite.a si my-profile 

With my patch, $sites_subdir will always be set to mysitedir.
With the unpatched code, $sites_subdir will be mysitedir with the first three commands, but will be a.mysite.com with the other two commands.

Given that there is a sites.php telling Drupal that a.mysite.com is mapped onto mysitedir, I reckon the current behaviour is wrong, and my patch should fix it.

Hi Greg.

Not sure what you are asking me to do :)
If you try and replicate what I explained in the original post and then run the commands in #4 with and without the patch, then you should see what I mean.

Please do tell me if my original post is not detailed enough.

Right! Will do.

Yeah, I still have to write the test in order for this to be accepted. But work is taking all my time.

I am not sure the test is checking the right thing to be honest, but I might be missing something that wamilton and the others have inferred.

My patch was never proposed to say that --sites-subdir was redundant. It was proposed because, in site-install, drush's ability to detect the right site folder was inconsistent across different ways of doing it under particular circumstances. I'll try and explain the scenario a bit better than I did in the past.

We have a number of sites in multisite configuration. Let's say that ls sites gives us this

all
example.com
example.net
default

The default folder is not used.

The circumstances I am talking about are to be found in sites.php:

<?php

$sites['example.com'] = 'example.com'; // Live domain.
$sites['www.example.com'] = 'example.com'; // Live domain.
$sites['com.live.mycompany.it'] = 'example.com'; // Alternate live domain (for admin access, or similar).
$sites['com.stage.mycompany.it'] = 'example.com'; // Stage domain.
$sites['com.test.mycompany.it'] = 'example.com'; // Integration/QA domain.
$sites['com.local.mycompany.it'] = 'example.com'; // Local development domain.

$sites['example.net'] = 'example.net'; // Live domain.
$sites['www.example.net'] = 'example.net'; // Live domain.
$sites['net.live.mycompany.it'] = 'example.net'; // Alternate live domain (for admin access, or similar).
$sites['net.stage.mycompany.it'] = 'example.net'; // Stage domain.
$sites['net.test.mycompany.it'] = 'example.net'; // Integration/QA domain.
$sites['net.local.mycompany.it'] = 'example.net'; // Local development domain.

We also have aliases set up for all sites, e.g.

$aliases["local.project.com"] = array (
  'root' => '/var/www/drupal-root',
  'uri' => 'com.local.mycompany.it',
  'path-aliases' => 
  array (
    '%site' => 'sites/example.com/',
  ),
  '#name' => 'local.project.com',
  '#file' => '/var/www/drupal-root/sites/all/drush/local.project.aliases.drushrc.php',
);

$aliases["local.project.net"] = array (
  'root' => '/var/www/drupal-root',
  'uri' => 'net.local.mycompany.it',
  'path-aliases' => 
  array (
    '%site' => 'sites/example.net/',
  ),
  '#name' => 'local.project.net',
  '#file' => '/var/www/drupal-root/sites/all/drush/local.project.aliases.drushrc.php',
);

Replace local with either live, stage or test and you'll have all the possible aliases that are compiled to target these sites.

So far I've set the scenario, and I hope, if I am not mistaken anything, that we all agree that in every circumstance, the site folder for the example.com site is always example.com regardless of whether the site is being accessed from one or the other of all the acceptable URLs mapped to that folder (e.g. www.example.com or com.local.mycompany.it). Same thing holds for example.net and all other potential sites (all set-up the same).

That said, here's a number of ways I could install one of these sites with drush:

$ drush si my-profile -l example.com
$ drush si my-profile --sites-subdir=example.com
$ cd /path/to/sites/example.com && drush si my-profile
$ drush si my-profile --uri=http://com.local.mycompany.it
$ drush @local.project.com si my-profile 

With the patch applied, $sites_subdir will always be set to example.com.
With the non-patched code, $sites_subdir will be set to example.com (correct) with the first three commands, but will be set to com.local.mycompany.it (incorrect) with the last two commands.

Given that there is a sites.php telling Drupal that com.local.mycompany.it is mapped onto the example.com directory, I reckon the behaviour of the non-patched code is wrong, whereas the patch brings in the correct behaviour.

Unfortunately I am not too sure how to reflect this into a valid test, being quite unfamiliar with drush internals.
I'll try and have a go now, that I've got some spare time on my hands (part of which I've just burnt to write all this :D).

Cheers,

V

Moved to a pull request on Github.