The paired imagedestroy() and invalid resource errors probably arise several ways, but one of them is from win/iis sending out "404.0" html files with jpgfilespec.jpg names, leaving Linux/Apache/php to conclude no, thank you, and to throw errors while keeping some of the fake .jpg files and recasting many of them as entirely hollow zero-byte .jpg files. "Oh, what a mess it was."
There were several problems on the table. I. Getting rid of them. II. Finding how they originated. III. Relating any of that to prior solutions which did not work or by happenstance worked or seemed to work. IV. Relating any of that to affected OC versions.
Preliminarily, since OC storefront activity activated the errors, every reasonable contributor to traffic spurts and the errors and bad images was shut off -- extensions for seo, Google, feeds, settings for both image downloads and uploads. The latter, done last, abruptly ended the errors. Errors resumed when the required product feed was allowed to resume and at its appointed hour ran, throwing (or causing to be thrown) the same error patterns while it ran. There was nothing else awake to contribute meanwhile.
I.-- Getting rid of them.
OC 1.5.3.1 threw imagedestroy() errors. In what had been stable 1.5.1.3, the hunt was on for why averages of 3 images of 9,050 bytes apiece and 27,657 bytes per product appeared among products as a mix of visible and useless /image/data/ original images which could not be made into thumbnails, while good /image/cache/data/ thumbnails already averaged about 3 per product.
With 6,544 products and 180,991,478 bytes in 19,998 /image/data/ original .jpg image files plus usually close to 997 (never quite 1,000) zero-byte .jpg files at a time, all coupled with the same triplets and occasional tetrads of image errors (but never quite 1:1 against corresponding logged errors) --
[systematically 3 lines of]
2013-09-18 5:49:01 - PHP Notice: in /[serverspec omitted]/image/data/31326.jpg on line 0
2013-09-18 5:49:01 - PHP Warning: imagejpeg(): supplied argument is not a valid Image resource in /[serverspec omitted]/system/library/image.php on line 45
2013-09-18 5:49:01 - PHP Warning: imagedestroy(): supplied argument is not a valid Image resource in /[serverspec omitted]/system/library/image.php on line 52
[sometimes, after brief delay, 4th line of]
2013-09-18 5:49:46 - PHP Warning: unlink(/[serverspec omitted]/system/cache/cache.product.1.0.8.2c09e2cbf63ed1848ceab2a48014bb5e.1379483383) [<a href='function.unlink'>function.unlink</a>]: No such file or directory in /[serverspec omitted]/system/library/cache.php on line 14
There were meanwhile 230,779,346 bytes of 19,998 good /image/cache/data/ thumbnails -- averaging about 3 images of 11,540 bytes apiece and 36,420 bytes per product.
The perhaps seemingly most practical way to be rid of the bad images is to download all of them, visually sort them by aid of thumbnail views, delete intermingled bad ones, then delete all of the image files on the server, and finally then send the remainder of good images back up. A quicker alternative is to use putty.exe to check each file for not having image format and delete the bad files. A still quicker alternative is executable Bad Peggy, allowing visual confirmation before deletion (http://download.cnet.com/Bad-Peggy/3000 ... 91203.html and https://github.com/coderslagoon/BadPeggy among others). Then an entire suite of images can be downloaded, culled almost instantly for non-image formats, deleted entirely from server (good and intermingled bad files), and then uploaded as a visually confirmed known good suite of image files.
Did the latter. Those opened (among thousands not opened) were harmless but annoyingly counterproductive html.
II.-- Finding their origin.
The culprit was a bona fide supplier's product feed, from a win/iis server. The feed was set up to fetch files that did not exist in paths specified pro forma. The win/iis response was its "404.0" html counterpart to the familiar Linux/Apache 404 html file. Unfortunately, win/iis SENT those with the unfound files' names but also the unfound files' .jpg extensions, to Linux/Apache/php as imagename.jpg rather than as imagename.html, and the mess was made.
Webserver source of image feeds: Microsoft-IIS/7.5
Fed BAD "images" of pure html: Microsoft-IIS/7.5 equivalent of Apache 404 document
Example: see image, not_jpg_but_iis_delivered_as_jpg_640x480.png. [Okay, so it attaches . . . so now the damned thing is in-line at bottom]
Not all instances of these errors will necessarily be thrown that way, but the occurrence seems quite entirely independent of OC version, occurring in 1.5.0.0 through in 1.5.5.1 it appears.
III.-- Prior solutions.
These links are scarcely exhaustive, just a sampler.
Generally, forum search yields "About 1,040 results (0.41 seconds)" at
"https://www.google.com/search?q=imagede ... encart.com
[finding link]
Early on Qphoria changed a quite wee bit of code in image.php and those changes persisted through ensuing versions.
2007, http://forum.opencart.com/viewtopic.php?f=4&t=121
0.6.3
in image.php deleted two lines, put one back, no answers; locked
2010, http://forum.opencart.com/viewtopic.php?f=19&t=11938
1.4 and 1.42, on daddy-o; FileZilla, php; .jpg and .png
suggested: images writable by server
2011, http://forum.opencart.com/viewtopic.php?f=19&t=43895
no version even after "WHAT VERSION?" asked
suggested: permissions on image and cache dirs, use FileZilla, replace files, FTP/Hoster
2012, http://forum.opencart.com/viewtopic.php?f=116&t=68678
no version, IE; feed, google base
suggested: turn off error reporting
2012,
1.4.9.4, also 1.5.1.2,
suggested: corrupted image. The GD library can't destroy images that are not really "images"
question back: so how do you know what image is a corrupted image? Was working fine until a few days ago.
2013, http://forum.opencart.com/viewtopic.php?f=20&t=106996
1.5.4.0, with also "Premature end of JPEG file"
suggested: php version
2013, http://forum.opencart.com/viewtopic.php ... 2&p=395425
no version, mysql error, plus the image errors each 30 seconds
suggested: image likely doesn't exist, possibly because the image name can't be retrieved from the database as a result of the mysql error; traffic is causing the mysql error
separate entry: cannot handle BMG image files [until] File was converted to jpg
2013, http://forum.opencart.com/viewtopic.php ... 4&p=417537
no version, images corrupted
suggested: php resizing (link to outside)
2013, http://forum.opencart.com/viewtopic.php ... 07#p431090
no version, missing button with destroy message
suggested: flush caches
2013, http://forum.opencart.com/viewtopic.php ... 0&p=392535
1.5.5.1, errors
suggested: nothing, no responses
IV.-- Affected OC versions.
The foregoing behaviors seem known for 0.6.3 through 1.5.5.1, and evidently often have nothing to do with OC version. The severity may owe to versions of php.exe, but the span of those concurrent with the span of OC versions suggests not. Some instances involve concurrent errors some of which may not be entirely independent of OC or its server. At least one cause of the errors is win/iis doing what Linux/Apache/php simply cannot do, and sending the mess to Linux/Apache/php, whereupon OC and its servers of residence have seemed at fault. Isn't it nice, when Linux/Apache/php/OC are not responsible?
Who is online
Users browsing this forum: No registered users and 92 guests
