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

Thank you so much for your input. It's all way above my head so I'll have to stick with copying files over until someone shares product info zoom with IH4.

Quote:

---

Originally Posted by nipinuk

Thank you so much for your input. It's all way above my head so I'll have to stick with copying files over until someone shares product info zoom with IH4.

---

The code of: http://www.zen-cart.com/showthread.p...52#post1263152
Is based on the downloadable product image zoom from the downloads section. What I had to do to get that "program" to work or force it to work was to move the javascript files out of their special little directory and place them with the other jscript files just off of the template's main folder. I then prefixed the files to load I think with jscript_. There are less forceful ways to do this, but with those files loaded and the provided code for themain image, product image zoom does work.

Now if you use the IH4 zoom on hover over small images feature then the code at: http://www.zen-cart.com/showthread.p...34#post1263234
Would be more appropriate if the product's image (medium sized image) is the same as both the small image and the large image, or if the large image is relatively repesentative of the product image being displayed.

Other than that, I can't see why more questions aren't asked instead of surrendering to doing more work than is necessary to run your store.

Quote:

---

Originally Posted by mc12345678

The code of: http://www.zen-cart.com/showthread.p...52#post1263152
Is based on the downloadable product image zoom from the downloads section. What I had to do to get that "program" to work or force it to work was to move the javascript files out of their special little directory and place them with the other jscript files just off of the template's main folder. I then prefixed the files to load I think with jscript_. There are less forceful ways to do this, but with those files loaded and the provided code for themain image, product image zoom does work.

Now if you use the IH4 zoom on hover over small images feature then the code at: http://www.zen-cart.com/showthread.p...34#post1263234
Would be more appropriate if the product's image (medium sized image) is the same as both the small image and the large image, or if the large image is relatively repesentative of the product image being displayed.

Other than that, I can't see why more questions aren't asked instead of surrendering to doing more work than is necessary to run your store.

---

Looking at what I did to make this work, I see that I didn't follow the instructions of installing css/js loader... I thought the lasttime I did that, I got more than I wanted/needed... Needless to say atthat time I uninstalled the application, until I would find a must need for it and as necessary keep/omit the aspects I wanted to have. Seems like it would accomplish the loading of the javascript to apply to the product(s) as necessary based on the auto_loader cll, though if you use a product type other than just product, the autoloder would have to be modified to apply to each applicable product type used/to which to apply the product image zoom code.

Sorry I was feeling completely overwhelmed! I'm looking at it again as you're right, I shouldn't just surrender so quickly :)

Here's what I've done and where I got stuck
1. move the following files from includes/templates/mytemplate/jscript/jquery to includes/templates/mytemplate/jscript
jquery.elevateZoom-3.0.8.min.js
jquery_product_image_zoom.js
jquery-1.10.2.min.js

2. 'prefixed the files to load I think with jscript_' - I got stuck here. How would you prefix the files to load? I tried looking into the script of the files mentioned but don't know which line or file to ammend. Which file/s would I need to ammend?

I just read your latest post. I need CSS JS Loader as I'm using the Fast and Easy Checkout plugin. I don't think I'll be using any other product type other than just product thank goodness!

Thank you for all your help mc12345678

Quote:

---

Originally Posted by nipinuk

Sorry I was feeling completely overwhelmed! I'm looking at it again as you're right, I shouldn't just surrender so quickly :)

Here's what I've done and where I got stuck
1. move the following files from includes/templates/mytemplate/jscript/jquery to includes/templates/mytemplate/jscript
jquery.elevateZoom-3.0.8.min.js
jquery_product_image_zoom.js
jquery-1.10.2.min.js

2. 'prefixed the files to load I think with jscript_' - I got stuck here. How would you prefix the files to load? I tried looking into the script of the files mentioned but don't know which line or file to ammend. Which file/s would I need to ammend?

I just read your latest post. I need CSS JS Loader as I'm using the Fast and Easy Checkout plugin. I don't think I'll be using any other product type other than just product thank goodness!

Thank you for all your help mc12345678

---

From what it seems like (ie, following the instructions which includes loading CSS/JS loader) then steps 1 and 2 above would be unnecessary. But, if not using that, then in step 2, the prefixing of the files is to rename the file so that it begins with jscript_ so jquery-1.10.2.min.js would become jscript_jquery-1.10.2.min.js. That said, caution should be taken to not have jquery load multiple times or under multiple versions... Otherwise some quirky things can happen/load time is increaased, errors etc... CSS/JS loader tries to minimize that by loading only the desired jquery files applicable to the situation/condition met in the autoloaders file(s).

Glad though that there is progress... As Diva pointed out there is one additional snippet of. code needed to control the display of the zoomed image according to the images->zoom on small image hover setting. A "partial" solution has been provided I apologize that I did not fully incorporate all aspects into a single snippet of code yet. The above code for using product image zoom will be active regardless of that setting, though still the image that will be presented on hover of the medium sized image (product image) will be the large size image. For general use of IH4 this doesn't make a difference, but for those that use IH4 to store two or three different images for a single "product", this code will display the large image as stored in the database/on the server.

Quote:

---

Originally Posted by mc12345678

So, dropped the product image zoom version of the above. Instead went with incorporating the existing zoom functionality of IH4, which I know Diva you dislike... :)

---

I dislike it because it's a silly feature which really has little to do with IH4's PRIMARY purpose, and for that reason I have despised it's inclusion in IH.. That said, I know folks like it including some of my own clients.. **SHRUGS**

Quote:

---

Originally Posted by mc12345678

The above does not require any additional switch to turn on/off the zoom functionality as it is auto controlled when it comes to the builtin zoom functionality.

---

and this ASSUMES that one would want to turn on image hover on both small and medium images.. that may NOT be the desired behavior.. Hence why I suggested that there be a configuration option for turning on/off zoom on medium images..

Thank you so much mc12345678! There is definitely progress indeed! I've deleted all my images in the images/large directory - hurrah!

Here's temporary link to my test site to show it working: http://tinyurl.com/nolf24y

I have more than one image per product. I currently use the additional images hover to display the additional images in the main product image area. Ideally I would like to be able to click on the little additional product image, display it in main product image area and be able to zoom in on the product. Then I won't need to use zen colorbox and additional images hover plugins. If this is beyond the scope of this thread, do let me know!

Relevant plugins used: IH4, zen colorbox, product image zoom, css js loader, additional images hover

Template used: westminster_new by Anne from picaflor-azul

File ammended (thanks to mc12345678 ) - includes/templates/westminster_new/templates/tpl_modules_main_product_image.php. Contents of file as follows:

Code:

---

<?php
/**
 * Module Template
 *
 * @package templateSystem
 * @copyright Copyright 2003-2011 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: tpl_modules_main_product_image.php 18698 2011-05-04 14:50:06Z wilt $
 */
?>
<?php require(DIR_WS_MODULES . zen_get_module_directory(FILENAME_MAIN_PRODUCT_IMAGE));
/* Begin add 1 of 2 by mc12345678 to support product image zoom */
if ($products_image != '') {
 if (function_exists('handle_image')) {
  $newimg = handle_image($products_image_large, addslashes($products_name), LARGE_IMAGE_WIDTH, LARGE_IMAGE_HEIGHT, '');
  list($src, $alt, $width, $height, $parameters) = $newimg;
  $products_image_large_test = zen_output_string($src);
  if (file_exists($products_image_large_test)) {
  $products_image_large = $products_image_large_test;
  }
 }
}
/* End add 1 of 2 by mc12345678 to support product image zoom 14-10-31*/
 ?>
<div id="productMainImage" class="centeredContent back">
<script language="javascript" type="text/javascript"><!--
document.write('<?php echo '<a href="javascript:popupWindow(\\\'' . zen_href_link(FILENAME_POPUP_IMAGE, 'pID=' . $_GET['products_id']) . '\\\')">' . zen_image(addslashes($products_image_medium), addslashes($products_name), MEDIUM_IMAGE_WIDTH, MEDIUM_IMAGE_HEIGHT,/* Begin add 2 of 2 by mc12345678 14-10-31*/ (file_exists($template->get_template_dir('loader_product_image_zoom.php',DIR_WS_TEMPLATE, 'auto_loaders','auto_loaders'). 'loader_product_image_zoom.php') ? 'data-zoom-image="' . $products_image_large . '"' : '') /* End add 2 of 2 by mc12345678 14-10-31*/) . '<br /><span class="imgLink">' . TEXT_CLICK_TO_ENLARGE . '</span></a>'; ?>');
//--></script>
<noscript>
<?php
  echo '<a href="' . zen_href_link(FILENAME_POPUP_IMAGE, 'pID=' . $_GET['products_id']) . '" target="_blank">' . zen_image($products_image_medium, $products_name, MEDIUM_IMAGE_WIDTH, MEDIUM_IMAGE_HEIGHT) . '<br /><span class="imgLink">' . TEXT_CLICK_TO_ENLARGE . '</span></a>';
?>
</noscript>
</div>

---

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

Yes!! I'm going to download the beta version :-D Thank you for putting so much effort in this community!

I have repeatedly followed the instructions for an install of IH4 for the last 4 days. I'm totally missing something. I change the name to my admin name I FTP the files over that are not the same name and use WinMerge to merge the files that are. Every time I try to start up I get a white screen instead of an Admin Login. I've tried to be in Admin then do the FTP of files as well but when I click on something I get the white screen. I'm clueless at this point in time. What could I possibly be doing wrong?

Please help me. the only blog I found that's like my problem gave no real response as to what he did to fix it and instead said "I got it"

Quote:

---

Originally Posted by Fungai

I have repeatedly followed the instructions for an install of IH4 for the last 4 days. I'm totally missing something. I change the name to my admin name I FTP the files over that are not the same name and use WinMerge to merge the files that are. Every time I try to start up I get a white screen instead of an Admin Login. I've tried to be in Admin then do the FTP of files as well but when I click on something I get the white screen. I'm clueless at this point in time. What could I possibly be doing wrong?

Please help me. the only blog I found that's like my problem gave no real response as to what he did to fix it and instead said "I got it"

---

A white screen means that there is an errorlog created in the logs folder, if you post the contents of the errorlog file we can help.

Quote:

---

Originally Posted by Fungai

I have repeatedly followed the instructions for an install of IH4 for the last 4 days. I'm totally missing something. I change the name to my admin name I FTP the files over that are not the same name and use WinMerge to merge the files that are. Every time I try to start up I get a white screen instead of an Admin Login. I've tried to be in Admin then do the FTP of files as well but when I click on something I get the white screen. I'm clueless at this point in time. What could I possibly be doing wrong?

Please help me. the only blog I found that's like my problem gave no real response as to what he did to fix it and instead said "I got it"

---

The template I was working with is the Holiday Zen template. For some reason I could not find the reason why I got a white screen instead of an Admin Login page. I have decided to wipe Zen Cart and all it's related images off the site and install a fresh Zen Cart, then the Image Handler 4. It worked. Starting from scratch was a setback to be sure.

For me, Image Handler 4 doesn't work with a site that's already populated. I would not recommend installing it unless it's a fresh Zen Cart install.

I have backups of the site that would give me the white screen on IH4 when I tried to merge it, in case anyone ever sees this and wants to respond. It would be nice to see what I missed.

Quote:

---

Originally Posted by Fungai

The template I was working with is the Holiday Zen template. For some reason I could not find the reason why I got a white screen instead of an Admin Login page. I have decided to wipe Zen Cart and all it's related images off the site and install a fresh Zen Cart, then the Image Handler 4. It worked. Starting from scratch was a setback to be sure.

For me, Image Handler 4 doesn't work with a site that's already populated. I would not recommend installing it unless it's a fresh Zen Cart install.

I have backups of the site that would give me the white screen on IH4 when I tried to merge it, in case anyone ever sees this and wants to respond. It would be nice to see what I missed.

---

I install Image Handler almost on a weekly basis for new an d existing shops, and never got a white screen. It must be some other module, which needs to be merged in to the new files.

Quote:

---

Originally Posted by Design75

I install Image Handler almost on a weekly basis for new an d existing shops, and never got a white screen. It must be some other module, which needs to be merged in to the new files.

---

Yup!!! **nods in agreement** :yes:

Quote:

---

Originally Posted by Fungai

For me, Image Handler 4 doesn't work with a site that's already populated. I would not recommend installing it unless it's a fresh Zen Cart install.

---

Sorry, but this is not a true statement at all.. Like Design75, I install IH4 all the time and it doesn't matter if it's a new site, old site..

Quote:

---

Originally Posted by Fungai

I have backups of the site that would give me the white screen on IH4 when I tried to merge it, in case anyone ever sees this and wants to respond. It would be nice to see what I missed.

---

well it would be nice to see the error logs so someone CAN respond.. (as Design75 suggested in response to your initial post)

Quote:

---

Originally Posted by Design75

A white screen means that there is an errorlog created in the logs folder, if you post the contents of the errorlog file we can help.

---

Agree that installation on a site prepopulated or not can be performed with success, and that spending four days independently trying to resolve the issue then waiting possibly 2 hours for a response before indicating that the software doesn't work is not the route to take. Further it seems from the description that the issue was with the admin side not the entire store. The admin side could have been addressed independently without rebuilding everything.

Quote:

---

Originally Posted by mc12345678

Agree that installation on a site prepopulated or not can be performed with success, and that spending four days independently trying to resolve the issue then waiting possibly 2 hours for a response before indicating that the software doesn't work is not the route to take. Further it seems from the description that the issue was with the admin side not the entire store. The admin side could have been addressed independently without rebuilding everything.

---

Yup!!! **nods in agreement** :yes:

Quote:

---

Originally Posted by Fungai

For me, Image Handler 4 doesn't work with a site that's already populated. I would not recommend installing it unless it's a fresh Zen Cart install.

---

I have done several upgrades on sites with IH installed, which means uninstalling the plugin, doing the upgrade, and installing the current version of the plugin. This works. I would have to surmise that the issue is conflict with another plugin you have installed or some piece of customization. The mere fact that there is content in the store does not preclude installation of IH.

Quote:

---

Originally Posted by mc12345678

Further it seems from the description that the issue was with the admin side not the entire store. The admin side could have been addressed independently without rebuilding everything.

---

Definitely. Check the log file - there are several places on the Zen-Cart site that tell you that when you get a white screen to check the log files. You may immediately recognize the error reported, in which case you could have fixed this before several days of frustration. If you can't recognize the problem immediately, don;t worry. Just post the log to this board as suggested immediately after you initially posted your problem. Someone here may have seen that exact problem before and be able to give you the fix or the developer may be able to translate the log for you and give you specific action items - or at least let you know what may be causing the conflict. It is possible that the issue is with one of your other plugins or themes, and you may need to check with support for that add-on...

I have installed IH 4 on the Glascow_Neat template and ZC 1.5.1. The template is only for the Catalog and not the admin side. I have everything on the admin side and actually can add additional images etc and it shows in the image handler manager, so the admin side I am going to assume is working properly. From the catalog the only image is the original image, can someone guide me to what changes I have to make, that the installer did not? I am fairly confident that it has to do with files not being placed into my Glascow_Neat template, I am just not sure which files are needed and where.

I just went through my whole site, and all files that are needed from the IH Package are all exactly where they are supposed to be, so now I am a bit more confused if that is possible. I actually, just in case it was an installer issue, used WinMerge on my old files with the ones from the Install package, and uploaded those, no changes. So now I am really stumped. I am experienced at merging code, and installing plug ins on sites, so I do not believe that is an issue.

The only thing that was off on the install was that the following files did not exist at all on my site and they were ones that were in the to be altered list. (they do exist now though)

/includes/modules/YOUR_TEMPLATE/additional_images.php
/includes/modules/YOUR_TEMPLATE/main_product_image.php
/includes/templates/YOUR_TEMPLATE/popup_image_additional/tpl_main_page.php

The message at the top of the admin page never happened either, however I can not be absolutely positive on that one, because apparently I had timed out and had to log back in when I clicked on the anylink part.

The Images are not enlarging on my site at.


http://www.rarecoinsandtokens.co.uk/...roducts_id=618


The version of Zen Cart Zen Cart 1.5.0
Database Patch Level: 1.5.0
v1.5.0 [2014-12-28 15:30:33] (Version Update 1.3.9->1.5.0)
v1.3.9f [2010-09-01 18:01:05] (Fresh Installation)

· The version of Image Handler 4 Version: 4.3.2
Image Handler⁴

Other add-ons you may have also installed
ckeditor

· Hosting/server information (PHP versions, mySQL versions, hosting provider etc)

PHP Version: 5.4.28 (Zend: 2.4.0)
Database: MySQL 5.5.40-cll

GD Support	enabled
GD Version	bundled (2.1.0 compatible)
Server Host: enterprise.terrassl.net (212.113.134.236)	Database Host: localhost (127.0.0.1)
Server OS: Linux 2.6.18-448.16.1.el5.lve0.8.70

· The EXACT error/issue you are experiencing

Enlarge image function does not work.
Images are displayed in small image size.


install sequence/method you used to install Image Handler 4.

Installed ZC 1.5 in subfolder.
Tested and operated correctly.

Moved files to main html directory and images not resizing.
Installed IH4 by copying all source files to correct folder tree position.
Message retrieved from Zen Cart
“Image Handler files all exist in correct positions in the directory structure.
and
Image Handler has been successfully installed”

These are the settings in Configuration – Images-

Image - Use Proportional Images on Products and Categories	1
IH resize images	yes
IH small images filetype	no_change
IH small images background	255:255:255
IH small images compression quality	85
IH small images watermark	no
IH small images zoom on hover	yes
IH small images zoom on hover size	Medium
IH medium images filetype	no_change
IH medium images background	255:255:255
IH medium images compression quality	85
IH medium images watermark	no
IH large images filetype	no_change
IH large images background	1:1:1
IH large images compression quality	85
IH large images watermark	no
IH large images maximum width	750
IH large images maximum height	550
IH watermark gravity	Center

A typical page can be seen here
http://www.rarecoinsandtokens.co.uk/...roducts_id=618


Image Handler for the above product reports as follows.

Image name	File Type	Default size	Medium size	Large size	Action
1736 roses & plumes shilling 001	.JPG	[IMG]file:///C:\Users\Sup\AppData\Local\Temp\msohtml1\01\clip_image001.jpg[/IMG] 142x75 3.56Kb	[IMG]file:///C:\Users\Sup\AppData\Local\Temp\msohtml1\01\clip_image002.jpg[/IMG] 227x120 7.56Kb	[IMG]file:///C:\Users\Sup\AppData\Local\Temp\msohtml1\01\clip_image003.jpg[/IMG] 750x395 55.41Kb

I am quite stuck now, since IH4 seems to be installed, but not communicating with the default Zen Cart files.
I have looked through the forum, but cannot find a relevant post, since I am not getting an error message as such.

One curious feature is that the file header_php_IH4.php in
/public_html/includes/modules/pages/popup_image_additional
renames to: header_php.phpIH_1419950695.OLD.IH4
which I do not understand.


Any help would be very much appreciated.

I checked out the page you linked to, and that product page is not using image handler to resize the image - the image on the page is still the image in the images directory - and it is quite large. The same is true on your product list pages.

The zoom function works for me, but the page that comes up shows the image at 150x75 because the image tag has that width and height set for the image.

Did you look through the "help" information on the ImageHandler4 admin page under the tools menu in your admin? This may have some helpful information. I suspect that some file (or files) on the public pages isn't installed correctly.

Thank you for the reply.
I have overwritten the source files from the zip several times now.

"that product page is not using image handler to resize the image"
...hence my post


"function works for me, but the page that comes up shows the image at 150x75"
...yes, the popup pops up, but no larger than the small image, hence my post.

"because the image tag has that width and height set for the image."
...is that why it is small even when 'enlarged'? If it is that simple, where should I set the image size so that just the enlargement is large?

"Did you look through the "help" information on the ImageHandler4 admin page"
.,..yes, it says "You can simply upload just one large image (that gets resized as required) or you can have different sources for medium and large images."

..which "simply upload just one large image" is what has been done.
This has never been a problem before. It wasn't a problem with 1.3.9, it wasn't a problem on my local wamp server.

Thanks for the suggestions.

Quote:

---

Originally Posted by kevin_a

Thank you for the reply.
..which "simply upload just one large image" is what has been done.
This has never been a problem before. It wasn't a problem with 1.3.9, it wasn't a problem on my local wamp server.

---

Yes, it should be that simple, and it was on my 1.5.1 installs. If it is working on your local WAMP machine, but not on your (I'm guessing) WAMP web server, have you diff'ed the product files to see if you can see a difference there? Are you using the same template on both servers?


Another thing I noticed there is that you are giving us full paths on your local drive (file:///C:\) when you refer to what is shown on the image handler admin. Those files aren't accessible to web users - at least not at that address. This particular piece of information would appear to be taken from a copy of Zen-Cart running locally, not on a web server. Can you confirm this?

Quote:

---

Originally Posted by kevin_a

Image Handler for the above product reports as follows.

Image name	File Type	Default size	Medium size	Large size	Action
1736 roses & plumes shilling 001	.JPG	[IMG]file:///C:\Users\Sup\AppData\Local\Temp\msohtml1\01\clip_image001.jpg[/IMG] 142x75 3.56Kb	[IMG]file:///C:\Users\Sup\AppData\Local\Temp\msohtml1\01\clip_image002.jpg[/IMG] 227x120 7.56Kb	[IMG]file:///C:\Users\Sup\AppData\Local\Temp\msohtml1\01\clip_image003.jpg[/IMG] 750x395 55.41Kb

I am quite stuck now, since IH4 seems to be installed, but not communicating with the default Zen Cart files.
I have looked through the forum, but cannot find a relevant post, since I am not getting an error message as such.

---

Since we cannot see your site, it's hard for any of us to say what might be going on on your site.. I will make a few observations though..

• Your "File Type" is uppercase... Do any of your images have lowercase suffixes?? JPG and jpg are treated differently by Unix servers.. You should change them all to lowercase and modify the suffix settings in IH4 accordingly if this is inconsistent.
• All of your filenames are not what I would consider good/proper/best practice naming conventions for your image file names, and for use in Zen Cart in particular.
  
  • The numbers in some of your image names can be problematic with the method Zen Cart uses to identify additional images as they could mistakenly be associated with the incorrect product.
  • For example this image name "1736 roses & plumes shilling 001.JPG" might be better as "roses-n-plumes-shilling-001.jpg". Please note the removal of the ampersand (character used in programming), the elimination of spaces (different servers handle spaces differently.. not always consistently), and the use of a lowercase suffix (more common naming convention practice)
  
  

The suggestions above may not solve the issues, but they are practices you should be using anyway as they will prevent other potential issues which may impact IH4.

Suggest trying some other things to boot..

• Eliminate your template as a root cause.. Some template authors make hard coded changes which impact other modules performance. Switch to the Classic template.. Re-install IH4 so that it get's installed in the Classic template folders. Does the problem persist??
• Check with your host to make sure your GD binaries are installed correctly and working..
• Double and triple check your install to make sure you copied over EVERYTHING (yes we know you checked/reinstalled/etc.. humor me and check again please..:smile:)
• Try uploading a completely DIFFERENT image. Not one of your product images.. Download the Zen Cart logo from this site.. Upload it.. Does the problem persist?? If it doesn't the issue could be a number of things including the size of your images, or even some kind of file corruption with your image files..
• Are the files you are uploading in the file format you are specifying?? IH4 has a built in image converter which will for example allow you to upload a JPG and have IH4 convert it to a PNG.. If you are using this feature to upload say a BMP file, its POSSIBLE that the conversion corrupted the file..

If none of this gets things back in order, one last thing you can try is doing a CLEAN vanilla Zen Cart install without your data, apply your template, then install IH4.. Test and make sure it's working.. If it is, then export your DB and import/restore it into your vanilla store and test again to see if things STILL work..

After all of this, if all else fails, you may have to consider paying someone to take a look and troubleshoot this for you..

Quote:

---

Originally Posted by kevin_a

One curious feature is that the file header_php_IH4.php in
/public_html/includes/modules/pages/popup_image_additional
renames to: header_php.phpIH_1419950695.OLD.IH4
which I do not understand.

---

As explained in the readme:

• Files with the ##########.OLD.IH4 suffice are your original files which IH4 renames and saves as a backup (once things are running smoothly you may safely delete this file)
• Files with the IH4 suffix are the IH4 installer files. They replace an equivalent file (usually an override file) of the same name with the PHP suffix instead of the IH4 suffix. (once things are running smoothly you may safely delete this file)

Quote:

---

Originally Posted by kevin_a

Thank you for the reply.
I have overwritten the source files from the zip several times now.

"that product page is not using image handler to resize the image"
...hence my post


"function works for me, but the page that comes up shows the image at 150x75"
...yes, the popup pops up, but no larger than the small image, hence my post.

"because the image tag has that width and height set for the image."
...is that why it is small even when 'enlarged'? If it is that simple, where should I set the image size so that just the enlargement is large?

"Did you look through the "help" information on the ImageHandler4 admin page"
.,..yes, it says "You can simply upload just one large image (that gets resized as required) or you can have different sources for medium and large images."

..which "simply upload just one large image" is what has been done.
This has never been a problem before. It wasn't a problem with 1.3.9, it wasn't a problem on my local wamp server.

Thanks for the suggestions.

---

Quote:

---

Originally Posted by weif

Another thing I noticed there is that you are giving us full paths on your local drive (file:///C:\) when you refer to what is shown on the image handler admin. Those files aren't accessible to web users - at least not at that address. This particular piece of information would appear to be taken from a copy of Zen-Cart running locally, not on a web server. Can you confirm this?

---

I think that was a copy/paste mistake.. I believe kevin was trying to copy images into his post..

Thank you for all the suggestions.
The fact is I would prefer to not want to need IH4.
I resorted to it when the enlarge function on the site was failing, so I thought to fix it with IH4.
Silly me.

It seems zencart works to enlarge images in its native state anyway, as it always did. That’s all I want.

I have made a fresh 1.5.3 install into a subdirectory on the server, created a product, and the enlargement works perfectly well…here..

http://rarecoinsandtokens.co.uk/zencart15/index.php


Since that is all I want to do, it seems IH4 is superfluous.

However, this new install is now proving difficult to import my backup up database into.
Why oh why is ZenCart so tortuous?

I now have the front end public area with faulty functioning,
and a subfolder copy of zencart which I cannot dump a database into.

Let me see..which nightmare shall I follow?

Sorry, but I am sick of this software. I have read endless threads of problems similar, and I really appreciate the efforts of kind users to help.
But I have now wasted days (I have read that so often in other posts)
and have turned a perfectly functioning site into a screwed up failed upgrade site.


Since I want to avoid IH4…(every add-on seems to bring another set of complications I which I can do without)….I shall divert to the subfolder 1.5.3 copy, and try to bring that to a point where it can be transferred to the root folder which means I need to start another thread in another section to solve the import database problem, and follow the journey along yet another branch of this pitiless maze.

Thanks for trying to help though.

Quote:

---

Originally Posted by DivaVocals

I think that was a copy/paste mistake.. I believe kevin was trying to copy images into his post..

---

Yes, that was the case the actual paths were
https://enterprise.terrassl.net/~mil...mage.50x26.JPG
https://enterprise.terrassl.net/~mil...mage.50x26.JPG
https://enterprise.terrassl.net/~mil...mage.50x26.JPG

Quote:

---

Originally Posted by kevin_a

Thank you for all the suggestions.
The fact is I would prefer to not want to need IH4.
I resorted to it when the enlarge function on the site was failing, so I thought to fix it with IH4.
Silly me.

It seems zencart works to enlarge images in its native state anyway, as it always did. That’s all I want.

I have made a fresh 1.5.3 install into a subdirectory on the server, created a product, and the enlargement works perfectly well…here..

http://rarecoinsandtokens.co.uk/zencart15/index.php


Since that is all I want to do, it seems IH4 is superfluous.

---

IH4 is hardly superfluous. It provides a rather useful purpose and that is to optimize images (thereby improving site performance) in addition it adds features which aid in facilitating the process of managing and uploading product images.. Now if you don't want these features, then that is a personal choice, but superfluous implies the module serves no useful purpose, and I wanted to clear that up..

That said it now sounds like you had a pre-existing issue with the image enlarge function. Sounds like you thought IH4 would fix this issue.. IH4 would NOT have fixed this as IH4 doesn't modify Zen Cart's native image management or the behavior of native functions.. (Doesn't modify the image enlargement function AT ALL) IH4 instead ADDS additional features which only work when the native functions are behaving as they should.

I did not mean to suggest that IH4 was globally superfluous, but that in my case it was, and perhaps should had added "to me", although I thought that was implied in
"Since that is all I want to do, it seems IH4 is superfluous."

Given your observations, it would indeed appear that the issue is higher up the structure, outside IH4, but I cant imagine where I would begin to look for that.:-), so decline to follow that branch.
With my fresh install of 1.5.3, I am now engaged with upgrading the database using buggy software which itself needs patching in files that dont even appear in my folders.
But that's another story.

Thanks again for prompt responses. All appreciated.

Image hover and resize issue:
ZC v1.5.4
IH v4.3.2
All install went through with no problems, image loaded with all the resize with no problems. But when trying to view it on the product page, the hover zoom doest not happen and clicking on the image does not bring up the large(original) image. Any suggestions is greatly appreciated.

link here : https://www.waterbabiesbikini.com/ze...&products_id=1

Quote:

---

Originally Posted by michaelchu

Image hover and resize issue:
ZC v1.5.4
IH v4.3.2
All install went through with no problems, image loaded with all the resize with no problems. But when trying to view it on the product page, the hover zoom doest not happen and clicking on the image does not bring up the large(original) image. Any suggestions is greatly appreciated.

link here : https://www.waterbabiesbikini.com/ze...&products_id=1

---

This would appear to be a very common problem, I have searched and reviewed quite a few threads with this common issue but have not found any solution yet. I have verified the IH installation and each of the effected php files. I must be missing something.

Quote:

---

Originally Posted by michaelchu

This would appear to be a very common problem, I have searched and reviewed quite a few threads with this common issue but have not found any solution yet. I have verified the IH installation and each of the effected php files. I must be missing something.

---

Not common at all unless IH4 is not installed correctly or if your server is configured using old configuration specifications and therefore blocks the auto installer.. Post your image settings (ALL of them not just the IH image settings).. Can't help by guessing.. need more details.. Do you have any other image mods installed?? a lightbox perhaps???

You should know that IH4 has not been yet updated for the current version of Zen Cart.. The yet unreleased updated version is on my GitHub repo (link posted here a page or two back). Doubtful that this is a version incompatibility issue though.. But wanted to throw that out there..

BTW, the image hover only works on the small images.. It doesn't apply to the image on the products info page (as is explained in the readme and in this support thread)

The image hover is functioning correctly. The issue is the zoom function. The product image is displayed with the option of click to zoom to bring up the large picture, 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. Granted you can resize the pop up window and make the image bigger but i think everyone would agree that is counter intuitive.

i fudged the code here to get the popup window/image sized correctly:
/includes/modules/pages/popup_image/jscript_main.php
/includes/modules/pages/popup_image_additional/jscript_main.php

original code
imgHeight = document.images[0].height+20-i;
imgWidth = document.images[0].width+20;

new code
imgHeight = document.images[0].height+810-i;
imgWidth = document.images[0].width+590;

Quote:

---

Originally Posted by michaelchu

The image hover is functioning correctly. The issue is the zoom function. The product image is displayed with the option of click to zoom to bring up the large picture, 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. Granted you can resize the pop up window and make the image bigger but i think everyone would agree that is counter intuitive.

i fudged the code here to get the popup window/image sized correctly:
/includes/modules/pages/popup_image/jscript_main.php
/includes/modules/pages/popup_image_additional/jscript_main.php

original code
imgHeight = document.images[0].height+20-i;
imgWidth = document.images[0].width+20;

new code
imgHeight = document.images[0].height+810-i;
imgWidth = document.images[0].width+590;

---

Right and while this solves YOUR resizing issue, this is not a reproducible condition in a clean Zen Cart install with IH4 installed. This is not a fix that will be incorporated into IH4, because it cannot be consistently reproduced, and I'm not suggesting that anyone else implement this change either...

IH4 is NOT working on your site.. None of your product and category images are being served from the bmz_image cache folder.. This is a telling sign that IH4 is not configured/installed/running correctly..

Quote:

---

Originally Posted by DivaVocals

Right and while this solves YOUR resizing issue, this is not a reproducible condition in a clean Zen Cart install with IH4 installed. This is not a fix that will be incorporated into IH4, because it cannot be consistently reproduced, and I'm not suggesting that anyone else implement this change either...

IH4 is NOT working on your site.. None of your product and category images are being served from the bmz_image cache folder.. This is a telling sign that IH4 is not configured/installed/running correctly..

---

There needs to be a LOT more information provided to determine why your site is not handling the larger images correctly..

Here is the list of what has been installed in the order it was installed:
ZC v1.5.4 clean install, empty database
Responsive All Business template v1.0 for ZC v1.5.x from Picaflor
FedEx Web services by Numinix
IH v4.3.2

Here is the list of image config:
mall Image Width 60
Small Image Height 100
Heading Image Width - Admin 57
Heading Image Height - Admin 40
Subcategory Image Width 60
Subcategory Image Height 100
Calculate Image Size true
Image Required true
Image - Shopping Cart Status 1
Image - Shopping Cart Width 100
Image - Shopping Cart Height 200
Category Icon Image Width - Product Info Pages 300
Category Icon Image Height - Product Info Pages 300
Top Subcategory Image Width 150
Top Subcategory Image Height 85
Product Info - Image Width 300
Product Info - Image Height 300
Product Info - Image Medium Suffix _MED
Product Info - Image Large Suffix _LRG
Product Info - Number of Additional Images per Row 3
Image - Product Listing Width 60
Image - Product Listing Height 100
Image - Product New Listing Width 60
Image - Product New Listing Height 100
Image - New Products Width 60
Image - New Products Height 100
Image - Featured Products Width 60
Image - Featured Products Height 100
Image - Product All Listing Width 60
Image - Product All Listing Height 100
Product Image - No Image Status 1
Product Image - No Image picture no_picture.gif
Image - Use Proportional Images on Products and Categories 1
IH resize images yes
IH small images filetype no_change
IH small images background 255:255:255
IH small images compression quality 85
IH small images watermark no
IH small images zoom on hover yes
IH small images zoom on hover size Medium
IH medium images filetype no_change
IH medium images background 255:255:255
IH medium images compression quality 85
IH medium images watermark no
IH large images filetype no_change
IH large images background 255:255:255
IH large images compression quality 85
IH large images watermark no
IH large images maximum width
IH large images maximum height
IH watermark gravity Center

I am not certain as to how you determined that the images are not served from bmz_image. I only uploaded 2 product pictures via IH, both were resized by IH and placed in the correct places. If you are correct and IH is not working and the images are not from bmz_image, then what else would automatically resize the 2 images I uploaded using IH and place them in the correct locations?:unsure:

Here is a screen shot of IH and the resized pics, let me know if you need any other info to trouble shoot:
Attachment 14840

Quote:

---

Originally Posted by michaelchu

Here is the list of what has been installed in the order it was installed:
ZC v1.5.4 clean install, empty database
Responsive All Business template v1.0 for ZC v1.5.x from Picaflor
FedEx Web services by Numinix
IH v4.3.2

Here is the list of image config:
mall Image Width 60
Small Image Height 100
Heading Image Width - Admin 57
Heading Image Height - Admin 40
Subcategory Image Width 60
Subcategory Image Height 100
Calculate Image Size true
Image Required true
Image - Shopping Cart Status 1
Image - Shopping Cart Width 100
Image - Shopping Cart Height 200
Category Icon Image Width - Product Info Pages 300
Category Icon Image Height - Product Info Pages 300
Top Subcategory Image Width 150
Top Subcategory Image Height 85
Product Info - Image Width 300
Product Info - Image Height 300
Product Info - Image Medium Suffix _MED
Product Info - Image Large Suffix _LRG
Product Info - Number of Additional Images per Row 3
Image - Product Listing Width 60
Image - Product Listing Height 100
Image - Product New Listing Width 60
Image - Product New Listing Height 100
Image - New Products Width 60
Image - New Products Height 100
Image - Featured Products Width 60
Image - Featured Products Height 100
Image - Product All Listing Width 60
Image - Product All Listing Height 100
Product Image - No Image Status 1
Product Image - No Image picture no_picture.gif
Image - Use Proportional Images on Products and Categories 1
IH resize images yes
IH small images filetype no_change
IH small images background 255:255:255
IH small images compression quality 85
IH small images watermark no
IH small images zoom on hover yes
IH small images zoom on hover size Medium
IH medium images filetype no_change
IH medium images background 255:255:255
IH medium images compression quality 85
IH medium images watermark no
IH large images filetype no_change
IH large images background 255:255:255
IH large images compression quality 85
IH large images watermark no
IH large images maximum width
IH large images maximum height
IH watermark gravity Center

I am not certain as to how you determined that the images are not served from bmz_image. I only uploaded 2 product pictures via IH, both were resized by IH and placed in the correct places. If you are correct and IH is not working and the images are not from bmz_image, then what else would automatically resize the 2 images I uploaded using IH and place them in the correct locations?:unsure:

Here is a screen shot of IH and the resized pics, let me know if you need any other info to trouble shoot:

---

Your small and medium images appear to be coming from the bmz_cache folder.. If you right click on the product image on the product page you posted, this is the image URL: https://www.waterbabiesbikini.com/ze...ge.199x300.jpg. The small image URL is: https://www.waterbabiesbikini.com/ze...mage.60x90.jpg

The large product image is not coming from the bmz_cache folder at all.. Click on the "larger image" link, and right click on the image in the popup window.. This is the URL of the image: https://www.waterbabiesbikini.com/ze...m%20bikini.jpg. Note that this image is NOT being served from the bmz_cache folder.. and this is because you have NOTHING in the large image settings.. (I JUST tested this use case and confirmed that this is what will happen if you have no values in EITHER the large height or width)

Now this doesn't resolve the original issue you had with the large image popup, and it's not an issue I can replicate.. It's also not something that's been noted as a known issue at all.. I am unable to say what the cause MIGHT be as it seems to be part of your specific setup...

Quote:

---

Originally Posted by DivaVocals

Your small and medium images appear to be coming from the bmz_cache folder.. If you right click on the product image on the product page you posted, this is the image URL: https://www.waterbabiesbikini.com/ze...ge.199x300.jpg. The small image URL is: https://www.waterbabiesbikini.com/ze...mage.60x90.jpg

The large product image is not coming from the bmz_cache folder at all.. Click on the "larger image" link, and right click on the image in the popup window.. This is the URL of the image: https://www.waterbabiesbikini.com/ze...m%20bikini.jpg. Note that this image is NOT being served from the bmz_cache folder.. and this is because you have NOTHING in the large image settings.. (I JUST tested this use case and confirmed that this is what will happen if you have no values in EITHER the large height or width)

Now this doesn't resolve the original issue you had with the large image popup, and it's not an issue I can replicate.. It's also not something that's been noted as a known issue at all.. I am unable to say what the cause MIGHT be as it seems to be part of your specific setup...

---

Need to add this:
"NOT being served from the bmz_cache folder" = your large images are NOT optimized NOR are they resized by IH4.. IH4 needs the image dimensions so that it can pass the image parameters to GD so that the image can be processed.. You will be able to use the IH4 admin tools to upload images, but your large images will NOT be optimized.. IH4/Zen Cart will instead serve up the original un-processed large image..

Quote:

---

Originally Posted by 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.
Attachment 14843

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.)

Quote:

---

Originally Posted by 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!

Quote:

---

Originally Posted by 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..

Quote:

---

Originally Posted by 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/orel6urew...d0JVQd6Ca?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:

Quote:

---

Originally Posted by 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/orel6urew...d0JVQd6Ca?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?

Quote:

---

Originally Posted by 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!

Quote:

---

Originally Posted by 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"...

Quote:

---

Originally Posted by 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!

Quote:

---

Originally Posted by 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:

PHP Code:

---

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

Quote:

---

Originally Posted by 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:

PHP Code:

---

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

Okay, which file do you think it is that needs to be restored to original, then compared against Image Handler?

Quote:

---

Originally Posted by sunshinelock

Okay, which file do you think it is that needs to be restored to original, then compared against Image Handler?

---

I couldn't say.. Suggest comparing them ALL.. and seeing where your code differs from what is in the Image Handler files.. BTW, IH4 currently available inthe downloads has NOT yet been updated/tested with v1.5.4 of Zen Cart..

I had to delete the templates/tableau/templates/tpl_main_product_image.php to get the proper 1st image to pop up again.

Problem 2 is the 2nd image. I'll post when I find the solution to that.

Quote:

---

Originally Posted by DivaVocals

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

---

Yep, Tableau is one of the worst, the only thing that is not included in the package is Zen Cart :laugh:

Quote:

---

Originally Posted by Design75

Yep, Tableau is one of the worst, the only thing that is not included in the package is Zen Cart :laugh:

---

**snickers**

The problem with all this bundling besides the fact that I don't always LIKE the bundling choices the author makes in choosing the bundled modules (ie: I prefer Zen Colorbox, & the author may bundle in Zen Lightbox for example) is that it sometimes makes troubleshooting issues a bit tricky.. Can't tell what's caused by the template, and what's caused by the module, or what's being caused by something else bundled in.. :huh: If sunshinelock's issues started RIGHT after installing the template, and the template was installed over a VANILLA Zen Cart install, I'd say the best bet is to go to the author of the template and ask them for assistance to resolve.. I am personally not going to be able to spend a lot of time trying to GUESS what MIGHT be the solution as my free time is limited.. Don't know what effect some of the modules bundled in with this particular template might have..

Had this little glitch before on another site with IH3 and wound up dropping it as we found no answer. Just had this (and two others show up on a recent upgrade to 1.5.4.

Quote:

---

[04-Feb-2015 16:25:51 America/Chicago] #1 strstr() called at [/home/OURSITE/public_html/includes/classes/bmz_image_handler.class.php:129]
#2 ih_image->determine_image_sizetype() called at [/home/OURSITE/public_html/includes/classes/bmz_image_handler.class.php:55]
#3 ih_image->ih_image() called at [/home/OURSITE/public_html/includes/functions/extra_functions/functions_bmz_image_handler.php:55]
#4 handle_image() called at [/home/OURSITE/public_html/includes/functions/html_output.php:187]
#5 zen_image() called at [/home/OURSITE/public_html/includes/templates/template_default/popup_image/tpl_main_page.php:17]
#6 require(/home/OURSITE/public_html/includes/templates/template_default/popup_image/tpl_main_page.php) called at [/home/OURSITE/public_html/index.php:97]

[04-Feb-2015 16:25:51 America/Chicago] PHP Warning: strstr(): Empty needle in /home/enignet/public_html/includes/classes/bmz_image_handler.class.php on line 129

---

Please note that this was NOT caused by either a faulty installation or the mod itself.
We found the problem absolutely by accident.
SOLUTION:
Somehow, the menu entry for Configuration >> Images >> Product Info - Image Large Suffix was BLANK:shocking: The default is _LRG. Adding this back into the menu item cured the problem.

The symptom that led us to the _LRG setting was that IH4 was working fine EXCEPT when looking at the large image on a product's page. Also, when viewing a product in the IH4 Image Manager, there was no Large size image shown.

Again, this was not a fault of the installation or IH4 itself.

Might be something to consider having the setup look for when auto-loading. It could say something like, "Your Images >> Product Info - Image Suffixes cannot be blank. IH4 does not care if the suffix is _LRG or _GRL BUT it does need something there in both the Medium and Large or it will throw the error above.

Time out got me. Meant to add

BTW: Everything is working well with 1.5.4, Apache, 5.4.36 PHP, 5.5.40-cll MySQL

Quote:

---

Originally Posted by dbltoe

Had this little glitch before on another site with IH3 and wound up dropping it as we found no answer. Just had this (and two others show up on a recent upgrade to 1.5.4.

Please note that this was NOT caused by either a faulty installation or the mod itself.
We found the problem absolutely by accident.
SOLUTION:
Somehow, the menu entry for Configuration >> Images >> Product Info - Image Large Suffix was BLANK:shocking: The default is _LRG. Adding this back into the menu item cured the problem.

The symptom that led us to the _LRG setting was that IH4 was working fine EXCEPT when looking at the large image on a product's page. Also, when viewing a product in the IH4 Image Manager, there was no Large size image shown.

Again, this was not a fault of the installation or IH4 itself.

Might be something to consider having the setup look for when auto-loading. It could say something like, "Your Images >> Product Info - Image Suffixes cannot be blank. IH4 does not care if the suffix is _LRG or _GRL BUT it does need something there in both the Medium and Large or it will throw the error above.

---

Wow!!! Nice catch!!! Don't cha just LOVE la9's backtrace plugin!!!! Handy as HE!! for tracing strange issues..

Now how to fix/prevent from happening again..

Hmmmm..

Thinking that adding a warning to the auto-installer is absolutely correct (and I'll see if I can figure out how to do that), but I'm wondering if in addition to that perhaps the auto-installer should just update the value to _LRG if this is found to contain a blank or NULL value (something I KNOW I can manage to update:laugh:)..

OR..

Maybe the auto installer should update the value to DON'T_DELETE_THIS_OR_IMAGE_HANDLER_WILL_BREAK :laugh:

backtrace is good but it wasn't used. Just happened to have two admin menus up from different sites and saw the missing _LRG. When you click to edit, it tells you that the default is _LRG.
Same thing happens with _MED just LOTS MORE WORSER.
Perhaps the installer should change them both to _BOO:shocking:

Quote:

---

Originally Posted by dbltoe

backtrace is good but it wasn't used.

---

Oh I realized you found the problem without backtrace..:smile: I just recognized the backtrace output from your error log..

Quote:

---

Originally Posted by dbltoe

Just happened to have two admin menus up from different sites and saw the missing _LRG. When you click to edit, it tells you that the default is _LRG.
Same thing happens with _MED just LOTS MORE WORSER.

---

GADS!!! Found a similar kind of weird one off issue just two days ago with COWOA..

Thanks for sharing this.. I was gonna pull the trigger on the new IH4 this weekend.. Hoping that this is a QUICK fix for me to make happen..

Quote:

---

Originally Posted by dbltoe

Perhaps the installer should change them both to _BOO:shocking:

---

**snickers**

Quote:

---

Quote Originally Posted by dbltoe View Post
Perhaps the installer should change them both to _BOO

---

that would not be so hard. But it would be much better to mend the mod itself so that if the setting was blank it didn't create an error. Judging from the errors what is happening is that IH is checking to see if a large image exists. It is matching the suffix, _LRG (or whatever).

It shouldn't be too hard to put a conditional around all that code so that if the suffix is blank it doesn't even bother looking for a large image.

If not having any suffix messes up any other aspects of images implicit in Zen, which is possible, then it would be better to put code in Zen that assured that the setting could never be blank.

Relying on the auto-installer only to ensure that the setting is not blank seems like a band-aid.

Quote:

---

Originally Posted by niccol

Relying on the auto-installer only to ensure that the setting is not blank seems like a band-aid.

---

Of course it is.. But it's a bandaid that I KNOW how to create.. You know I'm not REALLY a developer.. I only play one on TV..:laugh:

Quote:

---

Originally Posted by DivaVocals

Of course it is.. But it's a bandaid that I KNOW how to create.. You know I'm not REALLY a developer.. I only play one on TV..:laugh:

---

Yeah, but it is probably easier to change the module than change the auto-installer :-) You've got the line number form the errors

Code:

---

[04-Feb-2015 16:25:51 America/Chicago] PHP Warning: strstr(): Empty needle in /home/enignet/public_html/includes/classes/bmz_image_handler.class.php on line 129

---

You are probably going to do something like this

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                if (strstr($this->src, $ihConf['large']['suffix'])) {
                        $this->sizetype = 'large';
                } elseif (strstr($this->src, $ihConf['medium']['suffix'])) {
                        $this->sizetype = 'medium';
                } elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
                        $this->sizetype = 'small';
                } else
                $this->sizetype = 'generic';
        }

---

changed to:

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                $this->sizetype = 'generic';

                if($ihConf['large']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['large']['suffix'])) {
                                $this->sizetype = 'large';
                        }                       
                }

                if($ihConf['medium']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['medium']['suffix'])) {
                                $this->sizetype = 'medium';
                        }                       
                }               
               
                if($ihConf['large']['small'] != '')
                {
                        if (strstr($this->src, $ihConf['small']['suffix'])) {
                                $this->sizetype = 'small';
                        }                       
                }
}

---

Off the top of my head and without looking at any of the other areas or consequences.

Quote:

---

Originally Posted by niccol

Yeah, but it is probably easier to change the module than change the auto-installer :-) You've got the line number form the errors

Code:

---

[04-Feb-2015 16:25:51 America/Chicago] PHP Warning: strstr(): Empty needle in /home/enignet/public_html/includes/classes/bmz_image_handler.class.php on line 129

---

You are probably going to do something like this

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                if (strstr($this->src, $ihConf['large']['suffix'])) {
                        $this->sizetype = 'large';
                } elseif (strstr($this->src, $ihConf['medium']['suffix'])) {
                        $this->sizetype = 'medium';
                } elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
                        $this->sizetype = 'small';
                } else
                $this->sizetype = 'generic';
        }

---

changed to:

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                $this->sizetype = 'generic';

                if($ihConf['large']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['large']['suffix'])) {
                                $this->sizetype = 'large';
                        }                       
                }

                if($ihConf['medium']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['medium']['suffix'])) {
                                $this->sizetype = 'medium';
                        }                       
                }               
               
                if($ihConf['large']['small'] != '')
                {
                        if (strstr($this->src, $ihConf['small']['suffix'])) {
                                $this->sizetype = 'small';
                        }                       
                }
}

---

Off the top of my head and without looking at any of the other areas or consequences.

---

I would suggest either of the following two depending on the desired goal. First would be to prevent the error in this section of code, but wouldn't address similar potential problems later on, the second would set the variables in this section of code but also may still have the issue later, either way, an example to address the issue and maintain existing functionality. The example above appears to lead to all images being the size of the last defined size.

Code:

---

function determine_image_sizetype() {
global $ihConf;

if (zen_not_null($ihConf['large']['suffix']) && strstr($this->src, $ihConf['large']['suffix'])) {
$this->sizetype = 'large';
} elseif (zen_not_null($ihConf['medium']['suffix']) && strstr($this->src, $ihConf['medium']['suffix'])) {
$this->sizetype = 'medium';
} elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
$this->sizetype = 'small';
} else
$this->sizetype = 'generic';
}

---

Code:

---

function determine_image_sizetype() {
global $ihConf;
if (!zen_not_null($ihConf['large']['suffix']) {
$ihConf['large']['suffix'] = '_LRG';
}

if (!zen_not_null($ihConf['medium']['suffix']) {
$ihConf['medium']['suffix'] = '_MED';
}

if (strstr($this->src, $ihConf['large']['suffix'])) {
$this->sizetype = 'large';
} elseif (strstr($this->src, $ihConf['medium']['suffix'])) {
$this->sizetype = 'medium';
} elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
$this->sizetype = 'small';
} else
$this->sizetype = 'generic';
}

---

Quote:

---

Originally Posted by niccol

Yeah, but it is probably easier to change the module than change the auto-installer :-) You've got the line number form the errors

Code:

---

[04-Feb-2015 16:25:51 America/Chicago] PHP Warning: strstr(): Empty needle in /home/enignet/public_html/includes/classes/bmz_image_handler.class.php on line 129

---

You are probably going to do something like this

Code:

---

    function determine_image_sizetype() {
        global $ihConf;
       
        if (strstr($this->src, $ihConf['large']['suffix'])) {
            $this->sizetype = 'large';
        } elseif (strstr($this->src, $ihConf['medium']['suffix'])) {
            $this->sizetype = 'medium';
        } elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
            $this->sizetype = 'small';
        } else
        $this->sizetype = 'generic';
    }

---

changed to:

Code:

---

    function determine_image_sizetype() {
        global $ihConf;
       
        $this->sizetype = 'generic';

        if($ihConf['large']['suffix'] != '')
        {
            if (strstr($this->src, $ihConf['large']['suffix'])) {
                $this->sizetype = 'large';
            }           
        }

        if($ihConf['medium']['suffix'] != '')
        {
            if (strstr($this->src, $ihConf['medium']['suffix'])) {
                $this->sizetype = 'medium';
            }           
        }       
       
        if($ihConf['large']['small'] != '')
        {
            if (strstr($this->src, $ihConf['small']['suffix'])) {
                $this->sizetype = 'small';
            }           
        }
}

---

Off the top of my head and without looking at any of the other areas or consequences.

---

Quote:

---

Originally Posted by mc12345678

I would suggest either of the following two depending on the desired goal. First would be to prevent the error in this section of code, but wouldn't address similar potential problems later on, the second would set the variables in this section of code but also may still have the issue later, either way, an example to address the issue and maintain existing functionality. The example above appears to lead to all images being the size of the last defined size.

Code:

---

function determine_image_sizetype() {
global $ihConf;

if (zen_not_null($ihConf['large']['suffix']) && strstr($this->src, $ihConf['large']['suffix'])) {
$this->sizetype = 'large';
} elseif (zen_not_null($ihConf['medium']['suffix']) && strstr($this->src, $ihConf['medium']['suffix'])) {
$this->sizetype = 'medium';
} elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
$this->sizetype = 'small';
} else
$this->sizetype = 'generic';
}

---

Code:

---

function determine_image_sizetype() {
global $ihConf;
if (!zen_not_null($ihConf['large']['suffix']) {
$ihConf['large']['suffix'] = '_LRG';
}

if (!zen_not_null($ihConf['medium']['suffix']) {
$ihConf['medium']['suffix'] = '_MED';
}

if (strstr($this->src, $ihConf['large']['suffix'])) {
$this->sizetype = 'large';
} elseif (strstr($this->src, $ihConf['medium']['suffix'])) {
$this->sizetype = 'medium';
} elseif ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) {
$this->sizetype = 'small';
} else
$this->sizetype = 'generic';
}

---

---

Happy to update this once you guys hash out the details of WHAT update to make..:laugh:

:-)

Whatever. There is a typo in my code due copying and pasting but basically they will all work. Lots of ways of skinning a cat.

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                $this->sizetype = 'generic';

                if($ihConf['large']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['large']['suffix'])) {
                                $this->sizetype = 'large';
                        }                       
                }

                if($ihConf['medium']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['medium']['suffix'])) {
                                $this->sizetype = 'medium';
                        }                       
                }               
               
                if($ihConf['small']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['small']['suffix'])) {
                                $this->sizetype = 'small';
                        }                       
                }
        }

---

And, I am not sure that the first of your two options would prevent the error because if you put :

Code:

---

if (zen_not_null($ihConf['large']['suffix']) && strstr($this->src, $ihConf['large']['suffix']))

---

The 'strstr' will still always get evaluated. And it is that which is causing the issues. That's why they are nested in my version.

Quote:

---

Originally Posted by niccol

:-)

Whatever. There is a typo in my code due copying and pasting but basically they will all work. Lots of ways of skinning a cat.

Code:

---

    function determine_image_sizetype() {
        global $ihConf;
       
        $this->sizetype = 'generic';

        if($ihConf['large']['suffix'] != '')
        {
            if (strstr($this->src, $ihConf['large']['suffix'])) {
                $this->sizetype = 'large';
            }           
        }

        if($ihConf['medium']['suffix'] != '')
        {
            if (strstr($this->src, $ihConf['medium']['suffix'])) {
                $this->sizetype = 'medium';
            }           
        }       
       
        if($ihConf['small']['suffix'] != '')
        {
            if (strstr($this->src, $ihConf['small']['suffix'])) {
                $this->sizetype = 'small';
            }           
        }
    }

---

And, I am not sure that the first of your two options would prevent the error because if you put :

Code:

---

if (zen_not_null($ihConf['large']['suffix']) && strstr($this->src, $ihConf['large']['suffix']))

---

The 'strstr' will still always get evaluated. And it is that which is causing the issues. That's why they are nested in my version.

---

This is ME looking confused..:wacko: (as usual) Soooooooooooooooooooooooooooooooooo mom & dad.... Which one do I choose.. (looks at mom... cause she's leaning towards her code..:laugh:)

Quote:

---

Originally Posted by niccol

:-)

Whatever. There is a typo in my code due copying and pasting but basically they will all work. Lots of ways of skinning a cat.

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                $this->sizetype = 'generic';

                if($ihConf['large']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['large']['suffix'])) {
                                $this->sizetype = 'large';
                        }                       
                }

                if($ihConf['medium']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['medium']['suffix'])) {
                                $this->sizetype = 'medium';
                        }                       
                }               
               
                if($ihConf['small']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['small']['suffix'])) {
                                $this->sizetype = 'small';
                        }                       
                }
        }

---

And, I am not sure that the first of your two options would prevent the error because if you put :

Code:

---

if (zen_not_null($ihConf['large']['suffix']) && strstr($this->src, $ihConf['large']['suffix']))

---

The 'strstr' will still always get evaluated. And it is that which is causing the issues. That's why they are nested in my version.

---

One of the things about php is that in an if statement that has ands, it processes from left to right. When a false is encountered it ditches out and doesn't process the remaining... I chose zen_not_null to stay in line with typical ZC code. If that is not provide a satisfactory result, then would use != '' instead. But it is my understanding that if a variable is provided to zen_not_null that if it is a string = '' it returns false, if it is NULL that is provided it returns false. Either of these two values are expected for nothing being in the configuration setting depending on the mysql setup of allowing thie constant to be null or ''.

Further, the above suggested change of all ifs being evaluated and not one stopping subsequent evaluation when an earlier is identified as being "the one" depends on none of the other variables being set when entering this function. Thus, if all large, medium and small are set, then the result of the series of ifs is that the image will always be identified as small....

I haven't dug back deeper in the code to identify if only one of those is set upon entry into this function, which if not mistaken was also true when either suggestion was made based on previous comment.

Well alrighty then... I'll wait for you two titans to battle it out.. :laugh: I'll implement any change that ya'll feel is the best.. 'cause this is SURELY over my head to address with anything more than some Bactine Attachment 14950
and a Attachment 14951BandAid

:laugh:

Further, looking into: includes/functions/extra_functions/functions_bmz_image_handler.php, the $ihConf variable is set without discrimination of the requested image size. Therefore all sub variables of $ihConf[size]['suffix'] are assigned, although small is not assigned a value as evidence in the review of the dimensions that is performed in the third elseif...

What the original code actually does is take one single filename.

It then checks to see if it contains "_LRG"
It then checks to see if it contains "_MED"
It then checks to see it it contains "_SML"

( or whatever the prefixes in use actually are )

That is what one might aim to reproduce. Any comment that all filenames will result in small being chosen is nonsense. Small can only be chosen if the filename contains "_SML" . And if the filename contains "_SML" then in zen style it is definitely a small image.

Let's not loose track of what the function actually does.

Quote:

---

Further, the above suggested change of all ifs being evaluated and not one stopping subsequent evaluation when an earlier is identified as being "the one" depends on none of the other variables being set when entering this function. Thus, if all large, medium and small are set, then the result of the series of ifs is that the image will always be identified as small....

---

That would be true if it was working against an image. But it isn't. It is checking an individual path ( actually an image source ) to determine whether that path is 'large', 'medium', 'small' or 'generic'.

Diva, use whatever you choose. I typed some code off the top of my head. I have no emotional involvement in it. As often happens on this forum people seem intent on making some kind of stand that seems completely unnecessary. Not enough time in the world for my code is better than your code nonsense.

Agree, no time for "pumping chests" not worth it. I never did such, concerned about the accuracy of intention of the code and consideration of final result.

As said initially, it appeared that all results would end up as small. The fact is/was that there is a separate check once it is identified as not being empty, so yes the code provided (typos corrected which wasn't even a consideration in review) would at least check against the actual filename (src).

If however, and I don't recall the naming requirements identified in the instructions, the large and medium both are identified to have the same suffix (don't know why someone would do that, but same thing for having no suffix) then under the current code, the large image would be the default to display, whereas in the first suggested code, the medium would be the result with the sequence provided. So if going with the first suggested code, to maintain the current "result" the medium check should be ahead of the large check.

That stated, there is no defined small suffix. So that check would not work and result in the image being identified as the default 'generic' and not as a 'small' (disabling functions available to small images such as the zoom on hover).

I too don't care which code is "chosen" as long as it maintains functionality and prevents at least the identified error from occurring. With whatever change(s) are made, downstream effects need to be reviewed.

Quote:

---

Originally Posted by niccol

What the original code actually does is take one single filename.

It then checks to see if it contains "_LRG"
It then checks to see if it contains "_MED"
It then checks to see it it contains "_SML"

( or whatever the prefixes in use actually are )

That is what one might aim to reproduce. Any comment that all filenames will result in small being chosen is nonsense. Small can only be chosen if the filename contains "_SML" . And if the filename contains "_SML" then in zen style it is definitely a small image.

Let's not loose track of what the function actually does.



That would be true if it was working against an image. But it isn't. It is checking an individual path ( actually an image source ) to determine whether that path is 'large', 'medium', 'small' or 'generic'.

Diva, use whatever you choose. I typed some code off the top of my head. I have no emotional involvement in it. As often happens on this forum people seem intent on making some kind of stand that seems completely unnecessary. Not enough time in the world for my code is better than your code nonsense.

---

I agree.. I was simply waiting for the dust to clear here a bit..

I'll implement and test the code you suggested (with the correction you later posted), and try the very scenario for which this is supposed to address along with all the other functionality to make sure there are no negative unforeseen impacts and let you know the result..

Niccol.. Thanks again.. I know this isn't your fav module:smile:, but honestly it was YOUR work that kept this thing standing when the v1.5.x Zen Cart release came along. I appreciate that you check in on us mere mortals here every now and then to make sure things are still okay..:smile: As you KNOW I am truly only a POWERUSER of this module..:hug:The sum total of my CODE contributions to the "under the hood" inner workings of Image Handler is pretty small. My BIGGEST contribution has been to produce (what I think have been) better user docs for this thing.. The rest of this machine is not my doing.. I'm just the keeper of the Castle here..:smile:

Good point about there not being a small suffix.

maybe we can agree on something like:

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                $this->sizetype = 'generic';

                if($ihConf['large']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['large']['suffix'])) {
                                $this->sizetype = 'large';
                        }                       
                }

                if($ihConf['medium']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['medium']['suffix'])) {
                                $this->sizetype = 'medium';
                        }                       
                }               
               

                if ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height'])))
                {
                        $this->sizetype = 'small';
                }                       

        }

---

Cool will try this out this weekend..

Yup, Diva, you know my thoughts about this module. And the slightly bizarre naming conventions in Zen that are a hangover from osCommerce. And you know that I choose not to use it on sites these days :-)

If someone chooses to have the same suffix for medium and large that will mess up Zen. That really isn't an IH issue. It's a zen issue because even without IH zen would not function correctly if someone does that.

To keep Zen useful and at least slightly competitive you also know that my thoughts are that IH, or something similar, needs to rolled into the core. And that the bizarre naming conventions need to be done away with because in the modern world they are just completely limiting.

And I am more than aware that that would be lovely for you to because looking after IH takes a huge amount of work which is appreciated by some but not all. So, I would not underestimate your contribution.

Quote:

---

Originally Posted by niccol

Yup, Diva, you know my thoughts about this module. And the slightly bizarre naming conventions in Zen that are a hangover from osCommerce. And you know that I choose not to use it on sites these days :-)

--------

To keep Zen useful and at least slightly competitive you also know that my thoughts are that IH, or something similar, needs to rolled into the core. And that the bizarre naming conventions need to be done away with because in the modern world they are just completely limiting.

---

Bizarre naming was done away with in the version that's in my Github repo.. Another outstanding Zenner provided the code that finally gave the image filenames some "normalcy".. Once I get your code snippet incorporated and tested, I'll finally submit it to the free downloads.. I know you don't like Image Handler, but you might want to check it out if for no other reason just to see that FINALLY the MD5 naming of images is gone gone gone!!

Quote:

---

Originally Posted by niccol

And I am more than aware that that would be lovely for you to because looking after IH takes a huge amount of work which is appreciated by some but not all. So, I would not underestimate your contribution.

---

Awww sweet of you to say.. :blush:

If the naming convention is considered of having the same medium and large suffix is itself considered a no-no, then would leave the first two ifs in their current sequence, though to maintain current system response (and still solve the original issue of recent) would suggest swapping them.

What about if a large image and the small images have the same dimensions? Would there be a negative effect of the "small" image sizetype being provided when the file has the suffix for a large image? If that would be a problem, I would suggest that the last if group be placed before the first.

Basically because this section is being revised from an if it matches one of these things it is assigned a size in first match sequence of large, medium, small or generic, to it's generic until proven otherwise by the last match, I would suggest that to maintain the existing behavior to invert the sequence of the three if statements.

Yup, quite right again. If a user has taken the time to create and upload small and large images that are exactly the same size and taken the time to rename them accordingly then it may well confuse the issue. But this hypothetical user is quite a confused individual anyway. And actually the way that $this-sizetype is used in the rest of the class, on first glance, it really doesn't matter. But for consistency let's change it.

Code:

---

        function determine_image_sizetype() {
                global $ihConf;
               
                $this->sizetype = 'generic';

                if ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height'])))
                {
                        $this->sizetype = 'small';
                }               


                if($ihConf['medium']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['medium']['suffix'])) {
                                $this->sizetype = 'medium';
                        }                       
                }               
               
                if($ihConf['large']['suffix'] != '')
                {
                        if (strstr($this->src, $ihConf['large']['suffix'])) {
                                $this->sizetype = 'large';
                        }                       
                }
       

        }

---

Image Handler Readme

Quote:

---

Make sure that your main product image files names DO NOT contain any special characters (non-alphanumeric characters such as / \ : ! @ # $ % ^ < > , [ ] { } & * ( ) + = ). Always use proper filenaming practices when naming your images

---

What if there are about 2000 images containing these forbidden characters? That were in place before image handler was used...

could str_replace be used to stop & symbols breaking IH?

from google_feeder

Quote:

---

PHP Warning: preg_match(): Compilation failed: missing ) at offset 69

---

or

Quote:

---

PHP Warning: preg_match(): Compilation failed: unmatched parentheses at offset 88

---

image_handler

Quote:

---

PHP Warning: preg_match(): Compilation failed: missing ) at offset 36

---

Files with Parentheses are also a problem (as stated in the readme). Is it not possible to look at the filename and str_replace it to something that won't break it?

oh and the & symbol causes this error in google_base

Quote:

---

PHP Warning: DOMDocument::createElement(): unterminated entity reference

---

Yes there is a way. I have a filter written for another Zen Cart module we could apply. But may be worth adding an alert / warning / block adding image from admin as well with characters not typically allowed in URLs being in the image filename.

Just had a look in my database.... of the 27148 images....

Quote:

---

2882 images have ( or ) in the file name
938 images have & in the file name
71 have [ or ] in the file name
4 have @ in the file name
5 have # in the file name
158 have + in the file name
4 have = in the file name
1 has $ in the file name

---

I can't solve this manually...

Quote:

---

Originally Posted by lhungil

Yes there is a way. I have a filter written for another Zen Cart module we could apply. But may be worth adding an alert / warning / block adding image from admin as well with characters not typically allowed in URLs being in the image filename.

---

:) please elaborate

Hi all, please help me. I need use chached images miniatur from image handler in my php script. Please is possible use some function, who return chached image name? How this function name?

Many thanks.

Quote:

---

Originally Posted by puhycz

Hi all, please help me. I need use chached images miniatur from image handler in my php script. Please is possible use some function, who return chached image name? How this function name?

Many thanks.

---

Sorry.. I am not clear on what it is you are asking here.. What is it you are trying to do EXACTLY???

I have product id and I need return url of image for this product. Not image name from database, but image name/url miniatur generated by IH.

I just had a weird thing come up. When clicking on anything in admin like upload new photo, it just refreshes the page and goes back to the admin tools bit. I believe it was okay before. I checked and all the files were in place and dated the same as when I uploaded the mod. I uploaded the files again to be sure. I have added a mod or two since this was installed in Sept but I can't think what could cause this behavior. Looks like the server php build is from last Aug so no changes there. Anybody heard of this happening before?

Quote:

---

Originally Posted by delia

I just had a weird thing come up. When clicking on anything in admin like upload new photo, it just refreshes the page and goes back to the admin tools bit. I believe it was okay before. I checked and all the files were in place and dated the same as when I uploaded the mod. I uploaded the files again to be sure. I have added a mod or two since this was installed in Sept but I can't think what could cause this behavior. Looks like the server php build is from last Aug so no changes there. Anybody heard of this happening before?

---

Nope not heard of this.. Would try rolling back your other mods and see if that rights things..

Quote:

---

Originally Posted by puhycz

Hi all, please help me. I need use chached images miniatur from image handler in my php script. Please is possible use some function, who return chached image name? How this function name?

Many thanks.

---

I'm sure it's possible, but unless you provide some details on what it is you are doing we would be guessing at the right answer..

That said have a look at the IH4 functions files (they are in the FUNCTIONS folders)..

well, someone reported that they might not have used it since the upgrade last September. I have no clue.

Quote:

---

Originally Posted by delia

well, someone reported that they might not have used it since the upgrade last September. I have no clue.

---

I think some modules remove the IH_VERSION key from your database when installed because they remove all values with configuration_group = 0. This could result in the symptoms you described.
if it is missing use something like the query below to add it again. Be sure to use the right version Value

Code:

---

INSERT INTO configuration (`configuration_id`, `configuration_title`,  `configuration_key`, `configuration_value`, `configuration_description`,  `configuration_group_id`, `sort_order`) VALUES (NULL, 'IH version',  'IH_VERSION', '4.3.2', 'IH Version is stored but not shown on  configuration menus', '0', '10000')

---