Domain access does not allow drush to run commands such as sql-connect until a database is loaded

Try passing -uri or -l.

See https://drupal.org/node/1096956. I thought this was documented more generally, but probably needs clarification.

I don't know. I never use those commands ;-p.

I suspect I know _why_ this fails. Can you post a sample command that I can test with?

If you are debugging, look in _domain_bootstrap() inside domain.bootstrap.inc. I suspect the problem is that we are trying to leap ahead in the bootstrap phase. We've had problems with this before.

      // Make sure database is loaded.
      // The new update handler causes problems here, so we account for it.
      // Same with drush or other CLI resources. It turns out that the
      // drupal_is_cli() function is not consistent for php and drush scripts,
      // so instead, we check to see if the database driver has been loaded.
      // See http://drupal.org/node/1342740 for the latest background.
      $new_phase = FALSE;
      // If running from drush or update.php, we act differently.
      if (function_exists('drush_verify_cli') || function_exists('update_prepare_d7_bootstrap')) {
        $new_phase = TRUE;
      }
      drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE, $new_phase);

What version of drush?

That looks like the kind of exception handling we've had to implement due to inconsistencies in how drush and other external scripts interact with Drupal.

The question is: does it break anything else?

It does. It breaks drush domains and all regular drush functions.

Actually, this appears to be working properly and is in fact a drush documentation bug.

See #1117460: drush sql-connect < database.sql displays credentials and doesn't import database?

Try drush sql-cli < file.sql

Using that command works fine for me on drush 5.

Neither command caused any problems for me. I was using DA 7.x.3.x-dev and Drush 5.0.

My response is based on item 2 in the original post, which will only return the database connection string, because it is an improperly documented drush command. The command tries to import data, but will fail due to the drush bug listed above.

I ran drush cli < import.sql just fine. And drush sql-connect returned the expected string.

In effect, I am saying "cannot reproduce", but I left it open in case I'm missing something.

Wait, NO DATABASE? You can't run that command if settings.php isn't configured, with or without DA. Your request makes no sense to me.

None of these are broken for me.

If you are adding the domain settings config line to settings.php BEFORE you install the site, then you are simply doing it wrong.

I just pounded on this for a half hour, and it looks like an unsolvable drush issue to me.

The fact is that there is no way to accurately tell if a database connection will work -- unless there is a magic Drupal function or method that I am missing.

Your patch simply *breaks* drush commands if a database _is_ present. I tried a variety of methods to check to see if the database connection was loaded, but, in the end, drush simply won't allow it.

/me points to the install documentation: https://drupal.org/node/477372

If you can find a working solution, I'll commit it.

You MUST install Drupal before editing settings.php. This is documented because there is no consistent way to work around it, AFAIK. This problem is because drupal_bootstrap() doesn't actually give useful information on fail.

For your automated scripts, you may just have to wrap the DA include line in some IF logic specific to your build. Or you might use try/catch, which might be best practice.

With your patch, install the module and then try "drush domains". I get a load error . I get the same error with "drush vl" for Views module.

The drush command 'domains' could not be found.  Run `drush cache-clear drush` to clear the commandfile cache[error]
if you have installed new extensions.
Drush was not able to start (bootstrap) the Drupal database.                                                 [error]
Hint: This error often occurs when Drush is trying to bootstrap a site that has not been installed or does
not have a configured database.

Without your patch, this works fine.

That looks promising.

Here's the one remaining problem I have:

With this patch, drush skips the domain bootstrap process entirely if the site is already installed. This is a regression, because there are times when you want to target a drush command at a specific domain.

E.g.:

drush domains
WD domain: Domain access failed to load during phase: bootstrap include. Please check your settings.php file [error] and site configuration.

If we can fix that, we're all set.

That is consistent with my findings.

The difference is that drupal_boostrap() allows this type of "jumping" behavior.

In your case, I think the best thing to do is wrap that include line in a conditional, then we can document that and move on.

Since you are editing settings.php before installing Drupal anyway, this shouldn't bother the workflow much.

Yeah, wrap it in

if (!function_exists('drush_verify_cli')) {
 ... INCLUDE CODE ...
}

I keep trying to find another way, but there doesn't seem to be one. Ideally, you would remove that conditional once the site is built.

I know this topic is a bit old now but:
@joelcollinsdc: how did you manage to get that working: patch DA... or custom include in settings.php ?
I'm having the same problem but I'm confused

@gabriel.achille: replace your existing "include" line in settings.php with this:

if (!function_exists('drush_verify_cli')) {
  include DRUPAL_ROOT . '/sites/all/modules/domain/settings.inc';
}

... adjusting the path if necessary to reflect where domain module is.

ok thank you.

However when I tested it I still had the error message "WD domain: Domain access failed to load during phase: bootstrap include. Please check your settings.php file and site configuration. [error]" when doing a drush cc all... Apart from that it is working fine.

I tested another code in my settings.php file: If the calling context is a drush command, it checks if the table "system" exists:

/* ... */
if (function_exists('drush_shell_exec')) {
  $connect_string = _drush_sql_connect(_drush_sql_get_db_spec());
  drush_shell_exec('$connect_string -e "SELECT 1 FROM system" ');
  $output = drush_shell_exec_output();
  if ($output[0] == 1) {
    include DRUPAL_ROOT . '/sites/all/modules/domain/settings.inc';
  }
}
else {
  include DRUPAL_ROOT . '/sites/all/modules/domain/settings.inc';
}

Tested on mysql only and it is less elegant...

Can confirm this is a problem. Wouldn't it be best to move all of this logic into the core of domain access so that there aren't extra steps and code required for users to put into the settings file? It would then be properly tracked as a feature and not just a random recommendation made in the issue queue?

P.S Great to see the progress on the D8 version of the module coming along. Thanks for the work!

D7 forces us to use the settings file in many cases. If you can find a workaround within the code here, please do:

domain.bootstrap.inc

A small update on gabrielle's code.

/* ... */
    drush_shell_exec('$connect_string -e "SELECT 1 FROM system" ');
/* ... */

/* ... */
    drush_shell_exec($connect_string . ' -e "SELECT 1 FROM system" ');
/* ... */

I want to be able to use Drush to run site-install on a site that uses Domain access. This is an important use case if, for example, you want to be able to install a site using domain access from within a CI script. It is more convenient to be able to be able to set up settings.php in advance, rather than install the site first and then edit settings.php. It is also useful during the development workflow if you are able to `drush sql-drop` and then install again without having to modify files.

Swallowing errors from `domain_bootstrap();` does the trick nicely.

Again, given the Drupal bootstrap call stack, we have to load into settings.php. We don't have a choice.

I just account for that in my build scripts. e.g.:

# add setup to settings.php
chmod 775 sites/default/settings.php
echo >> sites/default/settings.php
echo "\$cookie_domain = '.example.com';" >> sites/default/settings.php
echo >> sites/default/settings.php
echo "include DRUPAL_ROOT . '/sites/all/modules/domain/settings.inc';" >> sites/default/settings.php;
chmod 664 sites/default/settings.php

The inconvenience with #32 is, on its own, `drush site-install` will fail if you ever run `drush sql-drop`. You have to remove `domain/setting.inc` before you do this, and then put it back.

It is way more convenient to just catch the errors from `domain_bootstrap();`; that way, you can keep the include of `domain/settings.inc` in your settings file, and re-install your site as needed. I have a working patch, and tried to attach it to #31, but for some reason it didn't get uploaded. I'll just attach it to this comment... (sorry about the filename/comment number mis-match).

See also: https://github.com/drush-ops/drush/pull/1442#issuecomment-126503886

Committed.

fcdd3d4..aa82b25 7.x-3.x -> 7.x-3.x