/wp-json/oembed/1.0/embed returns too big thumbnail_url

[colinleroy]

function get_oembed_response_data_rich( $data, $post, $width, $height )
uses $min_max_width (default 200-600),
and if that size of thumbnail is not generated, the full-scale url is returned in thumbnail_url field (leading to too big files being sent).

[colinleroy]

This patch is a quick fix that uses the 'medium_large' size

[colinleroy]

Correct patch. The constrained 99999 height was messing the ratio calculation, preventing image_get_intermediate_size() to consider good candidates.

[colinleroy]

My second patch fixes the problem cleanly for me. I hope it is correct :)

Use 0 as height, so that the closest bigger available image size will be used as thumbnail_url, instead of 99999 which prevented scaling down from happening at all.

Trac ticket: https://core.trac.wordpress.org/ticket/62094

[colinleroy]

For now I'm working around that with a filter in functions.php, but that is suboptimal:

function fix_image_downsize_99999($downsize, $id, $size) { 
  if (is_array($size) && isset($size[1]) && $size[1] == 99999) {
    $size[1] = 0;
    return image_downsize($id, $size);
  }
  return $downsize;
}
add_filter( "image_downsize", "fix_image_downsize_99999", 10, 3 );

[swissspidy]

Hi @colinleroy and thanks for your contribution!

Would you be willing to write some unit tests for this change to verify that this does what it is supposed to do? Alternatively, some manual testing instructions would be very helpful, so that this could be verified by hand, or used to write tests.

PS. No need to add both a patch file and a PR. A PR alone is enough :-)

[swissspidy]

For context, this is where this code was added originally: ​https://github.com/swissspidy/oEmbed-API/commit/049a7c34ce81b97ac3f3e95ec89f323dd5eda0b8

[colinleroy]

Thank you for your feedback!

I've updated the PR with a unit test. I hope it's what you expected.

For a manual reproduction, create a post or page; add a large image in the post, and set it as Featured Image. Publish the post, and check its <link rel="alternate" title="oEmbed (JSON)" type="application/json+oembed" href="...">

With this patch, it'll look like:

{
  "version": "1.0",
  "provider_name": "colin@colino.net",
  "provider_url": "https://www.colino.net/wordpress",
  "author_name": "Colin",
  "author_url": "https://www.colino.net/wordpress/archives/author/colin/",
  "title": "F*** capitalism in general and f*** Youtube in particular",
  "type": "link",
  "width": 600,
  "height": 338,
  "thumbnail_url": "https://www.colino.net/wordpress/wp-content/uploads/image-97-768x576.png",
  "thumbnail_width": 600,
  "thumbnail_height": 450
}

Without the patch,

{
  "version": "1.0",
  "provider_name": "colin@colino.net",
  "provider_url": "https://www.colino.net/wordpress",
  "author_name": "Colin",
  "author_url": "https://www.colino.net/wordpress/archives/author/colin/",
  "title": "F*** capitalism in general and f*** Youtube in particular",
  "type": "link",
  "width": 600,
  "height": 338,
  "thumbnail_url": "https://www.colino.net/wordpress/wp-content/uploads/image-97.png",
  "thumbnail_width": 600,
  "thumbnail_height": 450
}

In the second case, the served thumbnail_url is the full-size image.

The implications of this bug is that
a) Extra bandwidth is consumed
b) Some oembed consumers reject too big images altogether in "preview cards"; Mastodon servers are one of those.