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

[mc12345678]

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.

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

[Design75]

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

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.

[carlwhat]

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;
	}

[Design75]

Did you also look at the server error logs?

[carlwhat]

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

[Design75]

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.

[lat9]

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

As a suggestion, it's better to identify a post number instead of a page number since the number of posts/page is configurable based on your personal Zen Cart settings.

[Design75]

You are absolutely right. I totally forgot that was possible.

[marton_1]

Hello
Super piece of addon software.

Just to be sure I understood what I have read :)
The standard zen cart product listing image is set at _MED.
This medium size image is not part of the standard IH4 zoom, if I want to zoom here I have to add a patch which is not seen as an ideal step?