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

michaelchu:

the pop up window size is calculated from a call to the image height and width, but instead of calling the dimensions of the larger image, the smallest is picked up. So the end result is a tiny window displaying the small image when the user click on the product image to enlarge.Forgot one last thing.. Thinking that not having large image dimensions defined in the IH image settings is the likely cause of your original issue..

Thanks for looking into this. After carefully reviewing your suggestion and testing, here is what I found (so far):
According to the configuration description for IH large image under admin-configuration-images:
"IH large images maximum height
Specify a maximum height for your large images. If width and height are empty or set to 0, no resizing of large images is done."
This simply tells me that IH will not resize the image.
I have tried to enter the dimensions and here is what I found out. If I entered dimensions that exactly the same or larger than the original image, IH will not resize the image and it will be served from the directory where IH uploaded the image to. However, if the dimensions are set to something less than the full size of the original image, IH will resize the image to fit and this will be served from bmz_cache. This however will not resolve the issue of the image being served in thumbnail size. Here is a screenshot of how the image appears and the code, note that it is now from bmz_cache and the dimension is defined as 650x978.

michaelchu:

Thanks for looking into this. After carefully reviewing your suggestion and testing, here is what I found (so far):
According to the configuration description for IH large image under admin-configuration-images:
"IH large images maximum height
Specify a maximum height for your large images. If width and height are empty or set to 0, no resizing of large images is done."
This simply tells me that IH will not resize the image.
I have tried to enter the dimensions and here is what I found out. If I entered dimensions that exactly the same or larger than the original image, IH will not resize the image and it will be served from the directory where IH uploaded the image to. However, if the dimensions are set to something less than the full size of the original image, IH will resize the image to fit and this will be served from bmz_cache. This however will not resolve the issue of the image being served in thumbnail size. Here is a screenshot of how the image appears and the code, note that it is now from bmz_cache and the dimension is defined as 650x978.If there is NO re-sizing, then there is NO processing of the images by IH4 at all, and so YES, they will be served up from their original location. You are also correct that in order for the image to be re-sized and cached that at least ONE of the set dimensions in the settings must be LESS than the original image dimensions. This applies NOT just for the large images, but the small and medium images as well if you choose to upload a separate image for small and medium images versus letting IH4 create these images for you.. There are a FEW small image settings, and Zen Cart allows you to set them all differently if you so desire (ie: specials thumbnails can be different dimensions than the new products thumbnails for example), but in doing so, you will not be able to use the IH4 image hover feature. IH4's image hover feature is disabled if the small thumbnails on the product listings are not ALL the same dimensions..

The reasoning behind the re-sizing logic is that IH4's PRIMARY purpose is to handle all of the re-sizing and image optimization work for you. If you upload images sized and compressed, you would NOT want the image processed again.. So it requires the image dimensions settings to determine if it should process an image or not.

The history behind this assumption is this:
Many shopowners have images that are sized at very large dimensions from digital cameras or supplier supplied pics. Many of these images are 2000+ pixels (height or width) and are at a very high resolutions which increase the overall image size. Historically shopowners would use these images and rely on "artificially" re-sizing the image dimensions using CSS or inline styling with default Zen Cart settings.. While the images would LOOK the right size, these techniques merely changes the screen output, but behind the scenes these images are still the same size and dimensions and when they load, they will impact the page load. Many shopowners do not have the photo editing tools (or skillset to use them) to edit their image sizes, and optimize them for the web. Also for many busy shopowners, this editing and optimization work is time consuming.

IH4 takes the work out of photo optimization by not only sizing the images to the dimensions the shopowner desires on the fly, it compresses the images so the file size is reduced and this helps with page load/performance.

If the large images being uploaded are ALREADY sized to the shopowners preferences then IH4 will do no work on the large images. It will then process the small and medium images UNLESS the shopowner uploads a specific small and medium image. Again, if the small and medium images uploaded are already re-sized to the specs set in the image settings, then IH4 will not process them.

Thinking that before I submit the IH4 update I have in the works that I should update the configuration on screen instructions and perhaps add a little sumthin' to the readme to cover this a little better..

That said your original reported issue with the thumbnail being served up when you click the larger image is still not an issue that I can replicate. Without more widespread reporting of this issue (it's not a "common" issue as you originally asserted), and the ability to replicate this issue, I do not believe it is an IH4 issue. Suggest you try downloading the version on my Github repo which has been updated for v1.5.4 of Zen Cart and see if it works WITHOUT your modification..

Have been trying to upload images using IH4 and it has been a nightmare. The uploading process times out constantly, this was the same from IH3 as well. Has anyone else experienced this and is there a way to minimize this problem.

michaelchu:

Have been trying to upload images using IH4 and it has been a nightmare. The uploading process times out constantly, this was the same from IH3 as well. Has anyone else experienced this and is there a way to minimize this problem.

No, haven't had timeout problem, what size photos are you trying to upload? (Dimensions and file size.)

michaelchu:

Have been trying to upload images using IH4 and it has been a nightmare. The uploading process times out constantly, this was the same from IH3 as well. Has anyone else experienced this and is there a way to minimize this problem.
need to check your error logs.. They may provide some hints as to what's happening.. post the results of your error logs along with the other information we normally as for.. (see below)

Most often this is a symptom of a server configuration limit which will terminate processing before the GD binaries can finish the image processing. Now this could be a simple server configuration change to increase memory limits so that GD can finish processing your images, but the MOST likely cause is that your original images are too large to begin with and your host's servers limits will ALWAYS stop the GD processing..

In order to determine what's going on, (and not waste time on endless guessing) you do need to provide some information.. Start with the following. Go to Tools > Server/Version Info and provide the following information:

• Zen Cart Version
• Server OS
• PHP Version
• PHP File Uploads (also tells us the max size setting)
• Database
• PHP Safe Mode
  Also you don't say.. what version of IH4 are you running..

Finally what is the file size and dimensions of the image you are attempting to upload?? If POSSIBLE attach the image or provide a link where we can see the original pic in the exact size you are attempting to upload..

After some more testing, it appears that IH4 image upload doesn't play nice with Safari. Same exact set of images loaded just fine using Firefox.

Is this fully functional with the current/newest Zen Cart v1.5.4 release? Thanks. :cool:

Hi Guys,

I was wondering whether anyone could help me with the following problem. I'm currently running Zen Cart v.1.5.1 and Image Handler 4. I've noticed that certain images actually end up larger after compression and/or re-sizing. I have no idea why this happens as the original images are all identical (jpeg, same size, same export settings, etc.) and it only happens to some images. Has anyone encountered this problem before and if so, what could be the problem? :frusty:

Thnx!

McLovin:

Hi Guys,

I was wondering whether anyone could help me with the following problem. I'm currently running Zen Cart v.1.5.1 and Image Handler 4. I've noticed that certain images actually end up larger after compression and/or re-sizing. I have no idea why this happens as the original images are all identical (jpeg, same size, same export settings, etc.) and it only happens to some images. Has anyone encountered this problem before and if so, what could be the problem? :frusty:

Thnx!

Nope, and honestly hard to say without seeing the files where this happens, comparing to files where this does not happen.. Could be something in the underlying file meta data, server anomalies, etc.. Too many variables to name.. Finally since it is the GD binaries actually doing the "heavy lifting" the issue could be related specifically to GD processing these images in a different way having something to do with the file's underlying structure/metadata..

shrugs

Can't say for sure..

DivaVocals:

Nope, and honestly hard to say without seeing the files where this happens, comparing to files where this does not happen.. Could be something in the underlying file meta data, server anomalies, etc.. Too many variables to name.. Finally since it is the GD binaries actually doing the "heavy lifting" the issue could be related specifically to GD processing these images in a different way having something to do with the file's underlying structure/metadata..

shrugs

Can't say for sure..

Thanks for the quick feedback!

I've tried to add the two original images as an attachment with a screenshot of what happens with the image sizes after compression by Image Handler 4, but I'm afraid the forum File Handler automatically compresses the original images. So instead I've uploaded them to DropBox:

https://www.dropbox.com/sh/orel6urewx4km24/AAD7XYYMkNDP4Zqrd0JVQd6Ca?dl=0

The first screenshot (normal.jpg and bones-fashion-handtas-a1b2c3-1.jpg) is what normally happens: the image is compressed and/or re-sized without any problems. The second image (larger_after_compression.jpg and bones-fashion-handtas-a1b2c3-5.jpg) however causes problems: it *increasing * in size after compression and/or re-sizing.

I have no idea what might be wrong, as the export procedure for these images is identical. All images have the same structure, metadata, batch, etc. As for the server configuration, I suspect it would have to be quite an exceptionally rare anomaly, as Image Handler works correctly on most images... :wacko:

McLovin:

Thanks for the quick feedback!

I've tried to add the two original images as an attachment with a screenshot of what happens with the image sizes after compression by Image Handler 4, but I'm afraid the forum File Handler automatically compresses the original images. So instead I've uploaded them to DropBox:

https://www.dropbox.com/sh/orel6urewx4km24/AAD7XYYMkNDP4Zqrd0JVQd6Ca?dl=0

The first screenshot (normal.jpg and bones-fashion-handtas-a1b2c3-1.jpg) is what normally happens: the image is compressed and/or re-sized without any problems. The second image (larger_after_compression.jpg and bones-fashion-handtas-a1b2c3-5.jpg) however causes problems: it *increasing * in size after compression and/or re-sizing.

I have no idea what might be wrong, as the export procedure for these images is identical. All images have the same structure, metadata, batch, etc. As for the server configuration, I suspect it would have to be quite an exceptionally rare anomaly, as Image Handler works correctly on most images... :wacko:

Like I said, I couldn't really say, and I personally do not have free time available to really dig in and analyze the files you shared.. I can only share what I know about how this thing works under the hood. I am certain however that the REAL cause has to do with the way GD is interpreting and then processing your files..

Other things that may impact this how GD reads your files for processing.

• Files converted from one format to another. (GIF to JPG or PNG to JPG) If the image software does not correctly convert the file, GD will attempt to detect and correct when processing the file.

• Files "converted" by simply changing the file extension versus actually converting the file using an image editing software will DEFINITELY be processed with unexpected results by GD

• Corrupted files.
  **Recent example of this: **Using lat9's backtrace tool and having IH4 code set to allow GD error messages to be logged, allowed me to discover that a client had MULTIPLE jpg files which were corrupted/invalid. On the front-end these files were all viewable, but on the back-end GD rejected them for processing so there were no optimized images for these particular files. GD sent error messages every time this product was viewed because IH4 attempts to process images on the fly (via GD of course). Opening, re-saving, and then re-uploading these files allowed GD to re-process them with no errors. Do I know EXACTLY what was wrong with these files?? Nope.. Could have been ANYTHING (including the issues I names above).

It says IH4 is compatible with v1.5.0, v1.5.1

Is this release v4.3.2 compatible with ZC 1.5.4 please?

Did anyone try to install this with ZC 1.5.4?

DivaVocals:

New version of IH4 coming out which FINALLY (Thanks/credit to balhir:clap:) gets rid of those ugly MD5 hash file names.. NO OTHER updates in this release.. but given that this has been asked for repeatedly over the years, I think this is a pretty BIG change.

See what the new image URL's will look like here: http://overthehillweb.com/shop/bmz_cache/z/zc4wp.png.image.550x432.png

The new file naming convention in this release breaks down like this:
Actual file name
Filetype
Dimension

This should encourage shop owners to create image file names which are MUCH more meaningful, and it means that shop owners will need to implement file naming structures which follow proper file naming standards. (i.e. no file names with spaces in them or file names with invalid characters)

Needs to be tested.. I have been using this for MONTHS with no issues.. However both I and my clients do not engage in poor file naming practices, and I've not tested this when the file names include spaces or invalid characters.

See: https://github.com/DivaVocals/zen_Image-Handler

GENTLE reminder.. Yep it pays to search the support threads since many questions are already addressed..

Dearest Diva, Goddess of everything Zen! :D

I first humbly apologize for being unable to find the answer to my question which you have probably already answered somewhere back in this thread. I promise I did scan through, but I have failed to find the answer. :(

Ok, now I fear I must ask. I came here wondering if IH4 works on ZC154, same as kabko above. And I was happy to see your link to github, which clearly answers our question. However, the github link contains numerous folders and files.

So I'd fear I have to ask a followup question: Is there a link to a zipped collection of IH4 installation files for ZC154 somewhere?

Btw, long time no talk! Hope all is well!

Feznizzle:

Dearest Diva, Goddess of everything Zen! :D

I first humbly apologize for being unable to find the answer to my question which you have probably already answered somewhere back in this thread. I promise I did scan through, but I have failed to find the answer. :(

Ok, now I fear I must ask. I came here wondering if IH4 works on ZC154, same as kabko above. And I was happy to see your link to github, which clearly answers our question. However, the github link contains numerous folders and files.

So I'd fear I have to ask a followup question: Is there a link to a zipped collection of IH4 installation files for ZC154 somewhere?

Btw, long time no talk! Hope all is well!

Not sure what you mean by "numerous folders and files" as everything in the repo is EXACTLY what would be in the package submitted to the downloads here.. There are no extras..

link to the zip file is on the lower right hand side.. The button labeled "download zip"...

DivaVocals:

link to the zip file is on the lower right hand side.. The button labeled "download zip"...

Doh! I knew there was a simple answer! If it were a snake, it woulda bit me. Thank you! Sorry!

Feznizzle:

Doh! I knew there was a simple answer! If it were a snake, it woulda bit me. Thank you! Sorry!

No worries..:smile:

So sorry if this has been addressed, but I've searched and cannot find the answer. I've been trying to work my way through errors for 3 days now and have progressed to the point where I can't figure it out any more:

I have ZC 1.5.4
This was a new install.
I've installed the Tableau template. It came with the Image Handler 4 built into it.
I installed ZC from the automated script, and had to adjust a few settings to get the "all green" before installing.
Using PHP 5.2.17
MySQL 5.1.69
When I installed the Tableau template I got a few errors related to the install but managed to apply a few changes as per other threads and it installed.

My problem was that I wasn't getting images watermarking properly. After 2 days of diagnosing, I finally downloaded the latest Image Handler 4 and ran the script. I got the following errors:

Image Handler files all exist in correct positions in the directory structure.
Warning CORE FILE OVERWRITE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/MYADMIN/includes/modules/category_product_listing.php was NOT overwritten.
Warning CORE FILE OVERWRITE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/pages/popup_image/header_php.php was NOT overwritten.
Warning CORE FILE OVERWRITE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/pages/popup_image_additional/header_php.php was NOT overwritten.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/tableau/additional_images.phpwas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/tableau/main_product_image.phpwas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/templates/tableau/css/style_imagehover.csswas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/templates/tableau/jscript/jscript_imagehover.jswas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/templates/tableau/popup_image_additional/tpl_main_page.phpwas NOT created.
Error The auto-loader YOURADMIN/includes/auto_loaders/config.image_handler.php has not been deleted. For Image Handler to work you must delete this file manually.
Success Image Handler has been successfully installed

So after thread searching, I did a file compare and overwrote the files manually, and replaced the other files that were not created into the proper directory and deleted the script.

Now, images are watermarking properly. Very nice. Just as I want.

But now this problem:

My product images are not displaying the pop ups. And additional images aren't displaying properly.

I did some file comparisons and cannot find where things are going wrong.

Here's a link to a product page:

http://sunshinelocksmith.com/key-catalog/index.php?main_page=product_info&products_id=1

Notice when you click on the main image it says "The requested content cannot be loaded. Please try again later".

And when you click the 2nd image, the main image is blank.

I cleared out all caches and cannot trace where this might be giving me problems from. Nothing in the error logs to help either.

sunshinelock:

So sorry if this has been addressed, but I've searched and cannot find the answer. I've been trying to work my way through errors for 3 days now and have progressed to the point where I can't figure it out any more:

I have ZC 1.5.4
This was a new install.
I've installed the Tableau template. It came with the Image Handler 4 built into it.
I installed ZC from the automated script, and had to adjust a few settings to get the "all green" before installing.
Using PHP 5.2.17
MySQL 5.1.69
When I installed the Tableau template I got a few errors related to the install but managed to apply a few changes as per other threads and it installed.

My problem was that I wasn't getting images watermarking properly. After 2 days of diagnosing, I finally downloaded the latest Image Handler 4 and ran the script. I got the following errors:

Image Handler files all exist in correct positions in the directory structure.
Warning CORE FILE OVERWRITE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/MYADMIN/includes/modules/category_product_listing.php was NOT overwritten.
Warning CORE FILE OVERWRITE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/pages/popup_image/header_php.php was NOT overwritten.
Warning CORE FILE OVERWRITE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/pages/popup_image_additional/header_php.php was NOT overwritten.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/tableau/additional_images.phpwas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/modules/tableau/main_product_image.phpwas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/templates/tableau/css/style_imagehover.csswas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/templates/tableau/jscript/jscript_imagehover.jswas NOT created.
Warning TEMPLATE FILE CREATE : /hsphere/local/home/DIRECTORY/DIRECTORY/CATALOG/includes/templates/tableau/popup_image_additional/tpl_main_page.phpwas NOT created.
Error The auto-loader YOURADMIN/includes/auto_loaders/config.image_handler.php has not been deleted. For Image Handler to work you must delete this file manually.
Success Image Handler has been successfully installed

> 
> So after thread searching, I did a file compare and overwrote the files manually, and replaced the other files that were not created into the proper directory and deleted the script.
> 
> Now, images are watermarking properly.  Very nice.  Just as I want.
> 
> But now this problem:
> 
> My product images are not displaying the pop ups.  And additional images aren't displaying properly.
> 
> I did some file comparisons and cannot find where things are going wrong.
> 
> Here's a link to a product page:
> 
> <http://sunshinelocksmith.com/key-catalog/index.php?main_page=product_info&products_id=1>
> 
> Notice when you click on the main image it says "The requested content cannot be loaded. Please try again later".
> 
> And when you click the 2nd image, the main image is blank.
> 
> I cleared out all caches and cannot trace where this might be giving me problems from.  Nothing in the error logs to help either.
Not sure that this is aused by Image Handler.. Likely caused by whatever other image module you have installed or that came bundled with Tableau..

Personally I wish template authors would NOT bundle in things like lightboxes and Image Handler in with their templates.. they are GOTCHAS waiting to happen IMHO..