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'
Comments
Comment #1
moshe weitzman commentedDo you have any options specified in a drushrc file or on the command line?
Comment #2
phayes commentedHi moshe,
No I don't. Also ran
sudo find / -name "drushrc.php"just to make sure - nada.Comment #3
phayes commentedAlso 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"
Comment #4
phayes commentedOh, and this was not an issue for 5.1 - so this bug is new as of 5.2 (if that helps any).
Comment #5
moshe weitzman commentedCan 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.
Comment #6
phayes commentedHi 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 theNote that there is no working drupal directory anywhere in the tree other than the leaf/sites/portion of the working directory.drupal-webroot.Comment #7
phayes commentedAnother update: It's not the
/sites/part of the path that's triggering it. Something else is going on here...Comment #8
phayes commentedOkay, 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:
The problem is that function
drush_site_pathlooks for *any* directory above it for *any* file namedsettings.php, without doing any further checks.Comment #9
moshe weitzman commentedYeah, we have had occasional problems with that. feel free to suggest a more robust check that works for D6/D7/D8
Comment #10
moshe weitzman commentedComment #11
moshe weitzman commentedComment #12
phayes commentedI'm going to assign this to myself and see if I can produce a patch.
Comment #13
nagwani commentedPatch for drupal_site_path. Restricted the function to look for settings.php file within web root only.
Comment #14
moshe weitzman commentedSeems reasonable to me. Do we have to use realpath($path) or anything like that? Will wait a bit for more feedback before committing.
Comment #15
moshe weitzman commentedActually, 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.Comment #16
greg.1.anderson commentedThe 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.Comment #17
phayes commentedHi @greg.1.anderson,
I've confirmed that #13 does in fact work for my configuration (#8). The search for
settings.phpis stopping at/opt/sites/drupal-dev-phayes/drupal-webroot/, so it never finds (the erroneous)settings.phpone directory below it.Comment #18
greg.1.anderson commentedI 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.
Comment #19
moshe weitzman commentedI think we should actively ignore a settings.php in DRUPAL_ROOT and in /sites. I'd like to be robust here.
Comment #20
jonhattanRelated:
* #538702: Drush fails if parent of Drupal root directory contains a backup of the settings.php file
* #1539760: Drupal root getting miscalculated when sites dir is a symlink
Comment #21
nagwani commentedAny update required on this? Happy to patch again.
Comment #22
greg.1.anderson commentedThis 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.
Comment #22.0
greg.1.anderson commentedformatting