4

I have 2 sizes thumbs for featured images with the same height:

  • 300 x 200
  • 540 x 200

I've checked the uploads folder and both thumbs with different sizes appear correctly:

  • file_name-300x200.jpg
  • file_name-540x200.jpg

I'm trying to get the bigger thumb size (540x200) as following:

$width = 540;
$height = 200;
echo get_the_post_thumbnail( $post->ID, array($width,$height) );

However, the image markup that is returned is for the smaller thumb zise (300x200). Interestingly, the class is displayed with the correct domantions as 'attachment-540x200':

<img width="300" height="200" src="http://mysite.com/wp-content/uploads/file_name-300x200.jpg" class="attachment-540x200 wp-post-image" alt="file_name" title="file_name" />

Would really appreciate if anyone could explain what's happening and why the correct size thumb isn't returned.

Many thanks, Dasha

1 Answer 1

2

I think you've hit interesting logic issue in image_get_intermediate_size(). This function loops through available images and tries to find best possible match for custom dimensions you provided.

First it attempts to find image as per comment in code:

// already cropped to width or height; so use this size

See the issue? Not image, perfectly matching dimensions, but image that matches in width or height, with remaining dimension being smaller or equal than required to fit in dimensions.

So your 300×200 image has equal height and fits inside 540×200 dimension you want (and probably comes earlier in meta data) so WP happily grabs it to use.

Interestingly, the class is displayed with the correct...

No mystery there, class is simply generated from your input, without regard if values make sense and/or available.

6
  • Worth submitting a bugreport/patch? Seems like it would be simple enough to fix. I'll be happy to generate one and throw props back to @Rarst and this question... Commented May 31, 2011 at 14:14
  • Update: bugreport submitted, with patch attached: core.trac.wordpress.org/ticket/17626 Commented May 31, 2011 at 14:34
  • @Chip Bennett nice, I do not hang out on trac much :) I am not sure your proposed patch fixes the issue "if image fits perfectly use, if not check if it fits non-perfectly" - this will still grab smaller image if it came up earlier in data. This needs to loop through available sizes extra time - first looking for perfect match, second looking for non-perfect math.
    – Rarst
    Commented May 31, 2011 at 14:40
  • @Rarst I agree that it doesn't cover all use cases (I noted that in the ticket description). I had thought about looping through non-perfectly matching image sizes, but thought that might be worth some discussion on the ticket before writing up the code. The (simple) patch I submitted does cover the exact match use case, though. Commented May 31, 2011 at 16:17
  • @Rarst thanks for the explanation, makes sense now. I've ended up using the thum's name, instead of its size. @Chip Bennett thanks for submitting the bugreport. It would be nice to have that functionality! Thanks.
    – dashaluna
    Commented May 31, 2011 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.