Bootstrapping Drupal to run scripts from command line breaks when domain module is in use

Change to include_once() or require_once(), but this should not happen, and core Drupal and Drush never include settings.php more than once.

If your script does, then the script is broken.

e.g.

/**
 * Add the domain module setup routine.
 */
include_once DRUPAL_ROOT . '/sites/all/modules/domain/settings.inc';

BTW: "Breaks" is not a sufficient description of the issue. WHAT BREAKS?

Please file a proper bug report next time.

You have not addressed my point in #1. Nor have you provided ANY ability to replicate.

You can't run *your scripts*. Big difference.

A report of the actual error would be polite as well.

Note that getcwd() expects to be run from the drupal install root.

Thanks. The script is running from /www/site and Drupal is installed in /www/site/html, right?
This works fine from

/www/site/html/test.php

/**
 * @file
 * The PHP page that serves all page requests on a Drupal installation.
 *
 * The routines here dispatch control to the appropriate handler, which then
 * prints the appropriate page.
 *
 * All Drupal code is released under the GNU General Public License.
 * See COPYRIGHT.txt and LICENSE.txt.
 */

/**
 * Root directory of Drupal installation.
 */
define('DRUPAL_ROOT', getcwd());

require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
$nid = db_query("SELECT nid FROM {node} LIMIT 1")->fetchField();
$node = node_load(array($nid));
print $node->title;

I suspect the problem in your script is here:

// change to the Drupal directory
chdir('/var/www/site/html');
define('DRUPAL_ROOT', getcwd());

Testing now. Using PHP 5.3.

Runs fine from within the Drupal root. Moving and testing.

Runs fine from a directory back.

Is this looping? If so, try isolating the drupal_bootstrap() inside an IF check.

Odd. I ran it through a for() and no errors, but I'm running the script through the browser, not the cli.

Yup, from CLI, I can replicate that.

[09-Dec-2011 17:15:03] PHP Fatal error: Call to undefined function user_load() in /Applications/MAMP/htdocs/test.php on line 28

But that isn't a DA error, per se. That's a boostrap failure.

But it does vanish when commenting out the line in settings.php. And include_once doesn't help.

Odd.

Now that it's replicable, we should be able to fix.

BTW, #1366212: Fatal Error in Domain Content When trying to administer affiliated content is ready for a fix.

The problem is in this part of domain.bootstrap.inc.

function _domain_bootstrap($phase) {
  global $_domain;
  switch ($phase) {
    case DOMAIN_BOOTSTRAP_INIT:
      // Make sure database is loaded.
      // The new update handler causes problems here, so we account for it.
      // Same with drush or other CLI resources.
      $new_phase = FALSE;
      if (function_exists('update_prepare_d7_bootstrap') || drupal_is_cli()) {
        $new_phase = TRUE;
      }

The $new_phase bit works with drush but fails with this other CLI script. If you keep $new_phase as FALSE, the error disappears.

For the time being, adding this to your script should work:

$_SERVER['SERVER_SOFTWARE'] = 'drupal';

See http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal...

Here's a patch that works as expected for the following conditions:

• Normal browser-based Drupal
• Running update.php via the browser
• Drush commands
• The test.php script in comment 9
• SimpleTest, run through the browser
• SimpleTest, run via drush (drush test-run XMLRPCBasicTestCase --uri='http://example.com/')

Note that I have not tested the /scripts folder. I'm not getting those to run properly without DA in my test environment (MAMP).

Hrm, what exactly is wrong with the drupal_is_cli() function here?

Try running these two calls, and watch the php errors generated:

* drush cc
* php test.php

(Assuming the test file is taken from this issue.)

For DA to work, we have to initialize the database connection, but drupal_is_cli() is not a reliable predictor of _how_ to instantiate the db.

The problem may not be in drupal_is_cli(). It is more likely in how drush bootstraps as opposed to core. See the TRUE/FALSE logic in the domain.bootstrap.inc patch.

The discrepancy is noted in the patch's comments.

Note that the same inconsistent behavior is present if you run update.php instead of a normal drupal page call.

Tests correctly when running ./scripts/drupal.sh. Committing.

Patch applies cleanly to 7.x.2. Fixed in both branches.

Does not appear to be an issue in D6.

Having problems with drush.

drush sql-cli < ./database_file.sql

See: https://drupal.org/node/2175947#comment-8628697

A bug has not been fixed, because you preventing a new phase for Drush, but not for other command line tools, for example Behat.

Steps to reproduce:

1. Download and configure the Domain module.
2. Download and configure Behat Drupal Extension.
3. Go to Drupal installation directory via command line and execute the drush -dl command.

And then you'll see an error:
PHP Fatal error: Call to undefined function db_query() in domain.bootstrap.inc

Also we've got the next error when open the http://example.com/install.php on installed site:
Fatal error: Call to undefined function db_query() in domain.bootstrap.inc

Sorry, I made a small mistake in a previous patch: I forgot to check existence of a "MAINTENANCE_MODE" constant.

This patch corrects original bug and mistake from me. :(

bot up

And patch for the current, 7.x-3.11 version.

Patch #38 works for me, behat 3.0.14, domain 7.x-3.11.

Patch #38 is for current version of a Domain module - 7.x-3.11 and #36 - for development, 7.x-3.x branch.

P.S. I'd hope that maintainer read this topic and react for an issue.

I can confirm that the patch works for behat. please merge in existing code.

Come on, @agentrickard, look at this thread!!

This is problematic because it looks like a reversion of the original patch https://www.drupal.org/files/1342740-domain-bootstrap-script.patch.

What in Drupal core makes drupal_is_cli() reliable now when it wasn't three years ago? If you're going to add that back, then you have to change the comments that precede it and explain why it doesn't work.

Note that Behat support for Drupal didn't really exist when the original patch went in.

There's another potential issue in that the behat module installation instructions are not compatible with DA.

4) Set $base_url in settings.php if your site is not 
   accessible at http://localhost/ 
   (otherwise drupalPost() won't work)

DA sets $base_url dynamically, so setting it manually breaks the module.

The drupal_is_cli() function isn't changed from 7.1 release, but that's no reason not to use it. The drush_verify_cli() function does the same things, but Drush installed not at all. Also, my patch solves the problem on installation phase.

I installed domain, statuses module for facebook like status box on my website. I got an error saying domain access not installed. I edited the settings.php file by adding the following lines of code in the end:

/**
* Add the domain module setup routine.
*/
include './sites/all/modules/domain/settings.inc';

After this, I got the following error and my website has stopped working:

Fatal error: Call to undefined function db_query() in D:\Sporton\acquia-drupal-7.35.42.6236\sites\all\modules\domain\domain.bootstrap.inc on line 112

As I dont know php coding and I am building a website purely on the basis of installation of modules, I will greatly appreciate if someone can give my step by step solution for this.

P.S. I dont know how to work on drush as well as how to install patch modules.

The patch still does not address the issues raised in comment 43.

Let me be more clear.

You are asking to revert a patch that went in to fix a script that ships with Drupal core. Specifically, ./scripts/drupal.sh

See the list of conditions in comment 25.

@agentrickard on #48 with regards to patch #38.

Fair enough you have documented cases where drupal_is_cli does not work all the time. Will changing the condition check to include all three be sufficient?

Have hybrid:

if (function_exists('drush_verify_cli') || drupal_is_cli() || function_exists('update_prepare_d7_bootstrap')) {

A quick looks at the latest comments tells me that this issue needs review

#50 works fine for me

    "drupal/drupal-extension": "~3.0",
    "drupal/drupal-driver": "~1.0"

Can be merged

Bumping for review. Thanks, all.

#50 looks fine.

This breaks core's test runner.

[ ken ] : php ./scripts/run-tests.sh --url http://example.com/drupal-7 Profile

[25-Jun-2016 20:00:17 Europe/Berlin] PHP Fatal error:  Call to undefined function module_exists() in /Applications/MAMP/htdocs/drupal-7/scripts/run-tests.sh on line 31

The inclusion of drupal_is_cli() is what causes the test runner to fail. I think you misunderstood the code comment there: drupal_is_cli() is not a reliable function.

To get features like this in, it is necessary to test against core functionality.

I need one of the behat testers to give this a try.

See also https://www.drupal.org/node/1559486#comment-10188570

Would checking PHP constant work better?

if (PHP_SAPI === 'cli') {
  // Do stuff
}

Not really. The problem is that different CLI methods invoke Drupal's bootstrap, well, differently.

See this code in run-test.sh, for instance:

// Bootstrap to perform initial validation or other operations.
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

Behat (I think) and drush don't do that in the same way, which is why we have conditional statements that try to decide _which_ CLI is being used.

It boils down to knowing when to pass $new_phase = TRUE to https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drup...

That's why we have specific code checks in our bootstrap phase:

      if ((function_exists('drush_verify_cli') || function_exists('update_prepare_d7_bootstrap')) && empty($install_state)) {
        $new_phase = TRUE;
      }

The first is Drush, the second update.php, the third install.php. When you add in a generic CLI check, run-tests.sh (which is used by Drupal.org's test runner and is part of many CI setups) errors out.

And, for those who don't know, we are essentially injecting our own phase into Drupal's bootstrap. That's how we load domain-specific settings, aliases, and so forth. Fortunately, we don't have to do that in Drupal 8 anymore.

The issue with running Behat tests is that it is attempting to bootstrap using the DRUPAL_BOOTSTRAP_CONFIGURATION phase, and domain attempts to query the database to get the status of the domain module. The problem is the database layer isn't actually available yet.

    // \Drupal\Driver\Cores\Drupal7.php 
     public function bootstrap() {
    // Validate, and prepare environment for Drupal bootstrap.
    if (!defined('DRUPAL_ROOT')) {
      define('DRUPAL_ROOT', $this->drupalRoot);
      require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
      $this->validateDrupalSite();
    }

    // Bootstrap Drupal.
    chdir(DRUPAL_ROOT);
    drupal_bootstrap(DRUPAL_BOOTSTRAP_CONFIGURATION);
    if (empty($GLOBALS['databases'])) {
      throw new BootstrapException('Missing database setting, verify the database configuration in settings.php.');
    }
    drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  }

      // domain.bootstrap.inc::_domain_boostrap()
      // If the Domain Access module has been disabled, stop loading.
      $table = domain_get_primary_table('system');
      $check = (bool) db_query("SELECT status FROM $table WHERE name = 'domain' AND type = 'module'")->fetchField();

I think a possible solution could be to update the drupal driver from Behat to use the DRUPAL_BOOTSTRAP_DATABASE. I'm also not convinced that checking $database global is the best way to determine that Drupal is able to communicate to the database. Either way, this may be an issue to open with the Drupal Driver project.

Actually this issue was resolved in https://www.drupal.org/node/1941336 which was merged into 7.x-3.12. I was able to run a full suite of tests on my current project and a clean install using 7.x-3.13. Marking this as closed