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

[philou]

Hi,

just spend a whole evening trying to figure out why IH4 wasn't scaling my uploaded images. It just kept the large uploaded JPG for all three sizes small, med, large.

Reason: In Admin -> Configuration -> Images I had set: Product Info - Image Large Suffix to "_LRG"

Since I am updating an older ZC Shop to 1.5.5 all large images we had created for products and now wanted to upload have the suffix "_LRG", i.e. Prod_image_LRG.jpg

Turns out IH will not scale these images down to medium or small. (Code is in function "determine_image_sizetype()" inside ZC/includes/classes/bmz_image_handler.class.php)

Not sure if this is a bug or a feature, but it surely would be worth mentioning in the Troubleshooting section of the manual.

Best regards,
P.

[carlwhat]

i think i have spoken about this before.... unfortunately my memory is not what it once was....

while certain uses of '@' to suppress error messages are possibly worth wild, the inordinate amount of them in this plugin makes it rather frustrating.

the bmz_image_handler.class.php file will suppress error messages and cause a script to fail. specifically the functions:

imagecreatefromgif
imagecreatefrompng
imagecreatefromjpeg

i'm not sure how many others have clients who do not know the difference between a jpg and a png; but mine don't and will use whatever extension they feel like. so now you have a script failing and no error messages.... kind of a pain....

in addition, there is a php function: exif_imagetype() which will determine the file type. now i know i could make some changes and submit a new version, but prior to doing that, i'm curious if other people have this same problem.

[carlwhat]

i think i have spoken about this before.... unfortunately my memory is not what it once was....

while certain uses of '@' to suppress error messages are possibly worth wild, the inordinate amount of them in this plugin makes it rather frustrating.

the bmz_image_handler.class.php file will suppress error messages and cause a script to fail. specifically the functions:

imagecreatefromgif
imagecreatefrompng
imagecreatefromjpeg

i'm not sure how many others have clients who do not know the difference between a jpg and a png; but mine don't and will use whatever extension they feel like. so now you have a script failing and no error messages.... kind of a pain....

in addition, there is a php function: exif_imagetype() which will determine the file type. now i know i could make some changes and submit a new version, but prior to doing that, i'm curious if other people have this same problem.

in the interest of others who might have this problem, this corrected code works for me. it eliminates some functionality, but it removes the troubleshooting when someone uploads an image with the wrong file type. i suppose one could correct the filetype, but i think that might be a bunch more work.

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

[carlwhat]

i'm a copy and paste disaster.... small change from above code.... my apologies!

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

[mc12345678]

i'm a copy and paste disaster.... small change from above code.... my apologies!

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

So now instead of an obvious display issue identifying that there is a problem with the image(s), an incorrectly loaded image will just not be resized and the store owner that doesn't/hasn't properly loaded the images to the site will be none-the-wiser until some other tool or resource identifies that the image(s) should be resized to optimize performance or there is some other effect on people selecting the site...

In other words, has anything really been solved? I bring this up also because other similar modifications have been discussed throughout this thread as well as in other threads, in fact if you look back at the history of the plugin errors have been uncommented before only to be again commented out like what has been "discouraging".

Generally though, the solution?! Follow the instructions...

Seems almost might be better to simply remove the plugin if it can not be used properly.

If, however, going to use code like above, I would recommend that the applicable image type constant be used to maximize compatibility and code understanding when comparing the image type against $image_type. Such as: IMAGETYPE_JPEG, IMAGETYPE_GIF, IMAGETYPE_PNG, etc. instead of just a number. Based on looking over a few other things it seems that if going to go to such extremes, then should also validate that the image is large enough to support evaluation with the applicable function so that won't throw another error that was just attempted to be prevented.

[carlwhat]

So now instead of an obvious display issue identifying that there is a problem with the image(s), an incorrectly loaded image will just not be resized and the store owner that doesn't/hasn't properly loaded the images to the site will be none-the-wiser until some other tool or resource identifies that the image(s) should be resized to optimize performance or there is some other effect on people selecting the site...

In other words, has anything really been solved? I bring this up also because other similar modifications have been discussed throughout this thread as well as in other threads, in fact if you look back at the history of the plugin errors have been uncommented before only to be again commented out like what has been "discouraging".

Generally though, the solution?! Follow the instructions...

Seems almost might be better to simply remove the plugin if it can not be used properly.

If, however, going to use code like above, I would recommend that the applicable image type constant be used to maximize compatibility and code understanding when comparing the image type against $image_type. Such as: IMAGETYPE_JPEG, IMAGETYPE_GIF, IMAGETYPE_PNG, etc. instead of just a number. Based on looking over a few other things it seems that if going to go to such extremes, then should also validate that the image is large enough to support evaluation with the applicable function so that won't throw another error that was just attempted to be prevented.

#1 a mostly blank page with NO error log generated is what the current code does. your "average joe" gets a blank page, posts on this forum, and the 1st question, most of us ask, "are there any debug logs?" no debug logs makes the task that much harder.
#2 i agree. follow the instructions. when you only have clients that follow instructions, life is so much easier.... please pass those clients my way....
#3 i disagree with regards to your remove the plugin comment.
#4 perhaps just remove the '@' from the above 3 referenced functions? the functionality remains the same and the system now generates debug logs.

[carlwhat]

If, however, going to use code like above, I would recommend that the applicable image type constant be used to maximize compatibility and code understanding when comparing the image type against $image_type. Such as: IMAGETYPE_JPEG, IMAGETYPE_GIF, IMAGETYPE_PNG, etc. instead of just a number. Based on looking over a few other things it seems that if going to go to such extremes, then should also validate that the image is large enough to support evaluation with the applicable function so that won't throw another error that was just attempted to be prevented.

i beg to differ that using a numeric value affects compatibility in any way. i agree that using the constant helps in readability.

given that, i think the following code addresses the problems i have encountered and is an improvement over the base code in this plugin. i have chosen to not do any of the size validations.

    function load_imageGD($src_name) {
        // create an image of the given filetype
        $file_ext = substr($src_name, strrpos($src_name, '.'));
        $image_type = exif_imagetype($src_name);
        switch ($image_type) {
            case 'IMAGETYPE_GIF':
                if(!function_exists("imagecreatefromgif")) return false;
                    $image = imagecreatefromgif($src_name);
                break;
            case 'IMAGETYPE_PNG':
                if(!function_exists("imagecreatefrompng")) return false;
                    $image = imagecreatefrompng($src_name);
                break;
            case 'IMAGETYPE_JPEG':
                if(!function_exists("imagecreatefromjpeg")) return false;
                    $image = imagecreatefromjpeg($src_name);
                break;
        }
        return $image; 

[HeathenMagic]

Hello there,

I know CDN is not supposed to be compatible with CDN, but our hosts suggested a way to enter some code in .htaccess to fetch images from the CDN urls. I know this is probably doubtful, but thought I would just throw it out there anyhow.

[mc12345678]

Hi,

just spend a whole evening trying to figure out why IH4 wasn't scaling my uploaded images. It just kept the large uploaded JPG for all three sizes small, med, large.

Reason: In Admin -> Configuration -> Images I had set: Product Info - Image Large Suffix to "_LRG"

Since I am updating an older ZC Shop to 1.5.5 all large images we had created for products and now wanted to upload have the suffix "_LRG", i.e. Prod_image_LRG.jpg

Turns out IH will not scale these images down to medium or small. (Code is in function "determine_image_sizetype()" inside ZC/includes/classes/bmz_image_handler.class.php)

Not sure if this is a bug or a feature, but it surely would be worth mentioning in the Troubleshooting section of the manual.

Best regards,
P.

Would say that its somewhat neither.

While unfortunately the resizing aspect of the plugin was not operating under this condition and one might think that it is an issue with the plugin, the instructions indicate that images should be named in accordance with ZC process. Seems that the need for this is pretty well covered in this FAQ which is one of the links referenced on the troubleshooting tab in the Zen Cart and Image Management section of the instructions.

While the documents don't come out and say: if the filename ends with or includes the same text as assigned to the image suffix that "this" will happen; however, it does indicate how to name images for various product and sizes. That link, and others in the plugin help file, identifies the need to use different naming for different purposes. Yes, it is understandable that in the older version where the large image (having _LRG as the suffix) would be the one desired to be uploaded in accordance with the instructions, but in order to maintain the same files with/without changing the filenames (maintaining the base name to include _LRG), additional action is necessary. Either the filename suffix would have to be modified or the files/base filenames would need to be renamed. Thing is that technically the database (upgraded from the previous version, correct?) should already have all of the image information for the main product image name, so it seems that it comes back to the filename(s) or the extension. The filename can be addressed through one of the file renaming utilities or the database can be modified to look for a large image that has a different "ending" than _LRG.

Both of those are generally discussed above, but in a somewhat search for similar helpfile additions, this particular condition/situation was explained as being obscure, or unlikely as discussed on and before a discussion about the very code section identified above. The small number of reported occurrences and likelihood of occurrence when following the established guidelines/instructions make modifications appear to be made just for the sake of making them rather than bringing things back to the proper path.