Add an imageBlockProcessor so core/image blocks can support cdn and s3fs modules

I think the answer is to make an imageBlockProcessor that regenerates the image url. Since it has already been viewed the first time in the editor, it presumably was pushed to s3 already, and getting the url the second time from the file entity thats stored in the block should get the s3 url.
Then replace the image url in the src with this new url.

Does this make sense? would this be the correct place to do this?

If I go back into the node and switch the style and then switch back to what it was previously, it has the s3 url. Its just not getting it when it renders on the front end, or when it renders in the editor the 2nd time (unless you do what I described)

I think that was the way to go. I have this working on the frontend. But it still loads the local path in the editor.
I also changed the image styles 'full' key to '_original_'

@loze Should we maybe split up your two changes into a different issue? I think the change of the original image to `_original_` makes sense, but is quite independent from the image style URL rewrite for the CDN/s3f module.

szeidler → changed the visibility of the branch 3450325-alternative-image-style-url-processor to hidden.

szeidler → changed the visibility of the branch 3450325-alternative-image-style-url-processor to active.

@loze I just added my alternative approach, that also catches images without the core/image imageSlug by constructing image style from the old derivate URL, so that it is able to rewrite also gallery + media+text blocks.

Can you evaluate if it is further than your MR, we can decide on which one to continue then.

@szeidler
1. you're right about splitting the 2nd part of my issue into a separate issue.
2. I think your approach of loading the image by uuid is correct, as well as supporting image/gallery blocks.
3. this module has a Drupal\gutenberg\Html\TagProcessor class that can handle what your doing with \DOMXpath and we should probably use that since the other block processors use it.

Im going to try to combine the best of the two.

On second look, this does work with gallery blocks, since they are just a group of image blocks, the size is set on each individual image

Although there should probably be an option to set the size of all images in a gallery at once. there is an issue for that here 🐛 Images are not linked with core/gallery block Active

I'm not a maintainer of this module, so lets see what someone else says.

In the meantime, I've resolved the conflicts in MR!150. Here is a patch to use it in composer.