Lots of broken images after regenerate thumbnails

[chimok]

Bug Description

Steps to reproduce

1. Performance Plugin 3.3.0
2. Modern Images 2.0.2
3. Website with about 2500 images
4. Regenerate thumbnails with: wp media regenerate

Screenshots

About 7-10% of the images are missing. The broken images try load a image with DSC05480-600x432.webp but the generated image is DSC05480-jpg-600x432.webp.

Additional Context

• PHP Version:
• OS: 8.2
• Browser: chrome, safari
• Plugin Version: 3.3.0
• Device: all

[westonruter]

@jamesozzie This may be related to what you're investigating.

[chimok]

@jamesozzie I have this problem with a website that should go production in just 3 days. Could you already narrow down the issue? For me its a mystery and i am not able to reproduce it. If I add back the missing image and regenerate the images again, it's still there after the regeneration finished.

[jamesozzie]

@chimok Thanks for the update. I'll perform some additional checks on this today and report back to you here. I did leave an update in a users support topic in the plugin support forums, however, this user may have been impacted by a third party plugin.

Note also that there is an open GitHub issue regarding the possibility of modifying the generated -jpeg path of a plugin generated webp image.

While I'm performing some additional checks, on a test environment you may wish to check does the same occur with any plugin that can regenerate thumbnails.

[chimok]

I discover now images with names like: Partnerdialog-DACH-1-jpg-avif.webp that looks like the JPG got converted to AVIF, then the AVIF been converted to WEBP. But a lot of the missing images have nothing to do with AVIF. I had the missing images already with wepb_uploads 1.x when there was no AVIF option.

I have also Total-Protection_EN-jpg-webp.avif. .......JPG => WebP => AVIF??? I hope its tested compressed images won't be compressed again if someone switch between AVIF <> WebP?

It's also possible the content creators done something wrong they shouldn't do. They told me they download the picture from website and upload again sometimes. Of course, I've told then never do something like this. Could this generate such issues?

[jamesozzie]

Thanks for sharing your updates @chimok. From the checks I performed I don't encounter any broken images, although I have been able to experience multiple image format references in the file name.

To summarize some tests I performed:

Regenerating images on a site with existing WebP images. The option to keep a JPEG version is active.

 (Full image [here](https://imgur.com/MgJFzFk.png)) - The original image remains in original WebP format - Srcset images are JPEG

After switching to AVIF format and regenerating . The option to keep a JPEG version remains active.

 (Full image [here](https://i.imgur.com/F81whdC.png)) - The original image converts to JPEG format - Srcset images are served as AVIF (and they do include a `-jpg` path)

After switching back to WebP format and regenerating. The option to keep a JPEG version remains active.

 (Full image [here](https://i.imgur.com/1b9TSQV.png)) - The original image converts to WebP format - Srcset images revert to JPEG (and they do not include an changes to the file name)

When regenerating once more (after JPEG images are not output)

- The original image remains in WebP format, but does include a `-jpg` path in the file name.  (Full image [here](https://i.imgur.com/wT2Vmmb.png)) - All images, primary and srcset images are served as WebP. - After regenerating images, the main image along does have a `-jpg-webp` path, which may not be ideal, however, they are all valid.  (Full image [here](https://i.imgur.com/PAnkRMV.png))

When regenerating once more after selecting the AVIF format (JPEG option remain deselected)

- All images, primary and srcset images used AVIF. The primary image does have a `-jpg-webp` path included in the file name. - Srcset images do have a `-webp` path at the end of their file name, and as you also experience, a `-jpg-web` path before their image dimension size.  (Full image [here](https://i.imgur.com/atctDM8.png))

So to summarize, I'm don't encounter any broken images from my tests, however, I do see situations whereby some image name can end up having multiple path references (ie. -jpg-web), and this isn't limited to the end of the file name, with sometimes this path occurring before the dimension references for srcset images.

It's also possible the content creators done something wrong they shouldn't do. They told me they download the picture from website and upload again sometimes. Of course, I've told then never do something like this. Could this generate such issues?

This doesn't occur only if images are downloaded and uploaded, it can occur on multiple image regenerations as per my testing above.

Unfortunately based on the tests so far I've been unable to recreate any broken images. I am happy to perform some tests using the same plugin environment as your own in the event of a third party conflict. Feel free to share your Site Health information if so.

[chimok]

@jamesozzie It's a quite special setup with varnish cache and composer based Wordpress installation (Bedrock), so its not that easy to replicate. I've checked also with varnish disabled. But I have a lot of similar projects and performance plugin is now my default plugin everywhere. But only this projects had the problems.

I would like to remove all generated images, then run wp media regenerate again. But it's unclear how to to this safely. Can you give some advice's how to reset the plugin? Can I just do rm *.webp? Are all datebase entries removed when I uninstall it?

Btw, did you also test the following:

1. Enable AVIF
2. regenerate thumbnails, but stop after a few pictures before its finished
3. Enable WebP
4. regenerate thumbnails until its finished

What happen with the old AVIF? Did the AVIF got recompressed to WebP?

If the later happens, maybe at least a option to reset all images as they was before would be nice.

[jamesozzie]

Thanks for the update @chimok.

I would like to remove all generated images, then run wp media regenerate again. But it's unclear how to to this safely. Can you give some advice's how to reset the plugin? Can I just do rm *.webp? Are all datebase entries removed when I uninstall it?

You can enable the option to "Also output JPEG" enabled so there is a fallback in the event you are having issues with AVIF or WebP images. That way you can deactivate the plugin to revert to the JPEG version.

Regarding database entries, I would have to check what may be created when images are uploaded. Should you encounter any broken images after another round or regenerating thumbnails, a database replace for the formats alone may address any issues with broken images, regardless of whether they are WebP or AVIF.

Btw, did you also test the following:

Enable AVIF regenerate thumbnails, but stop after a few pictures before its finished Enable WebP regenerate thumbnails until its finished

I did indeed. You can expand on the checked I performed using the arrows. I was able to reproduce the issue with multiple jpg-web references, including where these are [included before the image dimensions in the file name, but in my case on test sites with not many images, I didn't encounter any broken or non existing images.

If the later happens, maybe at least a option to reset all images as they was before would be nice.

That's a good suggestion, however, a user may need to have the option to "Also output JPEG" enabled to the plugin can revert to the JPEG version for such a feature to work. The original JPEG version of an image is always uploaded after a WebP or AVIF is generated, I'm more referring to the responsive images WordPress generates. An improvement on such a feature would be the ability to regenerate existing images, a feature which is being worked on (see https://github.com/WordPress/performance/issues/24), and which you may find useful as an alternative to regenerating images.

If you can reproduce any broken images after regenerating consistently, maybe on a test site, I'd be happy to investigate this further.