warning: htmlspecialchars() expects parameter 1 to be string, array given in /home/opticist/public_html/includes/bootstrap.inc

Look here: http://drupal.org/node/320145#comment-2673928

Getting the same error after upgrading to 6.17. Seems to always occur in the error log after a comment form submission is BLOCKED by Captcha. However, blocked comment submissions do not always get followed by the error. There's another thread about this being started here: http://drupal.org/node/831722, but it's about as short as this one...

This patch works, and it has been reviewed by several users (in that post that I linked)... Would it be commited?
Thanks!

1. There is no patch attached.
2. Changes go to Drupal 7 before Drupal 6.
3. This issue is with the calling function not with our htmlspecialchars() invocation. Even if we cast an array to string, we will get "Array" in PHP, so not much use to get the actual content of the array. The error will go away, but it will not work as it supposed to. The caller has an issue, not this function.

subscribing

Subscribing. Have this problem on 6.17 and haven't pinned down the cause yet

subscribing

[edit out]

Turned out to be a default_value issue.

Cannot find a culprit for this warning anywhere. I've disabled every module that uses htmlspecialchars and none of them seem to be causing the issue. Tried different themes, disabling all new modules. I've developed a nervous twitch every time I see it pop up now >.<

This started happening for me after i installed the SWFupload module. I would create a node with several images, after i submit the node it's fine. But after I edit the node and change the order of the images i start getting this error.

If I delete the images the warning goes away. I'm then able to add new images in the same node and no warning. It just doesn't like to have the images rearranged.

@newToo: now that you know the problematic module, please submit an issue with that module. The issue should be fixed there, and they'll probably not know about it if its not in their queue.

Wow, thanks newToo. swfupload seems to be my issue as well. I created a thread there - I didn't pin it as the culprit for my case since apparently if there is only one image attached to a node, the warning doesn't show up, so I assumed swfupload was not to blame. It only happens with multiple images (although it happens to me whether I re-order them or not)

I want to keep this alive for those (like me) who do not have swfupload installed - still getting the error though...

subscribing

subscribe

Subscribe

seems like its not fixed in drupal 6.19?

i updated and i still have this error message.

@akaserer: yes, its still an issue with one or more of your contributed modules or themes, not Drupal itself.

now on: /bootstrap.inc on line 857.

i m also on 6.19 now, everything updated.
still the warning

You may want to do some detective work with your installed modules. Mikesteff gave me a clue with the default_value comment, and I found that the problem I had was caused by a module in a section that referenced the #default_value of file in a foreach loop.

If you have a tool that can search for a particular string in a file (like textpad) you can search for default_value in your modules folder and help narrow down which module it could be, then start disabling until you find the culprit

@Gábor Hojtsy: ya , i guess its an issue of a contributed module.

Check my reply @ http://drupal.org/node/525036#comment-3362618 . In my case it's a combination of Ctools and Panels.

Greets,
Kim

I found that when I removed an Address type field (i.e. generated by the Addresses CCK module), I got these errors to go away. It seems like that module is passing around the address as a PHP array, which makes some of the form.inc and bootstrap.inc functions choke because they're expecting simple types as inputs.

i still could not pin point the culprit, but is seems we have it on every page where there is possibility to write comments.
even on a simple node of the type page
http://www.revaki.ugent.be/?q=nl/onderwijs/onderwijs

error massages are hidden for not admin users.
but it gives an idea of the simplicity of the page

subscribe.

...and I can confirm, that it appears first after installing a group of other modules. Thanks to brinlo and nightlife for sharing their black sheeps causing it. And thanks to sansui advising to make a string search for default_value. I definitely will follow this and will share here, which module has caused it. We all should do it and create a list of modules causing it and should share it with the developers of that modules.

it this message occurs 8 times, does it mean that there are 8 plugins causing it?

thanks for all the good hints here!

digidog, I was receiving the error multiple times, but the culprit for me was one module. Since there were multiple files being rendered, each instance generated another error. So unfortunately it's hard to tell if its one or multiple modules contributing to the warnings

Sansui, many thanks for your fast reply. Did I get you right in your previous post, that you have used an advanced search-string to filter out "default_value" strings used inside of "for each()" loops? Otherwise I'll get here thousands of #default_value uses in the sites/all/modules folder ... by searching with dreamweaver ftp folder ...

Otherwise maybe this from "nightlife" (as he has posted above) could help to find the modules: http://drupal.org/node/525036#comment-3362618

but I am not really sure what I am searching for, to be honest.

And I found this part of the post from "srobert" in the other thread interesting: "... ... It appears only on translated pages. It doesn't on pages in default language." Can anybody confirm this?

My warnings did not come on translated pages. Not sure how dreamweaver searches, but something like textpad is free and you can tell it to search all files in your local modules folder (use a asterisk to specify all file types) and then search for "default_value". You won't get thousands of values - I had 100+ modules installed and found fewer than 10 modules that I needed to check, which I then disabled/re-enabled one by one until the error went away

@ Sansui: yeah, I know textpad. It was just a matter of low-treshold. I don't even use dreamweaver but it was just in the CS bundle and I tried searching with it before trying with others. And I had to search remote, not local. Almost every module uses #default_value, but not in a foreach loop. I also had tons modules installed. The most common ones, and mostly not the dev's or beta's, only a few which had no ready release, but needed because of dependies. My plugin manager says that panels are running in legacy mode, so I dropped it and all depending modules, also ctools. Finally the message is away and I can confirm that panel and ctools may have to do with it.

Good Night and Good Luck ...

its funny. re-installing them did it. now I have ctool and panels running wihtout that message ...

subscribe

I have got the same warning when trying to create a view that displays several thumbnails linked to the parent node. I get the warning after I add the image field to the view - as soon as the preview is displayed.

The solution i found and works what is even more enjoyable:
http://arjanwooning.nl/content/warning-htmlspecialchars-expects-paramete... its in dutch
the translation
/includes/bootstrap.inc
line nr 842 function check_plain($text) {

modify line 857
//Original return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
//fix http://arjanwooning.nl/content/warning-htmlspecialchars-expects-paramete...
return (preg_match('/^./us', (string) $text) == 1) ? htmlspecialchars((string) $text, ENT_QUOTES, 'UTF-8') : '';

i hope this helps others, took me a long time to find.

If that solution works, can it be rolled into the next release of Drupal core?

I´m trying that out, can anyone else confirm this solution? I mean, the status of this post is "Closed "works as designed", so it will be commited? What does this status mean?
Thanks!
Rosamunda

Does "works as designed" mean that warning is suppossed to always show?

i had this error message as well on my page.

after activating devel and krumo debugging i found out that the error actually comes from views.

after deleting the node-title field (with the views-field-option to show only 20 letters of the title) the error disappeared.

seems like not a core issue.

Moving this under views issues list.

I don´t quite understand it. In my case, the error appears in a node (a groupnode actually), but it has a couple of embedded views (embedded via the group .tpl). You mean that the issue should be because of anyone of that embedded views? Because the error didn´t appear in a page generated by views.
Thanks for the clarification. :)
Rosamunda

I guess there are several use cases in which this error appears.

In my case I have a node type, which has an multi-value imagefield in it. I am trying to create a pretty standard view that displays a grid of thumbnails linked to the node (nothing fancy, just a node id argument and filter by node type). I get the error message when I try to preview the view (even before saving it).

@kirilius true, the error appears in my admin section at times (i.g. after installing something with the Plugin_manager module) and on my module listing sometimes too.

Somebody above suggested that the problem might be connected to SWFupload module. I have that enabled for my ImageField but I don't see how this can affect a View output. SWFupload should only take over presentation of the ImageField only in edit mode.

kirilius, the swfupload widget also processes other information like image alt, title and description. You might as well try the temp fix for swfupload that was suggested in this thread and see if it works for you - http://drupal.org/node/864208

I don´t think that the problem connects necessarily with SWFupload module, because I don´t have it installed, and I´ve got the error.

Well, this is really hard to fix with this kind of info. I have seen this bug when I was developing some modules.

To know what was wrong I did this:

1) Install devel module:
2) Put this lines in the bootstrap.inc file:

  // Arround line 840 in drupal/includes/bootstrap.inc

  if ($php525) {
    if (is_array($text)) {  //add
      dsm($text);         //this
    }                   //lines
    return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
  }

So, this will give you the non-string that is causing problems. With this info we can trace the bug, if is a view bug...

.

Thanks dagmar. I did what you suggested and I have attached a screenshot of what I see (I get this when I try to display my view resutls). I guess I get each message twice as I have 2 results (images) in my view.

Additional try

  if ($php525) {
    if (is_array($text)) {  //add
      dsm($text);         //this
      dsm(views_trace());
    }                   //lines
    return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');

Tried that too. The views trace information I get is this:

imagecache.module: check_plain line 839
theme.inc: call_user_func_array line 656
imagecache.module: theme line 694
theme.inc: call_user_func_array line 656
content.module: theme line 1837
content_handler_field_multiple.inc: content_format line 254
views_handler_field.inc: content_handler_field_multiple->render line 452
theme.inc: views_handler_field->advanced_render line 225
theme.inc: call_user_func_array line 656
views_handler_field.inc: theme line 698
views_plugin_style.inc: views_handler_field->theme line 223
views_plugin_style.inc: views_plugin_style->render_fields line 178
views_plugin_style.inc: views_plugin_style->render_grouping line 142
theme.inc: views_plugin_style->render line 46
theme.inc: call_user_func_array line 697
views_plugin_display.inc: theme line 1825
view.inc: views_plugin_display->render line 861
views_plugin_display.inc: view->render line 1880
view.inc: views_plugin_display->preview line 945
admin.inc: view->preview line 387
menu.inc: call_user_func_array line 348
index.php: menu_execute_active_handler line 18

So this is a imagecache problem :)

Again, I don´t have image cahche and I still get this htmlspecialchars() problem...

Rosamunda equals Kirilius?

@rosamunda
You could try the same kind of stuff to find out the root of the problem.

subscribing

For me the error on line 857 dissapeared after uninstalling the Case Tracker Module (casetracker-6.x-1.0-beta8)
Hope this may help...

Hmm, I don't have the Case Tracker module. It seems different people experience this problem with different module sets. Obviously it must be something either in the Drupal core or some very popular module lile Views, that everyone has.

Obviously it must be something either in the Drupal core or some very popular module lile Views, that everyone has.

This is like saying "Obviously the sky is blue because blue is the favored color of the deity."

Any time invalid data is sent to check_plain(), this error occurs. That means that there could be any number of things that cause it that aren't related to each other in the slightest. Suggesting that it MUST be Views because everyone has Views is ridiculous.

YOUR problem is obviously imagecache. I say this because you provided a trace that says that imagecache calls check_plain() with invalid data. Therefore, imagecache is the next stop on your quest to find out what's wrong.

Rosamunda: As dereine said, you should do the same thing and get a trace to figure out where your version of the problem is coming from.

This entire issue got moved into the Views queue because one commenter said "My problem was with Views" (without providing any details) and suddenly everyone's problem is with Views? Please be more analytical than that.

I´ve done that, and this is what I get:

views_handler_field.inc: check_plain line 651
views_handler_field.inc: views_handler_field->get_render_tokens line 501
views_handler_field.inc: views_handler_field->render_text line 471
theme.inc: views_handler_field->advanced_render line 225
theme.inc: call_user_func_array line 656
views_handler_field.inc: theme line 698
views_plugin_style.inc: views_handler_field->theme line 223
views_plugin_style.inc: views_plugin_style->render_fields line 178
views_plugin_style.inc: views_plugin_style->render_grouping line 142
theme.inc: views_plugin_style->render line 46
theme.inc: call_user_func_array line 697
views_plugin_display.inc: theme line 1825
view.inc: views_plugin_display->render line 861
views_plugin_display_default.inc: view->render line 54
view.inc: views_plugin_display_default->execute line 922
node-consorcio.tpl.php: view->execute_display line 51
theme.inc: include line 1066
theme.inc: theme_render_template line 725
node.module: theme line 1028
node.module: node_view line 1101
node.module: node_show line 1797
menu.inc: call_user_func_array line 348
index.php: menu_execute_active_handler line 18

Maybe in my case it has something to do with views after all?

Thanks for your help!!
Rosamunda

Update: I´ve got a group node that uses this tpl: node-consorcio.tpl.php that adds a view, and this is the line 51:

    $view = views_get_view('consorcio');
    $args = array(array(0 => $node->nid));
    $body = $view->execute_display('default', $args);  // this is line 51

Maybe this code is what´s causing the problem?

Thanks!!
Rosamunda

Better use this code

    print views_embed_view('consorcio', 'default', $node->nid);

I guess this might fix the issue

I played with my view a bit more and found some even stanger bahaviour:
I am building a simple view that shows image (imagefield) thumbnails. If I use any Lightbox ImageCache preset for the image formatter, there is no problem. If I use any preset that I created manually, I see the error messages.

I solved this error on my site, I am running D7 dev version from September 10th. This is a fresh install with only one node created of type blog. I disabled all the core modules except for Devel 7.x-1.0-beta2 and administraction menu and still got this error.

Then I disabled devel and the error went away.

Now I have enabled all my other modules except for Devel and still no error. Just for completeness I enabled Devel and the error came back, disabled and the error is gone. So at least on my fresh install of D7 dev the devel module is the cause.

Modules I have working include: Administration menu, Token, Pathauto, Google Analytics, Wysiwyg (with TinyMCE), Views

See also: http://drupal.org/node/910328

It would be very ironic if indeed devel is the problem. Just wanted to point that out :)

No, I had the problem before I installed Devel ;-(

You all, this problem might be caused by different modules, for example imagecache.

This is a duplicate of #225211: warning: preg_match() expects parameter 2 to be string - SRSLY, WON'T FIX, EVER.; the error message changed for people on PHP 5.2.5+ because of some optimizations to check_plain.

This isssue itself is a trainwreck. The phrase "analytical skills of the common vole (Microtus arvalis)" comes to mind. When debugging, make yourself a cup of tea / coffee / other , then go ahead carefully. Assumptions and jumping to conclusions are your enemy.

The underlying cause is simple: check_plain() should not receive arrays as input. That's also the only thing all of you might have in common.

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

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. You very likely have a module with a bug somewhere which passes an array to check_plain instead of a string. Each of you seeing the message might have a different module with this bug.

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 check_plain() 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 check_plain().

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 converting function to make it deal with non-string input.

When you identify the cause of the issue, file an issue in the appropriate module queue. Make sure to file an issue that contains sufficient information. Include the backtrace and a description of additional detective work that lead you to the conclusion the module you're filing against is indeed the culprit so the maintainer is able to fix asap. No-one is getting prizes for being vague.

For example; Should anyone of you have confirmed your root cause is an issue with views, post a new issue in the views queue, this time adding the backtrace, your additional detective work AND follow the guidelines in Obtaining support for Views issues.

If you get stuck debugging, please ask for help in the forums or on IRC.

Thanks, and good luck!

This issue has been locked.