-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gutenberg: og:image tag does not pick the image from blocks #10501
Comments
ticket: 1528871-zen I am using |
Like you point out, this is indeed because of Gutenberg outputting image HTML without width/height attributes: <!-- wp:image {"id":77} -->
<figure class="wp-block-image">
<img
src="http://localhost/wp-content/uploads/2018/10/example.png"
alt=""
class="wp-image-77"
/>
</figure>
<!-- /wp:image --> Image tags without width/height are ignored here: jetpack/class.jetpack-post-images.php Lines 398 to 409 in 7ce8c1a
The solution could be to pick media ID from |
This is a duplicate of this issue: See my comment there for a detailed answer and a link to a Gutenberg PR that should solve the issue: Since there was no movement on that PR, maybe we should consider disabling our size checks for posts created with Gutenberg. |
This sounds good. Suppose FB won't penalize if we send smaller than 200px, it just won't pick it up. |
It may because of Publicize. Since we have accounted for it, I haven't tried recently, but generally, if there are issues with the OG tags, Publicize will fail. |
Gutenberg is looking to resolve lack of width/height on the front-end with work being done in the https://github.com/WordPress/gutenberg/tree/update/image-block branch. |
This seems potentially more robust, since you can check the width of the image in the database rather than just the width that is set in the post itself. If the image in the post is < 200px, but the original is larger, the original could be used for |
Noting we've had another user report of this here. |
Noting that not all images will include such a media ID; |
Fixes #10501 - This new method parses all HTML content using WP's parse_blocks. - We only select Core image blocks. - We also remove any image blocks that do not include a post ID. This is because image blocks that do not have a post ID are currently inserted using the "from image URL" option in the image block picker. As such, all the info in that block is the image URL; we have no data about image size for those images.
1638869-zen |
1638869-zen would like a response when we have a fix |
1682946-zen |
…11000) * Post Images: add new method to detect images from Gutenberg blocks Fixes #10501 - This new method parses all HTML content using WP's parse_blocks. - We only select Core image blocks. - We also remove any image blocks that do not include a post ID. This is because image blocks that do not have a post ID are currently inserted using the "from image URL" option in the image block picker. As such, all the info in that block is the image URL; we have no data about image size for those images. * Use new method to get data when extracting from attachments * Unit Tests: avoid failures for WP versions that do not support GB. * Add support for core Gallery blocks * Add support for Tiled Gallery block * Return empty string when no content instead of using undefined var * Fix the behaviour of get_post_html - It should be able to return the post URL when possible. - When it does not return any post content (like an empty string), it should be handled properly. - We should fetch the post URL and not the post title. * Fixed block image retrieval to not return empty arrays. This resulted in warnings because an opengraph tag function has tried to access the 'src' attribute of an empty array. Now the block parser doesn't return an empty array in case the image data is not found or not good enough. * Fixed one more case where false results needed to be filtered out.
Steps to reproduce the issue
Jetpack_PostImages:: from_html does not
og:image
is usinghttps://s0.wp.com/i/blank.jpg
If I add images through Classic Editor, there is no issue.
What I expected
og:image
should use the correct image.Debug more
I notice the differences are
width
andheight
attributes of tags when viewing the code editor:By default, the image block looks like this - the
og:image
tag is picked wrongly with the steps above:If I "hack" a bit and add
width
andheight
attributes - theog:image
tag is picked correctly.My testing enviroment
Possible Code
From
jetpack/functions.opengraph.php
Line 169 in 5a51ff2
Then
jetpack/functions.opengraph.php
Line 289 in 5a51ff2
Then
jetpack/class.jetpack-post-images.php
Lines 381 to 384 in 51afab4
The text was updated successfully, but these errors were encountered: