WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#7495 closed defect (bug) (fixed)

Insert image into post always inserts full size.

Reported by: lunabyte Owned by: westi
Milestone: 2.6.2 Priority: high
Severity: major Version: 2.6.1
Component: General Keywords: has-patch commit
Focuses: Cc:

Description

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.

Attachments (1)

image.patch (1.5 KB) - added by Txanny 7 years ago.
Corrected patch to solve this issue.

Download all attachments as: .zip

Change History (13)

comment:1 @lunabyte7 years ago

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.

comment:2 @lunabyte7 years ago

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.

comment:3 @westi7 years ago

  • Milestone changed from 2.6.1 to 2.6.2

2.6.1 has been released, moving to 2.6.2 milestone

comment:4 @Txanny7 years ago

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.

@Txanny7 years ago

Corrected patch to solve this issue.

comment:5 @Txanny7 years ago

  • Keywords has-patch added

comment:6 @santosj7 years ago

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

comment:7 @Txanny7 years ago

  • Keywords commit added
  • Version changed from 2.6 to 2.6.1

comment:8 @santosj7 years ago

Probably should be committed to trunk.

comment:9 @westi7 years ago

  • Milestone changed from 2.6.2 to 2.7
  • Owner changed from anonymous to westi
  • Status changed from new to assigned

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

comment:10 @westi7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:11 @westi7 years ago

  • Milestone changed from 2.7 to 2.6.2
  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-open for 2.6 branch

comment:12 @westi7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.