Steps to reproduce:
1. Enable domain (with addition to settings.php) and the SimpleTest module
2. Run any test from admin/build/testing
Tests will massively fail because you get errors like these from 'within' the test runner:
Warning: Table 'drupal6dev.simpletest198508simpletest198508access' doesn't exist query: SELECT 1 FROM simpletest198508simpletest198508access WHERE type = 'host' AND LOWER('127.0.0.1') LIKE LOWER(mask) AND status = 0 LIMIT 0, 1 in /home/dave/Projects/www/drupal6dev/includes/database.mysqli.inc on line 128
Warning: Table 'drupal6dev.simpletest198508simpletest198508cache' doesn't exist query: SELECT data, created, headers, expire, serialized FROM simpletest198508simpletest198508cache WHERE cid = 'variables' in /home/dave/Projects/www/drupal6dev/includes/database.mysqli.inc on line 128
Warning: Table 'drupal6dev.simpletest198508simpletest198508variable' doesn't exist query: SELECT * FROM simpletest198508simpletest198508variable in /home/dave/Projects/www/drupal6dev/includes/database.mysqli.inc on line 128
It appears that domain is clobbering the db_prefix being used by SimpleTest.
Comments
Comment #1
Ghostthinker commentedsame here, any ideas?
Comment #2
agentrickardAre you using Domain Prefix? Because that is the only place where Domain touches the $db_prefix global.
There may also be a problem with SimpleTest finding settings.php, which can happen to Drush as well, if the full URL isn't provided with a request. In that respect, DA functions like traditional multisite.
Comment #3
dave reidNo just the base domain module. There only other place domain touches the db_prefix is in domain.bootstrap.inc:
Comment #4
agentrickardRight, but that doesn't alter $db_prefix, it just reads it and uses it to run a query against the core {variable} table in case Domain Prefix is running.
I just encountered the error on a totally fresh install, without Domain Prefix, but cannot explain it.
Comment #5
agentrickardThe problem appears to be that SimpleTest cannot create its table clones.
Comment #6
dave reidIt's defintely not SimpleTest. If I comment out domain's settings.inc in my site's settings.php file, the tests run just fine.
Comment #7
agentrickardI think it's a collision between how DA works and what SimpleTest does.
I suspect this is the cause of the FAIL:
SimpleTest tries to run the Drupal installer during setUp, and I suspect that DA interrupts that cycle somehow because http://api.drupal.org/api/function/drupal_install_system/6 calls a full bootstrap, which causes DA to run again.
Let me try something quick.
Comment #8
agentrickardSo far, no luck. It looks like we need a reliable way to bypass the DA bootstrap function is SimpleTests are running. I tried using
class_exists('DrupalTestCase', FALSE)and no luck.Ideas?
Comment #9
dave reidYeah the problem is conf_init() (and loading settings.php) happens before DRUPAL_BOOTSTRAP_DATABASE in which the db_prefix is changed to the test prefix. :/
Comment #10
dave reidHah, I got it figured out. Just needed to check for the SimpleTest user agent and drupal_valid_test_ua() and it stops the processing in domain's settings.php.
Comment #11
dave reidConfirmed domain still works and executes in the normal site, but allows the 'test' site to run without any domain processing.
Comment #12
agentrickardRight, and drupal_valid_test_ua() is in the D6 patch, so we'd need to test for that function.
Is there any way we can execute this without running the preg_match?
The conflict, more than likely is in line 78 on domain.bootstrap.inc, when we jump ahead and initialize the Drupal database connection. The only way I can see to get around that would be to force the hardcoding of a module list into settings.php, which I don't like because it causes a burden on admins.
Comment #13
dave reidThis seems to be the best option as *none* of this processing should execute since the module is not technically enabled or installed when run within tests.
Added a function_exists() even though it would be a very odd situation if it got to that execution and the function didn't exist. Better safe than sorry.
Comment #14
dave reidComment #15
dave reidI guess though if we wanted to have domain enabled from within testing, this wouldn't fly. This is only a stopgap for now.
Comment #16
agentrickardIt's ironic, I think, because this error occurs because we are bootstrapping the database to make sure that Domain is enabled before we do any special loading...
I would also reverse that patch IF order, thinking that function_exists() is likely faster than preg_match(). Is it not?
Comment #17
agentrickardYeah, writing tests for domain functionality would be really hard. Hm. I think we should find where the actual FAIL is in the process, rather than just bypassing it.
Comment #18
dave reid@#17 Yes, I agree as well.
Comment #19
dave reidOooh ooh...I think I've got the real reason. Calling _drupal_bootstrap compared to drupal_bootstrap doesn't keep track of what level of bootstrap has occurred, so the database bootstrap gets called twice, adding the testing prefix twice. If we call drupal_bootstrap() from domain's settings.php testing works and we should be able to use domain testing as well!
Comment #20
agentrickardSeems to work just fine. Committing to 6--2 and HEAD!
Comment #21
agentrickardNote: Using Domain Prefix breaks SimpleTest in this same way. But that's a separate issue #702142: $db_prefix is assumed to be a string