Closed (works as designed)
Project:
Image Resize Filter
Version:
6.x-1.1
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
27 Feb 2009 at 07:41 UTC
Updated:
3 Mar 2009 at 16:02 UTC
Hi!
First of all - great module!
I have a small point to make this module a little bit better. If I resize an image (I create a node, append an image, let the image show with a width of 300px, save the node, edit the node again and modify the width to 200px) and the old resized version of the image is not required any more, it should be deleted. In my example, I would have an resized version of the image with 200px and one (unneeded) width 300px. So why not delete the 300px-one?
Best regards,
Sebastian
Comments
Comment #1
quicksketchImage Resize Filter doesn't really have a way of identifying which images are necessary or not. Because what might happen if you reference the same image in two places (say you used node clone module), but then you resize one of them? Image Resize Filter would not know if it were safe to delete image.
Instead Image Resize Filter is a bit more relaxed in its cleanup, and when the original image is deleted (if ever), then all the derivatives are also deleted. At least, it works this way for upload module. Filefield and other modules will be added in #372500: Delete Files When Originals are Deleted (hook_file support).
Comment #2
arlinsandbulte commentedTo keep extra, unused images from collecting in the resized folder, you could just delete the entire resized folder, clear the drupal cache, and let the images be regenerated on an as-needed basis.
Of course, this would add a performance penalty when regenerating the images.
Comment #3
sewid commentedHi!
Thanks for the replies. #2 would be a good solution for me, if the folder gets too large.
Best regards,
Sebastian
Comment #4
quicksketchYes, but Image Resize Filter has no way of identifying which nodes (or entries in the filter table) are referencing the image, so the only solution would be to clear the entire cache on every edit/insert/delete of nodes (or any where the filters are used). This could cause a drastic performance penalty on a site where nodes are being created frequently.
Comment #5
arlinsandbulte commentedYes, I am aware of the potential performance penalty.
I intended for the images to be deleted and the cache cleared only manually every once in a while if you so wish.
Could a special cache clearing option be implemented so ONLY the necessary cache information is cleared for proper regeneration of resized images?
Comment #6
quicksketchHmm, I'm still not keen on the idea. Image Resize Filter already provides a utility function to clear out ALL cached images, but I think it would be a big mistake to clear this out on a regular basis. Considering the price of disk space, and the relatively low cost of storing extra images (especially since they'll likely be small enough to display inline), the cost of regenerating the images would not be beneficial to most sites.
This single line of PHP code will clear all the cached images, and clear the caches so they can be regenerated:
But for now I'd like to omit this function from running on a regular basis. Ask yourself, why does it really matter if you have extra unused images in a directory you never have to look at? Even a $5/mo hosting plan from GoDaddy provides 10GB of space, so even on the cheapest hosting plans, you should need to worry about space.
1GB of space == 8388608 Kb.
1 150px square JPG at 95% quality == 15 Kb.
1 150px square JPG at 75% quality (the Drupal default) == 5 Kb.
1GB of space == 559,240 images at 95% quality or 1,677,721 images at 75% quality.
Even on the cheapest hosting available you'll be able to store over 10 million resized images. And honestly, if you're serving that many images you should probably upgrade your plan (in which case, $7/mo on cheap hosting gives you 150GB, or 250 million resized images).
Comment #7
arlinsandbulte commentedSetting to by design,
quicksketch makes some good points and there IS a workaround (albeit at a high performance cost).