Don't set DRUSH_OPTIONS_URI if disable_settings_management - breaks drush current multisite detection

[arafalov]

Describe the bug
With new DRUSH_OPTION_URI, drush stops recognizing current site when a command is run without an alias (in Web container).

To Reproduce
arafalov@bl3x-web:/var/www/html/web/sites/test-demo$ set |grep DRUSH
DRUSH_LAUNCHER_FALLBACK=/usr/local/bin/drush8
DRUSH_OPTIONS_URI=https://bl3x.ddev.site
arafalov@bl3x-web:/var/www/html/web/sites/test-demo$ drush status
Drupal version : 8.9.2
Site URI : https://bl3x.ddev.site
DB driver : mysql
DB hostname : db
DB port : 3306
DB username : db
DB name : db
....
arafalov@bl3x-web:/var/www/html/web/sites/test-demo$ drush @test-demo status
Drupal version : 8.9.2
Site URI : https://bl3x-test-demo.ddev.site
DB driver : mysql
DB hostname : db
DB port : 3306
DB username : db
DB name : test-demo
Database : Connected
...
arafalov@bl3x-web:/var/www/html/web/sites/test-demo$ unset DRUSH_OPTIONS_URI
arafalov@bl3x-web:/var/www/html/web/sites/test-demo$ drush status
Drupal version : 8.9.2
Site URI : http://test-demo
DB driver : mysql
DB hostname : db
DB port : 3306
DB username : db
DB name : test-demo
Database : Connected
...

Version and configuration information (please complete the following information):

• Host: MacOS
• DDev 1.15.3

Additional context
I understand this was introduced to improve the multisite support (#1806) but it seems to have broken it in another way now. I can't find documentation on how to unset that in a permanent fashion or any documentation mention of it at all.

Is it possible that the solution(s) is worse than the cure in this particular case?

[rfay]

Hi @arafalov - The real issue was that ddev was messing with drush.yml, and that broke lots of things for people.

What you have to do is use drush -l <uri> which is what they recommend anyway...

If you want to override DRUSH_OPTIONS_URI you can do it with a docker-compose.*.yaml file, and set it to "", I think that would work. And then you can set drush.yml wherever you want. But that will break your production site.

[arafalov]

Hi Randy,
Thanks for quick response.

The environment option may be recommended, but this specific option is explicitly not recommended for multi-site configuration: https://github.com/drush-ops/drush/blob/10.x/examples/example.drush.yml#L89-L92

Drush deciding the active site based on the current directory seems a core features that a lot of tutorials rely on and it silently failing inside DDev can be very disorienting. I only realized what the issue was because my default website is not setup and some of the drush commands were not showing up. Otherwise, I would be executing my commands against wrong site. I only know about the environmental option because I reported the drush.yml issue in the first place and was tracking its resolution. And even then it took more than an hour to realize that I should test its impact.

Also, a question (maybe in docs), what is a URI for a multisite individual site when using drush inside the web container? I tried a couple of permutations, but cannot get them to work. I do have site aliases which is how I normally use it, but that's not everybody's use case.

Finally, I will check ways to unset this in meanwhile. The hook (I looked at first) did not work, I guess each hook command runs in a separate shell session. I'll check docker extension next.

[arafalov]

Ok, I was able to work around this issue with docker-compose.override.yaml:

version: '3.6'
services:
  web:
    environment:
      - DRUSH_OPTIONS_URI=

[rfay]

It's possible we should not set DRUSH_OPTIONS_URI when disable_settings_management is on.

[arafalov]

This may be a reasonable - documented - solution, especially since there are also other files being put into default folder that are not necessarily useful in multisite configuration.

I guess I just don't want others to spend an hour or more hunting through the DDev/Docker/Drupal/Drush layers of influence to figure out why they exported the wrong SQL database or why their Drupal instance does not notice their updated plugin.

[PieterDC]

I discovered this issue report after having found the solution myself, but thanks for reporting it anyway.
For what it's worth, I can confirm removing $options['l'] from sites/default/drushrc.php (directly or via an approach described in earlier comments) does fix the Drush current multisite detection.

[rfay]

@PieterDC if you're on Drupal8+ and using a recent version of ddev, there shouldn't even be a drushrc.php in there, you can delete it, it's probably from a version of ddev a long time ago... But if you're working on any version of ddev, and you change a ddev-generated settings file, make sure to remove the #ddev-generated line at the top, or ddev will try to recreate it.

[PieterDC]

I'm using a recent version of ddev; version DDEV-Local version v1.16.1
But I'm running Drupal 7, not Drupal 8+
I already read about the #ddev-generated line at the top of DDEV generated files, but thanks for mentioning it anyhow. It wasn't super obvious the first time I had to remove that line ;-)

[rfay]

Yes, Drupal 7 does need the drushrc.php, so ddev generates it.