Dirty Butter Posted October 7, 2013 Share Posted October 7, 2013 Minor issue, but persistent: PHP Notice: GD::gdLoadFile - Unknown file type in /XXXXX/public_html/plushcatalog/classes/gd.class.php on line 75 I've read elsewhere when this error was discussed that it means a file in the image folder is either corrupt or has the format of an image file, but is not an image. Is there a way to find that image? We have about 4k images. Also, I've noticed that not all our images in source have the same permissions. What should they be and is there any way to change permissions in bulk? Would the wrong permission trigger this error? I have not noticed any listing that does not show an image, but it's certainly possible, with over 3k product listings. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 The function gdLoadFile is given the name of a file. It does exist, but the type cannot be determined. In the file /classes/gd.class.php, near line 75, change the statement to read: trigger_error(__METHOD__.' - Unknown file type:' . $file . ': ' . implode(',',$this->_gdImageData)); Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 Now getting this error message: [07-Oct-2013 13:35:23 America/Chicago] PHP Warning: implode() [<a href='http://docs.php.net/manual/en/function.implode.php'>function.implode.php</a>]: Invalid arguments passed in /XXXXXX/public_html/plushcatalog/classes/gd.class.php on line 77 [07-Oct-2013 13:35:23 America/Chicago] PHP Notice: GD::gdLoadFile - Unknown file type:/XXXXXX/public_html/plushcatalog/images/source/index.php: in /XXXXXXX/public_html/plushcatalog/classes/gd.class.php on line 77 Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 Very interesting. We will have to figure out what is calling gdLoadFile and processing the index.php file. A definite bug. (I was expecting the implode() error.) Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 While you work on this, and all your other endeavors - what should the file permission for the images be? Can permissions be changed in bulk from cpanel? Sure hope so. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 Meant to say - I was refreshing the General tab on a Product Listing to get this error. I do have a valid image on that product. Cache is disabled. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 "What should the file permission for the images be?" I would trust CubeCart to properly set the permissions when the image is uploaded. Otherwise (not being an expert on this), I would say 444. "Can permissions be changed in bulk from cpanel?" I really do not know. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 Please examine your CC_filemanager table and look for a filename called index.php. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 There is an index.php file in the Source folder. Do I need to delete it? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 There is an index.php file in the Source folder. Do I need to delete it? In CC523, that was put there for a reason -- of which I cannot determine. I'm looking at the ReBuild(Something) function that may be catching that new file. I need to know if you found index.php in the CC_filemanager database table. Now I want you to try this: trigger_error(__METHOD__.' - Unknown file type:' . $file . ': ' . print_r(debug_backtrace(),true)); Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 index.php IS in the filemanager database table. Here's the result of going to the General Information tab for a Product Listing: [07-Oct-2013 14:57:29 America/Chicago] PHP Notice: GD::gdLoadFile - Unknown file type:/xxxx/public_html/plushcatalog/images/source/index.php: Array ( [0] => Array ( [file] => /xxxx/public_html/plushcatalog/classes/catalogue.class.php [line] => 851 [function] => gdLoadFile [class] => GD [object] => GD Object ( [_gdImageMax:GD:private] => 300 [_gdThumbMax:GD:private] => [_gdJpegQuality:GD:private] => 100 [_gdTargetDir:GD:private] => /xxxx/public_html/plushcatalog/images/cache/ [_gdImageData:GD:private] => [_gdImageExif:GD:private] => [_gdImageType:GD:private] => [_gdImageSource:GD:private] => [_gdImageOutput:GD:private] => [_gdWatermark:GD:private] => [_gdUploaded:GD:private] => ) [type] => -> in /XXX/public_html/plushcatalog/classes/gd.class.php on line 77 Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 Ok, well.... Take note of the file_id(s) for all records that are index.php for the filename. Take note of the image filenames just one above and one below. Do these other filenames pertain to a recently added or edited product (since upgrading to CC523)? Then delete the index.php records. Next, with the list of file_id numbers, look in CC_image_index, find any records with those numbers as the file_id and delete them. It's odd that debug_backtrace() only gave us one "stack frame". Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 I have NOT added any photos since upgrading to 5.2.3. I've seen this error message for some time - really don't know when it started. I remember trying to track it down while on 5.2.2, but can't be sure it wasn't already there earlier. I was having trouble following your directions about finding the index.php id number and deleting the images on either side, and accidentally discovered one "photo" has this mimetype - application/octet-stream That HAS to be the issue, but I don't want to delete it until you tell me to. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 I won't go into tracking down that, just yet. But it is most certainly the index.php file in the filemanager. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 "deleting the images on either side" That's not what I meant. 10. Find a record in the CC_filemanager table that has index.php as the filename. Note it's file_id number. Delete that record. 20. Find a record in the CC_image_index table that matches the file_id noted earlier. Delete that record. Goto 20 until finished. Then Goto 10. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 The file id of my index,php is not new at all. It's 2129. The last id number is 2984, so the index.php file has been there for a long time. So you want me to delete any and all id records that show up as 2129? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 So you want me to delete any and all id records that show up as 2129? 2129 in the file_id column of CC_image_index, yes. But note the product_id first. As well as deleting 2129 in CC_filemanager. The fact that there is index.php in the /images/source/ folder is strange. I'm not finding it in any of my CC5 packages. What is it's date/time? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 Do you find the same situation in both stores? Or only the store that was upgraded from CC4? In CC4, the /images/uploads/ folder (renamed to source in the upgrade to CC5 process) has an index.php file in it. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 That certainly seems to have fixed it! Should I get rid of that one image with the wrong mimetype? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 7, 2013 Share Posted October 7, 2013 No. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 7, 2013 Author Share Posted October 7, 2013 I'll test the other store later, but I'm out of time to work on this right now. Thank you for your tireless help, Bsmither!!! Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 8, 2013 Author Share Posted October 8, 2013 The estates store was a clean v5.0 install originally and does NOT have an index.php file in the filemanager table. However, with a new upgrade to 5.2.4 - without having added any of my edits yet - I do get this error message again: PHP Warning: Invalid argument supplied for foreach() in /XXXX/public_html/dirtybutterestates.com/admin/sources/products.index.inc.php on line 348 referring to this section in the code again: // Filemanager - Images if (($uploaded = $filemanager->upload()) !== false) { foreach ($uploaded as $file_id) { $_POST['image'][(int)$file_id] = true; } } Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2013 Share Posted October 8, 2013 "The estates store was a clean v5.0 install originally and does NOT have an index.php file in the filemanager table." Ok, so this problem could have come from a bug (oversight, really) in the upgrade process from CC4. On your other topic: Known bug: if (($uploaded = $filemanager->upload() && is_array($uploaded)) !== false) { // Fix for invalid argument for next statement Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 8, 2013 Author Share Posted October 8, 2013 Glad to know the gd class error is resolved. So this new error message should have had its own thread? I'm sorry, but do I just comment out line 347 and leave the rest? I sure wish they'd get the Bug Tracker back up, although I often have trouble trying to search for error messages to see if someone else has already posted about it. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2013 Share Posted October 8, 2013 Replace the existing line 347 with the line I mentioned above. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.