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

himmon:

Unfortunately upon further inspection it does look like I've screwed something up as I'm no longer seeing the images under image handler, was previously. Have tried your uninstall script again and reupped 4.3.4. Still no luck, if you have any ideas would be extremely appreciated or worse comes to worse I'll restore the backup of the test site.

Thanks again.Attachment #15044

Just restore your backup from your testsite and start over.. It will be MUCH simpler..

Was thinking that rather than wasting time trying to dissect, just restored and installed IH 4.3.4.

All working fine, thanks again for the plugin.

I am using Zencart 1.5.4 with Image Handler 4. I am designing a new website. When I started out I had a "default" image which would appear whenever I didn't have an individual image for a product (let's call it xlogo.jpg) I deleted xlogo.jpg, thinking it would just delete from one product but it deleted it from being the default placeholder image. How can I make xlogo.jpg my default image for my products again?

Also, I wanted to eleminate the extra product images which appear under the main product image when you click on the view product button. Would I go into the admin area--->configuration-->images--->product info no. of additional images per row and set that number to 0 from the default of 3?

Thanks. I appreciate your help.

Hi,

I'm running zen cart 1.5.4 and from reading through some earlier posts on this thread have found out that the correct version of image handler can be found on GitHub which is a beta version.
I am confused though as to which version to download because when choosing the version under 'brach' it shows the following;

branch: 'Master' - Updated for Zen Cart v1.5.4

branch: v4.3.4 - Update for v1.5.2 compatibility

Please can you clarify which is correct for the new zen cart 1.5.4 as from reading some posts it seems to be the v4.3.4 but looking at the GitHub site it is pointing towards the 'Master' version?

Thanks,

Mike

fabienne:

I am using Zencart 1.5.4 with Image Handler 4. I am designing a new website. When I started out I had a "default" image which would appear whenever I didn't have an individual image for a product (let's call it xlogo.jpg) I deleted xlogo.jpg, thinking it would just delete from one product but it deleted it from being the default placeholder image. How can I make xlogo.jpg my default image for my products again?

Also, I wanted to eleminate the extra product images which appear under the main product image when you click on the view product button. Would I go into the admin area--->configuration-->images--->product info no. of additional images per row and set that number to 0 from the default of 3?

Thanks. I appreciate your help.
Neither of your questions pertain to specific issues with Image Handler.. the answer to your second question is yes.. to get help with your first issue, create a new post..

Miketh:

Hi,

I'm running zen cart 1.5.4 and from reading through some earlier posts on this thread have found out that the correct version of image handler can be found on GitHub which is a beta version.
I am confused though as to which version to download because when choosing the version under 'brach' it shows the following;

branch: 'Master' - Updated for Zen Cart v1.5.4

branch: v4.3.4 - Update for v1.5.2 compatibility

Please can you clarify which is correct for the new zen cart 1.5.4 as from reading some posts it seems to be the v4.3.4 but looking at the GitHub site it is pointing towards the 'Master' version?

Thanks,

Mikemaster.. dunno why anyone is looking at the other branches..

OK, I am running ZenCart 1.5.4. and would like to make an image the default image for all of the products in my cart which do not have a different image designated. Like a placeholder. This is about Image Maker specifically. How would you do it? If it's not possible, then please let me know. I have read the help section which came with it but this issue doesn't seem to be in there.

fabienne:

OK, I am running ZenCart 1.5.4. and would like to make an image the default image for all of the products in my cart which do not have a different image designated. Like a placeholder. This is about Image Maker specifically. How would you do it? If it's not possible, then please let me know. I have read the help section which came with it but this issue doesn't seem to be in there.

As previously (within the last page) stated, this issue has nothing to do with IH4. Nor does it relate to Image Maker... It is core zc functionality and a reason to be addressed in it's own thread (or one about default images)...

OK, thanks for clarifying.

Works perfect with latest version of zen. Only one confusion. IH4 does not show additional images with Previous and Next buttons, it only shows every additional image in popup windows, why so? It seems to be big mess.

RiazShahid:

Works perfect with latest version of zen. Only one confusion. IH4 does not show additional images with Previous and Next buttons, it only shows every additional image in popup windows, why so? It seems to be big mess.

Thinking you are mixing up issues and associating issues with your lightbox as issues with IH4.. IH4 doesn't add Previous and Next buttons to additional images..

Hi Guys, I'm running ZenCart v.1.5.1 with v.4.3.2 of Image Handler installed (everything is running smoothly) and I was wondering whether it's possible to implement a simple image swap that would work with IH. The image swap would only have to reveal (for example) one front angle image and one side angle image on mouseover (similar to what Aspinal of London has implemented on its website)? Usually, this is a relatively straight forward process (for example image1.jpg is replaced with image2.jpg on mouseover and image1.jpg is placed back when the mouse stops hovering). I've been trying to figure out whether a similar method could be used with IH, but I'm beginning to think that such as system is not possible due to the way IH handles and names images. So I was wondering whethere any possible alternatives might be possible (without basically having to rewrite large portions of IH)?

McLovin:

Hi Guys, I'm running ZenCart v.1.5.1 with v.4.3.2 of Image Handler installed (everything is running smoothly) and I was wondering whether it's possible to implement a simple image swap that would work with IH. The image swap would only have to reveal (for example) one front angle image and one side angle image on mouseover (similar to what Aspinal of London has implemented on its website)? Usually, this is a relatively straight forward process (for example image1.jpg is replaced with image2.jpg on mouseover and image1.jpg is placed back when the mouse stops hovering). I've been trying to figure out whether a similar method could be used with IH, but I'm beginning to think that such as system is not possible due to the way IH handles and names images. So I was wondering whethere any possible alternatives might be possible (without basically having to rewrite large portions of IH)?

Your swapping module would have to be written in a way that it works with IH4.. This is not directly related to IH4 support, so I don't have an answer.. If this is a module you are using perhaps asking on their support thread would yield you a specific answer.. Or if you have code you are trying to use, you might be better served asking this question in a separate thread on the forum..

Hi DivaVocals, thanks for the response. I'm not using any image swapping modules at the moment. I don't think any 'out of the box' solutions work (or at least I haven't found them yet). Right now my biggest problem is that I don't really know where to begin. Since the images are cached you end up with image names such as "071d16fadbb5599266a0e5da558f3dc0.image.300x300.jpg" placed in in different folders such as bmz_cache/0/, bmz_cache/1/, bmz_cache/2/, etc.) So I don't know of any method that would allow me to 'capture' the secondary image (in part because I don't know what it's named). I think I'll ask in a separate thread to see if anyone can give me any pointers.

McLovin:

Hi DivaVocals, thanks for the response. I'm not using any image swapping modules at the moment. I don't think any 'out of the box' solutions work (or at least I haven't found them yet). Right now my biggest problem is that I don't really know where to begin. Since the images are cached you end up with image names such as "071d16fadbb5599266a0e5da558f3dc0.image.300x300.jpg" placed in in different folders such as bmz_cache/0/, bmz_cache/1/, bmz_cache/2/, etc.) So I don't know of any method that would allow me to 'capture' the secondary image (in part because I don't know what it's named). I think I'll ask in a separate thread to see if anyone can give me any pointers.

And you might want to start using the yet unreleased version of IH4 on my Github repo (search this thread for Github to find the post with the link).. no BIG changes except one.. IH4 will not name images without the MD5 hash obscuring of the image names.. Instead the image names are based on the original image name and the image dimensions..

Great, thanks!

DivaVocals:

And you might want to start using the yet unreleased version of IH4 on my Github repo (search this thread for Github to find the post with the link).. no BIG changes except one.. IH4 will now name images without the MD5 hash obscuring of the image names.. Instead the image names are based on the original image name and the image dimensions..grrrr.. type...

Besides all that, it seems the swap process needs something known to swap with, the file naming/renaming occurs through program code, it really doesn't matter if the md5 hash or something else is used, if the same method of identifying the file is used consistently (with consideration of an image_handler involved) then this can be accomplished as well.

REALLY late in the game, but I thought that overall the md5 hash up to the renaming of the file itself made for a better directory structure/breakdown for having multiple images on a server, but I also haven't performed any serious analysis into the issue :(, so will continue with the good naming practices already employed. My "thought" was based on the expectation that such an analysis was performed upon implementation not just an implementation for some other reason potentially superfluous.

mc12345678:

Besides all that, it seems the swap process needs something known to swap with, the file naming/renaming occurs through program code, it really doesn't matter if the md5 hash or something else is used, if the same method of identifying the file is used consistently (with consideration of an image_handler involved) then this can be accomplished as well.

REALLY late in the game, but I thought that overall the md5 hash up to the renaming of the file itself made for a better directory structure/breakdown for having multiple images on a server, but I also haven't performed any serious analysis into the issue :(, so will continue with the good naming practices already employed. My "thought" was based on the expectation that such an analysis was performed upon implementation not just an implementation for some other reason potentially superfluous.

Ya lost me with that last part, but let me say this.. I have always thought that the MD5 hash made identification of images in the bmz_cache impossible.. It was virtually impossible to link anything with it's source image.. Also why why NOT give the cached images INTELLIGENT HUMAN SOUNDING names.. After all HUMANS need images names they can understand.. the machines don't care..

DivaVocals:

Ya lost me with that last part, but let me say this.. I have always thought that the MD5 hash made identification of images in the bmz_cache impossible.. It was virtually impossible to link anything with it's source image.. Also why why NOT give the cached images INTELLIGENT HUMAN SOUNDING names.. After all HUMANS need images names they can understand.. the machines don't care..

So it seemed to me that the md5 hash did two things. One it placed the image in a "wide" directory structure that would more than likely not result in two images having the same foldername (that's part of a hash' goal. But the second thing that I and. Many others don't agree with is that it renamed the file itself... So instead of shoes_205x205, it would be some mess of information pertinent to the "hash" and then the size... (That "mess" could have been one more directory path more with the actual filename left at the end, but that was not how it was implemented. I totally agree that the image itself should/could be provided in a sensical format (original filename plus perhaps some size indication). Further it would seem that the hash function would provide basically one unique directory path to the image and while not something sensical to us normal readers, wouldn't cause a problem with computer search tools.

Call it a balance between the two, again assuming that the hash provided a benefit beyond some computer science programmer showing that the possibility of applying a hash to a file structure. Beyond that, if the hash actually harmed the use of images (again I'm thinking of the filename remaining intact) for things of the internet, then let it be gone. 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.