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

Ghostthinker’s picture

same here, any ideas?

agentrickard’s picture

Are 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.

dave reid’s picture

No just the base domain module. There only other place domain touches the db_prefix is in domain.bootstrap.inc:

function domain_get_primary_table($table) {
  global $db_prefix;
  if (is_string($db_prefix)) {
    $table = $db_prefix . $table;
  }
  else if (is_array($db_prefix)) {
    $table = $db_prefix['default'] . $table;
  }
  return db_escape_table($table);
}
agentrickard’s picture

Right, 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.

agentrickard’s picture

The problem appears to be that SimpleTest cannot create its table clones.

dave reid’s picture

It's defintely not SimpleTest. If I comment out domain's settings.inc in my site's settings.php file, the tests run just fine.

agentrickard’s picture

I think it's a collision between how DA works and what SimpleTest does.

I suspect this is the cause of the FAIL:

  protected function setUp() {
//...
    include_once './includes/install.inc';
    drupal_install_system();

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.

agentrickard’s picture

So 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?

dave reid’s picture

Yeah 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. :/

dave reid’s picture

Status: Active » Needs review
StatusFileSize
new699 bytes

Hah, 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.

dave reid’s picture

Confirmed domain still works and executes in the normal site, but allows the 'test' site to run without any domain processing.

agentrickard’s picture

Right, 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.

dave reid’s picture

This 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.

dave reid’s picture

StatusFileSize
new742 bytes
dave reid’s picture

I guess though if we wanted to have domain enabled from within testing, this wouldn't fly. This is only a stopgap for now.

agentrickard’s picture

It'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?

agentrickard’s picture

Yeah, 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.

dave reid’s picture

@#17 Yes, I agree as well.

dave reid’s picture

StatusFileSize
new927 bytes

Oooh 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!

agentrickard’s picture

Status: Needs review » Fixed

Seems to work just fine. Committing to 6--2 and HEAD!

agentrickard’s picture

Note: Using Domain Prefix breaks SimpleTest in this same way. But that's a separate issue #702142: $db_prefix is assumed to be a string

Status: Fixed » Closed (fixed)

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