Thumbnails in MODx browser rendered differently on different servers

I’m not convinced this is a MODx bug, so I’ll start off with this thread to maybe get some ideas where to troubleshoot. So here’s the deal...

I’m migrating a site to a new server. The only snag I’ve come upon is how thumbnails look in the MODx browser in the manager. On the old server, they look fine, but on the new, they are distorted. Please see attached screenshots.

Old server vs New server

While taking a closer look, I noticed the reason for the thumbs being distorted. This:


Old server on the left, new on the right

A nice white padding is added on the old server above and below the image. However, using the inspector in Chrome, I can see that the img element has set a height attribute of 60 pixels for both environments. Yet phpThumb on the new server never adds that white space, hence making the thumb look distorted.

I have no idea why this is and what the possible cause might be. I’m not even sure where to start looking to find out why these thumbs are generated in such a different way. I’m hoping the good people of the MODx community can bring me some ideas!

MODx & server info

Old server
PHP: 5.3.6 (CGI/FastCGI)
Apache: Most likely 2.x
OS: Linux srv86 2.6.26-2-vserver-amd64 #1 SMP Tue Mar 9 23:51:13 UTC 2010 x86_64
MySQL: 5.0.51a-24+lenny5-log
MODx version: MODX Revolution 2.1.3-pl (advanced)

The GD section of phpinfo();

New server
PHP: 5.3.6 (CGI/FastCGI)
Apache: Most likely 2.x
OS: FreeBSD 8.1-RELEASE
MySQL: 5.1.43-log
MODx version: MODX Revolution 2.1.3-pl (advanced)
Notes: This server lacks a $_SERVER[’DOCUMENT_ROOT’]

The GD section of phpinfo();

System settings for phpThumb on both server are vanilla. I’ve changed nothing there.

I hope that’s all info needed. Otherwise let me know! And thanks in advance.

The old server that adds white to the top/bottom of a PNG output is actually not the desired behavior. PHPThumb is designed to always output a transparent background when PNG output is selected.

This might have something to do with the older version of libPNG in your GD.

If you want to get the white back, you might try adding &f=jpg to your phpthumb call. This changes the output to JPG, which doesn’t support transparency.

Well, that’s actually not the problem. The images in the example are originally JPEG (they just went PNG for the screenshot). The main problem is not the white itself, but the fact that the new server does not add any pixels in order to maintain the proportions that the MODx manager expects, given that the image has a height of 40 pixels while the img element has a height attribute of 60 pixels.

Try changing output to JPG and see if it adds the extra pixels you’re looking for. The server will not add any height to the image of a PNG because the extra space is transparent.

Looked into it and, as far as the image browser is concerned, I don’t think there’s anything that can be done on your end. We’d need to narrow down what’s actually changed and then submit a bug request.

If you can use some phpThumb variable to get your own images to display properly, then that can simply be added to the file browser for the next release. you might try:

&iar=`1` (ignore aspect ratio)

or

&far=`1` (force aspect ratio)

just to see how each affects your own images. Could give us some clues.

ps: all of my servers are set up similar to your new server. I just never gave any thought to the distorted images in the file browser.

Just wanted to add a quick note that I did another test, upload six versions of the same image; three regular images with black text and white background, and an additional three with the colors inverted. It was the same image saved in GIF, JPEG and PNG. Oddly enough, the same problem just appeared on my old server!

abelafonte, I’ll try your suggestions and see what I get.

I tried fiddling with far and iar on the frontend and all that happens is that phpThumb stretches the image according to the set height, as expected. No padding like in the example above takes place. I completely agree with you that adding those pixels is not a desired behavior, so maybe this should be filed as a bug for the MODx manager?