We are working on making use of the csvimport plugin to pull in some image files via http. However, after mapping the columns to elements and starting the import csv process we get the error down below scrolling through the apache error log constantly. At one point it ran the server out of disk as the log grew to around 15GB in size in a matter of minutes.
From what I can tell, it would seem perhaps that the fopen call is not returning the proper value of a resource id and is instead a boolean value for some reason. I'm not sure since it can obviously open the same file and read the contents of it since those fields show up in the map columns page. The permissions on the csv files look fine so that isn't the issue from what I can tell. Anyone have any ideas on this one?
[Tue Nov 10 10:51:20 2009] [error] [client 129.1.77.38] PHP Warning: fgetcsv() expects parameter 1 to be resource, boolean given in /var/www/hosts/memories/html/cm10/plugins/CsvImport/models/CsvImport/File.php on line 321, referer: https://memories.bgsu.edu/cm10/admin/csv-import/index/map-columns
Looks like it could be that for some reason the fopen is not giving a proper handle, and then it gets stuck in that loop, filling up your log.
I refactored the CsvImport_File class and committed my changes to the trunk.
You can checkout the trunk of the plugin into your plugins folder using svn as follows:
cd plugins/
svn co https://addons.omeka.org/svn/plugins/CsvImport/trunk CsvImport
Of course, uninstall your current version of the plugin and remove it from the plugins folder.
Let me know if the newest version of the plugin works for you.
Thanks for pointing out this error.
By newest version, I mean the trunk of the plugin in svn repository.
I would also make sure that when the user on which the php command line interface runs has permission to read your csv file.
I updated our install with the updated version you mention above and indeed my tests that were previously failing are now working as expected so whatever you changed seems to have fixed the issue. Thank you very much!
I'm kind of an amateur php programmer so if you have a minute could you explain exactly what the fix was. Thanks again.
Omeka didn't have proper access to the files, so they were given a "null" value -- which means that they don't exist. The plugin previously did not check to see if the files were null, and so the plugin was getting stuck in an infinite loop (which is why your error log was so huge). Will's patch to the plugin's code fixed this by checking to see if the system can access the files before attempting to import them.
Dave