Printable View
Diva, old friend, (yes, I am still alive!) I have a question that may not have been addressed before. Is there some way to change where the bmz_cache is kept? The cart would be in a subfolder with the bmz_cache folder in the root. I suspect I would be the only person to ever ask this as it is a special situation. I tried to find in the files where that folder designation is made but a find in dreamweaver did not work.
Have installed on a ZC 1.5.5b site with no issues, able to navigate the product pages without loss of the image(s). There are a few other things seen that could cause a problem or be caused to have a problem, but if you are further interested in it working on your site as provided then would need to know more information about your configuration and system history (ie, posting tips information).Quote:
Originally Posted by schoolboy
Search in github identifies that after installation will want to touch/work with the definition as provided in: includes/extra_configures/bmz_io_conf.php at or around line 19. The installer (YOUR_ADMIN/includes/init_includes/init_image_handler.php) also has a reference to the bmz_cache directory so that it copies information to the correct location.Quote:
Originally Posted by delia
We have a few sites on a virtual server, so all using the same versions and configutrations of apache, php etc. Hosting is with TerraNetwork, who not only know what they are doing technically, but have a wealth of knowledge on zencart and ecommerce in general. Terra was owned by Rhea Anthony (ZC user "Vger") who was one of the founders of OsCommerce - she sadly passed away a few years ago, but the current owners and tech team are superb. So the hosting environment is properly configured to run ZC and the majority of its (properly built) plugins.Quote:
Originally Posted by mc12345678
We have been using IH for many years and on almost all the websites we've built or owned - over 300 to date - and it has never been a problem. With the latest site, we're using one of picaflor's templates (westminster_new) and this has (built-in) zen lightbox and fual slimbox. I don't like either of these systems and have never installed them on our sites (though I have tinkered with them on dev sites). With installation of IH over Lightbox, there are some requirements to pay attention to code structures in certain files. I did a full Beyond-Compare analysis of all files and code differences, but could find very little difference that would affect behaviour, or cause conflict. According to IH installation instructions, these modules should play nicely together...
But for some reason, it's not playing nicely on this westminster_new template and ZC 1.5.5b .
Im busy getting the dev site completed with all the plugins we need (with the exception of IH right now) and because I am in a hurry to make it live, we will launch the site without IH. Then I can mess around with the dev copy to see what I can find.
If at that stage I come to a dead end, I'll come back here for more pointers and advice, but thanks a ton for showing interest in helping. I really appreciate what you contribute to this forum.
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.
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.
Would say that its somewhat neither.Quote:
Originally Posted by philou
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.
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.Quote:
Originally Posted by carlwhat
Code: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;
}
i'm a copy and paste disaster.... small change from above code.... my apologies!
Code: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...Quote:
Originally Posted by carlwhat
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.