srcset not added when the original image size doesn't exist in the database after regeneration

[smerriman]

Suppose you have a post where you've inserted a 'large' image size. Any other image sizes of the same proportion are added to the srcset on the front end.

Now, change the 'large' image size to something else, and regenerate thumbnails (using the plugin, CLI, etc).

The image in the post continues to work (since plugins / CLI tend not to delete non-existing sizes from the file system precisely because they may be embedded in posts).

However, it no longer receives any srcset - because the src_matched variable never gets set to true in wp_calculate_image_srcset.

Can the src_matched logic be adjusted to cover this case?

[joemcgill]

Hi @smerriman,

Thanks for describing this use case. In order to ensure that we're not including sources in the srcset that are unrelated to the src file, we have that check to ensure we have data about the src image in the attachment metadata from which to compare other sources. If that image is not listed in metadata after images have been regenerated, then it opens the possibility that the browser would be serving an different version of the image (e.g., from a different crop) rather than simply including the same image with different dimensions.

I don't think there is a good fix for this case, besides ensuring you can filter the srcset to cover this case.

[smerriman]

Given thumbnails have a consistent -[width]x[height] format, is it not possible to simply check the version without that is in the metadata?

If the attachment ID matches (already tested), AND the full size filename matches, AND the ratio matches (already tested, so won't result in other crops), I find it unlikely you'd ever run into issues.

[smerriman]

PS - note that the width and height are primarily read from the parameters on the img tag (only metadata if width and height don't exist), so other crops aren't an issue regardless.

The only issue would be is if the image ID doesn't match the actual image, and it serves a completely different image instead - which testing the URL with -[width]x[height] stripped would resolve.

[peterwilsoncc]

In 44375:

Docs: Correct inline documentation versions for Cron API changes.

[43540] introduced changes to allow hijacking the cron implementation.

These changes were slated for 5.0, but have since been moved to the 5.1 release.

See #43540.

[peterwilsoncc]

Please ignore above commit, the ticket reference ought to have been #32656