Corrupted product database entry leads to blank product listings

That is a very good question. I've seen this regularly but never gotten that question answered. No error messages. I think the top image size is about 800kb. This only started with Image Handler 4. Of course any images that large are usually too large anyway so it's the kind of thing that usually crops up when some cart owner has been uploading unoptimized and really large images and then gets upgraded or installs ImageHandler 4.

Does IH contain specific calls to error_reporting() such as error_reporting(0) which tells it to report no errors from that point onward in the code? If so, then that could be what's stopping it from logging any memory errors. Or maybe it's just got logic in it to abort without warning when it encounters images it can't handle, and that might be an area the plugin could improve on.

I've never dug into it. Don't see anything right off hand. It's definitely not a php error when this happens. I think I posted about this on that thread to no avail.

delia:

face - eggy.

image handler and too large images - why I didn't go there first I don't know. But this was not what I thought it was.

Makes for a great thread though!!!

Thanks everyone for flogging this horse!

Too big meaning WHAT??? (specifics please..) I don't remember ANYTHING being posted on the IH4 thread about large images causing blank product pages.. ever.. Can you point out your post on this??

DrByte:

Does IH contain specific calls to error_reporting() such as error_reporting(0) which tells it to report no errors from that point onward in the code?
Just searched the IH4 code, and the answer here is no..

I did not find where I posted it as a problem but have answered posts about it - http://www.zen-cart.com/showthread.php?194740-Image-Handler-4-%28for-v1-5-x%29-Support-Thread&p=1137157#post1137157

It did start in version 4. That is for sure - and evidenced by the upgrade I just did which included 3 to 4. Since I found no information about it, I assumed then and still assume, most folks don't run into this issue because they don't try to use 1 meg images!

I don't see that it is necessary to change the mod to accommodate these really large images. But I guess it should be noted somewhere that such large images could cause problems. (and branded on my forehead so that I don't drive me and anyone else crazy looking for answers)

delia:

I did not find where I posted it as a problem but have answered posts about it - http://www.zen-cart.com/showthread.php?194740-Image-Handler-4-%28for-v1-5-x%29-Support-Thread&p=1137157#post1137157

It did start in version 4. That is for sure - and evidenced by the upgrade I just did which included 3 to 4. Since I found no information about it, I assumed then and still assume, most folks don't run into this issue because they don't try to use 1 meg images!

I don't see that it is necessary to change the mod to accommodate these really large images. But I guess it should be noted somewhere that such large images could cause problems. (and branded on my forehead so that I don't drive me and anyone else crazy looking for answers)
Thanks for the info..:smile: That post was from two years ago.. I don't see this issue posted often so yeah it's not unlikely that I forgot..:laugh:

I suspect this is probably less of an issue with IH4 and possibly in issue because PHP GD - which IH4 relies on for re-sizing/optimizing images - is choking when processing these large images.. I wonder if this is due to memory size limit of the server's PHP processes..

IMHO it's a poor practice to upload such large images anyway. Perhaps a future enhancement to IH4 could include a method to somehow trap for these extremely large image uploads before they are processed, stop them from being processed, and then display an error message indicating the issue..

:laugh: Alas all of this is over my head to execute, but in the upcoming IH4 release (which simply updates the way the images in the IH4 cache are named so they use REAL file names vs the MD5 hash names they have always used..), I will make a double check to make sure that the readme does make a note of this.. (thought it did.. perhaps a more strongly worded message is necessary) Perhaps a note of this on the interface screen as well is in order as a stop-gap measure..

DivaVocals:

Thanks for the info..:smile: That post was from two years ago.. I don't see this issue posted often so yeah it's not unlikely that I forgot..:laugh:

I suspect this is probably less of an issue with IH4 and possibly in issue because PHP GD - which IH4 relies on for re-sizing/optimizing images - is choking when processing these large images.. I wonder if this is due to memory size limit of the server's PHP processes..

IMHO it's a poor practice to upload such large images anyway. Perhaps a future enhancement to IH4 could include a method to somehow trap for these extremely large image uploads before they are processed, stop them from being processed, and then display an error message indicating the issue..

:laugh: Alas all of this is over my head to execute, but in the upcoming IH4 release (which simply updates the way the images in the IH4 cache are named so they use REAL file names vs the MD5 hash names they have always used..), I will make a double check to make sure that the readme does make a note of this.. (thought it did.. perhaps a more strongly worded message is necessary) Perhaps a note of this on the interface screen as well is in order as a stop-gap measure..

Yeah, really poor practice. So many of my customers already have sites so I do a lot of cleanup and training clients. This is more common than one would think.

And over my head completely. I have never used my brain to figure out why this is happening. Though since I have two servers of my own, it is something we could test out to see if we can overcome it server-wise. (I have may have servers but I'm not a server guru!). Something tells me that we may need a server guru to help!

But it doesn't happen with imagehandler 3 remember.

delia:

But it doesn't happen with imagehandler 3 remember.

Right.. dunno ** shrug**:smile:

I've done some quick research and I believe that the issue is due to some kind of processing limit coming from the GD library.. Over my head to address:laugh:.. I will add the appropriate text to readme and admin screens..

hmm, now thinking along the lines of limiting size of product images. Of course some folks actually ftp these images up as well but does zen cart distinguish image size from file size (such as product downloads)? I never even wondered about it before but it sure would be nice if it were separated in the code. The server views them as files only and the upload settings on the server can control that but not useful when you have things like videos as downloads.

But is it GD limit or is the php memory_limit also a factor?

delia:

hmm, now thinking along the lines of limiting size of product images. Of course some folks actually ftp these images up as well but does zen cart distinguish image size from file size (such as product downloads)? I never even wondered about it before but it sure would be nice if it were separated in the code. The server views them as files only and the upload settings on the server can control that but not useful when you have things like videos as downloads.

But is it GD limit or is the php memory_limit also a factor?

Don't know.. Would need some error trapping to test the exact cause.. Again this is over my head to execute.. I suspect if you look at your server logs though you might find some hints there..

It seems logical that since the GD Libary is processing the images it's most likely that this processing failing is the cause of the issue.. One way for sure to know if the GD processing is failing is to see if there are re-sized images at all.. You can't do that easily using the current IH4 with the MD5 re-named images, but the beta version in testing on Github uses friendly image names. You could see very quickly if larger images are even being processes by looking for the cached images..

Definitely complicated. Stretching my brain in that direction is not my choice of tasks for today. Hopefully though, this discussion will help others and serve as resource when someone else runs into the problem. Thanks!

FWIW Events Calendar v4 has image resizing built into code, at upload of image and upon selecting an image to use in mod. The person that provided this code, Rus Lacamus, was a absolute gem.

delia:

Definitely complicated. Stretching my brain in that direction is not my choice of tasks for today. Hopefully though, this discussion will help others and serve as resource when someone else runs into the problem. Thanks!
Agreed!!

dw08gm:

FWIW Events Calendar v4 has image resizing built into code, at upload of image and upon selecting an image to use in mod. The person that provided this code, Rus Lacamus, was a absolute gem.

Right..

Well if Rus wants to jump in and contribute to the IH4 dev then I welcome his contribution.. In the meantime a decent solution that** I can **execute in the meantime is to warn folks NOT to upload GINORMOUS product and category images to begin with.. I think that whatever the long term solution is, that it should most likely include a method to reject the upload of those overly large images to begin with.. IH4 does not touch the original image. This is to support IH4 regenerating it's cache if you clear it. I personally think that storing images this large is a poor practice especially for stores operating on a shared hosting environment..

Agreed, Diva!

DivaVocals:

Don't know.. Would need some error trapping to test the exact cause.. Again this is over my head to execute.. I suspect if you look at your server logs though you might find some hints there...
I see calls to @imagecreatetruecolor, @imagecreate, and @imagecopyresampled in IH4. The @ will suppress error message including any PHP "Out of Memory" errors. I'm going to "guess" this is the issue, as those functions usually create an uncompressed image (which could be quite large at higher resolutions).

If after removing the "@" from those calls you see PHP "Out of Memory" errors, you may want to check what is configured in IH4 for max dimensions on the generated "large" images.

Diva, if you'll do that, I can use my client's website to test. We still have the larger images in a directory separate from the live site.

lhungil:

I see calls to @imagecreatetruecolor, @imagecreate, and @imagecopyresampled in IH4. The @ will suppress error message including any PHP "Out of Memory" errors. I'm going to "guess" this is the issue, as those functions usually create an uncompressed image (which could be quite large at higher resolutions).

If after removing the "@" from those calls you see PHP "Out of Memory" errors, you may want to check what is configured in IH4 for max dimensions on the generated "large" images. Thanks for this.. a place to start.. :smile:

delia:

Diva, if you'll do that, I can use my client's website to test. We still have the larger images in a directory separate from the live site.

I assume by "do that" you mean make the changes that lhungil suggested..:laugh: I made the updates to the beta IH4 in my Github repo.. https://github.com/DivaVocals/zen_Image-Handler

Note: The version on Github includes balhir's update to use REAL file names for the cached images versus the ugly MD5 hash names IH has used since inception..

Got distracted, and didn't commit the changes.. Github repo is updated now..