drush-ops/drush — pull request #106 by vincenzo (2013-09-15 08:18:26+00:00)
Title: Site-install in multi-site with Drush aliases and Drupal sites.php aliases

This pull request follows from [this issue](https://drupal.org/node/1824072) that was ongoing discussion on `drupal.org`.

I'll copy the description of the issue from the last comment I put there:

This change was never proposed to say that `--sites-subdir` was redundant (see previous comments on the issue linked above). 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
'/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:

```bash
$ 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

PS: this might still need a unit test done for it; any contribution would be appreciated.