Corrupted product database entry leads to blank product listings

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

[DivaVocals]

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

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

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

[DivaVocals]

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!!

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

[delia]

Agreed, Diva!

[lhungil]

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.

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

[DivaVocals]

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

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

[DivaVocals]

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