Multiple errors occur when image IPTC copyright field contains the © symbol

[dreamcolor]

When I upgrade from 2.3.3 to 2.5 RC2. In "Media Library". Those image attachments have some error messages out.

Error like this:

Warning: Invalid argument supplied for foreach() in x:\xxxxxx\xxxxxx\wp-includes\media.php on line 262

My server is Windows 2003 + IIS6 + PHP5 + MySQL

I have the same issue. I have debugged it and I know where it come from. In the wp_postmeta table in the DB, you have a field called meta_value which gives the some information about the pictures in the gallery.

It looks like this :
a:5:{s:5:"width";i:158;s:6:"height";i:69;s:14:"hwstring_small";s:23:"height='55' width='128'";s:4:"file";s:67:"/homepages/13/4375/htdocs/blog/wp-content/uploads/2008/01/logo.jpg";s:5:"thumb";s:18:"logo.thumbnail.jpg";}

The number after the s: gives the length of the parameter value after the second :

For unknown reasons, the value isn't correct, it is too high (here 67 while it should be 66). If you perform the change manually into the DB to set it to the correct value, it works fine, the error goes away. The problem is that when you have 500 pictures, it could be very long to perform the change manually for all pictures...

I personnaly started to have problems with pictures in the gallery following a blog @ change (removed a directory in the URL/path).

I guess the solution would be to fix the value on the fly if it is discovered that it isn't good by just calculating the lenght of the string between the " ".

The problem isn't related to IIS6. My WP runs on linux/apache.

Same issue, but, it seems, different cause. One of my wp_postmeta meta_value fields contains following:
a:6:{s:5:"width";i:800;s:6:"height";i:536;s:14:"hwstring_small";s:23:"height='85' width='128'";s:4:"file";s:71:"/home/content/d/n/e/dneez/html/dneez/wp-content/uploads/2008/04/pic.jpg";s:5:"sizes";a:2:{s:9:"thumbnail";a:3:{s:4:"file";s:15:"pic-150x150.jpg";s:5:"width";i:150;s:6:"height";i:150;}s:6:"medium";a:3:{s:4:"file";s:15:"pic-300x201.jpg";s:5:"width";i:300;s:6:"height";i:201;}}s:10:"image_meta";a:10:{s:8:"aperture";d:4.20000000000000017763568394002504646778106689453125;s:6:"credit";s:12:"Deniss Saksa";s:6:"camera";s:9:"NIKON D80";s:7:"caption";s:0:"";s:17:"created_timestamp";i:1206836068;s:9:"copyright";s:38:"[[BR]]

Notice missing end part. My copyright IPTC field starts with copyright symbol (©) on images that cause the problem. Images that don't contain IPTC copyright field work normally. And I confirm that it is not related to IIS6 as my WP runs on linux too.

possibly related: ​http://trac.wordpress.org/ticket/6532#comment:5

I have confirmed that when an image IPTC copyright field contains the © symbol multiple errors occur.

Errors for such files I have noticed include:

The error “Warning: Invalid argument supplied for foreach() in ../blog/wp-includes/media.php on line 264” appears above image on manage media admin page. (See screenshot here ​http://www.enliteart.com/images/screenshoterror.gif)

When inserting images in a post only the full sized images is used regardless of size selected.

When deleting images from the manage media admin page only the full size image is deleted. (i.e. The “medium” and “thumbnail” size images remain on the server but wordpress ignores them.)

Would it be possible to attach an image (test or otherwise) which can reproduce the bug?

Replying to DD32:

Would it be possible to attach an image (test or otherwise) which can reproduce the bug?

Sure -to test I just created a new blank .jpg in photoshop CS2 and uploaded one with containing the symbol and one without. They are located here:

​http://www.enliteart.com/images/copy.jpg -with symbol
​http://www.enliteart.com/images/none.jpg -no symbol

note: they are both blank white

Replying to andyfarmerboy:

Sure -to test I just created a new blank .jpg in photoshop CS2 and uploaded one with containing the symbol and one without. They are located here:

This a weird one :)
Its related to storing certain values in the database base, which is probably related to #6532

I cannot reproduce it on my normal test install. I can reproduce it on another test install (Which is stock), I cannot reproduce it on a new install(All trunk). All running exact same wp-config.php's, all on the same database, all wish the same table setups.

In the case of the failing one, The SQL Insert doesnt insert the entire serialized string, It gets cut off at the Copyright character, So its probably related to a charset issue as Denis mentioned before: #6532 ?

Ok, I was an idiot. They were not identical config files, i didnt open the right one :)

Adding

define('DB_CHARSET', 'utf8');

to the wp-config.php file allows the bug to be reproduced. So its likely the copyright symbol isnt being escaped. Removing it will fix it for furthur additions, But will not fix current items as the data is corrupted in the database.

My database is running with utf8_general_ci collation, with a UTF-8 Unicode (utf8) default charset.

The issue is related to the fact that the field is corrupted and the field size (as written into the DB) isn't the same as the current field size (because it has been truncated) so a fix would be to parse the DB and correct the field size so that the error doesn't happen anymore...

Replying to firebird75:

The issue is related to the fact that the field is corrupted and the field size (as written into the DB) isn't the same as the current field size (because it has been truncated) so a fix would be to parse the DB and correct the field size so that the error doesn't happen anymore...

Yes, However it is only truncated as it's written to the databas incorrectly, Which is the root cause of the bug.

For affected items the field would need to be deleted and a new one inserted into its place, It'd be impossible to simply 'correct' the value if the actual original data is unknown.

Well, a workaround could be to parse the database and correct the incorrect value. Removing and reinserting hundred of entries manually is just not feasible...

Well, a workaround could be to parse the database and correct the incorrect value. Removing and reinserting hundred of entries manually is just not feasible...

Yeah, point taken that its not a viable solution to manually correct them, However, Until an actual bug(Other than a configuation error) is determined, Theres not much that could be done.

Dont take my word as an end-all, because its not, And i'm not really interested in debating the point, But, From what i can see, It appears to be a configuration issue with certain settings(utf8), if thats the case, then i'll leave it to someone who understands those issues more, From what i know, utf8 is a pain at present in WordPress while wanting to support older versions of PHP/MySQL, and as such, it might not be a simple fix if its happening between the Database class and the database server.

Functions like "wp_get_attachment_image" didn´t return thumbnail- or middle-sized images and it took me quite some time to figure out why.

Test images are available here: ​http://trac.wordpress.org/ticket/7278.

I hope this issue can ce corrected soon. (Not inserting special characters into the db would be fine for me...)

Milestone 2.5.2 deleted

While waiting for 2.9 deleting the IPTC data (using a command line tool, a photoshop action or something similar) is one option.

Turning off the problematic IPTC support Wordpress is offering, is another. Deleting the small part in wp_generate_attachment_metadata (image.php) might do the trick.

Seem to be an issue related to encoding.

this bug is actually encoding related but is also based on other bugs. first of all, the store of meta data is not everytime binary safe (as with some option values as well) so that when converting / updating / reusing / server-changes-in-the data(base), you might get errors on de-serializing data (like on this one).

next to this, there can be encoding errors then caused by this because the chain is broken.

related: #9417

hopefully after that is patched, utf-8 encoded data is returned from the IPTC fields sothat the chain is more stable in the future.

This bug is not fix-able because it is based on data that has been wrongly inserted into or read out of the database. This can have multiple issues. Therefore this wont fix.