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

moshe weitzman’s picture

Status: Active » Fixed

thats normal and harmless. set a uri in your drushrc if this bugs you.

escoles’s picture

Status: Fixed » Active
Issue tags: +uri

Additional 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

escoles’s picture

sorry, 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.

rbayliss’s picture

Escoles, 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.

miro_dietiker’s picture

I don't understand why $base_url is ignored.

Any statement about that possible?

This breaks e.g. sending newsletters terribly...

moshe weitzman’s picture

Status: Active » Fixed

I 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.

escoles’s picture

@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.

miro_dietiker’s picture

Is 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...

escoles’s picture

The 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.

jonhattan’s picture

AFAIK 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.

escoles’s picture

Here'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.

greg.1.anderson’s picture

Title: drush status shows Site URI of 'http://default' when only one site directory exists » drush should attempt to pull --uri from settings.php if it is not provided on the command line.
Version: 7.x-4.4 »
Category: support » feature
Status: Fixed » Active

There 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.

escoles’s picture

Version: » All-versions-4.x-dev

So, 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.

escoles’s picture

Title: drush should attempt to pull --uri from settings.php if it is not provided on the command line. » drush status shows Site URI of 'http://default' when only one site directory exists

also changing title, as the new title did not accurately describe the support request.

greg.1.anderson’s picture

Category: feature » support
Status: Active » Fixed

You 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.

escoles’s picture

Greg, 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.

greg.1.anderson’s picture

Okay, 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'?

escoles’s picture

Just when I think I understand you, I'm forced to decide I don't.

You said:

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). [emphasis added]

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'.

greg.1.anderson’s picture

Well, 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.

escoles’s picture

Well, 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.

greg.1.anderson’s picture

As 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.

escoles’s picture

RIght; what I'm telling you is that whenever I install Drush 4.x, it can't do that.

greg.1.anderson’s picture

Version: All-versions-4.x-dev »
Status: Fixed » Postponed (maintainer needs more info)

Perhaps you are having some other problem. Try on 5.x-dev. It is working for me.

$ drush --root=/srv/www/d7.com/ status
 Drupal version                :  7.0-dev                                  
 Site URI                      :  http://default                           
 Database driver               :  pgsql                                    
 Database hostname             :  localhost                                
 Database username             :  www-data                                 
 Database name                 :  d7db                                     
 Database                      :  Connected                                
 Drupal bootstrap              :  Successful                               
 Drupal user                   :  Anonymous                                
 Default theme                 :  bartik                                   
 Administration theme          :  seven                                    
 PHP configuration             :  /etc/php5/cli/php.ini                    
 Drush version                 :  5.0-dev                                  
 Drush configuration           :          
 Drush alias files             :    
 Drupal root                   :  /srv/www/d7.com/                         
 Site path                     :  sites/default                            
 File directory path           :  files                                    
 Private file directory path   :  private                                  
jhr’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

novice triaged - feel free to reopen

attheshow’s picture

Version: » 8.x-6.x-dev
Issue summary: View changes

This tip worked well for me. I added a new file "drushrc.php" within my "default" directory with the following:

// See: https://drupal.org/node/1158144
// Keeps drush from showing http://default in links.
$options['uri'] = 'http://sitename.com';
fejn’s picture

@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

dshumaker’s picture

@attheshow Many thanks! that's perfect. cross post here: https://github.com/drush-ops/drush/issues/87

albertski’s picture

You can update settings.php with your base url.
$base_url = 'http://localhost:8888'; // NO trailing slash!

lhridley’s picture

@albertski, setting the $base_url in settings.php does not result in drush picking that up as the DRUSH_URI.

albertski’s picture

@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

Rob C’s picture

--uri= also works (for uli for example)

@lhridley #31 it does for me (with drush uli). might depend on your drush version.

saranya ashokkumar’s picture

Follow the steps from http://api.drush.org/api/drush/examples%21example.drushrc.php/master to get base url in drush cli.

Dhruv-ln-web’s picture

In 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.

options : 
  uri: 'website-name'