Responsive images with ImagePlus and pThumb on new Gen.2 platforms Modx Cloud not working as expected

Having copied a live site to a new Gen.2 cloud with Modx-Cloud (PHP 7.4), a problem arises:
I have to disable ‘use Resizer’ for pThumb in the system settings. When using Resizer, ‘/www’ is prepended to the path to the generated images and the paramater ‘zc=1’ isn’t respected from the ImagePlus template (newsImageSmall) below.

<picture>
    <source srcset="[[+source.src:pthumb=`[[+crop.options]]&h=344&w=682&zc=1&q=85&f=webp`]] 2x,
                    [[+source.src:pthumb=`[[+crop.options]]&h=172&w=341&zc=1&q=85&f=webp`]] 1x"/>
    <img src="data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=" 
        alt="[[+alt]]"/>
</picture>

Template with imagePlus call:

            [[ImagePlus?
                &tvname=`imageSrcSet`
                &docid=`[[+id]]`
                &type=`tpl`
                &tpl=`imagePlus.newsImageSmall`
            ]]

After setting ‘use Resizer’ to false, the images get the correct path BUT the aspect-ratio of the images isn’t correct anymore and the cropping applied via the ImagePlus TV seems to be ignored.
How can I fix this?

Or is this a question a should pose to the people at Modx Cloud Support?

Not that I have much insight, but my understanding is, that the “Resizer” in pThumb is very outdated.

In general all these resize extras (pThumb, phpThumbOn, phpThumbOf, …) just seem to use the “phpThumb” version that is included in MODX.

“phpThumb” then relies on the underlying graphics libraries to create the thumbnails.

My guess is, that there is maybe a new version of GD (or ImageMagick) on the server that is not compatible with the “phpThumb” version in MODX. Maybe you can check the version of GD with phpinfo().

What version of MODX are you using?

Modx: 3.01
pThumb: 2.3.3
Resizer: 1.0.2-beta
Imagick: 3.5.1

Does the cropping work correctly if you call the phpthumb connector directly?

https://yourdomain.com/connectors/system/phpthumb.php?&src=path/to/yourimage.jpg&sx=100&sy=200&sw=800&sh=400

The crop area is defined by these 4 parameters:

  • sx = left side of source rectangle
  • sy = top side of source rectangle
  • sw = width of source rectangle
  • sh = height of source rectangle

I think you’re right about the outdated pThumb, so I uninstalled that and Resizer as well in order to rely on phpThumb.
In the website ‘/www’ is still prepended to the image path and no cropping is applied.
Yes the cropping works correctly when I call it directly as you suggested.

So if you uninstalled pThumb, what crop engine do you use now as an alternative?

For the direct call it would be phpThumb, which is the default in ModX, as you said.
But ImagePlus requires pThumb according to Image+ - Image+ | MODX Documentation
So I’m not sure what to do.

ImagePlus should work with either of these extras: pThumb, phpThumbOf, phpThumbsUp or phpThumbOn.

I’m somewhat confused. If phpThumb works correctly and all of these extras use phpThumb, where does the problem occur?

If you output the crop values placeholder ([[+crop.options]]) directly (to see the actual content), is this output correct?

I guess ImagePlus does not work with the default phpThumb? So which one of the Thumbs would you recommend – as they are all outdated?
With phpThumpOn or without any thumb extra the output of
[[+crop.options]] is sx=1154&sy=969&sw=4500&sh=2727 (added to the imagePlus template from above).

phpThumb is a PHP library. You need an extra with a snippet (and some caching) to use it.

I have no idea and I don’t know if it makes much difference. I’d probably still use pThumb (just without Resizer as it doesn’t seem to support modern file formats).

So if you combine this with the other settings from the pthumb call (&h=344&w=682&zc=1&q=85&f=webp) and add it to the phpthumb-connector (connectors/system/phpthumb.php), do you get the same output?

That renders a comletely distorted/squashed part of image
image

And this worked correctly on your old server? Or just when using Resizer?

Maybe set an “Aspect Ratio” in the Image+ configuration, so you don’t have to use height (&h), width (&w) and zoom-crop (&zc=1) in combination with the crop settings.

Yes, this still works correctly on the old server. – with Resizer

That’s not really an option, as I’m not using one specific aspect-ratio for all images.

I’ll report a bug for it to ImagePlus

This is NOT an ImagePlus problem.
This seems to be a problem with phpThumb.

That means I have to report a bug to Modx? Although I’m thinking ImagePlus requires an Extra (which has a bug) so it’s a bit of an ImagePlus problem as well, isn’t it?
I’m lost here :frowning: but thanks for answering anyway.

If it really is a problem with phpThumb then this doesn’t help.

No. ImagePlus requires an Extra that uses a MODX class (modPhpThumb) that uses a PHP library (which has a bug). What exactly should the author do about that?

Hmm thank you for clearing that up.

The problem seems to be this part of the phpThumb code

You could try changing it to this

$scaling_X = $this->thumbnailCropW  / $this->w;
$scaling_Y = $this->thumbnailCropH / $this->h;
if ($scaling_X > $scaling_Y) {
	// some of the width will need to be cropped
	$allowable_width = $this->thumbnailCropW / $scaling_X * $scaling_Y;
	$this->thumbnailCropX += round(($this->thumbnailCropW - $allowable_width) / 2);
	$this->thumbnailCropW = round($allowable_width);

} elseif ($scaling_Y > $scaling_X) {
	// some of the height will need to be cropped
	$allowable_height = $this->thumbnailCropH / $scaling_Y * $scaling_X;
	$this->thumbnailCropY += round(($this->thumbnailCropH - $allowable_height) / 2);
	$this->thumbnailCropH = round($allowable_height);

} else {
	// image fits perfectly, no cropping needed
}

But don’t held me accountable if it doesn’t work. (I haven’t a clue what I’m doing.)


In MODX 3, the file is under core/vendor/james-heinrich/phpthumb/phpthumb.class.php.

1 Like

I’ll try it anyway :slight_smile: