Hi,
I use Drupal 6.13 and cck-6.x-3.x-dev with Last updated: August 18, 2009.
In Content Type Manage Page, when I edit a multigroup field, I have this error :
warning: preg_match() expects parameter 2 to be string, array given in /includes/bootstrap.inc on line 771.
If I refresh the page this error message disappear.
Thanks for all.
Bye

CommentFileSizeAuthor
#7 1.txt335.98 KBcostinius

Comments

markus_petrux’s picture

Status: Active » Postponed (maintainer needs more info)

This is drupal_validate_utf8(), which is used by check_plain(). So, it seems to be that check_plain() is invoked for something that is not a string. It maybe caused by a certain field, or combination of fields. So we would need to know which combination exactly triggers this issue.

Still, to find the exact problem, this needs debugging so that we can see who's calling what and which conditions are involved so we can think about a fix. But first, we need to know how to reproduce this issue.

markus_petrux’s picture

Please, read the following issue to see how to report a backtrace.

#285391: Recoverable fatal error in bootstrap.inc

pydubreucq’s picture

Hi,
I don't know how to reproduce this issue. :(
I'm French and I use French Character but my database is in utf8 encoding.
If you want to test my content type I can put it here.
Bye

mdriess’s picture

I have the same error message but in my case it is coming up after importing translations. As far as I can see with my poor programming knowledge but with my experiences as consultant an logical thinking wouldn't it be a way to use addslashes() and/or preg_quote() in line 771 of the bootstrap.inc?

markus_petrux’s picture

@mdriess: It is not bootstrap.inc which is at fault here, but the one who is calling drupal_validate_utf8() with something other than a string. And the caller could be doing this because the data it manipulates is not correct, or because of a bug in the caller.

We need to know who's the caller and what it is trying to do. For this, the only way is proceed as described in the link I posted in #2.

mdriess’s picture

@markus_petrux. thanks for that advice. I will test it like described in #2 and the link in there and will post the results of it.

costinius’s picture

StatusFileSize
new335.98 KB

@markus_petrux:

I have the same mistake. I created a node type 'Resume' using CCK and content_multigroup. I also have 2 languages installed - English (default) and Russian. When I view the node with my UI language set to English, everything is fine. But when I switch the UI language to Russian, I am getting the above mistake twice (maybe because I have 2 multigroups).

I tried to backtrace the origin of this mistake as you suggested and attach below the results. Looks like it's originating in the core filter.module at line 967. Here's that part of the code:

function filter_xss($string, $allowed_tags = array('a', 'em', 'strong', 'cite', 'code', 'ul', 'ol', 'li', 'dl', 'dt', 'dd')) {
  // Only operate on valid UTF-8 strings. This is necessary to prevent cross
  // site scripting issues on Internet Explorer 6.
  if (!drupal_validate_utf8($string)) {
    return '';
  }

After commenting the line which calls 'drupal_validate_utf8' function, the mistake disappears, but when viewing a node at the top of each multigroup it adds a word 'Array'.

A similar mistake is also described here: http://drupal.org/node/404984

markus_petrux’s picture

@costinius: Try edit the settings of the group 'group_education' in your content type 'resume' and save. It seems to me that the value of $group['settings']['display']['description'] for that group is somehow corrupted and saving the group settings would have to fix this.

...or check the translation of this group description as the corruption could come from the translated string.

costinius’s picture

@markus_petrux:

Thanks Markus, it really helped :) Actually I had to re-save both multigroups' settings and the mistakes disappeared. Do you happen to know what might have caused the data corruption? Anyway, thanks! I expected a much more complicated solution to this problem :)

PS: I haven't translated anything yet, so both UI languages show the same content for the time being...

markus_petrux’s picture

Status: Postponed (maintainer needs more info) » Fixed

No idea, but the backtrace you posted was showing the contents of display description was an array of strings in russian, which is really strange and it could have been caused by an occasional error, or maybe a bug somewhere else, in any other module that you have installed. This kind of things are pretty difficult to track.

I would say "won't fix" to a CCK bug report, but I'm setting this issue to "fixed" so it can still be viewed for a while in case someone else finds this problem.

@all: if you have this problem, then please proceed as described in the link I posted in #2. Thanks

spflanze’s picture

I am also getting this error and its in a fresh install of 6.13 with no modules other than core installed. The selected language is english.

I have two sites in sites/all. The only modifications in settings.php are the data table prefixes recommended for the singlesignon module. But because one of my two domains is a subdomain of the other singlsignon is not needed so it is not installed. The cookie domain is the same for both is the same and set to the donain without the domain name.

It looks to me like a bug in Drupal 6.13 core.

spflanze’s picture

I have done some debugging. The warning message is:

warning: preg_match() expects parameter 2 to be string, array given in F:\Websites\Mirrors\Drupal6\includes\common.inc on line 492.

Looking at the line 492 I see:

  if (preg_match("/simpletest\d+/", $GLOBALS['db_prefix'], $matches)) {
    $defaults['User-Agent'] = 'User-Agent: ' . $matches[0];
  }

This is passing an array to preg_match() because I have opted to use a database prefix array in settings.php. So $GLOBALS['db_prefix'] is an array.

That $db_prefix can be an array is in the documentation for settings.php and depended upon by the singlesignon module. There is no question that it is supposed to be valid that $db_prefix can be an array in settings.php. So this is a bug in Drupal 6.13 core.

janamills’s picture

I agree. I am using CiviCRM and hence needed it to be an array.

spflanze’s picture

Status: Fixed » Active

Changing status to active to hopefully get this bug in core the attention of the developers.

markus_petrux’s picture

Status: Active » Fixed

@spflaze: The lines of code you have posted in #12 are part of drupal_http_request(). AFAICT, this function is not used by CCK.

So I think your issue is not related to CCK. Please, search the issues queue of the Drupal project, as it could be already reported. If not, then please file a new issue in that queue. Thanks

Status: Fixed » Closed (fixed)

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