Using picture element for images in RTE?
# help-with-umbraco
m
When an image is added into the RTE block is there a way to set it so it uses the picture element and makes use of the source commands so we can do auto-croping for different view sizes? Right now it just does a normal img element and sets the static height/width so if it is a large image it looks fine on a desktop but then if you go to the page on a mobile device it is the same huge size.
m
With the legacy grid the rte.cshtml had
value = HtmlImageSourceParser.EnsureImageSources(value);
that you could manipulate the afterwards.. not sure where that is with the new blocklist/grid? https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Web.UI/Views/Partials/grid/editors/rte.cshtml#L10
But I guess with blocks.. you can always manipulate the rte value once you have it? In your blocklist/component/{block renderer}.cshtml ?
m
I was hoping a more friendly way then modifying core code.
m
with value convertors, you can always replace with your own, via DI than modify core code?
m
None of this is happening in a blocklist, the RTE is a normal property. Also parsing an entire string to remove/replace the tag to convert to would be very taxing and hard to program (I would imagin, I have no idea how I would even start to do that)
m
sorry
RTE block
led me to block...
regexp would be your friend... 🙂
and maybe a taghelper on to do the work..
m
Again you getting into moding core code, I am looking for a simpler soltion. Same with REGEX that is not a simple solution.
m
have a look at umbTagHelpers img taghelper..
why is regexp not a simple solution 😉 ?
perhaps that is a simple solution.. add
our-img
to your images in the rte source, and using
our umbraco tag helpers
.
m
Not everyone here has been programing for 50 years and has mastered regulare expressions.
I am not seeing any documentiaon on tag helpers or umb-img. I am on Umbraco 13 have they been renamed or possibly droped?
m
it's a package
might also need to extend rte (tinymce) to allow
our-img
attribute on image tags (as might strip due to valid elements)
m
The ?
m
the our-img. but actually this might not work with the rendered output of the rte, as expects a media-item to be passed in...
sorry, might have given you false hope there..
m
It looks like it would also require the editors to edit the source input of the RTE which I really don't want them doing and I would rather not have to go behind each editor to edit the RTE source for them ether.
m
then think you are back to learning a little about regexp, or htmlAgilityPack to manipulate the string that is returned from the rte. Or overriding the rtevalueConvertor? 😦
Or maybe someone else has a better solution for you?
m
None of wich I have the skill to do.
m
Do you need images in the rte? or can you construct with blocklist/grid?
m
AFAIK they need to be in the RTE. The RTE is used mainly pages like news articles or guides where the placement of images is dynamic depending on the content.
m
yep a blockgrid can be dynamic.. only thing you loose is floating images in a content block.. downside I guess of allowing complete html control for your editors..
s
It is not that easy or reliable to "fix" the problem after the editor has done their work. I've had a look at inserting
<picture>
into TinyMCE and it looks like nobody else has really solved this problem either (was hoping there would be a plugin for Tiny that could be adapted). The easiest way to work around this would be to not rely on a single RTE to do this but to set up a block editor, where editors could alternate between RTE blocks (without the "insert image" button enabled) and picture blocks. Now I will say I don't have a lot of experience with the
picture
element so I am not sure how to design a good block editor for it, but it should be something that is possible.
m
I wonder if you can get the raw rte content prior to the valueconvertor and implement you own image tag manipulation..
m
I think block grid would not be a good way to do it. Sure it can be dynamic but then yuour talking add a block for a few setntances, add new block for the image, another blokc for the rest of the paragrah...What bout images with the text wraped around it and such? I don't think block grid is a good solution
m
age old conundrum... one likes one way, another another.. wrapping text around images and then viewing on mobile vs ultrawide monitor is not to some peoples liking either 🙂
also allowing editors to generate any old content in the rte might polute the brand style guidelines...
but this is a different topic 🙂
s
I mean, ideally, you have multiple images represented in the picture element, I would find it near impossible to make a nice editing experience for this inside the RTE. Of course you can generate these images, but proper cropping is often important.
m
Well CSS can easly deal with the text wrapping when downscaling to mobile but it is more the managment of information in the back office. Take this page for example: https://www.ffinfo.com/news-home/march-2024/final-fantasy-vii-rebirth-director-is-open-to-future-updates-for-queen-s-blood-minigame/ To do that with a block grid your talking 3 blocks and breaking the text information into two differnet blocks. Now some of the artivels are 5ish times that size with about a dozen images. That gets into a lot of blocks and a lot of segmented text
m
just like type setting a printed page.. 🙂
s
Wrapping could be done with 2 blocks next to each other, etc. The problem here is what kind of design control you want to give your editors as well, the more flexibility you give them, the more "creativity" they will exhibit as well.
m
think that's the ultimate.. but for responsive more about just serving the image at suitable dimensions, and prob with a preset crop for breakpoints..
m
In my mind it was more a single image source but being able to define mutople media queries and then using the built in croper to serve them:
m
ditto...
s
Anyway, I think it is an interesting topic and I'd love to see examples of editing experiences that work well. Maybe we can take some inspiration.
m
don't think you need to enhance the editor experience in the rte.. just chose an image.. and we'll sort at breakpoints. 🙂
s
One other thing I can think of is to make add a macro in the RTE, the macro can have an upload field (and even a full cropper). In the macro code you can set up the exact rendering of the image easily.
m
don't you mean block in the rte? 🙂
s
I think we even have Blocks in the RTE now, which would make it better since macros are going away.
m
If the existing img selection interface was updated so that the window where you put alt text and caption maybe had an area "Media Sizes" that you put in the media query paraiters and then listed the dimentions that could be stored and then insterad of rendering an img it rendesr the picture with the supplied paramnters for each source node?
m
@Matthew Alexandros having used both rte and legacy grid, block grid and block list.. (going back to umb4) Only thing I can point to is that rte html for editors had much more support required, and breaking rendering than the more structured others... (as you say you dont'expect your editors to use source and html so they aren't html devs to understand what breaks.. )and then they post pre formatted word html in a 🔥 )
but aren't you back to the editor has to understand breakpoints etc at that point...
m
We kind of are there but at least with this I could say "Always use these parameters" or maybe even be able to define a default set when createing the data type.
s
Yeah.. but that's not there right now. It sounds like an interesting feature request, but I believe the answer might be: we can't keep adding more to the image picker, this is why we have blocks inside the RTE now so YOU can add all the features you want on your "custom" image picker (aka your block).
👍 also agreed, your editors will need to understand what this is for and how they can use it
m
Does the block show up in the editor bar like the image picker? (I have not messed with blocks in the RTE at all)
m
and enter it for every image every time...
m
Hence the default values.
m
which most editors will use? (just thinking editor experience here.. would say that's a very advanced override....)
m
If this all can be achived with blocks it is something I will look at, though not keen on the idea of having to manually edit almost 100 existing documents.
m
you could write a process to update the content programatically.. 🙂
but with only 100... prob quicker to manually update
m
Huh? If I, the dev, sets the default values why would the editors have to over ride them?
s
I think he's indicated multiple times now that this is not an option 😅 😛
m
also depends on your umb version for blocks in the rte... can't quickly remember.. is it v13+ @Sebastiaan
s
Blocks in RTE is a v13 feature yes.
m
Well that level might be an option, would take some learning and lots of time though. probibily faster to manually edit the 100 documents. Its more regex, DI, and core file editing that is beyong my basicly entry level knoledge
s
You'd probably have to regex the current data to change it 😉
m
I've not used blocks in the rte.. but hope they are a little more robust than macros.. seem to remember tinymce could mess with the injected html for a macro very easily....
m
Well then, maybe when GPT5 comes out and it could generate me a decent regex
s
While Mike is pointing out Core files, he never means editing the CMS core, that was to give you hints to find extension points to use. 🙂
m
https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Core/Templates/HtmlImageSourceParser.cs could be the starting point.. already has your regexp for grabbing the image dupe that to your own.. and then replace the umb core implementation via
Services.AddSingleton<ResponsiveHtmlImageSourceParser>();
in startup...
m
Which just goes to show you my level of understanding on these things....🥺
s
My advise: - Try out blocks in the RTE - takes a while to get used to making block editors, but it pays off in the end - And take the hit, a quiet Friday afternoon spent replacing a 100 images is okay for a one-time thing
m
I have the next two days off and am going to look into the block thing. it does sound like the best current solution.
m
That's the beauty of umbraco.. so extensible and for all walks of user too... 🙂
Hope you make some headway.. and with that time to go get myself a haircut 💇‍♂️
m
I have used block lists a few times already so I should not have any problems making the templates. @Sebastiaan Do you know if I would have to do anything special for the render of the RTE propery or would @Html.Raw(@Content.RTEProperty) still work fine?
Looking at that package I like what it does so even if it does not help here I will probibily end up using it for other places too. Thanks for showing it to me.
m
there's slimsy too.. for responsive images.. though not used it seen mentioned
s
Duh.. forgot about Slimsy. It's great! And it will work, but not for the RTE - this answer points to macros - https://our.umbraco.com/forum/umbraco-9/107798-rich-text-editor-and-images and that should now be blocks instead of macros. But Slimsy can certainly help with rendering that block easily.
m
I don't think I will have an issue making the block template, I ahve made a few and redndere them as part of block lists on pages already but non in an RTE. I was just more asking if there is extra stepts to render an RTE that has blocks in it vs what I do now withthe html.raw(content.reteproperty) call
s
You just do what you normally do when rendering the RTE - it will know how to render the blocks and their view.
m
Cool, that will make the transition easier. Apreacte everyone's inputs.
11 Views