Upgrading to the last version yesterday I get an error viewing a page that contains a link field.
The error says: "warning: "preg_match() expects parameter 2 to be string, array given in /xxx/xxx/includes/bootstrap.inc on line 777".
This behaviour didn't happen before.
I have a custom content type with a field of type 'Link'. When I set the display of that field to 'URL, as plain text' or to 'hidden', the error disappears.
But once I change the display to 'Title, as link' or 'URL, as link' or ... the error shows up.
The URL itself is nothing special: http://www.example.com/node/69.

Comments

Assigned:Unassigned» jcfiala
Priority:Normal» Critical

Thanks - was this updating to 2.8, or updating to the 6.x-dev? If it was 2.8, would you mind trying the dev version and seeing if you're still getting that error?

Looks like 2.9 is going to be a bugfix/stability release. :)

Assigned:jcfiala» Unassigned
Priority:Critical» Normal

I upgraded to the 6.2.8 version. I will try the dev version now and inform you asap. Thanks for the fast support.

I have installed the dev version, but with no luck. I have cleared the cache, but the error remains.

Priority:Normal» Critical

he same problem is mentioned in the Views project.
See http://drupal.org/node/627326
Hope this helps.
Downgrading the Links module to 2.7, running on 6.14, doesn't help either.
It seems there are problemes withe Drupal 6.14

I don't think it's strictly 6.14. I got the same problem while running 6.13. I upgraded to 6.14 in the hopes that it might fix the problem, but it did not. I did get two slightly different error messages, essentially being the line in the include to throw the error.

Drupal 6.13 then 6.14
Apache: 2.2.11
Linux CentOS: 5.4
MySQL: 5.1.30
PHP: 5.2.5

Views 6x-2.7
Link 6x-2.8

6.13 error was this:
warning: preg_match() expects parameter 2 to be string, array given in [my site]/includes/bootstrap.inc on line 771

6.14 error is this:
warning: preg_match() expects parameter 2 to be string, array given in [my site]/includes/bootstrap.inc on line 777

Oddly, I have one view with a pager and the error does not appear on the first page, it only appears once you click the pager controls. This error began appearing after I updated to Link 6x-2.8 and Views 6x-2.7. The error does not prevent the page from displaying, but it does show a large, highlighted message at the top of the page, including the site's home directory path.

Priority:Critical» Normal

Well, here's the deal: Line 777 of bootstrap.inc is part of the drupal_validate_utf8() function declaration, and a quick text search of the link module seems to indicate that we don't use that function at all. So, on first look, this doesn't look like it's a Link error.

But, I'm planning to put more time in on Saturday to bang out some of these recently generated bug reports, and I'll trace it back then.

That said, have you read this issue #627326: Error Message - warning: preg_match() expects parameter 2 with views?

The drupal_validate_utf8() is called by t(), so almost everyone uses it without knowing :)

I ran into the same problem, but I think I isolated the problem to other modules, so I don't know where to post ...

I'll try here, hoping that your problem is similar ...

For me, everything comes from the menu_block module.

In the function menu_block_get_all_menus(), it defines a new hook (if I understand well) :
$all_menus = module_invoke_all('get_menus');

In my case, this calls menu_get_menu() (drupal core) and menu_access_get_menu() which are very similar ...
As those functions return arrays, module_invoke_all merges them with array_merge_recursive().

For duplicates keys, we then have a problem : the menu array now has arrays values instead of strings. When calling t() with paramaters that are supposed to be strings but are arrays, you get the warning: "preg_match() ..."

No, what is the solution ? Well, I don't know ...
Is it a bad practice to define a new hook with a frequent name (ie: get_menus) ? In this case, this should be corrected in block_menus module. Is the menu_acces_get_menus hook wrong (didn't have time to look deeply in this module) ?

How is this linked to "Link" ? (I din't find any link_get_menus() function in your code) ?

Anyway, for those having the problem, do you have block_menu enabled ? If yes, can you try to deactivate this module and see if the warning is still here ?

My quick fix (working only on my installation:
replace $all_menus = module_invoke_all('get_menus'); in menu_block_get_all_menus() by

if (module_exists('menu_access')) {
$all_menus = menu_access_get_menus();
}
else {
$all_menus = menu_get_menus();
}

I'm posting this here because I ran into this problem yesterday after upgrading to CCK 6.x-2.x-dev (2009-Nov-20) (I ran into this issue "#625768: Fatal error while running userreference_update_6002()" with CCK 6.x-2.6) and Link 6.x-2.8. I tracked it to a bad CCK Link value in my site's database. The "preg_match() expects parameter 2 to be string" problem appears all over the Drupal forums, not just in CCK Link, because of two separate issues that both need to be considered.

(1) If some value in the database is supposed to be a string but isn't, and eventually gets fed to preg_match(), then you've got a database corruption issue. You need to either fix the bad database entry (if you can find it) or revert to an earlier database backup that doesn't show the problem.

(2) Barring cosmic rays damaging the hard disk data, there is some bad code that either is (a) feeding preg_match() an incorrectly structured argument, or (b) storing improperly formatted values in the database, corrupting it, or (c) both! The first is a module programming issue that can be explored by turning off whatever module you've recently updated. The second is a double whammy, because even after fixing the bad module you may still have bad values in the database, causing the problem to continue appearing. This can be rather frustrating. ;-)

The least painful way to handle this is to revert to the backup you made immediately before your recent module(s) upgrade, and revert to the previous version of those module(s). But it can be the case that the problem was introduced several waves of upgrades earlier, in which case you also lose whatever content has been added since then. That's not fun.

So the other approach, which can work if you suspect the current versions of your code is OK and it's a database corruption problem, is to track down the bad value. I was able to do this because the error came up when some lists of links were displayed but not others. I temporarily modified the Views view that displays those lists to show only one link per page, and paged through until I got to a link that showed the preg_match() error. I then could simply re-save that link (go to its edit page and save without making changes), clear the Views cache and the overall cache, and the problem was fixed.

I suspect that either the CCK upgrade or the link upgrade either damaged the database value for that node's link field, or somehow exposed a preexisting bad database value that was not causing problems before. Why only that one out of dozens of link values, I don't know.

Status:Active» Postponed (maintainer needs more info)

Could someone who is having this problem go into their database, look up the field in the content_node_field table, and send me the data in that row for the misbehaving link field?

ie, "SELECT * FROM content_node_field where field_name = 'field_link';" - if the name of your fiend were 'link'.

This would help in trying to figure out what's going on.

Status:Postponed (maintainer needs more info)» Active
StatusFileSize
new1.6 KB

I've got the issue with module 'Link' not installed.

The issue takes place when i try to manage fields of a newly created node type.

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

I've attached a list of modules that are enabled on my site (everything latest versions, mostly stable).

I've enable some modules that were used but disabled during site migration. The amount of warnings decreased drastically: now there are only two warnings instead of dozens.

I was having this issue and though I actually am not sure what I did that fixed it I can tell you what I know. I am not sure what actually fixed it because I was trying several things and I believe the Views cache was not being cleared everything I made a change. I am on D6.14, using CCK 6x-2.4 and Link 6x-2.8 and Views 6x-2.6.

The error was appearing on a "page" view that was set to display several fields from a custom content type. Among these fields were two "Link" fields, "Email" and "Website". Based on this thread I guessed that these were the problem. I cloned the View to make a testing version, then I removed the Website field from the test version and the problem remained. I re-added it and removed the email field and the problem disappeared. I then re-added the Email field to continue testing. There are only 7 pages of this particular content type so it was easy to notice that two of these email fields were typos: the content person had put just the email address in the link field where it was expecting the format "mailto:email@address.com" and Drupal had tried to format these as http links. I refreshed the View-generated page and it did not clear the error (but again I could've been looking at cached data at this point). I then deleted the NOFOLLOW bit and the link Target settings from the Email link field but the problem remained.

So I went back into the View and changed the output of the Email field from "Title, as Link" to "URL as plain text" and the problem disappeared. (Again, I am not sure if this cleared a cache or actually fixed things.) I switched it back to "Title, as Link" and everything was fine. It must've been caching the View for that particular CCK field is all I can think of.

StatusFileSize
new68.22 KB

I think it must be something happened between link 2.6 and link 2.8 (I havn't tried 2.7).
When I install link 2.6, everything is fine. When I install link 2.8, I get the warning.
In the Link Module the only differences is in the file link.module.
Perhaps some changes in bootstrap.inc can help us, but I think it is the wrong way to solve the problem.
I've attached the comparison in af fileset.

For me, the problem was exhibited by the rootcandy theme code:
#656558: $items passed to theme('item_list',...) may contain subarrays from menu_navigation_links's $menu_tree

Perhaps this description will help you find the problem here.

The backtrace was:
bootstrap.inc: drupal_validate_utf8 line 741
common.inc: check_plain line 1526
theme.inc: drupal_attributes line 1499
theme.inc: call_user_func_array line 617
template.php: theme line 135
theme.inc: call_user_func_array line 617
template.php: theme line 128
page.tpl.php: _rootcandy_admin_navigation line 52
theme.inc: include line 1020
theme.inc: theme_render_template line 686
index.php: theme line 3

It passed an array of items to the theme() function but these menu arrays can have additional arrays within them not present in the standard menu tree, for example:

<?php
Array
(
    [
menu-232] => Array
        (
            [
attributes] => Array
                (
                    [
title] =>
                )
            [
href] => <front>
            [
title] => Front
       
)
...
[
Later, a data attribute is added to the array, like [data] => <a href="/">Front</a> ]
?>

I think the critical part is the function theme_item_list, which declares $items as "An array of items to be displayed in the list. If an item is a string, then it is used as is. If an item is an array, then the "data" element of the array is used as the contents of the list item. If an item is an array with a "children" element, those children are displayed in a nested list. All other elements are treated as attributes of the list item element.":
http://api.drupal.org/api/function/theme_item_list/6

It is not prepared to deal with an array that contains an array that is not a "children" element. It treats it as an attribute, i.e. a string, leading to the error. There may well be similar assumptions made by other code.

StatusFileSize
new13.76 KB
new98.7 KB

Follow up to #13:
It IS an issue in Link v2.8:

The function theme_link_formatter_default returns l($element['#item']['display_title'], $element['#item']['url'], $element['#item']); in both versions, but in v2.8 the $element has changed.
In v2.6 the $element['#item']['attributes'] is an array(1): ['target'] (String)
In v2.8 the $element['#item']['attributes'] is an array(2): ['target'] (String) and ['rel'] (array(3)).
The function l (lovercase "L") require an array in 3. parameter, but the array ['#item']['attributes']['target'] MUST be a string-array.
I think the structure is made in function _link_sanitize, but I havn't had time to check more.
In the attaced files you can see compares between v2.6 and v2.8.

Solution:
In link.module:

Add unset($element['#item']['attributes']['rel']); in the function theme_link_formatter_default like this:

function theme_link_formatter_default($element) {
  // Display a normal link if both title and URL are available.
  if (!empty($element['#item']['display_title']) && !empty($element['#item']['url'])) {
    unset($element['#item']['attributes']['rel']);
    return l($element['#item']['display_title'], $element['#item']['url'], $element['#item']);
  }
  // If only a title, display the title.
  elseif (!empty($element['#item']['display_title'])) {
    return check_plain($element['#item']['display_title']);
  }
}

After much investigation, I've found the specific conditions that cause this warning to appear on my site with Link 6.x-2.8. Following these steps should do it:

  1. Find a node that has a link field. In my examples, I'll use mytype as the content type and mylink as the link field name.
  2. Manually update the content_type_mytype table (or the content_field_mylink table if the field is set for multiple values) row for that node as indicated below:
    • Set field_mylink_url to an invalid URL such as test
    • Set field_mylink_title to any string or NULL (this value doesn't seem to matter, as long as the title is set as optional)
    • Set field_mylink_attributes to NULL
  3. Clear the cache (or just delete the node's row from the cache_content table)
  4. View the node in a browser and the warning should appear.

Updating the field via the node edit form does not result in a warning, even if the URL is invalid. This seems to be because field_mylink_attributes gets set to a non-NULL value; in my case it is set to the following: a:3:{s:6:"target";s:7:"default";s:5:"class";s:0:"";s:3:"rel";s:0:"";}

So the first issue appears to be with old link fields that have a NULL attributes value.

I added the following to the beginning of the drupal_validate_utf8() function in bootstrap.inc:

<?php
if (!is_string($text)) {
 
print_r(debug_backtrace());
}
?>

This showed the following hierarchy of function calls:

  1. bootstrap.inc: drupal_validate_utf8()
  2. common.inc: check_plain()
  3. common.inc: drupal_attributes()
  4. link.module: l()
  5. link.module: theme_link_formatter_default()
  6. theme.inc: call_user_func_array()
  7. common.inc: theme()
  8. common.inc: drupal_render()
  9. (etc.)

So according to 4 and 5 above, on line 569 of link.module the theme_link_formatter_default() function is calling l($element['#item']['display_title'], $element['#item']['url'], $element['#item'])

Uv516 is correct in comment #15 above regarding $element['#item']['attributes']. As you can see in the first item below, the 'rel' key is set to an array rather than a string, which results in the PHP warning. In the second item it is simply left out, which works fine.

    [#item] => Array
        (
            [url] => test
            [title] => Test
            [attributes] => Array
                (
                    [rel] => Array
                        (
                            [0] =>
                            [rel] =>
                            [class] =>
                        )
                )
            [display_url] => http://example.com/test
            [display_title] => Test
            [label] => Other Sites
            [#delta] => 3
        )
    [#item] => Array
        (
            [url] => http://www.google.com/
            [title] => Google
            [attributes] => Array
                (
                )
            [display_url] => http://www.google.com/
            [display_title] => Google
            [label] => Other Sites
            [#delta] => 4
        )

drupal_attributes() passes the array to check_plain(), which passes it to drupal_validate_utf8(), where it ultimately produces the warning.

So the second issue is that the values in the $element['#item']['attributes'] array should be strings, but in this case the value for the 'rel' key gets set to an array for some reason.

I have not had a chance to track this down further than that, but I hope this is helpful in determining the source of this bug.

I ended up using Uv516's solution, except that I only unset it if the value is an array:

<?php
function theme_link_formatter_default($element) {
 
// Display a normal link if both title and URL are available.
 
if (!empty($element['#item']['display_title']) && !empty($element['#item']['url'])) {
    if (
is_array($element['#item']['attributes']['rel'])) {
      unset(
$element['#item']['attributes']['rel']);
    }
    return
l($element['#item']['display_title'], $element['#item']['url'], $element['#item']);
  }
 
// If only a title, display the title.
 
elseif (!empty($element['#item']['display_title'])) {
    return
check_plain($element['#item']['display_title']);
  }
}
?>

Assigned:Unassigned» jcfiala

Wow, that's pretty detailed. Thanks for all the information, folks.

Subscribing

Strangeways, that was a fantastic bout of work. Finding that the problem was that the 'rel' attribute was getting an array, allowed me to dig around and find that the problem was

<?php
$item
['attributes']['rel'] = str_replace('nofollow', '', $item['attributes']);
?>

Which really should be

<?php
$item
['attributes']['rel'] = str_replace('nofollow', '', $item['attributes']['rel']);
?>

as per my rules, I'm creating a test to exercise the fix, but once I know it's working and not breaking anything else (which I doubt), I'll be committing this.

Status:Active» Fixed

Okay, I honestly think I've got this fixed now, and a nice little test that shows that it's fixed. Much thanks to strangeways, and could people who are having trouble with this try updating to the 6.x-2.x-dev release sometime tomorrow (2/21 or 2/22 or later).

Status:Fixed» Active

Error still exists with Drupal 6.16
warning: preg_match() expects parameter 2 to be string, array given in /home/drupal/includes/bootstrap.inc on line 777.

It appears only on translated pages. It doesn't on pages in default language.

I use Link 6.x-2.x-dev (2010-Mar-01)

Same as #21.. but I am using 6.x-2.8

I have the same issue...

I have a link CCK field and one of my users put in 'N/A' in the field instead of a link. This caused the error to occur.

Subscribe

StatusFileSize
new528 bytes

Here's a patch for anyone who needs to patch 2.8 without downloading dev.

Error comes back with Drupal 6.17 and last Link module 6.x-2.x-dev.

warning:
preg_match() expects parameter 2 to be string, array given
in /home/drupal/includes/bootstrap.inc on line 842.

Hi all, here is a solution:

for Drupal 6.16
http://drupal.org/node/525036#comment-2144000
for Drupal 6.17
http://drupal.org/node/525036#comment-3046610

Okay, folks - to be able to fix this when it comes up with the link module, I need a bit more detail about what's going on. If you're having this problem, and you think it's because of the link module, please do the following:

1) Go up to http://drupal.org/node/628902#comment-2474016 and see what strangeways did to find what, exactly, was blowing up in his code.

2) Following his example, give me the backtrace in a similar format as he did, and emphasize which line numbers are involved for the calls in link.module.

3) Even better - when you find the bad line in link.module, add some

<?php
drupal_set_message
('<pre>'. print_r($something, TRUE) .'</pre>');
?>
lines, replacing $something with a variable in the bad line in link.module, and let me know what the variables are when the code's gone bad. This will help me figure out what I need to guard against to fix this.

Thanks.

Status:Active» Postponed (maintainer needs more info)

Heh. Forgot to change the status.

Amusingly, I think I've just stumbled across this after doing some testing with the protocol filter, and may have it fixed in the next release.

Version:6.x-2.8» 6.x-2.x-dev
Status:Postponed (maintainer needs more info)» Fixed

Okay, I think I've got a fix placed - I discovered through some testing with views that the protocol filter was using the wrong way to check it's value by default - I've overridden it and am now pretty happy with the result. (For people looking for help, I needed to override the admin_summary() function so that it wouldn't do a check_plain on $this->value, which was an array.)

Status:Fixed» Closed (fixed)

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

Version:6.x-2.x-dev» 6.x-2.9
StatusFileSize
new15.44 KB

Hi,

In 2.9 version the error still happens...with 2.8 also

warning: mysql_real_escape_string() expects parameter 1 to be string, array given in /srv/www/htdocs/webs/iova/includes/database.mysql.inc on line 331.
warning: mysql_real_escape_string() expects parameter 1 to be string, array given in /srv/www/htdocs/webs/iova/includes/database.mysql.inc on line 331.

the error is in the function db_escape_string($text) where $text is expected to be a string but an array is passed

I attach the debug_backtrace file (it's incomplete) for more details

So, I think I should use the dev version, isn't?

Thanks

Status:Closed (fixed)» Active

Subscribing.

Adding: This maybe a bit unique to my situation, but maybe it will helps someone. I receive this error only when saving the module via php node_save() and not saving the module directly. It pops up regardless of changing the link info or not. It doesn't seem to affect what I'm doing, but then again I'm not setting any attributes.

Subscribe