I set up -l http://chx.itv.com and then this is the value of drush_get_option('uri');

string(18) "http://chx.itv.com"
string(18) "http://chx.itv.com"
string(18) "http://chx.itv.com"
string(18) "http://chx.itv.com"
string(18) "http://chx.itv.com"
string(18) "http://chx.itv.com"
string(14) "http://default"
string(14) "http://default"

I have no idea why. I tried symlinking sites/chx.itv.com to default but that didnt quite help. I have no idea where to look.

Comments

chx’s picture

chx commented

To clarify further, this means that $_SERVER['HTTP_HOST'] gets set to 'default' no matter what because as drush bootstraps, it loses the pre-set uri value.

chx’s picture

chx commented

I was using the si command.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Postponed (maintainer needs more info)

Hi chx, seems like you have the right idea; set up --root and --uri, or equivalently, -r and -l, to specify the Drupal root and site URI to use. This should set $_SERVER['HTTP_HOST'] as you expect.

Could you give more info on how you are calling Drush, per guidelines on the issue submission page? e.g. show drush status output, commandline to drush that you are using, relevant sections of drushrc.php, --debug output, etc.

greg.1.anderson’s picture

greg.1.anderson commented

Sorry, I missed #2. Use --sites-subdir rather than -l with the site-install command. I'm not entirely sure that site-install will set $_SERVER['HTTP_HOST'], so this might in fact be a bug with si.

greg.1.anderson’s picture

greg.1.anderson commented
Category: bug » support
Status: Postponed (maintainer needs more info) » Fixed

Just took a quick look at the code (Drush-5.x), and $_SERVER['HTTP_HOST'] is set. In D6, we bootstrap to DRUPAL_CONFIGURATION; otherwise we only go to DRUPAL_SITE, which sets HTTP_HOST. If you use --sites-subdir, then it should work. Note that we can't use -l or --uri for this operation in site-install; if we did that, Drush would try to bootstrap the site before it was initialized, which could cause problems when we tried to bootstrap it for real.

Here is the si bootstrap code in question, for reference: (drush/commands/core/site_install.drush.inc)

  // The Drupal 6 installer needs to bootstrap up to the specified site.
  // We need to be at least at DRUSH_BOOTSTRAP_DRUPAL_SITE to select the site uri to install to
  if (drush_drupal_major_version() == 6) {
    drush_bootstrap(DRUSH_BOOTSTRAP_DRUPAL_CONFIGURATION);
  }
  elseif ($sites_subdir != 'default') {
    drush_bootstrap(DRUSH_BOOTSTRAP_DRUPAL_SITE);
  }
greg.1.anderson’s picture

greg.1.anderson commented

Hm, we also have this in the validate function:

    // Make sure that we will bootstrap to the 'sites-subdir' site.
    drush_set_option('uri', 'http://' . $sites_subdir);

Perhaps the scenario above could be made to work with a slight code modification. I'm not really sure why we have --sites-subdir instead of just using --uri here. Could re-open as a feature request if it was felt to be compelling enough.

moshe weitzman’s picture

moshe weitzman commented
Priority: Critical » Normal

I think that if we require folks to specify a --uri in simple form (without http and such) then we can probably get rid of sites-subdir.

greg.1.anderson’s picture

greg.1.anderson commented

--sites-subdir allows people to specify the port number and such; unless we gave the same level of control with --uri, it wouldn't be good to get rid of --sites-subdir.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.