WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 10 months ago

#43540 new defect (bug)

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

Reported by: smerriman Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:
PR Number:

Description

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?

Change History (5)

#1 @joemcgill
19 months ago

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.

#2 @smerriman
19 months ago

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.

#3 @smerriman
19 months ago

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.

#4 @peterwilsoncc
10 months ago

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.

#5 @peterwilsoncc
10 months ago

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

Note: See TracTickets for help on using tickets.