Skip to content
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

wpseo_opengraph_image_size custom size is ignored once post is saved in wp_yoast_indexable table (since 16.2) #19039

Closed
andrewstaffell opened this issue Oct 8, 2022 · 7 comments

Comments

@andrewstaffell
Copy link

andrewstaffell commented Oct 8, 2022

Original issue #17029 was closed, but the issue persists, I now have new information as follows.

We never managed to resolve this and have been stuck on 16.1 ever since, despite repeated attempts to upgrade. Every time we try to go beyond 16.1 the problem resurfaces. Tried again this week on 19.7.2 and it started up again.

To recap the issue, in 16.2 Yoast starts ignoring our custom OG image size (set via the wpseo_opengraph_image_size filter). I noticed it was a bit sporadic: you need to have either published or updated the post after upgrading to 16.2 or later, otherwise it doesn't occur, which might explain why @Djennez couldn't previously reproduce it.

I've spent the last couple of days going deep into the code to try to figure this out once and for all and have made some discoveries that I think may help lead to a fix. It seems to me the bug is related to both of the following:

  1. The wp_yoast_indexable database table. As soon as there's an entry in that for the post, it starts ignoring the custom size and serving the full featured image size instead.
  2. The following code block, which was new in 16.2 (src/generators/open-graph-image-generator.php lines 121-125):

Screenshot 2022-10-08 at 10 57 15

Commenting out this code block restores the correct behaviour. Likewise, if I delete the row for the post in wp_yoast_indexable, the correct behaviour is restored.

So my interpretation (and I've done my best to verify this by a thorough analysis of the complex code / OO structures) is that this new if() clause in 16.2 is essentially looking for the entry in the wp_yoast_indexable table and if that's found, the correct image size does not end up getting requested.

Further to that, running the "Reset Indexables tables & migrations" task from the Yoast Test plugin also restores correct behaviour because it empties out the wp_yoast_indexable table.

Digging deeper still I found this documentation and I've added this filter to my theme:

add_filter('Yoast\WP\SEO\should_index_indexables', '__return_false');

... believing that this would stop the indexables from saving altogether, but it doesn't seem to have any effect. The wp_yoast_indexable table starts getting populated again as soon as I save a post and this immediately triggers the bug (open graph image URL/size reverts to full rather than custom).

Is that a second bug in the filter or am I doing something wrong?

Originally posted by @andrewstaffell in #17029 (comment)

@andrewstaffell andrewstaffell changed the title wpseo_opengraph_image_size custom size is ignored once post is saved in indexables table wpseo_opengraph_image_size custom size is ignored once post is saved in wp_yoast_indexable table Oct 8, 2022
@andrewstaffell andrewstaffell changed the title wpseo_opengraph_image_size custom size is ignored once post is saved in wp_yoast_indexable table wpseo_opengraph_image_size custom size is ignored once post is saved in wp_yoast_indexable table (since 16.2) Oct 8, 2022
@mmikhan
Copy link
Member

mmikhan commented Oct 14, 2022

Thanks for bringing this to our attention once again @andrewstaffell. It looks like you discovered a bug where we are not considering the filter wpseo_opengraph_image_size filter. So, I will mark it as a bug so our dev team can look into this. In the meantime, do feel free to submit a PR as well if you want it to be fixed immediately 🙏

@andrewstaffell
Copy link
Author

@iamazik Thanks for the acknowledgement and escalation.

I would gladly push a PR if I could figure out a fix, but I am struggling to unpick undocumented aspects of the code. Is there a member of the dev team with a better understanding of the architecture with whom I could step through this directly?

It seems to me that the only place the open_graph_image_meta property is set is at line 107 of src/builders/indexable-social-image-trait.php but I couldn't manage to interact with / debug this (logging around this line didn't seem to have any effect during my testing, so maybe there is another place where the metadata is set – which would be logical given that the wp_yoast_indexable table functions as a kind of cache – but I can't find it by searching the codebase).

@mountbatt
Copy link

For me it works if i re-save my post. Maybe you can try to re-save all your posts via a batch?

@andrewstaffell
Copy link
Author

@mountbatt thanks for the comment. In our case the opposite seems to be true: saving the post creates the entry in the wp_yoast_indexable table and that causes the wrong image size to be served in the open graph meta tag. If we then empty the database table (manually or using the tool in Yoast Test) it will temporarily work, but only until we save again.

In other words batch re-save would guarantee they were all broken!

@andrewstaffell
Copy link
Author

@Djennez @mmikhan this issue still persists – is there any way I could work through it with a member of Yoast development team?

@mmikhan
Copy link
Member

mmikhan commented Dec 13, 2022

👋 @andrewstaffell I am very sorry that it's taking a bit longer than usual for us. However, I have forwarded it right to the team so it never get lost.

Looks like it's a known issue for quite a while and have existing report already.

@andrewstaffell
Copy link
Author

@mmikhan Thanks for this update! I looked at the issues you cited, I am not sure it's exactly the same issue (the one we're experiencing involves the wp_yoast_indexable table and I'm not sure those do) but perhaps they are related.

I would be happy to be contacted by any of your colleagues to help work through the problem and solution, let me know if that would be helpful. I have tried but there are parts of the code whose interrelationship I can't quite figure out (as explained in the messages above).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants