DirectResizeLite: A Simpler Highslide-Friendly Image Resizer for Evolution CMS

Before phpThumb-based image pipelines became the default answer for everything, a lot of Evolution CMS projects just needed one practical thing: resize images on output and open them cleanly in a lightbox. This historical plugin note captures one of those early simplification efforts.

What the plugin was trying to solve

The original DirectResize flow had grown heavier than many small projects needed. The older “install and it works” feeling was gone, and the newer versions pushed image delivery through image.php plus extra rewrite rules. For sites using Highslide instead of Lightbox, that also meant more adaptation work.

DirectResizeLite was a stripped-down variant aimed at a simpler use case: scan page output, detect matching images, generate cached thumbnails, and optionally wrap them in a Highslide-ready link to a larger version.

How it worked

The plugin was attached to OnWebPagePrerender. It parsed the rendered document, found image tags inside the configured image folder, and rebuilt their src values with pre-generated resized versions. If the source image was larger than the displayed version, it could also wrap the image in a Highslide link.

$e = &$modx->Event;
switch ($e->name) {
    case "OnWebPagePrerender":
        $o = $modx->documentOutput;
        preg_match_all("/<img[^>]*>/", $o, $imgs, PREG_PATTERN_ORDER);
        // detect images, resize them, rebuild src, and optionally wrap in Highslide
        $modx->documentOutput = $o;
        break;
}

Why this mattered historically

This is a good example of the Evolution CMS ecosystem at its most practical. Instead of waiting for a perfect official package, people regularly trimmed an existing extra down to the exact project shape they needed. In this case, the result was a lighter image workflow for documentation pages, portfolios, and content-heavy sites that wanted cached thumbnails without a full image-routing layer.

Integration notes

The original thread also noted that the plugin did not auto-load the JavaScript needed by Highslide. That had to be added manually in the template, with the graphics path configured explicitly. In modern terms, the important takeaway is the pattern: keep the resize logic separate, and keep the frontend viewer integration simple and explicit.

Source

DirectResize discussion on the MODX forums

Why this belongs in the timeline

This post matters because it shows how Evolution CMS teams solved real project problems with small, explicit patterns instead of heavy abstractions. That practical, incremental style is one of the clearest through-lines in the old Evo ecosystem.

Building Video Search Result Cards with AjaxSearch and phpThumb in Evolution CMS
Preventing DirectResize from Touching TV and multiTV Images