Restarting phpThumbOf development

phpThumbOf is a super useful package that's helped out loads of people. However its last update was a good year ago and since then the issues and pull requests folks submit have been piling up with no response.

In an effort to get things restarted, I've released a fork of phpThumbOf called pThumb. I've tried to address most of the open issues, especially the bugs with file naming which bite people pretty regularly. I also added a few new features that people have suggested, like a global JPEG quality setting, an option to update a cached image when the original has changed, or the addition of the resource ID to error messages in the log to make tracking down problem images easier. Performance has been improved significantly, especially for sites with lots of images or the same image on multiple pages. pThumb will happily run when MODX is installed in a subdirectory. Cache cleanup actually works now, and I changed the phpThumbOfCacheManager plugin to clean up the cache instead of deleting everything, which I think is generally a better choice. See the GitHub page for a more complete list.

It's very simple to install: just uninstall phpThumbOf and install pThumb. Since it uses the same namespace and component names, anything which used phpThumbOf will use pThumb with no modification.

I've marked it as a beta version for now, only because it hasn't been tested too widely yet. For what it's worth, I've got it running on a couple production sites with no problems. But I'd appreciate it if a few people would try it out and let me know if they come across any bugs. You're guaranteed to get a response faster than if you'd opened an issue with phpThumbOf ;-)

One thing I haven't done anything with is the Amazon S3 functionality. The SDK is rather dated now, and I'm sure things could be improved some, or at least modernized. I might get around to working on this but since it's not something I currently use, it might be awhile. If somebody who's familiar with this would like to have a go at it, I'd be very appreciative.

What a great contribution. It's something that's been needed for a long time.

Thank you! This is indeed something that has been badly needed. It's hard for the Revo devs to work on extras like this as well as work on the core (and wonderful things are happening in 2.3 so we don't want them to stop that work), so it's great that community members like you are able and willing to take on some of these more commonly used extras.

Thanks, I'm happy to be able to chip in! I've gotten a ton of mileage out of other peoples' work on MODX over the past couple years, so it's nice to add some back.

A big thank you also from my side =), appreciate your work!

My hoster just activated GraphicsMagick (http://www.graphicsmagick.org/) for my hosting and I'd love to try it...how difficult would it be to extend phpThumb to use this library if it's there? Any ideas?

Since GraphicsMagick is a fork of ImageMagick and mostly uses exactly the same syntax and options, it should be pretty straightforward. It'd entail making a few changes to the core phpThumb class (core/model/phpthumb/phpthumb.class.php): adjusting ImageMagickCommandlineBase() to check for the gm command, then for it to use 'gm convert' instead of 'convert'. phpThumb puts a lot of effort—maybe too much—into verifying the command, version and available options, so it'd probably take a few other adjustments here and there to make things work with gm, but nothing major.

Another idea is pThumb could include it's own version of the phpThumb class so it wouldn't have to rely on the core one, or it could eventually switch to something else entirely. I was just looking at a library called Imagine, which looks pretty good—modern and actively developed too. Then switching between GD2, Imagick and Gmagick is quite simple.

thanks for the detailed answer!

Imagine looks awesome, would love to see this as phpThumb replacement =), but probably a lot of work right?

Actually not that much. Have a look at the 2.0.0-rc2 version of pThumb.

Of course, I didn't implement all of phpThumb's rather baroque feature set. I figure most of that stuff is rarely used and could be better done nowadays with CSS transformations and the upcoming filters. So currently the replacement (Resizer) will do image sizing and cropping, which is mostly all it's needed for. Besides being faster, I wrote it so that all nine zoom crop positions work even with GD, and dimension options like wp, hl, ws, etc. work now too (they're broken in phpThumb).

Resizer works with any of these three PHP extensions: Gmagick, Imagick or GD. It'll auto-select the best one or you can set your preference. pThumb transparently handles switching between phpThumb and Resizer and you can even use both on the same page, so if you need some crazy phpThumb option you can use it for a particular image while using Resizer for the rest of the images.

Resizer doesn't work with the command-line versions of ImageMagick or GraphicsMagick, just the PHP extensions. That's a limitation of Imagine. But it makes detection much easier. Seems like half the time phpThumb couldn't find ImageMagick even if it was installed.

If you have Gmagick, would you mind testing it? I don't have that so I've just tested with Imagick and GD. Once you install pThumb, go to System Settings > phpthumbof and change Use Resizer to Yes; it's not enabled by default. If you change the &debug property on the phpthumbof snippet to Yes, it'll put some debug messages in the error log so you can see what it's doing.

Just for grins I did some rough speed tests comparing phpThumbOf 1.4.0 and pThumb with phpThumb and Resizer. The test page is image heavy: 29 fairly large images to resize and zoom crop, and 4000 existing images in the phpthumbof cache to simulate a big site.

To generate the page with no image resizing: 0.92 s

To generate the page with none of the 29 images in the cache:
phpThumbOf: 20.5 s
pThumb (phpThumb): 9.14 s
pThumb (Resizer - GD): 7.39 s
pThumb (Resizer - Imagick): 5.67 s

To generate the page with the 29 images already cached:
phpThumbOf: 12.3 s (mostly because of the 4029 cached images)
pThumb: 1.00 s (no difference between phpThumb and Resizer since neither is even loaded)

So once the resized images have been cached, pThumb adds very little overhead.

Amazing.
Thank you.

This is a very interesting project, one of the things which has always bugged me and my clients is the slowness of the thumbnail caching.

I've installed the plugin and the thumbnail output works most of the time; however with a particular configuration of MIGX the images fail to load:

• I have a Media Source to load the user into an images directory
• Then I've got an MIGX image grid where the image is chosen
• Then I have a getImageList with the &toSeparatePlaceholders=`image` parameter so the client can choose the location of the images in the body of the article
• Then in the content the client types [[+image.1]], [[+image.2]], etc
• Then inside each [[+image.#]] tpl I use this to generate the thumbnail <img src=[[+image:phpthumbof=`w=540&q=90`]]">

However, via the new thumbnail generator each image loads like this as the <img> src: http://assets/images/article-images/2011/11/image-name.jpg
Instead of: http://www.domain.com/assets/images/article-images/2011/11/image-name.jpg

I've also set a <base href="[[++site_url]]"> in the <head>

In the Error Log there's this

[2013-08-28 04:51:53] (ERROR @ /index.php) [pThumb] Resource: 145 || Image: (none)
Retrieving http://assets/images/article-images/2011/11/image-name.jpg
Target filename: /paas/c1812/www/assets/components/phpthumbof/cache/assets-images-article-images-2011-11-image-name.jpg
cURL error: Couldn't resolve host 'assets' *** Skipping ***

I think I've covered every stop of my process, I've tried debugging it but without any success. Does anybody have any ideas which step is causing the problem?