Use proper URL for resized images in the ImageObject schema

[leonidasmi]

Context

• When the ImageObject node of the schema is being retrieved by the first content image and that image is resized in the content, we need to use the resized URL for the node's attributes, not its full-sized counterpart.

Summary

This PR can be summarized in the following changelog entry:

• Improves the schema generation of ImageObject when it uses the first content image and that's a resized one, by using the URL of the resized image instead of its full-width counterpart.

Relevant technical choices:

• We use a regex to identify resized images, as I couldn't find a case where a resized image won't end with -<width>x<height>.file_extension
  • But even if there is a case that it might, we will fallback gracefully to the old solution and output the full-sized image.
  • Also, WP Core make sure that images that get uploaded with the -<width>x<height>.file_extension format get renamed, so we won't have false positives.
  • Also, for cases where an image with the -<width>x<height>.file_extension format has been manually uploaded to the server and gets added via custom HTML, the output of the schema stays the same with trunk, because we can't retrieve its ID and the fallback simple_image_object() method is used for schema output.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Create a post and upload an image in it. (Add no feature image in the post)
• Select a resized version of it via the image block (thumbnail, medium, large) and NOT use the full size image. For example, select the thumbnail.
• Visit the frontend of the post, check the page source and find the primary image ImageObject.

Before this PR:

{
   "@type":"ImageObject",
   "@id":"https://example.com/test/#primaryimage",
   "url":"https://example.com/wp-content/uploads/2023/02/example.png",
   "contentUrl":"https://example.com/wp-content/uploads/2023/02/example.png",
   "width":1500,
   "height": 1500
},

With this PR:

{
   "@type":"ImageObject",
   "@id":"https://example.com/test/#primaryimage",
   "url":"https://example.com/wp-content/uploads/2023/02/example-300x300.png",
   "contentUrl":"https://example.com/wp-content/uploads/2023/02/example-300x300.png",
   "width":300,
   "height":300
},

because the post will have a <img src="https://example.com/wp-content/uploads/2023/02/example-300x300.png"> image in its content

• Validate the schema output with the 3 validators (https://validator.schema.org/, https://classyschema.org/Visualisation and https://search.google.com/test/rich-results)
• Go to Yoast SEO settings->Enable Media pages and enable that setting
• Reset indexables and repeat the above test
• Also make sure to test with a .jpg file that's over 4000 pixels in width (because WP scales those images upon upload)

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• Smoke test the schema generation of How To blocks

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #19848

[coveralls]

Pull Request Test Coverage Report for Build 56f1fadb2994cbd9f62ed3dcddf54cdd60d52596

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 15 of 15 (100.0%) changed or added relevant lines in 2 files are covered.
• 13 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+5.2%) to 54.728%

---

Files with Coverage Reduction	New Missed Lines	%
src/editors/framework/site/base-site-information.php	6	0.0%
inc/class-wpseo-utils.php	7	43.27%

Totals
Change from base Build bc3a4e966336e035c87bf7445627c054d34ed794:	5.2%
Covered Lines:	29775
Relevant Lines:	54648

---

💛 - Coveralls

[vraja-pro]

For the test, since you implemented Regex in two methods, I would expect to have some data provider with cases for the unhappy path.