Drush fails to detect sites other than default when a site-local drush is installed #2285
Comments
fago
changed the title
fago
changed the title
…ite-local drush is installed.
|
Looks like there is simply a chdir() call causing that. It looks like thes chdir() is even unnecessary, in my tests removing it did not cause any troubles and fixed the problem. See PR #2286 |
|
I'm working on a D8 multisite now, and I have not experienced this problem. I also call a global Drush which hands off to a site-local Drush. On D8 a sites.php is required in order for multisite to work. I mention that in case you are running D8. Any chance you can zip up your site and send to me? Don't think I need the DB or uploaded files. If not, running with --debug might provide insights. |
|
The problem appears on a Drupal 7 site. Unfortunately I cannot share the site, but it has sites.php configured as well. I can check whether this is redrocuable on a plain drupal 7, but I very much think so. Here is the drush st --debug output in case it helps: |
|
I used the following commands (adjust for your DB server as needed) but could not reproduce the problem. It would be great if you tried with latest Drush (8.x or master, both global and site-local). My output has |
|
Coming back to this one after running into the applied patch. Sry for not responding earlier, I missed your update. I tested the problem with your commands, just slightly adapted to use my fitting db-credentials and drush in version "8.x-dev". When I ran drush status from sites/d7c2 I get: Thus, I can reproduce the problem with above steps. I've no idea why this problem is not there for you though. I made sure I've got drush 8.x-dev 72494ac installed both globally and at project level still same results. Then, after applying the changes from PR-#2286 it works as it should: |
|
Can we re-open this? Looks like I cannot. |
|
Thanks moshe! What's needed to move on with this issue? PR #2286 still works and resolves the issue for me. |
|
Can you reproduce the problem with the steps I posted? If not, what steps are needed? I need to see the bug to know if thats a good fix. |
|
Yes, as written above I was able to reproduce with the steps that you provided:
-> The only thing that I had to change was the drush version - I used "8.x-dev" what shoud be fine. |
|
I can reproduce error as well. Tested on multiple environments (OS X + PHP7, Debian8 + PHP5.6, Ubuntu 16.04 + PHP5.6). Workaround is to use -l option which is quite inconvenient. |
|
I can report the same issue. We're using a multi-site environment without a default site and any drush command (with our without --uri='' and in root or in a sites folder), returns:
Because the default site doesn't have any configuration. Edit: |
|
I also have the same issue.. cd into the site folder Checking drush path Drush st in my site folder Running Drush with -l option |
|
I keep having the same problem on Drupal 8 installed with composer, which includes drush. I removed the drush 8.1.12 installed by composer, doing This on Ubuntu 16.04 multisite standard installation on all 3 cases. |
|
|
|
I believe I'm encountering the same situation(s) described above.
This is on a Debian "Jessie" server with php 5.6. The same version of Drush ( 8.1.15) is installed globally and locally as part of the Drupal install. Removing the local version of drush via Happy to help with testing or provide more info about my setup. |
|
Are you located in the sites subdirectory when you make the cli request? Are you using any symlinks? |
|
I'm in /composer-root/web/sites/sitename.org/ when running I don't have any symlinks in the Drupal directory structure. My global install of drush does rely on a symlink: /usr/local/bin/drush is a symlink to /home/myusername/.composer/vendor/bin/drush |
|
Actually, today I also run into this issue. My global drush version is 8.1.15 and I currently have multisite Drupal instance with two sites. When trying to run However, by applying patch from this #2286 the issue got fixed. |
|
With Drush 9.2.1, neither an alias nor the --uri option can make Drush use a directory other than sites/default as the site path. |
|
Yeah I had the same issue as @darrenoh, not sure if there is a fix currently. My solution was going back to drush 8 |
I am experiencing the same issue. |
|
Same here - multisite deployments are broken by drush 9, as we've always assumed if you're in the correct sites directory then drush will use the correct site settings to do things like clear cache and update the db - it's definitely not doing that. Here's the CLI output from a drush 9 test I ran just now: Note specifically Be good to know if the drush team consider this a bug and are fixing, or I should start the refactor of code so it expects to use Thanks, Greg |
|
Wow, OK, so I downgraded to drush 8.x but I have the same problem (we don't do much multisite, so hadn't spotted this before). Check out the CLI output: So drush 8.1 seems pretty broken too. I couldn't go back to drush 8.0 to try, too many broken dependencies. I know drush 7.4 is fine, because we have a couple of Drupal 7 multisite clients using it without problems. I might have to bite the bullet and implement the |
|
In your drush9 log, you are calling `drush`. What is that pointing to? The
drush-launcher? Thats the recommended way to have a global drush these
days. See install docs. We could eliminate global drush from the discussion
by calling `vendor/bin/drush` instead of `drush`
|
|
I posted a fix for Drush 8 to #3550. Please test that and let me know how it there how it goes. Sorry it took so long. I didn't think of just doing another chdir() when I last looked at this. I still can't reproduce this on Drush9. If folks could post STR that would be helpful. Start with |
|
For drush 8 I patched |
|
Thanks. Whats the value passed to the new chdir(). Can you echo that? At same time would be helpful if you posted a new debug log. |
|
Of course, sorry! Just letting a test build finish then I'll re-patch and post something more meaningful for you! |
|
So I'm definitely getting some weirdness. To complete the picture, we're using this Puppet module to install system-wide drush - https://forge.puppet.com/jonhattan/drush It's always been fine in the past, but your earlier comments suggest this is no longer a good way to do things, and indeed it might be the cause of some issues here. Anyway, on to what I'm seeing. At first this wasn't making much sense to me - I tried to write something to the terminal around where the patch is. At first I tried to simply But my Bingo! There's the output I wanted. And when I use the full path to drush I get the correct multisite behaviour, so your patch does indeed work. If I don't specify a path, then I guess it's using system drush: Which is fine. But what I don't get is why even when I use system drush, the debug output looks like this, making me think I'm not using system drush? That output looks to me like it claims to be using the drush in the project, but it isn't actually. So for all I know when I thought I was using drush 9, it may have been the system drush 8 reporting as drush 9 when I did a Weirdness! |
|
When you use a global Drush like I wonder if others who are reporting problems with Drush9 are similarly confused. If they are using Drush8 as a global launcher, the problem would be drush8 (and now fixed). ping @darrenoh, @markdorison, @Pederytter to learn if you are using a global launcher. I suspect if you patch your global Drush, you won't need to patch project-specific one or pass in an absolute path. So, you have a few options on how to proceed. I've just merged #3550. We can reopen this issue if there is indeed a Drush9 problem too. |
|
I’m using Drush Launcher, not Drush 8. And using the -l argument doesn’t help. Here is the output of The actual site path is sites/home.darren.oh.name.drupal.8. |
|
Thanks @darrenoh. I assume you have created a sites.php? Thats a pre-requisite for multisite in D8. What is the contents of that file? |
Right, but the problem is it categorically didn't do that. It claimed it handed control to the site-local drush, but I can repeatedly demonstrate it's not doing that with something as silly as an What caused me so much confusion, and what I was trying to explain above, but there's probably too much in one post, is 'system' drush claimed to be launching 'local' drush, but it wasn't doing. |
|
startup.inc is before the handoff.
|
|
Hmm, OK - point remains though, sometimes it's handing off, sometimes it isn't, and I have no idea why. Probably another issue entirely though. |
|
@weitzman, the sites.php file is a copy of example.sites.php. Multisite is working without trouble in Drupal. |
|
@darrenoh - when you say "a copy of example.sites.php", I assume you mean it also has When that line is present, then I am seeing your bug fixed when I use #3166. I'll work on fixing its test fails tomorrow. Lets move discussion there. |
|
Drupal 8 checks site directories as long as sites.php is present. sites.php is not required to have content unless you want to use an alias for the site directory name. |
|
I had the same problem because of an uppercase character in the subdir : sites/mySite. Changing to lowercase fixed it. |
|
sites.php indeed can be empty but must be there. |
|
@Mark-Kiss |
|
Yes! However there might be a reason for that. Let me first show you the phenomenon.
As you can see in both case it's aware of Drupal root. |
Similar as reported in #2070, detecting multi-site directories does not work when a site-local drush is in use. The reason is that a global drush 8 automatically picks the site-local drush up, but loses the directory context while doing so.
Steps to reproduce:
Expected:
A output of
Drupal Settings File : sites/my-site/settings.phpActual behaviour:
Drupal Settings File : sites/default/settings.phpThe text was updated successfully, but these errors were encountered: