Derivatives images not generated

I ran into this same issue. We made updates to the images styles to convert to webp, once the image cache was flushed, all images added through gutenberg show up as broken images. Since we have thousands of pages, we were unable to make this update to improve site performance due to the limitations of gutenberg to handle this update.

Any help would be greatly appreciated!

The problem arises with all blocks, that store the full image derivative path including `?itok` parameter in the body text.

So whenever images style derivatives are not existing (flushed, or not existing because of different environments) they need to be regenerated. This is been done by the `itok` parameter verification for DDOS protection. If your environments have different hashes, the itok will be different and the image generation would fail.

The same problem arises when you use the `Convert` image style action. If you convert to another file type, the corresponding image URL needs to change (but also the itok, will be different). That's the reason that after enabling the `webp` conversion and flushed image styles, the the image path is wrong in the body text and will result in a 404 (not generated image).

There are only two workarounds for this problem:
1. Re-select the image - the image url will be updated
2. Add a Gutenberg BlockProcessor or Text Filter that takes the file uuid, regenerates the image style URL and replaces it in the text

This problem might become more prominent, when people start adding `webp` conversion actions after it went into Drupal Core in 10.3

I have a MR for version 3.0 that I think addresses this issue. It adds an image block processor that generates the derivative on the front end. In my case I needed this because the path stored in gutenberg did not reflect the correct path when using the s3fs or cdn modules. ✨ Add an imageBlockProcessor so core/image blocks can support cdn and s3f modules Needs review

Worth noting that this also causes stage_file_proxy not to load the image at all as long as it was used within the core/image block. Media works fine.

Thanks for your input @loze. Those issues are actually closely related, because both require a on-the-fly rewrite of the stored image paths.

I actually have a similar patch to yours, that supports `core/image`, `core/gallery` and `core/media-text`. Should I add it as a separate merge request to your issue @loze, so that you can have a look and see where to continue.

Can we get this fixed on 2.x and 3.x? seems rather high priority IMO