Aqua Resizer - Resize WordPress images on the fly

Hey guys,

Just a heads up on this new script I developed to resize/crop/scale images uploaded through WordPress.

It uses WordPress built-in functions so it’s completely native.

Some of the features:

  • Completely native - uses WP's built-in functions
  • Works both on single or multisite install
  • Easy to use, just feed in the URL
  • Lightweight - can be minified down to +/- 50 lines of code
  • Only process image once, then return the URL if the image already resized
  • Options to crop, soft-crop, array return etc.

I have supplied a little write-up about it on WPExplorer.

The script now lives on Github and licensed with WTFPL.

Cheers :slight_smile:

It works beautifully! :wink:

Genius! Well … not quite… but useful.

Great,thanks a lot :slight_smile:

Great job man! \m/


Thanks guys.

I really hope WP authors will find it useful and adopt it into their themes.

With the script resizing it’s so simple and straightforward, e.g.:

<img src="<?php echo aq_resize($image_url, $width, $height) ?>"/>

It gets saved to the uploads directory and will just retrieve the url if the cropped image is already there = fast + easy + secure and overall just plain efficient. :slight_smile:

More examples here -

Looks bloody good!

Will definitely have to try this out in the next project, thanks for sharing! :slight_smile:

  • Ed

Thank you very much for SMOF and for this. :slight_smile:

Thanks a lot! Wow, incrideble! :stuck_out_tongue:
Muchas gracias!

Thanks guys.

Would love to hear some feedbacks from those who have tested it, especially authors who used timthumb or any similar scripts religiously in their themes before. Would it be a good replacement? :slight_smile:

It’s supposed to be very easy enough to implement. Just paste the code in the functions.php file then fire away with aq_resize()


That’s a good solution and we’ll defo give it a try. Only thing i’m concerned about is when you have a lot of (new) images in a single page: having to resize them all at once could hit memory limit with some hosting providers.

If that happens, you could be left with broken (resized) images which won’t be generated again due to caching.

Altough the above is a minor issue may i suggest a little change ? use image_resize with a temp filename and then rename it on the next line. This way, if image_resize crashes (memory limit), the image will be created again on next page reload.


That’s actually a very brilliant reminder. I slapped when my forehead when I read it.

Just updated the script to 1.1.2 and now it checks for broken image so it can replace it.

Actually, during testing I did roughly about 300 iterations with 1px step to see how big the image_resize() would hit the server, and saw no major issue except for a tad slower page load. I think WP also trusted that user servers can handle more than a handful of GD resizing as even them did not apply this check as far as I know.

But it’s better to be safe than sorry. :slight_smile:

Thanks for the tips bud.


p/s: The iteration testing resizes an image that was just resized then resize some more. For every step it will output a URL & small scaled (via css) image next to it. Thought I’d give people some idea how I conducted the test.

SyamilMJ said

I think WP also trusted that user servers can handle more than a handful of GD resizing as even them did not apply this check as far as I know.

yeah, they do not. But we found ourselves in cases where buyer had such "unfriendly" hosting setup that he couldn't even upload image bigger than a certain size without hitting the memory limit (= broken thumb).

Thanks for the update, we’re going to use your script for sure in our next theme and provide more feedback.



I developed a similar script into my new framework, so I just wanna ask and compare :slight_smile:

1.) can you set the storing directory ?

2.) can you set image expiration time ( caching )

3.) does it automatically tests the permissions ?

4.) how the script behave when the image is actually smaller than wanted dimensions ?

5.) if its stored automatically into upload directory, what happen when I resize 2 images with same name but different location. For example:

img1: /template/nyc.jpg

img2: /images/nyc.jpg

does it have hashing function which can different these 2 images ?

could you share some kind of technical problems which you were experiencing ?

thx and cheers, freshface

@pixelentity - Great to hear that sir.

@freshface -

1 - Not currently, but it’s in the tunnel. See its wiki page under “Future plan” -

2 - This should be handled independently by plugins. I believe trust WP made similar decision about this.

  1. Currently the resized images reside in wp uploads dir, so i made an all or nothing assumption that the directory will always be writable by the server (because otherwise WP wouldn’t function at all). But since there will additional option to define custom dir in the future this will be included along with that feature.

4 - Refer image_resize_dimensions()

5 - This shouldn’t be an issue since the relative path relies on how WP uploaded the images in the first.

To illustrate:

nyc.jpg --> WP media uploader --> nyc.jpg --> aq_resize() --> nyc-50x50.jpg
nyc.jpg --> WP media uploader --> nyc-1.jpg --> aq_resize() --> nyc-1-50x50.jpg

Technical problems: None that I noticed so far.

Hi SyamilMJ!

thank you for your response.

2.) I think that this is abad future decision. Because you can flood the upload dir with all unused images like nyc-50x50.jpg, nyc 52x52.jpg and other. In my resizing script I’m storing the timestamp into the database and user can se how often will be the cache deleted.

5.) What if you want to resize some images based on the theme needs ( for example background image which has different sizes for different templates )

cheers, freshface

SyamilMJ said

2 - This should be handled independently by plugins. I believe trust WP made similar decision about this.

wp stores thumbs info into attachment metadata: when the attachment is deleted, related thumbs get cleared too. Anyway, the above requires messing with the db which is overkill in this case.

A good compromise, imho, would be to create a dedicated subfolder into wp upload dir (to avoid permission issues), this way one could delete all generated thumbs and developers may even provide a dedicated option for that in the theme admin page.

For additional safety, you may want to consider comparing original attachment/cached thumb mtimes and regenerate when original image is newer.


awesome work will definitely try.

Caching is such a broad subject and with WP it gets even more complicated because there is no set standard compounded by this framework.

I will try not to touch the DB if possible, as that would go against advertising the script as “easy” & “fast”. Maybe for advanced users I can add the ability to store timestamp using transients, but no, I won’t be dedicating a table for storing those information. That’s a little intrusive for a small little script to do that.

Regarding the attachment metadata, I actually had a look at the codex on that - . I don’t really like the idea but if there are enough users requesting for this feature it should easy enough to implement (at a loss of little speed of course), or maybe make it an option.