Hi gurus,
for my client we use image variants to differentiate image sizes for different devices. Now we want to let the CKEditor image picker render source for all available image variants like this:
<@hst.link var="imgDesktop" hippobean=image.pageDesktop/>
<@hst.link var="imgTablet" hippobean=image.pageTablet/>
<@hst.link var="imgMobile" hippobean=image.pageMobile/>
<figure>
<picture>
<source media="(min-width: 941px)" srcset="${imgDesktop}"/>
<source media="(min-width: 641px)" srcset="${imgTablet}"/>
<source media="(min-width: 0px)" srcset="${imgMobile}"/>
<img src="${imgDesktop}" alt="Banner"/>
</picture>
</figure>
We need to be able to read the variants for the selected image. Then, based on naming convention, we can decide which variant belongs to which device size and generate the above code.
What is the best approach? Should we create a custom plugin that can do this? ==> please give pointers how because we already investigated this. Another option we investigated was the HST ContentRewriter (https://www.onehippo.org/library/concepts/rewriting-rich-text-field-runtime/hst-2-rewriting-rich-text-field-runtime.html), but this sounds more like a (workable) hack.
We use Hippo 11.2
Are we talking a reactive design? This should be doable through javascript in any case. The link for one variant is very easy to change into another link. Inspect the urls and it should be obvious.
yes for reactive design.
Interesting thought, we will investigate.
This is not a workable/desirable solution for us. Right now I’m looking into the contentrewriter, but that costs processing time during rendering of the page.
So if anyone has a better solution, please speak up 
I don’t see a solution using CKEditor plugins. Even if you would fork the hippopicker plugin (although forks are a bad idea in general), I don’t think it’s a good idea to generate hst-specific markup (like @hst.link tags) in a rich text field. For example, it hardcodes that the field will be rendered in a Freemarker template and not in a REST response or JSP. And the server-side HTML cleaning will also strip out the Freemarker tags.
A ContentRewriter sounds like a good match.
Mathijs
I doubt that the overhead of the contentrewriter is something you need to worry about. One thing though, if this is done server side then how will the site react to browser resizing? If this triggers a page reload that would be inefficient (though mostly for network latency).
the combination of the source-tag and some javascript as a fallback for certain browsers we aren’t allowed to mention by name ( 
) handles the resize event.
Thank you Mathijs for joining this thread.
The code in my question was the original source in our freemarker templates. The code below is the actual code that needs to be written to the field:
<figure>
<picture>
<source media="(min-width: 941px)" srcset="/binaries/desktop/content/gallery/..../image.jpg"/>
<source media="(min-width: 641px)" srcset="/binaries/tablet/content/gallery/..../image.jpg"/>
<source media="(min-width: 0px)" srcset="/binaries/mobile/content/gallery/..../image.jpg"/>
<img src="/binaries/gallery/desktop/content/..../image.jpg" alt="Banner"/>
</picture>
</figure>
So your justly argument that the original code fragment will indeed not work for REST/JSP is correct. But the latter solution won’t have that issue.
I got it all working now with the ContentRewriter solution.
Good to hear, thanks for letting us know.
I see. That markup could indeed be generated by a custom CKEditor plugin. But it would still require forking the hippopicker plugin, which I would not recommend. Or you’d have to create your own plugin that opens a Wicket image picker, which won’t work anymore in the Visual Editor in the Channel Manager in version 12.
So using a ContentRewriter is by far the most future-proof solution. And the least amount of work since you already got it working :).
Mathijs
again thanks for yourinput.
And thanks for the heads-up regarding the changed editor in HIppo 12.