Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The /sites folder for the site in question contains the following subfolders:
./all
./default
The only settings.php file is in default. Yet when I execute drush status
, the Site URI value is always given as 'http://default' unless I explicitly specify the URI.
Is this normal behavior now? If not, what are some configuration elements that could be causing it?
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedthats normal and harmless. set a uri in your drushrc if this bugs you.
Comment #2
escoles CreditAttribution: escoles commentedAdditional clarification: This behavior occurs wherever I put myself in the folder hierarchy. E.g., if I
cd
to sites/default, the behavior is still the same.If I supply the
--uri=<em>site-uri</em>
, the behavior is as-expected.So, this is not the same as this: http://drupal.org/node/1129464
Comment #3
escoles CreditAttribution: escoles commentedsorry, crossed wires on the update -- did not see Moshe's answer until now. Must have over-written his response with my update.
However, this is not my understanding of the "normal" behavior -- are you saying that
--uri=http://domain.tld
is now a required parameter? If not, then how do I get it to not require that parameter? The behavior that I'm accustomed to seeing is that where there's only one settings.php file, Drush doesn't need to be told what the site URI is; where there are multiple (i.e., multisite), drush will use the most proximate settings.php file. In this case, it's not using any until you tell it explicitly where to look.So, if that's not the designed behavior, I'd just like to know what's causing it.
As for harmless, sure -- but it's a nuisance.
Comment #4
rbayliss CreditAttribution: rbayliss commentedEscoles, I don't think it's possible to determine a URI without either --uri passed into drush or a $base_url in the default settings.php.
Still, if you set a $base_url in settings.php, it isn't used in the output of drush status. I understand that the DRUSH_URI should stay set to http://default for portability and compatibility reasons, but how about an additional context for DRUPAL_URI that can be used for human readable URI output? I'm happy to take a crack at it if this makes sense.
Comment #7
miro_dietikerI don't understand why $base_url is ignored.
Any statement about that possible?
This breaks e.g. sending newsletters terribly...
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedI don't think adding a DRUPAL_URI in addition to DRUSH_URI clarifies anything. The only reason that drush cares about a uri is because drupal cares. Basically, you just have to set --uri properly in this case. We could discuss a patch to switch DRUSH_URI based on an explicit $base_url when such a patch arises.
Comment #9
escoles CreditAttribution: escoles commented@rbayliss: the reason I posted an issue about this is that in all previous versions of Drush that I've used, the
-l
or--uri
argument was not necessary unless you were using multisites.What I'm still not clear on is whether there's been an explicit change that makes that no longer the case. I'm seeing this behavior on all new Drush installs, so my working assumption is that it is an explicit, intentional change. I guess I'd just like some confirmation of that.
Comment #10
miro_dietikerIs the need of --uri defined in the README or somewhere in the documentation?
I also see much risk in this change as all calls without --uri will lead to broken host information.
Possibly we should implement a patch to consider $base_url asap...
I refer to something like e.g. git: As long as you don't specify the config for username and email, you'll always get a warning message that tells you about the risk / issues the lack produces. So, IMHO we should warn as long as uri isn't present...
Comment #11
escoles CreditAttribution: escoles commentedThe failure mode if
--uri
is missing currently appears to be that it simply doesn't work.The way it used to work is that if the context supplied enough information to infer the site, it would just work without
--uri
. My issue here is that the behavior appears to have been changed both without documentation of the fact that it's changed and possibly without awareness on the part of the developers that it has changed.From my perspective as a heavy Drush user, having to perform extra scripting and configuration steps to ensure that I don't have to type a
--uri
argument every time I issue a command is a royal pain. Of course, if I don't do that, then I do have to type that--uri
argument for every command. Which is even more of a royal pain.Comment #12
jonhattanAFAIK there's no change in this area since 3.x days. Can you people explain what's exactly the problem?.
Yes, drush assumes default for sites/default or example.com for sites/example.com and yes, drush ignores $base_url.
Patches to set the uri to $base_url are welcome as has already been said. Not a trivial task btw.
Comment #13
escoles CreditAttribution: escoles commentedHere's what I have come to expect from Drush: If there's only one settings.php, it assumes that's what site it should be looking at. If there's more than one, it requires
--uri
or-l
.That's not how it seems to work in the current version: Now it seems that
--uri
or-l
is always required.Comment #14
greg.1.anderson CreditAttribution: greg.1.anderson commentedThere has been no change to the requirements for --uri or -l parameter since even the 2.x days; --uri has always defaulted to "http://default", it simply was not displayed in drush status.
As moshe said in #8, drush does not care what the URI is; however, if the URI is not initialized correctly, then Drupal might do the wrong thing if it tries to use the URI that drush provides to it. #7 gives an example of this.
As moshe says in #8, we can consider a patch that reads $base_url from settings.php and uses it to initialize the URI parameter. This would have to be done in drush-5.x, as it is drush policy to maintain a consistent operating environment in drush-4.x. I think it would be a useful enhancement.
Comment #15
escoles CreditAttribution: escoles commentedSo, if that's the case, then I'm returning to the original support request (which was NOT about $base_url), re-setting the version to 4.x.
What is causing the behavior I described and how can I configure systems to prevent it? Behavior is observed only 4.x versions of Drush.
Comment #16
escoles CreditAttribution: escoles commentedalso changing title, as the new title did not accurately describe the support request.
Comment #17
greg.1.anderson CreditAttribution: greg.1.anderson commentedYou must set --uri or -l or $options['uri'] in drushrc.php or 'uri' in your alias record. If you do not, drush will set --uri to 'default'. So has it been since drush-2, if not earlier.
Comment #18
escoles CreditAttribution: escoles commentedGreg, I understand what you're saying. But it's not accurate. Drush 3.x did not behave that way on the 5 or 6 sites where I installed it.
Comment #19
greg.1.anderson CreditAttribution: greg.1.anderson commentedOkay, perhaps your memory is better than mine; I did not (and do not think I will) investigate 3.x to confirm. So, perhaps drush-3 set uri to empty instead of 'default'? In any event, the behavior was the same insofar as the default site was selected if uri was not specified (as is always the case with the default site -- it will match any specification that is not picked up by a specific multisite).
Are there any scenarios where Drupal works with an empty uri, but does not work when uri is 'default'?
Comment #20
escoles CreditAttribution: escoles commentedJust when I think I understand you, I'm forced to decide I don't.
You said:
Right: That's what I'm saying. If the URI wasn't specified, drush through 3.x selected the default site. So, if you were not using multisites, and you issued
drush status
, the URI displayed would be the URI of the default site -- NOT 'http://default'.NOW, with Drush 4, no matter where I install it,
drush status
without a--uri=<em>x</em>
or-l
argument always displays a URI of 'http://default'.Comment #21
greg.1.anderson CreditAttribution: greg.1.anderson commentedWell, if my memory is at all accurate, you will not see the URI of the default site under drush-3 in those circumstances, but I'm not going to take the time to install it to find out, as drush-3 is not supported any more. Sorry. Let's move forward and talk about how it should behave. Reset per #14, or make a new issue.
Comment #22
escoles CreditAttribution: escoles commentedWell, if my memory is at all accurate, you will not see the URI of the default site under drush-3 in those circumstances...
You would see the URL of the default site.
That is, if the default site was example.com, you'd see 'http://example.com'. If you saw 'http://default', it meant you could effectively do nothing with Drush because it was not able to connect to the database.
As for how it should behave: I'm having a hard enough time establishing how it does (i.e., is designed to) behave.
What seems to me to be the case is that, in the absence of custom configuration files, either
-l
or--uri=
are now required parameters. Without those parameters, Drush is not able to determine what database to access. Is that accurate?What I want to know is this: If that's not accurate, then how do I stop it from working that way? Because that's the way it works wherever I install Drush 4.
Comment #23
greg.1.anderson CreditAttribution: greg.1.anderson commentedAs far as I can remember, that is the way it has always worked. However, drush can still determine which database to access, even if URI is "default"; it gets it from the settings.php file in sites/default.
Comment #24
escoles CreditAttribution: escoles commentedRIght; what I'm telling you is that whenever I install Drush 4.x, it can't do that.
Comment #25
greg.1.anderson CreditAttribution: greg.1.anderson commentedPerhaps you are having some other problem. Try on 5.x-dev. It is working for me.
Comment #26
jhr CreditAttribution: jhr commentednovice triaged - feel free to reopen
Comment #27
attheshow CreditAttribution: attheshow commentedThis tip worked well for me. I added a new file "drushrc.php" within my "default" directory with the following:
Comment #28
fejn CreditAttribution: fejn commented@attheshow: I'm unclear as to just what directory you mean by "default": a) the sites/default directory, or b) the site root directory (e.g., probably your 'example.com' directory if the site is http://example.com
TIA, Jeff
Comment #29
dshumaker CreditAttribution: dshumaker commented@attheshow Many thanks! that's perfect. cross post here: https://github.com/drush-ops/drush/issues/87
Comment #30
albertski CreditAttribution: albertski commentedYou can update settings.php with your base url.
$base_url = 'http://localhost:8888'; // NO trailing slash!
Comment #31
lhridley CreditAttribution: lhridley commented@albertski, setting the $base_url in settings.php does not result in drush picking that up as the DRUSH_URI.
Comment #32
albertski CreditAttribution: albertski commented@lhridley
I thought it worked for me but I may be wrong. I ended up just going with adding -l argument in my drush command.
drush -l http://localhost:8888 my_drush_command
Comment #33
Rob C CreditAttribution: Rob C commented--uri= also works (for uli for example)
@lhridley #31 it does for me (with drush uli). might depend on your drush version.
Comment #34
saranya ashokkumar CreditAttribution: saranya ashokkumar at UniMity Solutions Pvt Limited commentedFollow the steps from http://api.drush.org/api/drush/examples%21example.drushrc.php/master to get base url in drush cli.
Comment #35
Dhruv-ln-web CreditAttribution: Dhruv-ln-web at LN Webworks Private Limited commentedIn Drupal 9 or 10,
In Drupal root verify drush folder exist (If not create one) and create drush.yml file inside drush folder define the uri paramters.