Corrupted product database entry leads to blank product listings

Was reading this thread yesterday and it reminded me of a post I made to the IH4 forum. I haven't gone back to look at the instructions for relation, but was wondering if the "direction" of this thread would lead to a resolution to the problem identified below?

mc12345678:

Running Version 1.5 of ZenCart, have only Image Handler V4 installed for photo maintenance with GD FreeType Version 2.3.7 (GD Version bundled (2.0.34 compatible)). Probably need to upgrade to the most recent sub-version; however, haven't seen in the documentation anything that indicates a potential upper limit on image dimensions. Others have commented either in this version or previous versions about how they have had to resize the image before presenting to IH4. I typically will ensure that the largest dimension of an image is 1280 pixels. Though some have been larger without issue, this seems to be about where the image can be displayed even in the small perspective. Otherwise, pages will not display that include the image (at any size) which is problematic also in the admin section.

Is this something that IH4 can not handle, is it related to GD, is it a combination of the two? When such an image is uploaded and causes problems, then if I disable IH4, I can go back and address the image (remove, replace, etc...); however, I can't seem to remember having seen anything documenting the upper limits of an image.

Some aspects of the site have since been upgraded; however, effectively what was happening at the time was that after upload of the image to the admin page, any attempt to view the image (ie., attempt within IH4 to select the product for editing/viewing) would result in a blank page. I don't recall seeing any error logs, but to get back to where I could work with the picture/product I had to go and modify/remove the image from the server (or modify the image path within phpmyadmin) in order to access the page that contained an image for that product. I thought that the above discussion was going to target ImageMagik, but it was discovered using GD as documented above and am not sure if what I was seeing is what has been described in this thread... I don't think that the images were originally as large as 5000x5000, but I had found anything greater than about 1280x1280 would cause the problem...

Just wonderin'

yep, there it is. I found a smaller size limit and it obviously due to the server issues as discussed in this thread.

mc12345678:

Was reading this thread yesterday and it reminded me of a post I made to the IH4 forum. I haven't gone back to look at the instructions for relation, but was wondering if the "direction" of this thread would lead to a resolution to the problem identified below?

Some aspects of the site have since been upgraded; however, effectively what was happening at the time was that after upload of the image to the admin page, any attempt to view the image (ie., attempt within IH4 to select the product for editing/viewing) would result in a blank page. I don't recall seeing any error logs, but to get back to where I could work with the picture/product I had to go and modify/remove the image from the server (or modify the image path within phpmyadmin) in order to access the page that contained an image for that product. I thought that the above discussion was going to target ImageMagik, but it was discovered using GD as documented above and am not sure if what I was seeing is what has been described in this thread... I don't think that the images were originally as large as 5000x5000, but I had found anything greater than about 1280x1280 would cause the problem...

Just wonderin'

Upload large image.. get blank page.. yep.. that's what we are discussing.. Posted a summation on what we all believe is the solution a post or two back..

Not clear on what the question is here..

delia:

yep, there it is. I found a smaller size limit and it obviously due to the server issues as discussed in this thread.

Thanks for the confirmation Delia!!:smile:

So having had a minute having the changes suggested a few posts back by lhungil "ON" for a bit, I think I have some insight as to why Tim disabled GD error messages to begin with.. GD is CHATTY AS HE** on a site with LOTS of images!!!:laugh: GD it turns out is pretty picky and will throw an error for a LOT of things!!! Many errors are ones the average site owner won't be aware of since GD will process the image and IH4 will serve it up..

Thanks to lat9s error logging and error backtrace tools though, I can now see these error logs from the comfort of my shop's admin.. (no more searching the "logs" folder via FTP)

Here's some of the errors I've gotten:
PHP Warning: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error:
PHP Warning: imagecreatefromjpeg(): '/home/divaweb/subdomain/public_html/clientscrappin/images/Best Creation/TD003.jpg' is not a valid JPEG file

So here's some interesting "stuff" I've discovered, and it seems to support the general theory being floated in this thread that the cause of the initially reported issue is an out of memory state caused by GD being unable to finish processing image files over a certain size.

One other potential problem you may run into is to do with memory. It seems that GD holds all images in memory as bitmaps once they've been opened. This means that a 5MB image can actually consume more memory than a single PHP thread is allowed, resulting in a fatal error. I had this problem with some image uploads and had to reduce the maximum file size I allowed to get around the problem.
Fatal error=blank product info page. Considering that IH4 processes images on the fly, this makes sense.. A page load would trigger the image processing (if the image had not already been processed and stored in the bmz_cache).

If you get this error: "Warning: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error" then check the JPEG files. If they are saved in CMYK format (instead of RGB) then GD will fail to load them (tested with GD 2.0.12)". Finally, there were comments about images shot with certain cameras which wrote extra information into the JPEG headers causing problems.
[2006-12-21 09:23 UTC] [email protected]
The messages already says it: Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: 'C:\ModelMayhem\Source/userphotos/8_48_R.JPG' is not a valid JPEG file [2006-12-21 09:26 UTC] hnthanhphong at yahoo dot com
But I open this file in photoshop. It works no problem.
[2006-12-21 09:43 UTC] [email protected]
Photoshop also "repairs" broken JPEGs, PHP does not do that, and will never do that. I bet if you re-save it in Photoshop PHP can read it as well.
[2006-12-21 09:49 UTC] hnthanhphong at yahoo dot com
I re-saved in Photoshop, and post again it works property. Thank you very much.
[2006-12-21 12:12 UTC] [email protected]
GD does provide a mechanism to be more tolerant with broken jpeg images. Using error_reporting(E_ALL); while developing would have told you what's going on. GD did report some errors in the jpeg codec. Some of the jpeg errors are recoverable, like those in this image. You can change the behaviors of the jpeg codec using gd.jpeg_ignore_warning: ini_set("gd.jpeg_ignore_warning", 1); $im = imagecreatefromjpeg("test.jpeg"); $im contains now your image.
I downloaded the images which were being called out in the error logs (thanks to lat9s backtrace tool). They all looked fine in GIMP (my photo editor) so I simply resaved them all again.. Gonna see if that stops this error.. If it does I'll assume that there was some kind of file malformation that GD was screaming about..

you may want to use imagecreatetruecolor() instead of imagecreate() it will look better
Wondering if any of the learned folks here know how much truth there is to this assertion..

Okay.. now that I've had to go through the exercise of cleaning up some of my client's corrupted images, I am no longer seeing ANY GD errors :smartalec:.. Along the way in completing this exercise, I have come to a few conclusions..

• Tim Kroeger's original decision to suppress the GD error and warning messages was probably ultimately the RIGHT decision for a NORMAL IH4 install/setup..
• The "fix" for the error messages I was getting was to simply re-save and re-upload the images in question. However, because these were WARNINGS and not hard ERRORs, I confirmed that GD did in fact process the images. So therefore they were in the bmz_cache as I would expect.
• I did find that the GD warning messages were VERY chatty before "fixing" the offending files.. Every page load that included the offending images could trigger the error. So therefore I will be re-enabling the suppression of the GD error and warning messages before submitting the latest IH4 version to the Zen Cart modules repo.
• In addition to other enhancements discussed here in this thread to address the memory errors from large image uploads, another potential future enhancement to IH4 probably should be some additional admin settings and conditional statements added to the core code to turn on/off the GD error and warning messages for troubleshooting purposes should someone need it..
• Turning on/off GD error and warning messages will REQUIRE the installation of lat9's backtrace, and error log from the admin modules. This will make it easy for novice shopowners to see their error messages without needing to use an FTP tool or the cPanel File Manager to access the store's logs folder. More advanced users may not NEED to install these modules (though they are NICE), but I would suggest that even advanced users will want to AT LEAST install the backtrace module. the backtrace module will be needed to see FULLY the source of any GD error and warning messages. (this may NOT be apparent without the backtrace module as some of the GD error and warning messages are not terribly "explanatory")

It may be worth using an error handler to catch the warnings. Then you could possibly log (or ignore) based on settings... And leave off the @ suppression so fatal errors are logged...

lhungil:

It may be worth using an error handler to catch the warnings. Then you could possibly log (or ignore) based on settings... And leave off the @ suppression so fatal errors are logged...

I agree.. That's the RIGHT/BETTER way to do this..

Well that's gonna have to happen in a future release and it will have to be another contributor who adds this functionality because it is DEFINITELY over my head to add that..:laugh: (along with the OTHER changes discussed in this thread)

In the meantime, I'm putting the error suppressing @ signs back, and see if adding an admin option to choose the ImageMagik library is an EASY fix for me to make, so I can get the Zen Cart v1.5.4 compatible release submitted..

Sounds like a plan, look forward to playing with the new version in the future!

lhungil:

Sounds like a plan, look forward to playing with the new version in the future!

Ha!! I hope to be looking forward to an IH future with YOU KNEE DEEP into the innerts.. :laugh:

And believe it or not - I've run into a site that has to have really large versions of images. So there truly is a situation where a site owner might rely on really really big images. I will not explain here - just take my word for it!

So I have to figure out a work around. Did anyone actually try imageMagick to see if that overcame the problems? I've asked server guy to install it but he's not been able to figure it out yet.

Did anyone every figure out if a php setting can be changed to accommodate the larger images with GD? This is a dedicated server so settings can be changed.

@delia, which version of Zen Cart provides the base for the "large image" store you mentioned?

1.5.4

We got imageMagick installed on my server and I uploaded one of the really large photos and it seems to be working. Now waiting for the other guy to get it installed on that server to be sure.