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!
- 🇩🇪Germany szeidler Berlin
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 textThis problem might become more prominent, when people start adding `webp` conversion actions after it went into Drupal Core in 10.3