warning: preg_match() expects parameter 2 to be string - SRSLY, WON'T FIX, EVER.

This may be a problem with search forms (http://drupal.org/node/219591).

I did a search on this message and it's turning up a lot and being blamed on a bunch of different modules. I think it's a core issue with the Form API, probably on search forms, and possibly related to blocks. Since it's so prevalent, I'm marking this critical to get some core folks to look at it. (BTW, I am also seeing this in 6.0.)

This was originally opened against 5.7, so it is an ongoing issue.

For us, it appears to originate from within search.module.

drupal_validate_utf8() is called on this array:

array(
  '0' => 'Enter the terms you wish to search for.'
);

The preg_match() fails because the second argument supplied is an array, not a string.

We have Drupal 5.7 / PHP 5.2.0-8+etch5~pu1, and enough modules loaded that I won't bother listing them unless asked :)

Based on all the hits I get when I searched on this, I'd say this has to be the most frequently encountered bug in Drupal - and it's not getting much attention. But I hav to admit, just about every case I've seen was the result of a bad call.

Yeah, I'm getting there error too, but it appears to be self inflicted. I'm using hook_search() in an attempt to make a Sphinx Search module. If I turn off my module, and clear my cache, this error goes away.

I patched my drupal_validate_utf8() so that anything other than a string returns "false". I don't know if this is good or not. I guess I could post a patch.

Are you using transliteration.module? I think my problem is because of this module.

No, I'm not using that. The sources of this are MANY. The problem is inadequate error-detection in this function.

It's not adequate to add array detection to drupal_validate_utf8 instead that's called bloat. You very likely have a broken form which passes an array to check_plain instead of a string. If we would suppress the error as some here wants to do then you won't see a helpful error message alerting you to this fact.

I agree that my check is probably not the thing to do. The error message is not in the least helpful. There is nothing that helps to track down the offending element, not even a backtrace provides anything useful.

subscribing.

subscribing

my error got solved, it was problem with email function. drupal 6 email parameters are different. as the error shows something in core, we can't understand which cause the error.

Is there any debug code we can add to track down the offending form? in my case, I see this error at the top of workflow_ng rule configs page. yet I've been using this for a long time now and haven't seen it before. I'm trying to retrace my steps but this is not really possible after a certain point.

I try to implement reasonable test plans along the way during development & configuration of sites, but I can't check every admin page after every small change I make (not possible).

So any advice about how to deal with this would be appreciated – even if not the 'right' way (like adding some temporary debug code in bootstrap.inc) – I'm just not quite knowledgeable enough about this to know what to add.

Thanks in advance!
Scott

About all I can suggest is to go into drupal_validate_utf8 and check if the text is a string. If not, do a print_r on it so you might get an idea of what the error is.

Nancy, you mean go into function drupal_validate_utf8 in bootstrap.inc? If so, here's what we've got on line 666 (lovely number btw!) which returns the error on line 670:
(I'm working in D5.7)

function drupal_validate_utf8($text) {
  if (strlen($text) == 0) {
    return TRUE;
  }
  return (preg_match('/^./us', $text) == 1);
}

Sorry to have to ask, but I'm not sure what you mean "check if the text is a string"? :p

Also, where do I put the print_r to debug? It would help if you could be *slightly* more specific – cause while I've used print_r I'm still a bit of a noob :) thanks!

Before the "if" statement, try something like:

  if (!is_string($text)) {
    drupal_set_message(print_r($text, true));
  }

For me, this happens on a site where I copy the DB from a live to testing server. It indicates that one of the serialised config variables is borked, and I just need to edit the config settings and save that variable to fix it. (Happens to be theme edit -> save that fixes this for me.)

You might not have the same issue (unless, like me, you do something like mysqldump drupal | sed -e 's#site1#site2#g' | mysql test_drupal). By doing so, I'm loading "bad" data into my DB, so the warning is being helpful and telling me so.

This issue has been marked "won't fix" because the warning is actually a useful indicator that something else is wrong and needs fixing. Find that problem and fix it, rather than hiding the error message.

You can just hide the warning, but what will help MORE is to do a bit of debugging and learn where this bad string is coming from, so you can handle it better.

Subscribing - also receiving this error.

Subscribing. I'm getting this error while working on and then subsequently viewing a View. The error message appears on the "Edit View" page as soon as any change is made to the View, and it also appears on the public page in which this View is mounted as a Block. I'm using Views 6.x-2.x-dev, and Date/Calendar 6.x-2.x-dev. I mention the latter because the error began appearing after I played with adding a date-based filter to my view. After looking around up here, the problem seems to be bigger than any one contrib module. Still have no idea what's causing it.

Well, if you notice in #10, chx marked this "won't fix;" that pretty much means core developers aren't looking at this issue any more.

I had the same issue with this error. My solution was to disable the module that allows for photo uploading during registration. http://drupal.org/project/reg_with_pic Disabled - error goes away.

Yeah I know, Nancy, I'm just using this page as an excuse to hang around talking about it ;-) I think it's a legacy thing in various modules, and I think it's working its way out of the system. Old habits die hard...

I'm getting the error on a views edit page and no where else. Not sure what the deal is. I might try to recreate the view to see if that solves the problem.

Got this problem after I installed the imagefield module for D6.

I got the error too, after implementing a production site, using the test DB, as i changed some thing in the testsite ... i gor the error ..
but what to do ?

LejfM, there are many causes of this error, but the comment above which sounds most similar to your situation is #19.

You don't say which of the suggestions above you've tried already.

Try re-reading my earlier comment, and if that doesn't help you could try a few of the other suggestions above too.

Do post back what you learn, so that others may share your wisdom when they face the same challenge at a later date!

Thanks

I got this error too recently, but it disappeared when I updated to the newest version of Views (6.x-2.3).

-----------------
EDIT: Ok, I spoke too soon. It's back.

This is odd, because it's only happening on one of the 10+ Drupal sites I host. Here's a list of the modules I use on that one site that I do NOT use on any of the others. They're all the latest versions. I hope this helps:

OpenID (Core, but the only site I actually use it on.)
Content Profile
SimpleTest
Token Actions
Rules

sorry found http://drupal.org/node/431186 which fit my issue

This is on 6.12 - I'm not sure where else to post it. If anyone can direct me to a more relevant area, please do.

I was able to solve this problem by editing the bootstrap file on line 771 and also the previous function to this affect:

/**
 * Encode special characters in a plain-text string for display as HTML.
 *
 * Uses drupal_validate_utf8 to prevent cross site scripting attacks on
 * Internet Explorer 6.
 */
function check_plain($text) {
if (is_array($text))
return implode(' ',$text);
else
  return drupal_validate_utf8($text) ? htmlspecialchars($text, ENT_QUOTES) : '';
}

/**
 * Checks whether a string is valid UTF-8.
 *
 * All functions designed to filter input should use drupal_validate_utf8
 * to ensure they operate on valid UTF-8 strings to prevent bypass of the
 * filter.
 *
 * When text containing an invalid UTF-8 lead byte (0xC0 - 0xFF) is presented
 * as UTF-8 to Internet Explorer 6, the program may misinterpret subsequent
 * bytes. When these subsequent bytes are HTML control characters such as
 * quotes or angle brackets, parts of the text that were deemed safe by filters
 * end up in locations that are potentially unsafe; An onerror attribute that
 * is outside of a tag, and thus deemed safe by a filter, can be interpreted
 * by the browser as if it were inside the tag.
 *
 * This function exploits preg_match behaviour (since PHP 4.3.5) when used
 * with the u modifier, as a fast way to find invalid UTF-8. When the matched
 * string contains an invalid byte sequence, it will fail silently.
 *
 * preg_match may not fail on 4 and 5 octet sequences, even though they
 * are not supported by the specification.
 *
 * The specific preg_match behaviour is present since PHP 4.3.5.
 *
 * @param $text
 *   The text to check.
 * @return
 *   TRUE if the text is valid UTF-8, FALSE if not.
 */

function drupal_validate_utf8($text) {


  if (strlen($text) == 0) {
    return TRUE;
  }
if (is_array($text))
return implode(',',$text);
else
  return (preg_match('/^./us', $text) == 1);

I had some modules wanting to pass an array, or mixed string/array through the preg_match filter. I edited it to 'if array'>'implode array' before passing to the filter. It seems to have worked so far in our beta testing.

I have also considered writing a separate preg_match type filter for the array, but have not had the time to do so and likely will not as this seems to work for me.
If it continues to work I might do a patch.
I'd like any feedback on this.

drupal_validate_utf8() does not accept arrays as input.

Patching core to remove the error message is simply masking your real issue, which is that some other module or function is passing inappropriate data to drupal_validate_utf8().

See chx's reply above giving the reason for marking this issue won't fix.

Please do not work around this issue by patching your core files, for reasons which are better explained elsewhere.

Instead, you should debug a little further to where the problem has originated rather than where the error message appears.

Because you're working on a development install (right?) and have the devel module installed, you can temporarily add a snippet of code like this to the start of drupal_validate_utf8() to debug the issue -

if ( !is_string($text) ) {
  $bt = debug_backtrace() ;
  dpm($bt);
}
 

... which will show you the preceding functions and arguments which led to the passing of an array or other non-string data into drupal_validate_utf8().

That's where the problem lies. You may have to dig a little further (eg, "Why is it that search.module is getting handed an array of search terms when it expects a string?") but the solution is definitely not to add code to a string validation function to make it deal with non-string input.

That's why this issue is marked won't fix.

If you get stuck debugging, please ask for help in the forums, on IRC (via web), or by asking for paid support before adding another workaround / comment to this issue.

Thanks, and good luck!

Thanks Xurizaemon,

I get the point: I have to go to the module that wants to pass an array and implode it (or whatever it takes) there.

And follow the rule: "DO NOT HACK CORE"

Ben

For me everything was working properly until I enabled "Optimize JS files" option from the Performance admin.
Then I started getting this error. The error was being thrown from the function check_plain(). I modified the function as follows.

function check_plain($text) 
{
  if (is_array($text))
  {
	$text = implode('',$text);
  }
  return drupal_validate_utf8($text) ? htmlspecialchars($text, ENT_QUOTES) : '';
}

I am not sure why this error did not turn up until I enabled JS optimization.

@tejuspratap: I just checked and my JS Optimization is disabled and I've been having this issue since we upgraded.

Is this possible that this issue is showing up for upgraded Drupal installs from 5.x? Any other upgraders out there?

I have upgraded many and rarely use JS optimization. In my experience, #33 is correct. Frankly, I'd like to see it changed, but that would take a new issue.

It happened to me while sending email to more than one address(recipient) in a single email. However if i send an email invitation to a single recipient; no error.
I request mssarath (#13, #14) to give me the details of how he has overcome the problem as he mentioned that he too encounter the error while sending email.

Any other folks who has encountered the same error while sending email and has successfully resolved please post your solutions.
Thanks.
Making your journey memorable forever
www.balikampung.com

Balik (and the next person who comes in via Google), please refer to comments #10 and #33 above which explain why this issue is marked WON'T FIX.

This is not the issue you're looking for.

#18 was very helpful, thanks NancyDru :)
This told me what was going wrong and saved a tonne of trouble shooting

For the record I started getting a version of the error (/includes/bootstrap.inc on line 771) while correcting taxonomy spelling errors in /admin/content/taxonomy/x

Unfortunately I didn't notice *which* change it was.

Based on the type of the error (regular expression getting something besides a string) I'm curious if I introduced a duplicate that's being returned as, I dunno, maybe a record count or an array containing the two duplicates instead of the expected string? Total speculation, obviously. If I can find something obvious in the database I'll report back.

See #18 and #33

Subscribing, having this error using taxonomy hierarchical select.
Greetings, Martijn

Then report it to the HS maintainer - it is not a core problem.

I am not sure it is a HS thingie..will investigate more...
Trying #33, but got memory problems with Devel. Particularly Krumo! I set memory on settings.php to 500M! But still problems with Devel. Will still investigate more.. greetings, Martijn

EDIT: The HS is fixed, it was a label not filled in.
Having this issue now with newest ctools /panels..

I'm getting the error in the views module. I created a view to list events/dates similar to one that already existed, and the error suddenly appeared.

I reverted teh view I was working with to the default view and the error went away. I lost my work, but didn't loose any content. Since I wasn't sure what I had, and am new in the development end of Drupal, I figured it was the easiest thing to do.

Hi,

I have this error as well. I would love to find the bug according to #33, but I don't know how to do this.

add a snippet of code like this to the start of drupal_validate_utf8()

How do I do this? I can see that Devel allows me to add a snippet of php, but how do I add this "to the start of drupal_validate_utf8()" ?

Tnx in advance for any help.
Danny

@ Danny_Joris have you read #18 and #33 as instructed by others with similar questions?

Great, tnx.

I managed to copy the right code and at one point where I always have this error, this is the output: http://dannyjoris.be/files/fora/preg_match-debug.png . I don't really know what to look for here...

I am also wondering: could it be related to this: http://drupal.org/node/372710#comment-2102300 . I added that Patch. I believe it has to do with uft-code, but I'm not sure what that is.

I feel I shouldn't discuss this here, but I wouldn't know where, because I don't know the cause yet.

Cheers,
Danny

-- Edit: I solved this issue thanks to a lot of help from bdragon on irc chat. It appeared that there was no default time set for the drupal install and that conflicted with a custom content type called Events, which uses a Date cck field...

--Edit2: This preg_match error came back very quickly. After a long search i found that this was caused by Rootcandy after all. It was this issue: #656558: $items passed to theme('item_list',...) may contain subarrays from menu_navigation_links's $menu_tree . I upgraded to the .dev version and that fixed it. I still don't understand how to find the source of preg_match errors though.

I've closed this issue for further comments.

Here's the procedure once again, copied from #33:

drupal_validate_utf8() does not accept arrays as input.

Patching core to remove the error message is simply masking your real issue, which is that some other module or function is passing inappropriate data to drupal_validate_utf8().

See chx's reply above giving the reason for marking this issue won't fix.

Please do not work around this issue by patching your core files, for reasons which are better explained elsewhere.

Instead, you should debug a little further to where the problem has originated rather than where the error message appears.

Because you're working on a development install (right?) and have the devel module installed, you can temporarily add a snippet of code like this to the start of drupal_validate_utf8() to debug the issue -

if ( !is_string($text) ) {
  $bt = debug_backtrace() ;
  dpm($bt);
}
 

... which will show you the preceding functions and arguments which led to the passing of an array or other non-string data into drupal_validate_utf8().

That's where the problem lies. You may have to dig a little further (eg, "Why is it that search.module is getting handed an array of search terms when it expects a string?") but the solution is definitely not to add code to a string validation function to make it deal with non-string input.

That's why this issue is marked won't fix.

If you get stuck debugging, please ask for help in the forums, on IRC (via web), or by asking for paid support before adding another workaround / comment to this issue.

Thanks, and good luck!