I have a site set-up using "sites/default" (no other install on the same code-base at all).

When running drush-site-install i get

You are about to create a sites/drupal-dev-phayes/files directory and create a sites/drupal-dev-phayes/settings.php file and DROP all tables in your 'drupal_dev_phayes' database. Do you want to continue? (y/n):

Note the erroneous "drupal-dev-phayes", which should be "default".

Running drush site-install --sites-subdir=default results in the correct behavior.

Note that the documentation states:

 --sites-subdir=<directory_name>           Name of directory under 'sites' which should be created. Only needed when the subdirectory does not already exist.        Defaults to 'default'   
CommentFileSizeAuthor
#13 patch.txt652 bytesnagwani

Comments

moshe weitzman’s picture

Status: Active » Postponed (maintainer needs more info)

Do you have any options specified in a drushrc file or on the command line?

phayes’s picture

Status: Postponed (maintainer needs more info) » Active

Hi moshe,

No I don't. Also ran sudo find / -name "drushrc.php" just to make sure - nada.

phayes’s picture

Also of note, I don't have "drupal-dev-phayes" in any files anywhere except for in my setting.php database setting as "drupal_dev_phayes"

phayes’s picture

Oh, and this was not an issue for 5.1 - so this bug is new as of 5.2 (if that helps any).

moshe weitzman’s picture

Status: Active » Postponed (maintainer needs more info)

Can you paste in your settings.php? I'm curious what you have that says 'drupal-dev-phayes' there. Feel free to change the DB pasword so we can't all see it here.

phayes’s picture

Hi moshe,

I've done a bunch more work debugging this and I'm starting to hone in on the problem. It has nothing to do with my settings.php

I have all my drupal sites installed in directories that look like this

/opt/sites/drupal-dev-phayes/drupal-webroot/
/opt/sites/drupal-prod-myproject/drupal-webroot/

I think drush is getting confused by the /sites/ portion of the working directory. Note that there is no working drupal directory anywhere in the tree other than the leaf drupal-webroot.

phayes’s picture

Status: Postponed (maintainer needs more info) » Active

Another update: It's not the /sites/ part of the path that's triggering it. Something else is going on here...

phayes@drupal-dev-phayes:/opt/asdf/drupal-dev-phayes-tesing/drupal-webroot$ drush site-install

You are about to create a sites/drupal-dev-phayes-tesing/files directory and create a sites/drupal-dev-phayes-tesing/settings.php file and DROP all tables in your 'drupal_dev_phayes' database. Do you want to continue? (y/n): 
phayes’s picture

Okay, I found the problem... It has to do with how I have my settings.php configured.

I have files directory and settings.php sym-linked so that I can maintain a "clean" git repository (nothing ever shows as overridden or additional).

My files are set-up like so:

/opt/sites/drupal-dev-phayes/
/opt/sites/drupal-dev-phayes/drupal-webroot
/opt/sites/drupal-dev-phayes/settings.php
/opt/sites/drupal-dev-phayes/files
/opt/sites/drupal-dev-phayes/drupal-webroot/sites/default/settings.php --> ../../../settings.php
/opt/sites/drupal-dev-phayes/drupal-webroot/sites/default/files --> ../../../files

The problem is that function drush_site_path looks for *any* directory above it for *any* file named settings.php, without doing any further checks.

moshe weitzman’s picture

Category: bug » feature

Yeah, we have had occasional problems with that. feel free to suggest a more robust check that works for D6/D7/D8

moshe weitzman’s picture

Title: site-install command does not default to "default" » drush_site_path not robust when resolving an implied --uri
moshe weitzman’s picture

Component: Core Commands » Base system (internal API)
phayes’s picture

Assigned: Unassigned » phayes

I'm going to assign this to myself and see if I can produce a patch.

nagwani’s picture

StatusFileSize
new652 bytes

Patch for drupal_site_path. Restricted the function to look for settings.php file within web root only.

moshe weitzman’s picture

Status: Active » Reviewed & tested by the community

Seems reasonable to me. Do we have to use realpath($path) or anything like that? Will wait a bit for more feedback before committing.

moshe weitzman’s picture

Assigned: phayes » greg.1.anderson
Status: Reviewed & tested by the community » Needs review

Actually, not so sure. I see drush_get_context('DRUSH_SELECTED_DRUPAL_ROOT'); just below the changed code so this function gets called before drupal root is set. Maybe we should be using 'DRUSH_SELECTED_DRUPAL_ROOT instead.

greg.1.anderson’s picture

Assigned: greg.1.anderson » Unassigned
Status: Needs review » Needs work

The patch in #13 does not fix the problem for the configuration in #8, because #13 will still find settings.php files at the Drupal root. If the configuration shown in #8 is legitimate (and it works for Drupal, so I presume by default that we would support it for Drush), then we should stop before we reach the Drupal root. This could be accomplished by reversing the order of the call to _drush_shift_path_up($path) and the test for the Drupal root.

If we are going to stop our walk up before we get to the Drupal root, should we also refuse to look for settings.php files inside the 'sites' directory? It seems to me that spare copies of settings.php should not go in the sites folder OR the Drupal root, but as long as we're doing some sanity checks, might as well catch both of these.

You are correct that drush_site_path() is called before 'DRUSH_DRUPAL_ROOT' is set, so drush_get_context('DRUSH_SELECTED_DRUPAL_ROOT'); should be used here.

phayes’s picture

Hi @greg.1.anderson,

I've confirmed that #13 does in fact work for my configuration (#8). The search for settings.php is stopping at /opt/sites/drupal-dev-phayes/drupal-webroot/, so it never finds (the erroneous) settings.php one directory below it.

greg.1.anderson’s picture

I misread where the webroot is in the above example; sorry. The question remains whether we should stop before the webroot, or perhaps before the sites folder remains. People should not put settings files here, but Drupal does not check for them in these locations, so problems could arise. We could just document it away if we protect against settings.php files above the webroot as done in #13.

moshe weitzman’s picture

I think we should actively ignore a settings.php in DRUPAL_ROOT and in /sites. I'd like to be robust here.

nagwani’s picture

Any update required on this? Happy to patch again.

greg.1.anderson’s picture

Version: » 8.x-6.x-dev
Status: Needs work » Closed (won't fix)
Issue tags: +Needs migration

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

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.

greg.1.anderson’s picture

Issue summary: View changes

formatting