Insert image into post always inserts full size.

[lunabyte]

Fresh install of WP 2.6 always inserts full image size, regardless of settings.

This is a completely clean install of 2.6, without plugins or any adjustments whatsoever.

PHP: 5.2.5
Apache: 2.2.8
MySQL: 5.0.45
DB Charset: utf8
DB Collation: utf8_bin

• Medium image size is created as expected
• Thumbnail size is created as expected.
• CSS class(es) added as expected

• URL to image is always the full size image, regardless of selecting thumb or medium.

Tracked down thus far:

function image_get_intermediate_size (on/about line 276) in /wp-includes/media.php initially calls to wp_get_attachment_metadata, which is checked to be an array. If not, returns silently.

This check fails because the value returned by wp_get_attachment_metadata for $imagedata has failed to be unserialized.

Selecting the data directly from the database, then running unserialize also fails to unserialize the stored data.

Using css to scale down an image isn't sufficient as the browser still downloads the full size image.

This isn't a path/url issue, as well. All paths/urls are properly rendered.

With the data failing to be unserialized, the check for the array in image_get_intermediate_size will always return false.

[lunabyte]

As an update to this, I've also tested r8621 from trunk for this, with the same results.

I've even taken this as far as modifying wp-includes/post.php so that if the meta_key was _wp_attachment_metadata, running serialize on the data and skipping the call to maybe_serialize.

That also failed to produce data which was able to be unserialized as well, which results in an overall symptom in the browser where (with r8621) all image size buttons are disabled, with "full size" being the only option available (and selected by default).

Which all comes back down, after tracing back all functions, to the data failing to be unserialized.

If the data array can't be directly serialized, that would lead me to think that perhaps there is some type of malformed data within the array and it causes it to be serialized improperly, resulting in a failure when trying to unserialize.

[lunabyte]

Another update.

Tracked this down to problems with images that have image_meta associated with them.

The array is fully constructed, but when serialized it fails to fully serialize the data, which results in the string not being able to be unserialized. wp_specialchars had no affect on the data.

The particular image_meta portion of the array (prior to serialization) resembles the following, confidential details replaced with dummy text:

    [image_meta] => Array
        (
            [aperture] => 4
            [credit] => Fname MI. Lname/My Service
            [camera] => Canon EOS-1D Mark II N
            [caption] => Month Day, Year - Continue on with about a 100 char description here...
            [created_timestamp] => 1202676120
            [copyright] => ©My Company, Inc. (Alt Co. Title)
--ALL RIGHTS RESERVED--
contact: sales@domain.tld
http://www.domain/.tld
            [focal_length] => 300
            [iso] => 200
            [shutter_speed] => 0.0003125
            [title] => 
        )

What it appears to be is an incompatible data format. Whether it's conflicting with utf8, or whatever the case may be.

[westi]

2.6.1 has been released, moving to 2.6.2 milestone

[Txanny]

I'm having this error with some images. And to now, what I've found is: If the Image IPTC (Image Title) data contains special characters: quotes or international characters, full size is always inserted into post.

Thumbnail is created correctly, Medium Size image also. But They are not inserted into post. And, if you delete the image from gallery, thumbnail and medium size is not deleted from disk.

I've patched my copy of wordpress to make it run by utf8_encoding the read IPTC data. I'll attach the patch I'm using to solve this issue.

[Txanny]

Corrected patch to solve this issue.

[santosj]

I have this problem on my blog, so I'm probably going to test it there.

[santosj]

Probably should be committed to trunk.

[westi]

Patch looks good. Will land in trunk and 2.6 branch for any possible further 2.6 maintenance release.

[westi]

(In [8744]) utf8 encode data from IPTC tags. Fixes #7495 for trunk props Txanny.

[westi]

Re-open for 2.6 branch

[westi]

(In [8745]) utf8 encode data from IPTC tags. Fixes #7495 for 2.6 branch props Txanny.

[flexseth]

#60655 was marked as a duplicate.