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

Three Sisters:

SOMEWHERE... Somewhere (and I obviously can't find it after much time searching) I read that you should install Image Handler after you install your template. However, I am in the process of giving my website a complete facelift. I may decide change templates as I play around with things.

Are there many affecting template files? Can I simply copy them to new template folder when/if I change templates? I'm assuming those IH_INSTALL folders denote what will become template folders after the installer has its way, but I would like verification before I plow ahead.

Thanks for your time!

If you take a breath and read the installation instructions you will basically see what it is you are searching. The instructions advise that when working with a template to merge the modifications made to support IH4 with those of the equivalent template file. Thus to do so means that the template must be there to which to merge the files.

Further, it is generally recommended to install the desired template as the "first" thing after installing ZC, so that such template modifying code and changes can be placed in sensible locations and not haphazardly operate. Blindly copying template files from one template directory to another may produce undesirable results.

Yes the IH_INSTALL folder in each applicable location relates to the override/modification that the installer is to address. I haven't dug into the 1.5.5 version of the installer, but at one point if the associated template override directory didn't exist then the install would not complete, so that is something with which to possibly have to deal.

mc12345678:

If you take a breath and read the installation instructions you will basically see what it is you are searching....

Further, it is generally recommended to install the desired template as the "first" thing after installing ZC, so that such template modifying code and changes can be placed in sensible locations and not haphazardly operate. Blindly copying template files from one template directory to another may produce undesirable results.

Thank you, very much, for your reply. Sincerely, I DID read and re-read the instructions. I had successfully installed a template and Image Handler. But then, I decided to scrap the template. Since I wasn't very far along, I decided to start all over again because I didn't know what direction to take the template issue in relationship to IH. I just needed the reasoning behind what I had remembered reading.

Actually, I think your second paragraph is the real crux of the issue at hand. Thanks for setting my thought process in order. :)

hi,
i will admit i am a little late to the image handler party. that said, since i have installed this add-on, i think it's awesome.

now to a small problem i have encountered and i am curious if any one else has this same issue. i am running v155 and IH v4.0 for v1.5.x. and frankly i'm not sure if its related to the image handler and the BMZ cache or part of the base ZC code, but i thought i would present it here. here is the situation:

• product 1 has an image associated with it called image1.jpg
• i now want to change the image for product 1. i have a new image file with the same name of image1.jpg
• i edit the product and select my new image file with the same name. it successfully gets uploaded to my site.
• image1_MED.jpg and image1_LRG.jpg do NOT get deleted. so now those image files remain for the old image.

i have now modified the code in /admin/includes/modules/product/update_product.php to delete those files.

	  if ($new_image == 'true') {
		  $src = DIR_FS_CATALOG . DIR_WS_IMAGES . zen_get_products_image((int)$products_id);
		  $filename_small = $src;
		  preg_match("/.*\/(.*)\.(\w*)$/", $src, $fname);
		  $products_image = zen_get_products_image((int)$products_id);
		  $products_image_extention = substr($products_image, strrpos($products_image, '.'));
		  $products_image_base = preg_replace('*' . $products_image_extention . '*', '', $products_image);

		  $filename_medium = DIR_FS_CATALOG . DIR_WS_IMAGES . 'medium/' . $products_image_base . IMAGE_SUFFIX_MEDIUM . '.' . $fname[2];
		  $filename_large = DIR_FS_CATALOG . DIR_WS_IMAGES . 'large/' . $products_image_base . IMAGE_SUFFIX_LARGE . '.' . $fname[2];
		  if (file_exists($filename_large)) {
			  unlink($filename_large);
		  }
		  if (file_exists($filename_medium)) {
			  unlink($filename_medium);
		  }
	  }

and frankly, i'm curious if someone else has experienced this problem; or if i did not install this plug-in correctly; or if by deleting those old files at this time, i am bypassing any of the benefits associated with this plugin.

thanks in advance!

That's the beauty of Image-Handler ... no more worrying about those _MED and _LRG images!

Image Handler places all of its "handled" images into the /bmz_cache folder. If you take a look at one of that folder's subdirectories, you'll see files named

[B]some_unique_string[/B].image.[B]width[/B]x[B]height[/B].jpg

The some_unique_string (for IH-4, anyway) is an MD5-hash of the file's name and some additional values to uniquely identify the base file. The **width **and **height **values in the file's name are the resultant image's width and height.

So, you'll see your images' small, medium and large images all grouped together and identified by the actual image's dimensions.

lat9,
based on what you are saying, this only comes into play for NEW images that are uploaded after IH was installed and with NEW names.

based on what you are saying i would need to delete the OLD images PRIOR to the upload, as opposed to after the base image gets uploaded.

listen, i see the beauty of IH. what i'm not sure you are seeing is that there is a definite bug here. which is either part of the base ZC or part of IH. when i upload a different image with the same file name, the old file remains. and IH does nothing to address that issue.

carlwhat:

lat9,
based on what you are saying, this only comes into play for NEW images that are uploaded after IH was installed and with NEW names.

based on what you are saying i would need to delete the OLD images PRIOR to the upload, as opposed to after the base image gets uploaded.

listen, i see the beauty of IH. what i'm not sure you are seeing is that there is a definite bug here. which is either part of the base ZC or part of IH. when i upload a different image with the same file name, the old file remains. and IH does nothing to address that issue.Not a bug - Its a feature...
The old way you need to upload a small, _MED and _LRG image
If you now upload a new (different) small image with the same name, you need to also upload a new image version of the _MED and _LRG
If you don't then the old versions still remain there.

Same with IH4
Upload a (now larger) new image and it will create new medium and large images ONLY if there are NO existing _MED and _LRG images already there.

They will NOT be auto deleted as its a feature so that you can "over-ride" IH4 with specific alternate images if required.

So..... to quickly see the new images rename the folders that contain the _MED and _LRG images.
This will force IH4 to create all size images itself.
When you are happy with this, then you can delete all existing _MED and _LRG images

gilby,
awesome. thanks for the explanation. much appreciated.

best.

There's also an option (not sure if it has been repaired yet or not) that is supposed to delete all of the "alternate" images and is selectable in the tools IH4 window. If it hasn't been corrected it is discussed/described in this thread about what it takes for it to work as "expected".

And how one could use the "image handle image" ?
If check the $GLOBALS...but I still haven't found out.
I'm still working on a lot of things at the same time for this shop with 155, and I've made a OG image link, but when sharing a image to FB I think I'm still getting the original image.
Thanks

I am testing ZC 1.5.5a for a future upgrade from 1.3.9h.
PHP 5.2.17 (have to use this version until I can upgrade from 1.3.9h)
MySQL 5.5.42
Test folder is: k - 9 d e s i g n s . c o m / t e m p 1 5 5 a/

I have the classic responsive template selected. I installed Image Handler from GitHub. This is a clean install on ZC and the only mods I have installed are SQL backup and Easy Populate v4. No core files were modified prior to Image Handler.

I am seeing strange category image overlapping behavior that differs in severity across IE, Firefox, and Chrome. It seems worse in chrome and seems to surface itself on a refresh of the page. The issue goes away if I uninstall Image Handler.

Symptoms and it various between browsers and if you refresh the page or not:

1. Pages that have more than two or three Categories overlap with the row above.
2. Pages that have any number of Categories overlap with the row above if the category has "Featured Products" being displayed. The "Featured Products" section will also overlap the categories. The "Featured Products" is also cutoff on the bottom.
3. If a product has Additional images, the images overlap each other

Has anyone experienced this type of behavior?

NOTE: Without Image Handler installed, when you refresh the page, the categories are temporarily overlapped (split second) and then it somehow adjusts itself and it looks normal. With Image Handler installed, the auto adjust behavior doesn't occur leaving the categories as overlapping. This is just an observation with and without IH installed.

Adding on to my previous post:

I also just noticed a problem when viewing the test site on mobile (IOS using Safari or Chrome):

When you click the menu button (three horizontal lines), the page shifts over to the right to open the menu, but it's completely blank (White) with no items to click on.

This problem does not present itself when Image Handler is uninstalled. The menu opens just fine with items to click on.

Any one experience these problems noted in both of my posts?

These issues appear to be related to the lack of merging the changes of IH4 with your existing template before "installing" IH4. Note: generally speaking the files in the IMAGE_HANDLER directory are modified based off of a vanilla ZC install. The equivalent template files for your store are also in some way modified off of a default install, but the two are likely to be modified in different ways. You need to merge the pieces/parts needed for IH4 to do its business with the template file(s) of your site so that on installation you don't end up with the issues that you are explaining. The merge "process" is described in the IH4 instructions.

mc12345678:

These issues appear to be related to the lack of merging the changes of IH4 with your existing template before "installing" IH4. Note: generally speaking the files in the IMAGE_HANDLER directory are modified based off of a vanilla ZC install. The equivalent template files for your store are also in some way modified off of a default install, but the two are likely to be modified in different ways. You need to merge the pieces/parts needed for IH4 to do its business with the template file(s) of your site so that on installation you don't end up with the issues that you are explaining. The merge "process" is described in the IH4 instructions.

Thanks for the reply. I followed the new installations instructions, but apparently I misunderstood something. I typically don't have a problem with this stuff, but maybe it's been awhile. The way I read step 7 was that if I had customized the files listed in the table, then I need to make file merges. I have not customized any of the listed files, so I didn't do any manual merges. I then thought the auto-installer would take care of the rest. I am re-reading the instructions and it still reads that way for me.

Crunch:

Thanks for the reply. I followed the new installations instructions, but apparently I misunderstood something. I typically don't have a problem with this stuff, but maybe it's been awhile. The way I read step 7 was that if I had customized the files listed in the table, then I need to make file merges. I have not customized any of the listed files, so I didn't do any manual merges. I then thought the auto-installer would take care of the rest. I am re-reading the instructions and it still reads that way for me.
By general process of working with the template override system, files generally should only exist in a template override folder if they are different (customized) than the default version of the file with the same name in the zc "core" area (template_default or each of the overrideable directories in the includes folder, etc.) so while you may not have written the code, the fact that such a file exists is a customization that has been "done" by you, by your direction (someone else), or by someone else before you were presented this store.

So, with that in mind, it would be advisable to merge the existing files with the IH4 so that when IH4 installs only the specific IH4 related code is "added" to your store.

Lastly, now that the above has been read. My apologies for using the word you so much. Was kind of to drive a point not to point fingers. :P

hi,
i have a site than is running:

Image Handler4 v4.0 for v1.5.x

the ZC version is 1.5.5 and the PHP Version is 5.6.19.

i have found a "problem", in that it seems IH chokes on a large file size and specifically in the function resize_imageGD. i have not tracked it down further as of yet.

the store owner uploaded a file that was 4.4 MB.

i have a few questions with regards to this situation. has anyone experienced this problem? is there any maximum file size? is it part of the server configuration or IH configuration? and finally, if it is a known issue, what do you think about adding some hooks for logging of this situation? ZC generated no logs, and i saw no apache error logs as well, which made tracking down the problem just a bit more time-consuming.

if someone has already posted about this situation and i missed it, i apologize in advance. and if anyone has any ideas about, i would appreciate it.

best.

There was a discussion started on page 143. I think was the same as your problem.> carlwhat:

hi,
i have a site than is running:

Image Handler4 v4.0 for v1.5.x

the ZC version is 1.5.5 and the PHP Version is 5.6.19.

i have found a "problem", in that it seems IH chokes on a large file size and specifically in the function resize_imageGD. i have not tracked it down further as of yet.

the store owner uploaded a file that was 4.4 MB.

i have a few questions with regards to this situation. has anyone experienced this problem? is there any maximum file size? is it part of the server configuration or IH configuration? and finally, if it is a known issue, what do you think about adding some hooks for logging of this situation? ZC generated no logs, and i saw no apache error logs as well, which made tracking down the problem just a bit more time-consuming.

if someone has already posted about this situation and i missed it, i apologize in advance. and if anyone has any ideas about, i would appreciate it.

best.

thanks for that. i have tracked it down to the function imagecreatefromjpeg. it should come back as false. but on my server, it just dies. i did finally get 1 error logged, with a memory size exhausted.

the problem is here, and considering the php function is just dying, i'm not sure how to even handle it:

	function load_imageGD($src_name) {
		// create an image of the given filetype
		$file_ext = substr($src_name, strrpos($src_name, '.'));
		switch (strtolower($file_ext)) {
			case '.gif':
			    if(!function_exists("imagecreatefromgif")) return false;
			    	$image = @imagecreatefromgif($src_name);
				break;
			case '.png':
			    if(!function_exists("imagecreatefrompng")) return false;
				$image = @imagecreatefrompng($src_name);
				break;
			case '.jpg':
			case '.jpeg':
			    if(!function_exists("imagecreatefromjpeg")) return false;
				$image = @imagecreatefromjpeg($src_name);
				break;
		}
		return $image;
	}

Did you also look at the server error logs?

i did. the apache error logs show nothing.... although i find apache error logs on shared servers to not be so reliable...

carlwhat:

i did. the apache error logs show nothing.... although i find apache error logs on shared servers to not be so reliable...
Yes, I have the same observation. Some errors will be logged to the root user (host) only. Probably the best solution for now is to tell the customer to use smaller image sizes , or a lower quality. Which won't make a difference for most end users, as they don't have a super high resolution screen.