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

mc12345678:

... But seems that there was a reason to employ it, one that may not be known any longer or perhaps is not as important as once thought.
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.

lhungil:

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.

lhungil:

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.

mc12345678:

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..:laugh: (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.. :laugh:

I will be submitting the updated IH4 this week..

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:

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

mc12345678:

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

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.

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

DivaVocals:

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

mc12345678:

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

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.

I have IH4 installed on 2 systems, both are zc154 all zc files are identical.(checked with wimerge). System1 is my test box (local) and the second is a live site.
IH4 functions properly on the local however on the live site it doesn't. When it's off all images work as they should, however when it's on they don't show in Admin>tools>IH4,
I also loose them for the Online catalog categories.
In the "specials" side box the image is gone but on mouseover it pops up.
They do write to the bmz_cache folder ie: "10-255.jpg.image.50x33.jpg"
In the error logs I am finding: File does not exist: /home/xxxxx/public_html/x (looks like something isn't being directed to the correct directory)
File does not exist: /home/xxxx/public_html/x, referer: http://www.xxxx.com/myadminfoldername/image_handler.php?products_filter=1817&current_category_id=3

Since both systems have the same files etc this would kind of eliminate any interference. The only difference would be the configuration settings but since the images work without IH4 the configuration would be correct ???

I've been working on this for a couple days now and give up trying to figure it on my own- hopefully someone has seen his before :-))
Thanks

Haven't specifically seen it, but seems like it might be file/folder permissions on the bmz_cache directory.

I found it- I realized I don't use htaccess on local so I checked that on the live site.
From ages ago I had entered a 301 for the bmz_cache, evidently I had seen numerous requests for it so I just gave it a 301 over to the base :-))
What a relief to find that old line in there, my hair is already starting to grow back :-))

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.

Then I suggest that you download it from Github, install it and end the mystery.. Because I don't know if I'll be able to submit it this week as I stated earlier.. Not entirely sure why you think you HAVE to get it from the Zen Cart downloads.. I don't have ANYTHING new to add/remove with regards to the IH4 version in my Github repo..

DivaVocals:

Then I suggest that you download it from Github, install it and end the mystery.. Because I don't know if I'll be able to submit it this week as I stated earlier.. Not entirely sure why you think you HAVE to get it from the Zen Cart downloads.. I don't have ANYTHING new to add/remove with regards to the IH4 version in my Github repo..

I meant that more in general. I wasn't specifically referring to your contribution. :smile:

McLovin:

I meant that more in general. I wasn't specifically referring to your contribution. :smile:

Ahhh.. well download it and check it out.. Let me know if it get's you a basis to start what you are trying to achieve..

DivaVocals:

Ahhh.. well download it and check it out.. Let me know if it get's you a basis to start what you are trying to achieve..

I certainly will. Well, fingers crossed, let's see if I can put my idiot savant coding skills to good use (more idiot than savant I'm afraid).

McLovin:

I certainly will. Well, fingers crossed, let's see if I can put my idiot savant coding skills to good use (more idiot than savant I'm afraid).

:laugh::laugh: Well good luck then.. Sometimes wine helps.. Not with the coding, but with the comforting part if things go horribly wrong.. :laugh:

DivaVocals:

:laugh::laugh: Well good luck then.. Sometimes wine helps.. Not with the coding, but with the comforting part if things go horribly wrong.. :laugh:

Sir, you insult me. I don't even start coding until I'm cross-eyed drunk.

ZC 1.5.4 fresh install - under construction
Template: Winchester responsive
Plugins:
IH4
Easy Populate (not used at this stage)
Cross sell advanced

Standard options added to product
Attributes

Issue - IH stopped working either after CS added or attributes.

Have stopped building the site