How to handle responsive images in a blog with many images via TinyMCE?

[Krlos]

Hi everyone, I’m building a blog in ProcessWire for a client who wants to insert images every 1–2 paragraphs using TinyMCE. They’ve already been optimizing images somewhat, but each page still ends up weighing multiple megabytes due to the sheer volume of images. One of their key requirements is that all inserted images be responsive—especially on mobile devices—and they’d like a straightforward way to manage those images without a lot of extra steps.

Any tips or example would be greatly appreciated! Thanks in advance.

[Robin S]

A general approach:

1. The client doesn't do any optimising but just inserts images into TinyMCE. If there are different styles/positioning of images they apply these via classes on the image.
2. You use a textformatter module that finds the images within the field, and if the image corresponds to a Pageimage (as opposed to some external image that you don't have control over) you do whatever resizing and optimising is needed and replace the original <img> markup with the markup you want (srcset or whatever). You can check the class on the original image and output different markup accordingly.

A proof of concept module that could be a starting point: https://processwire.com/modules/textformatter-process-images/

[Krlos]

Hey @Robin S, thank you for the feedback!

Usually, I rely on the PageimageSource module for responsive images and it works great. However, this is the first time I’ve had a client insist on inserting multiple images directly into a single TinyMCE field. I’m actually a bit surprised there isn’t a more official or comprehensive solution for this in ProcessWire—perhaps it’s a more niche requirement than I realized? I don’t have extensive experience with blogs, so I was hoping there’d be a straightforward, out-of-the-box approach. Thanks for pointing me to that proof-of-concept Textformatter Process Images module. I’ll definitely give it a try!

[bernhard]

12 hours ago, Krlos said:

I don’t have extensive experience with blogs, so I was hoping there’d be a straightforward, out-of-the-box approach.

RepeaterMatrix and RockPageBuilder. There you don't add content to one WYSIWYG field but instead compose your blog content from predefined blocks where you have full control over the generated markup for each block and the client still has the flexibility to choose whatever blocks he/she needs.

Similar to what @Robin S suggests if you are using RockFrontend that's already on board via Dom Tools.

$dom = rockfrontend()->dom($page->your_wysiwyg_field);
$dom
  ->filter("img")
  ->each(function (HtmlPageCrawler $node) {
    $newHTML = '...'
    $node->replaceWith($newHTML);
  });
echo $dom->html();

I'd highly recommend not to use images in richtext fields, though.

[Krlos]

Hi @bernhard, thank you for the suggestion! I’m already using Repeater Matrix to arrange some content blocks on the homepage, and it works really well. However, my client is very used to the WordPress style of creating blog posts—typing and inserting images freely into a single editor field. While they’re loving ProcessWire’s strengths, they still prefer that workflow.

Also, the site is built with Tailwind CSS, and using the Tailwind Typography plugin, I just added the prose class to the content body to get beautiful typographic defaults with minimal markup. I’ll likely stick with the single WYSIWYG approach for now, but if I can’t manage to handle images responsively in the editor, I’ll try presenting Repeater Matrix again to see if I can change their mind. Thanks again for your input!

4 hours ago, bernhard said:

I'd highly recommend not to use images in richtext fields, though.

I’m also in agreement with you. However, when I was discussing this with my client, they asked, “So why have a rich text editor that can insert images if that’s not the ideal approach?” Since I haven’t used WordPress for a long time, I couldn’t give a direct comparison to how WordPress handles it nowadays—but that was their main concern.

[bernhard]

20 minutes ago, Krlos said:

So why have a rich text editor that can insert images if that’s not the ideal approach?

That's a valid question by the client. That's why I do not allow images in richtext fields. But there's never an "ideal approach". Everything has pro's and con's.

[Julie]

Since the client wants to keep using TinyMCE, I'd focus on the generated markup rather than changing the editing workflow.

One thing worth checking is the sizes attribute. With a width-based srcset, leaving it out makes the browser assume the image takes up the full viewport width. Since you're using Tailwind's prose class, that could mean downloading larger images than the content column actually needs.

I'd also use loading="lazy" for images further down the article, while keeping the above-the-fold images loading normally. Adding width and height would help avoid layout shifts too.

You could handle all of that in the Textformatter hook Robin mentioned, using ProcessWire's existing image variations.

[Julie]

Thanks for sharing this! I noticed a small issue with the tablet media queries. They use (min-width: 415) without px, so those sources won't match as intended. It should be (min-width: 415px).

I'd also be a bit careful with applying loading="lazy" to every image. It's useful for images further down the page, but I'd leave it off images visible immediately, especially the main image that might affect LCP. One other thing I'd check is the 2x descriptor on the 767px tablet images. If an image takes up most of the screen width, that resolution might not be enough for a high-density display. Otherwise, I like the idea of keeping everything within ProcessWire's image API. It makes the setup fairly easy to maintain.

[Julie]

Hey Krlos, I'd probably keep the TinyMCE workflow since that's what your client is comfortable with. Also I'd check is whether TinyMCE inserts the original image or an already resized version. If it's the latter, I'd try resolving it back to the original Pageimage before generating new sizes. That should help avoid losing image quality along the way. I'd start with ProcessWire's built-in variations and the Textformatter Robin mentioned. I've also used imgproxy for on-demand resizing and WebP/AVIF conversion: https://github.com/imgproxy/imgproxy It could handle the image processing separately, but you'd still need to generate the URLs and srcset in ProcessWire. For this setup, I'd try the built-in approach first and only add another service if there's a real need for it.