Drush fails if parent of Drupal root directory contains a backup of the settings.php file

I have the same problem. I'm using MAMP and two devel sites on the same multi-site install, drush works on one site but not the other, just give 'Drush command could not be completed'. Adding the -d switch and get:

Found command: status [0.018 sec]                                    [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.019 sec]   [bootstrap]
Initialized Drupal 6.13 root directory at                               [notice]
/Users/matthewyoung/devel/drupal/drupal-6/drupal-6 [0.026 sec]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.027 sec]   [bootstrap]
Drush command could not be completed. [0.206 sec]                    [error]

The site that works has lots of modules enable, the site that doesn't work is a fresh install. Both have identical settings.php except the $db_url.

Are you running drush from the site path or passing --root and --uri in the command line.

@dbabbage: 'it works' mean that the updatedb command is run succesfully by performing the updates?
If you doesn't have provied a --uri and you're running drush from /var/www/drupal/sites/example.com, drush will extract the information from the path and will set:

Site Path         : sites/example.com
Site URI          : http://example.com

it's annoying that your output is contradictory with that.... as sites/default is only used as a fallback if no --uri or path can help drush determine which is the site.... Do you have a valid site un sites/default? do you are using --uri in the drush invokation? It seems to me that the two sites that works really doesn't work (both of them has `Site Path: sites/default` isn't it?) and the one that you think doesn't work does really work but the command fails for some reason. Does it make sense? Can you perform some `drush status` withing several directories and alternatively by using --uri in order to get close to the problem?

$ drush -l http://site-A.com status
Drush command could not be completed.                                [error]
$ drush -l http://site-B.com status
  PHP configuration : /Applications/MAMP/conf/php5/php.ini
  Drupal Root       : /Users/matthewyoung/devel/drupal/drupal-6/drupal-6
  Drupal version    : 6.13
  Site Path         : sites/site-B.com
  Site URI          : http://site-B.com
  Database Driver   : mysqli
  Database Hostname : localhost
  Database Username : xxxxx
  Database Name     : xxxxx
  Database Password : xxxxx
  Database          : Connected
  Drupal Bootstrap  : Successful
  Drupal User       : Anonymous

How to debug this to find out what cause the error?

drush --debug -l http://site-A.com status

$ drush --debug -l http://site-A.com status
Found command: status [0.02 sec]                                     [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.021 sec]   [bootstrap]
Initialized Drupal 6.13 root directory at                               [notice]
/Users/matthewyoung/devel/drupal/drupal-6/drupal-6 [0.028 sec]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.029 sec]   [bootstrap]
Drush command could not be completed. [0.211 sec]                    [error]

I did this before but it doesn't show any useful information at all :(

Is there anyway to know what the error is? Is there some module I need to enable? The site that doesn't work is a fresh install of Drupal and no contents. The one that works has lots of modules enables.

@dbabbage: there's no problem with using sites/default of course

It's a weird thing and it seems we can't get more clues from drush itself. If tracing the code is an option for you, go on :)

This is a pretty subtle issue indeed - originally I was going to post that I couldn't reproduce this, but then I noticed that it could potentially cause issues if the URI is not provided, and Drush is called from a directory other than the one you want to bootstrap. Ordinarily (i.e. if the cwd does not contain a settings.php) then Drush will try it's "last resort" which is to pass Drupal a URI of "http://default" (since we have no other clues, and this actually works fine for a bunch of common cases) and see what happens. Obviously if the default site is not configured nothing good will happen, but if it is configured you will get the default site and be able to work with it.

However, if there is a settings.php in the current directory, it will pass Drupal a URI of http://[current directory name]. It is not clear how this is causing the problems described. Unless the current directory happens to be named after a sites directory (that you don't want) Drupal should pick the default site and proceed as above. The URI passed in won't be http://default, but neither http://default nor http://[current directory name] are likely to be the "correct" URIs so it shouldn't really matter.

@dbabbage where is the http://example.com coming from in your case? Is the directory above your drupal root (with the settings.php causing the problem?) named "example.com" and you have a "sites/example.com" directory with an unconfigured settings.php that is breaking Drush? If not, then there seems to be something else going on, and we will need quite a bit more detail about your directory structure, any settings.php or drushrc.php and how you are calling drush to be able to figure this out.

The attached patch checks that the current directory is within a directory named "sites" before suggesting it as a site path. If folks with issues could please test the attached patch and post results back here that would be great. I am not sure that this patch is committable, because some people use symlinks to sites, and run drush from a site directory where the parent is not named "sites" (setting the Drupal root via a drushrc) and using the auto URI pickup in this scenario. There are probably other approaches we could consider though (e.g. stop descending if you hit a directory with index.php in it).

e) I do not have any other sites configured in /sites... specifically there is no sites/example.com so that is not why Drush was breaking.

In this case my hypothesis is not correct - there must be something else going on here. If the above is the case it shouldn't matter what URI we pass into Drupal - it should always use sites/default, and use that settings.php. While we could try and improve the heuristics around URI detection I don't think that will fix the root cause of this issue.

Some other points of potential confusion:

* We decend directories to find a settings.php if no specific URI is passed in because this allows drush to bootstrap the correct site with no configuration as long as you are inside the Drupal root an anywhere inside the sites directory. As an example if I call Drush from /var/www/mydrupalroot.com/sites/mydrupalroot.com/modules/custommodule/ it will (a) decend to /var/www/mydrupalroot.com/sites/mydrupalroot.com/ find settings.php and set the URI to mydrupalroot.com. It will then(b), if no specific Drupal root directory was passed, descend to /var/www/mydrupalroot.com/, find index.php and name this directory as the Drupal root. We can't really ascend directories because we would have no idea what directory to pick at each point.

* There is no limit to how far Drush would ascend because adding a limit would not achieve anything. Let's say you have both sites/default and sites/example.org as valid sites, and you want to download a module to example.org. You start Drush from the Drupal root, but don't pass in a "-l" parameter. If Drush decends to "/" without finding a settings.php it will pass http://default, which is an incorrect fictional URI, but ensures that there is an arbitrary string in this variable (since many places in Drupal assume it is present) and Drupal will select sites/default in any case. If however there is a settings.php in /Development, then Drush will pass http://Development, which is equally arbitrary and fictional, but should result in the exact same result of sites/default. The possible exception is if you have a settings.php in a directory named example.org (even if this is "above" the Drupal root, Drush/Drupal would pick that site, since it is a valid site, however that is arguably the correct behavior and is one that I have used from time to time.

* Your message suggested that you thought the settings.php we located in (a) is actually used - however this is not the case. We simply pass the name of this directory in to Drupal as a URI "hint". If Drupal's conf_path() mechanism finds a directory in sites.php that matches the URI with the appropriate rules it will use the settings.php from that directory (this would normally be the same settings.php we found). However if the directory does not exist for whatever reason it should always fall back to sites/default if it exists, and use that settings.php.

I was stung *BADLY* by this as well. I backed up my settings.php in the root and then spent two days trying to work out why some servers worked and others didn't.

The fact that the bug still exists and this thread has been paused *three years* over a disagreement of semantics is a farce.

@DrMiaow - this issue was not paused due to a disagreement in semantics, it was because nobody who experienced the issue actually tested my patch in #15 and indicated if it fixed the issue for them or not. Perhaps you would be willing to do that?

The code in the patch looks good to me, but I can't reproduce this problem on D6 or D7. When I copy my settings.php file to the Drupal root, everything keeps working just fine. If I have sites/default/settings.php, it is found; if I have sites/mysite/settings.php, it is found if I include --uri=mysite, and it is not found without it, regardless of whether I have a copy of settings.php at the root or not. Looks like we still need confirmation that the patch is helpful.

Yes - I couldn't reproduce the problem as described, but I am also not very clear on the exact steps to reproduce.

The only issue I could find (which is what the patch fixes) was one with multisite where if you have a settings.php in your Drupal root (or similar) AND the name of your Drupal root directory matches one of your site directories, it could trigger a specific multisite, rather than sites/default, which you might not otherwise expect.

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.

Opened a PR with a slightly different implementation on github. https://github.com/drush-ops/drush/pull/159