Backport SimpleTest testing in drupal_http_request()

+1

Might as well bump to RTBC, this is a backport and works fine. We just need a decision on it since it isn't a bug per say.

Helping tests work is important, so committed.

Great! Thanks.

drupal_http_request() is producing an error with this add-on when using an array for $GLOBALS['db_prefix']

Line 492:

preg_match("/simpletest\d+/", $GLOBALS['db_prefix'], $matches)

preg_match expects the second argument to be a string, not an array... Perhaps the if statement should be extended with an is_string() call like this:

if (is_string($GLOBALS['db_prefix']) && preg_match("/simpletest\d+/", $GLOBALS['db_prefix'], $matches)) {

Thanx in advance & cheers

hctom

@hctom: Line 492 causes "string expected" problem for us even without the "simpletest" module on Drupal 6.13.

I am not sure if another broken module causes this, but if we use "Check manually" on Available Updates page, Drupal 6.13 gives series of

warning: preg_match() expects parameter 2 to be string, array given in /includes/common.inc on line 492

warnings after a remarkably long pause.

With your modified "if", warning disappears but simpletest module does not work anyway.

Tx.

@Dave Reid: Sorry, post form default values have set that.

@chawl: Of course the error occures without the simpletest module installed... the mentioned line of code is code form the core common.inc file, so no other module may be in charge :)

I guess the only way to solve this is something like this:

if (is_string($GLOBALS['db_prefix']) && preg_match("/simpletest\d+/", $GLOBALS['db_prefix'], $matches)) {
  $defaults['User-Agent'] = 'User-Agent: ' . $matches[0];
}
elseif (is_array($GLOBALS['db_prefix'])) {
  foreach ($GLOBALS['db_prefix'] as $prefix) {
    if (preg_match("/simpletest\d+/", $prefix, $matches)) {
      $defaults['User-Agent'] = 'User-Agent: ' . $matches[0];
      break;
    }
  }
}

@Dave: what do you think about this solution?

Cheers

hctom

@hctom: Tx :) I was really confused even I might suspect a rainy day.

Our problem turns out to be a remnant from Faceted Search module which needs $db_prefix to be defined as an array in the settings.php. But there were no problems before 6.13 strangely.

Anyway, sorry for bloating the thread.

I realized the bug during a multisite install preparation where some tables are shared... and so the $GLOBALS['db_prefix'] also has to be an array...

... but you are right... this code fragment is new in 6.13

cheers

hctom

Will we find solutions to the 6.13 problem here?

Committed to CVS HEAD. Thanks!

+1, please commit to D6 ASAP. 6.13 currently generates errors for any http request it generates (when module updates are checked, for example) on any site (as above) with db_prefix setup as an array, ie any multi-site, or using faceted search, for just a few common examples.

+1
Used the D6 patch on a 6.13 multisite, the errors are gone with this patch.

I have also been affected with on multisite install of D6.13. The D6 patch from #18 should really be committed before releasing D6.14.

The patch in #18 resolved the problem for me in 6.13.

Thanks, committed to Drupal 6 too.

Subscribing. (I know it's fixed, but I wanted to remind myself I needed to patch this in my Drupal 6.x installs until 6.14 is released.)

In a multisite setup with shared tables, $db_prefix is *not* a string, but an array (see http://drupal.org/node/2622). The patch for this issue that made it into D6.13, however, doesn't handle this case ($db_prefix an array) correctly, since line 492 in common.inc

if (preg_match("/simpletest\d+/", $GLOBALS['db_prefix'], $matches)) {

now assumes $db_prefix to be a string. Therefore, on certain requests/actions an error/warning occurs, like:

warning: preg_match() expects parameter 2 to be string, array given in /srv/www/vhosts/freerunning.net/httpdocs/includes/common.inc on line 492.

Is there any solution in the making?
(like an "foreach($db_prefix ...)" loop?)

So in Drupal 6.14 the case that $db_prefix is an array will be handled correctly, right?

@Everybody, who helped with this issue: Thanx for all the work :)

I'm looking for ward to the new Drupal release

Cheers

hctom

Yea, again!

Great, Thank you all, too :-)

Now everything works fine as Dave Reid hase prognosed in #30. Thank you very much! Drupal 6.14 rulz :-)