Image Handler 4 (for v1.5.x) Support Thread

[DivaVocals]

The only reason a HASH would ever be needed would be if one wanted a "quick, but not perfect" COMPARE to see if one image was a copy of another image (to save on storage space). Only relevant if on a cheap host w/ limited space AND the end user was silly and uploaded multiple copies of the same image with different names or uploaded the same image to multiple different paths. Both can be avoided when necessary.

If I remember correctly (it has been a long time since I've looked at the Image Handler code), the hash was used to provide a unique name based on ONLY the path and dimensions. This is the old way image "caches" were handled in the past (computers don't care if the image name is not user friendly and the hash saves a small amount of space in the file names). As space is not a high premium anymore, newer systems simply use a unique path and the image dimensions (retains contextual information about the image in human readable format). I for one was very happy to see someone update the behavior! The more user friendly an image name is (especially for searchable images), the better IMHO.



NOTE: If one wanted, additional management and handling for images could be added. Adding new behavior and features would probably involve a new database table for images along with some refactoring of the existing Zen Cart database tables. A hash of the file contents (not name or dimensions) could be used as a "quick" compare. This is not a small undertaking and probably not worth the effort at this time. Saving a little physical space at the application level is a dying concern these days, especially with the advent of newer filesystems supporting automatic deduplication.

Currently images are all stored at the filesystem level (with unique paths - enforced by the filesystem). The product data simply references the relative path to the images and Image Handler reads this and returns the path to the corresponding Image Handler "optimized" image (creating the image if needed in bmz_cache. This behavior matches the behavior of other CMS systems such as WordPress.

Sorry haven't highlighted the pertinent part, but overall there's the explanation of why the hash function was used and why it is no longer necessary. I presumed (incorrectly) that the hash covered far less information than described. BE GONE hash filename! :) May it rest in peace having fulfilled the need that previously existed.

Thanks lhungil.

Let me give an even simper answer.. I didn't CARE if there was some "perceived" benefit to the MD5 hash naming used.. (and I suspect that one of the other reasons had to do with obscuring and protecting images from image thieves as well)

In any case, it's use has LONG made the images in the bmz_cache unusable for many since you couldn't match the names of the images in the cache to their original "parent" images.. So unless someone can give me a COMPELLING reason why NOT to make the change to more usable image names, I am okay that this change is an improvement for the better.. (in other words, I have NO PLANS to remove it..) and by compelling I do mean something other than providing some small means to "idiot proof" file naming for site admins.. I am not going to try and idiot proof file naming in IH4.. Folks who use poor file naming practices have historically always had issues with IH4 anyway.. The answer to that behavior is to STOP using poor file naming practices..

I will be submitting the updated IH4 this week..