Per this thread, someone mentioned they narrowed this warning/error down to swfupload. I checked an install I was having an issue with, and can confirm after deleting any images attached to the node, the warning goes away.

Doesn't matter if I re-order the images or not, as long as there are images attached to a node through swfupload, I receive this warning.

The warning does not appear if I only have one image, but it appears twice if I have 3 images, 5 times if I have 6 images, etc etc. This is why originally I couldn't pin which module was causing me the problem, because I had a lot of nodes with just one image that didn't display the error.

CommentFileSizeAuthor
#27 864208-27.patch740 bytesroderik
#25 swfupload_htmlspecialchars.patch859 bytesjvandooren

Comments

sansui’s picture

sansui commented

Forgot to link thread where issue is discussed - http://drupal.org/node/829250

EugenMayer’s picture

EugenMayer commented
Priority: Normal » Major

running into this issue also having swfupload installed, so this shall be confirmed. Pretty anoying message, setting it to major

yakker’s picture

yakker commented

Having this issue also, but I do not have swfupload on the site....

sansui’s picture

sansui commented

Looking at other modules that have had this issue, it seems most that have resolved it have indicated it's an issue with a default value somewhere, or a value being set twice by two different modules.

I tried poking around but not really sure what I was looking for. In the meantime I guess it's back to fupload for these sites.

sansui’s picture

sansui commented

Alright, one last thing to offer - it seems like the error is only occurring on ubercart product pages. I set up a page content type with just the swfupload imagefield and some other fields, and those pieces of content display the images without error.

So is this a conflict with ubercart? Eugen, are you having the issue with UC pages?

EugenMayer’s picture

EugenMayer commented

Well finally i see that my issues tracks down to apachesolr right now, and no, no UC involved

sansui’s picture

sansui commented

Alright, paint me embarassed. Somehow in my product tpls, I had commented out where I was setting variables for product titles, alts, descriptions, and the error was occuring from the imagecache function I was calling and using those variables.

Edit: Actually... I still have no clue what's going on. After fxing that, the error went away, now it's back. Seemingly intermittent. Banging head on desk

Edit 2: Some of my nodes are not displaying the error, but I can get all of them to display it if I do this:

1.) Find node without error
2.) Edit node, save without changing anything, error now appears

To remove the error:
1.) Edit node, enter a title for an image
2.) Save node, error is gone

Each time I edit the node, as long as I add or remove a title field, the error doesn't appear. Once I save without deleting/adding title text to an image, I get the error again. When the error is not present, I can refresh the node as many times as I want and not get the error. Once I save without modifying a title field, the error is present and stays however long I refresh the node, until I add a title tag again.

This happens in Garland theme as well, and not just my own, and I can reproduce these steps in Garland to get the error to appear or disappear

sansui’s picture

sansui commented

Ok... more digging. I made some changes to swfupload_widget.inc which starts on line 62. I changed line 76 from:

$file += array('description' => $tmp_file['data']['description'], 'alt' => $tmp_file['data']['alt'], 'title' => $tmp_file['data']['title']);

To the following:

          if(!$tmp_file['data']['alt']) { $my_alt = 'Default Alt'; } else { $my_alt = $tmp_file['data']['alt']; }
          if(!$tmp_file['data']['title']) { $my_title = 'Default Title'; } else { $my_title = $tmp_file['data']['title']; }
          if(!$tmp_file['data']['description']) { $my_description = 'Default Description'; } else { $my_description = $tmp_file['data']['description']; }
          $file += array('description' => $my_description, 'alt' => $my_alt, 'title' => $my_title);

The error no longer ever appears with this in place. Am I right to assume then the problem is when these tmp_file variables are empty?

matulis’s picture

matulis commented

Thanks, sansui! No error message anymore :)

swfupload_widget.inc, line 82 (6.x-2.0-beta7)

replace

          $file += array(
            'description' => $tmp_file['data']['description'],
            'alt' => $tmp_file['data']['alt'],
            'title' => $tmp_file['data']['title'],
            'list' => $tmp_file['list'],
          );

with

          $file += array(
            'description' => $tmp_file['data']['description']? $tmp_file['data']['description']: '',
            'alt' => $tmp_file['data']['alt']? $tmp_file['data']['alt']: '',
            'title' => $tmp_file['data']['title']? $tmp_file['data']['title']: '',
            'list' => $tmp_file['list'],
          );
kirilius’s picture

kirilius commented

I have very similar issues with SWFUpload. If the above fix works, can it be rolled into a release?

EugenMayer’s picture

EugenMayer commented
Status: Active » Patch (to be ported)

The above works, but be aware it wont fix existing uploaded files only for following uploads.

I will stuff this into the next release.

kirilius’s picture

kirilius commented

Hmm... I actually tried the fix and it really didn't fix my old nodes.

sansui’s picture

sansui commented

You might try resaving your old nodes kirilius..... this won't fix things retroactively.

kirilius’s picture

kirilius commented

Yes, resaving the old nodes cleaned up the mess ;-)

Thanks!

EugenMayer’s picture

EugenMayer commented

So for the records:

if you apply the patch, you have to resave the old nodes so the error disapears there. New nodes wont be buggy anymore.
(will need that for the release notes)

skilip’s picture

skilip commented
Status: Patch (to be ported) » Fixed

Thanks guys!

Status: Fixed » Closed (fixed)

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

kirilius’s picture

kirilius commented

I got the beta8 and the problem is still there. Does anybody know when the fix will be available in a release?

sylverspyder’s picture

sylverspyder commented
Version: 6.x-2.0-beta6 » 6.x-2.0-beta8
Component: Miscellaneous » User interface
Status: Closed (fixed) » Needs work

Hi,

I'm second-ing kirilius. Im on 6.x-2.0-beta8 as well and saw this bug when I edit and rearrange uploaded images.

Furthermore, the new arrangement wont get saved, no matter how many times i tried to edit it.

Hope you guys can fix this soon :D

Thanks.

ranx’s picture

ranx commented

I had the same problem with 6.x-2.0-beta8

Applied the fix from #9 and everything seems to work.

EDIT:

The original error message disappeared but the fix seems to have messed up something else. No matter what I do I can't get views to display any images. Even ones that have been uploaded through imagefield. I also got several errors inside views. I might have done something wrong myself but i would proceed with caution when trying this fix.

Naiya’s picture

Naiya commented

i fix my 6.x-2.0-beta8 with a patch from #9.

I was carefully as @ranx said. i have added a view with my swfupload-field and modify existing one.
for now everything seems to be fine.

net_runner’s picture

net_runner commented

Same here on beta8 - but bug shows on line 857 (6.20).

jvandooren’s picture

jvandooren commented

I also patched my 6.x-2.0-beta8 with the patch from #9.

I re-saved the specific node, error was gone. I created a view and the photos were displayed just fine...

kirilius’s picture

kirilius commented

I believe it is confirmed that the fix from #9 does remove the problem. Can it be rolled into a release so it doesn't need to be applied manually every time one re-installs (updates) the module?

jvandooren’s picture

jvandooren commented
StatusFileSize
new swfupload_htmlspecialchars.patch859 bytes

Patch with the changes from #9 attached...

As Kirilius mentioned, I also think it's safe to change the status...

jvandooren’s picture

jvandooren commented
Status: Needs work » Reviewed & tested by the community

And I forget to do it :)

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented
StatusFileSize
new 864208-27.patch740 bytes

RTBC +1!

New patch is the same, only has a little more consistent spacing.

carvalhar’s picture

carvalhar commented

ok #9 worked for me.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Hi,

when will the patch be applied to a released version?

bzbzh’s picture

bzbzh commented

subscribe

doublejosh’s picture

doublejosh commented

Cripes, patch didn't solve it for me.
I have one htmlspecialchars() error for each filefield image on the node page and really thought this was going to get it.

However, when I disable this module the errors go away. Will keep digging.

doublejosh’s picture

doublejosh commented

...and nevermind... this DOES WORK! Just needed to RESAVE nodes... like it says in plain English above.
(I'm running on the latest beta8)

huba’s picture

huba commented

subscribe

doublejosh’s picture

doublejosh commented

I was also able to solve this problem on node types by adjusting the field display settings.

pfournier’s picture

pfournier commented

I have the same problem. The proposed patch fixed the error message, but not the root of the problem, which is that the alt and title attributes of the $tmp_file['data'] are set to an empty array instead of an empty string.

We should try to find who is responsible for this bad data (maybe the javascript code?).

faqing’s picture

faqing commented

I have installed this module in two sites (sub-domain) of the same server. One has no problem, one with this message:
warning: htmlspecialchars() expects parameter 1 to be string, array given in /home/xxx/includes/bootstrap.inc on line 860. The message only displays under teaser view. Anyone got the same problem?

oriol_e9g’s picture

oriol_e9g
Primary language Catalan
Location Barcelona
commented

Yeah! Same problem and patch in #27 fixes the warning!

faqing’s picture

faqing commented

If #27 fixes the warning, can we release a stable version?

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

*PUSH* Did the module maintainer have a look at this?
A new releasae would be very helpful!