It’s a shame that so many useful plugins are abandoned.
Thank you for this update and taking the initiative.
I haven’t abandoned it, I simply don’t think that it’s a particularly useful plugin in and of itself.
The plugin was meant as a proof of concept only, really. Not as something for people to actually use on live sites. Dynamic image sizing like this scales rather poorly.
I’d like to get something similar built into core instead. And there are alternative implementations such as the Photon module built into Jetpack, which have additional benefits such as serving from the WordPress.com CDN’s.
I’m not a dev so I’ll take your word about there being better implementations. But I’m a bit surprised to hear that you don’t think it’s a particularly useful plugin as it is.
It was exactly what I needed for my small sites to easily clean up the thumbnail and resized image litter that had built up after making theme changes over time.
I just published version 1.1 of my plugin WP Performance Pack which includes dynamic image resizing based on Dynamic Image Resizer. It includes some of the above fixes but serving resized images works a bit different: Instead of hooking into the 404 handler I’m using rewrite rules to serve images using SHORTINIT. No more “c” is added to cropped files. Images get cropped, if resizing to the desired size results in different width or height as given in the filename. This way also images with “old” meta data entries which would be missing the “c” get cropped correctly.
@samuel: I can add you to the list of contributors of WPPP if you want.
Images get cropped, if resizing to the desired size results in different width or height as given in the filename.
That won’t give desirable results when you have images with the same size but different cropping parameters.
The crop value matters. You can’t really eliminate it and just proportionally scale all the time, because sometimes you actually do want to crop to a fixed size. Or vice-versa.
You can’t really eliminate it and just proportionally scale all the time, because sometimes you actually do want to crop to a fixed size.
Maybe you misunderstood me or I misunderstand what you mean.
When an image is to be resized (not when the meta data is generated – that will use the cropping parameter and thus will create the correct image dimensions as suffix but I don’t append the “c” to the filename) I call wp_constrain_dimensions with the original image dimensions and the dimensions given in the filename suffix. If the results of that call don’t match the dimensions from the suffix then cropping is used for the dynamic resizing.
image_resize_dimensions in media.php returns the same dimensions wether cropping is true or false if the image can be resized (proportionally) to the desired dimensions. I don’t see in which case that won’t work.
Assume you have an original image size of 600×400. Create an image size 300x200cropped, e.g. add_image_size( 300, 200, true). Function wp_constrain_dimensions() will return that size exactly as the aspect ratio for both dimensions is the same. As a consequence your code will assume it is a soft resized image and not a cropped one.
Be aware that in WP3.0+ hard cropping does not mean to demagnify the image content, only borders are cut away.
image_resize_dimensions in media.php returns the same dimensions wether cropping is true or false if the image can be resized (proportionally) to the desired dimensions. I don’t see in which case that won’t work.
That case works fine. But the case where cropping is not used and the size is not proportional, does not.
It is commonplace to want there to be a proportional image scaling done, without cropping, to an image whose proportions you don’t know in advance.
So if I define an image size as (300, 200, false), and then I upload a 600×500 image, then I want to actually get an image that is 240×200. Not cropped, just scaled to the maximum size on one side that will still fit in the allotted space.
This is what that crop flag is actually for. It defines whether you want an exact fit by cropping off two of the sides of the image, or whether you want an inexact fit but which still contains the entire image. As such, the flag needs to be remembered and not discarded. All you’re doing is to always set crop to “true”, without accounting for the “false” case. The flag exists for a reason.
So if I define an image size as (300, 200, false), and then I upload a 600×500 image, then I want to actually get an image that is 240×200. Not cropped, just scaled to the maximum size on one side that will still fit in the allotted space.
I agree. That’s why the calculation of image sizes in the wp_generate_attachment_metadata override uses the crop flag. So the filename saved in the meta data will be <i>filename_240x200</i> when no cropping is used. I haven’t changed that. When the actual resizing is done on the first request to exactly that (intermediate) Image, only the I do the mentioned calculations to determine if to use cropping or not. I don’t ignore the crop flag. I only not add the “c” Suffix as the information about to crop or not is implicitly contained in the filename. (If the Image size would be defined as (300, 200, true) then the intermediate filename would become <i>filename_300x200</i> image_resize_dimensions without cropping would return 240×200, so cropping would be applied)
Unfortunatelly Samuel resizer doesnt really work on me. Although the_post_thumbnail(‘smallsquare’) (smallsquare is 76,76,true) it doesnt automatically generate. I had to use Regen Thumbnails to make it work. If I delete file it doesnt generated. The plugin only works on admin it generate images with a c at the end like 38-150x150c.jpg but in normal files like 38-150×150.jpg it doesnt work. Its really weaird. Any help from author please?
dinko: I recommend not using this plugin on production sites at all. Like I said originally, it was and is a proof of concept, not a plugin designed to be used on real sites.
JochenT: Thank you. Your new version works on 3.9.2. However I would suggest you publish it as a seperate project, it is too hard to find your excellent work. Samuel Wood already explained he doesn’t wish to see the project updated, since his excellent work is only a proof of concept – the same thing happened with Minix and result is a fork named Linux, history may love to repeat itself. I agree this design better be made into Core, but the beaten road to introducing it to Core, is to publish it as a working plugin and have enough people using it, not to convince lead developers about it, that’s the way of evolution – there will be enough users to push the idea, consider popularity of VPS nowadays.
There is a big difference between design and evolution. A design can attack the problem directly, however, evolution must pass through all phrases while the entity alive and working, including ugly middle-way stages. If in one phase it is not working, it stopped evolving. From my observation, evolution is more efficient than design, because as the product matures, designers are usually forced into maintainence role and become obstacles of changes, and enter re-act mode instead of acting. Hence, working plugin is more efficient than pursuading core changes.
My plugin WPPP has gone a long way since I first added the dynamic image feature, so I just wanted to keep you updated:
I’m using (overriding) WP_Image_Editor so intermediate images won’t get created even if you edit them directly in WP (with Dynamic Image Resizer creation of intermediate images is suppressed only on upload). This also allows usage of image optimizers like EWWWIO.
Crop settings are no issue anymore. WPPP first checks if the requested (original) image exists in WPs database and then serves the requested size using the image meta data (not registered sizes don’t get served as a security feature to prevent unwanted creation of images).
Other new features include usage of EXIF thumbs, adjustable image quality, not saving intermediate images at all or using WP object cache or CDN for Images.
Any feedback is welcome.
