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

[mc12345678]

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.

[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..

[mc12345678]

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..

Thing is and part of my point a couple of posts back is that both could be used: the hash to do it's original task and the filename be left alone at the end to match or as is currently suggested approximate the original "parent" image. That is if the only goal was to provide an imahe name that could be matched to it's original "parent". However, the direction chosen has been to eliminate the hash portion entirely, which was why I asked what the goal of the hash was to ensure that other reasons for it being used weren't ignored.

Regardless McLovin will still need to take into account how the filename is named with consideration of the image size as I recall the sample names provided indicate that the image size becomes part of the filename like it does currently in the hash included version. So a similar problem in that regards still exists: what filename to use to swap an additional image with the primary image... And I would think the same solution would apply to use the name generated through the image_handler for the two images being swapped.

[DivaVocals]

Thing is and part of my point a couple of posts back is that both could be used: the hash to do it's original task and the filename be left alone at the end to match or as is currently suggested approximate the original "parent" image. That is if the only goal was to provide an imahe name that could be matched to it's original "parent". However, the direction chosen has been to eliminate the hash portion entirely, which was why I asked what the goal of the hash was to ensure that other reasons for it being used weren't ignored.

I understood your original point.. so here's the answer.. I don't know what the logic was behind Tim's original choice to use an MD5 hash to name the files.. He doesn't say in ANY of the original docs on his site (most of which have been incorporated into the current IH4 readme file..) So to err on the side of caution, I didn't rush to release this version when the change was made.. I wanted to see if there was anything that I hadn't considered that might "crop" up as a result of the change..

Since I've changed it and have it running in this form on a few places now (including my own site) I cannot see that the change has been detrimental.. So yep.. I stand by my original POV on this.. Folks have been asking about better file names from IH4 for YEARS.. A fellow Zenner generously provided the changes needed to do this, I've "beta tested" it for going on close to a year now.. I'm satisfied that this is the right direction.. I can't see where anyone is really gonna say "Gosh I miss the old obscure file names in IH4, can you bring those back?".. No one who's downloaded this version has said this either, nor have they raised any other concerns/issues.. So I'm comfortable submitting this new version..

[mc12345678]

I understood your original point.. so here's the answer.. I don't know what the logic was behind Tim's original choice to use an MD5 hash to name the files.. He doesn't say in ANY of the original docs on his site (most of which have been incorporated into the current IH4 readme file..) So to err on the side of caution, I didn't rush to release this version when the change was made.. I wanted to see if there was anything that I hadn't considered that might "crop" up as a result of the change..

Since I've changed it and have it running in this form on a few places now (including my own site) I cannot see that the change has been detrimental.. So yep.. I stand by my original POV on this.. Folks have been asking about better file names from IH4 for YEARS.. A fellow Zenner generously provided the changes needed to do this, I've "beta tested" it for going on close to a year now.. I'm satisfied that this is the right direction.. I can't see where anyone is really gonna say "Gosh I miss the old obscure file names in IH4, can you bring those back?".. No one who's downloaded this version has said this either, nor have they raised any other concerns/issues.. So I'm comfortable submitting this new version..

Let's see... Due diligence?! Check.... Right... Well then, let's get the party started. :)

[DivaVocals]

Let's see... Due diligence?! Check.... Right... Well then, let's get the party started. :)

Excellent!!

[McLovin]

Very interesting. Unfortunately, it seems that as it currently stands, any workable modification to this version of IH which would allow an image swap is well beyond my programming skills. (I've always been a bad programmer. I tend to take bits and pieces of different programs and put them together. That's why I end up with Frankenstein programs). But I think that with the new modification to IH (some form of human traceable naming convention) it might be possible. I'm very curious about the new version of IH.

[delia]

Image handler is installed on this website. I know it is and installed correctly. GD 2.3.11 is installed and enabled.

But it's not creating new images.

I'm so used to this working right out of the box that I'm now just confused.

I checked folder permissions. Can gd show up in the phpinfo but not work? Never seen it do that but this server is so locked down with mod security and its firewall that things just aren't normal.

[DivaVocals]

Image handler is installed on this website. I know it is and installed correctly. GD 2.3.11 is installed and enabled.

But it's not creating new images.

I'm so used to this working right out of the box that I'm now just confused.

I checked folder permissions. Can gd show up in the phpinfo but not work? Never seen it do that but this server is so locked down with mod security and its firewall that things just aren't normal.

At the risk of asking an obvious question, did you turn it on.. The setting that starts IH4 working is off by default when you install it..