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.
Running a bootstrapped version of drupal from the command line breaks when adding the include to the settings file.
Comment | File | Size | Author |
---|---|---|---|
#57 | domain-domain-bootstrap-1342740-57.patch | 555 bytes | agentrickard |
#50 | domain-domain-bootstrap-1342740-50.patch | 1.14 KB | chriscalip |
Comments
Comment #1
agentrickardChange 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.
Comment #2
agentrickarde.g.
BTW: "Breaks" is not a sufficient description of the issue. WHAT BREAKS?
Please file a proper bug report next time.
Comment #3
blasto333 CreditAttribution: blasto333 commentedI changed:
the include to:
include_once DRUPAL_ROOT . '/sites/all/modules/domain/settings.inc';
By broken I mean I can't use any of the functions such as node_load or node_delete or any enabled module functions.
Comment #4
blasto333 CreditAttribution: blasto333 commentedThis is still happening. This makes it impossible to run scripts from the command line.
Comment #5
blasto333 CreditAttribution: blasto333 commentedComment #6
agentrickardYou have not addressed my point in #1. Nor have you provided ANY ability to replicate.
You can't run *your scripts*. Big difference.
Comment #7
agentrickardA report of the actual error would be polite as well.
Comment #8
agentrickardNote that
getcwd()
expects to be run from the drupal install root.Comment #9
blasto333 CreditAttribution: blasto333 commentedOk here it is:
/var/www/site/test.php
Comment #10
agentrickardThanks. 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
I suspect the problem in your script is here:
Testing now. Using PHP 5.3.
Comment #11
blasto333 CreditAttribution: blasto333 commentedIf I put the script in /var/www/site/html/test.php and get rid of chdir, it still fails you can try both ways.
Comment #12
agentrickardRuns fine from within the Drupal root. Moving and testing.
Comment #13
blasto333 CreditAttribution: blasto333 commentedNOTE: I am running these from the command line.
Comment #14
agentrickardRuns fine from a directory back.
Is this looping? If so, try isolating the drupal_bootstrap() inside an IF check.
Comment #15
blasto333 CreditAttribution: blasto333 commentedsite/html# php test.php
PHP Fatal error: Call to undefined function node_load() in /var/www/site/html/test.php on line 21
PHP Stack trace:
PHP 1. {main}() /var/www/site/html/test.php:0
root@roc-dev1:/var/www/site/html#
Comment #16
agentrickardOdd. I ran it through a for() and no errors, but I'm running the script through the browser, not the cli.
Comment #17
agentrickardYup, 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
Comment #18
agentrickardBut that isn't a DA error, per se. That's a boostrap failure.
Comment #19
agentrickardBut it does vanish when commenting out the line in settings.php. And include_once doesn't help.
Odd.
Comment #20
blasto333 CreditAttribution: blasto333 commentedYes, very odd. I will see if I can do some digging this weekend.
Comment #21
agentrickardNow 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.
Comment #22
agentrickardThe problem is in this part of domain.bootstrap.inc.
The $new_phase bit works with drush but fails with this other CLI script. If you keep $new_phase as FALSE, the error disappears.
Comment #23
agentrickardFor the time being, adding this to your script should work:
See http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal...
Comment #24
blasto333 CreditAttribution: blasto333 commentedThanks for your work, I will give it a try
Comment #25
agentrickardHere's a patch that works as expected for the following conditions:
Comment #26
agentrickardNote that I have not tested the /scripts folder. I'm not getting those to run properly without DA in my test environment (MAMP).
Comment #27
Dave ReidHrm, what exactly is wrong with the drupal_is_cli() function here?
Comment #28
agentrickardTry 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.
Comment #29
agentrickardNote that the same inconsistent behavior is present if you run update.php instead of a normal drupal page call.
Comment #30
agentrickardTests correctly when running ./scripts/drupal.sh. Committing.
Comment #31
agentrickardPatch applies cleanly to 7.x.2. Fixed in both branches.
Comment #32
agentrickardDoes not appear to be an issue in D6.
Comment #34
bzitzow CreditAttribution: bzitzow commentedHaving problems with drush.
drush sql-cli < ./database_file.sql
See: https://drupal.org/node/2175947#comment-8628697
Comment #35
BR0kENA 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:
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
Comment #36
BR0kENSorry, 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. :(
Comment #37
podarokbot up
Comment #38
BR0kENAnd patch for the current, 7.x-3.11 version.
Comment #39
asherry CreditAttribution: asherry commentedPatch #38 works for me, behat 3.0.14, domain 7.x-3.11.
Comment #40
BR0kENPatch #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.
Comment #41
eMuse_be CreditAttribution: eMuse_be commentedI can confirm that the patch works for behat. please merge in existing code.
Comment #42
BR0kENCome on, @agentrickard, look at this thread!!
Comment #43
agentrickardThis 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.
Comment #44
agentrickardThere's another potential issue in that the behat module installation instructions are not compatible with DA.
DA sets $base_url dynamically, so setting it manually breaks the module.
Comment #45
BR0kENThe
drupal_is_cli()
function isn't changed from 7.1 release, but that's no reason not to use it. Thedrush_verify_cli()
function does the same things, but Drush installed not at all. Also, my patch solves the problem on installation phase.Comment #46
Mahavir_Drupal CreditAttribution: Mahavir_Drupal commentedI 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.
Comment #47
agentrickardThe patch still does not address the issues raised in comment 43.
Comment #48
agentrickardLet 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.
Comment #49
chriscalip CreditAttribution: chriscalip commented@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:
Comment #50
chriscalip CreditAttribution: chriscalip commentedComment #51
badrange CreditAttribution: badrange at Wunder commentedA quick looks at the latest comments tells me that this issue needs review
Comment #52
podarok#50 works fine for me
Can be merged
Comment #53
agentrickardBumping for review. Thanks, all.
Comment #54
Chris Charlton#50 looks fine.
Comment #55
agentrickardThis breaks core's test runner.
Comment #56
agentrickardThe 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.
Comment #57
agentrickardI need one of the behat testers to give this a try.
Comment #58
agentrickardSee also https://www.drupal.org/node/1559486#comment-10188570
Comment #59
Chris CharltonWould checking PHP constant work better?
Comment #60
agentrickardNot really. The problem is that different CLI methods invoke Drupal's bootstrap, well, differently.
See this code in run-test.sh, for instance:
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:
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.
Comment #61
aczietlow CreditAttribution: aczietlow as a volunteer and at Mindgrub Technologies commentedThe 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.
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.
Comment #62
aczietlow CreditAttribution: aczietlow at Mindgrub Technologies for Dixon Valve commentedActually 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