CSV File Won't Import


I am having trouble with the CSVImport plugin not importing CSV files.

We are running Omeka Build 1.4.

At first, when using CSVImport 1.2, if the CSV file had an URL to pull an image file from, the import would import the data from the first 3 columns of the first row and then stall at the URL. The import would never finish and give us 1 record out of the CSV file, but not give us the image for that record or any of the records following.

Then when the CSVImport version 1.3.2 was released, we installed it hoping it would fix. Now, we can't get any file to import whether it has URLs in it or not. We map the file to the appropriate elements but when it "imports" it says "Completed" but that no rows have been imported or skipped.

It seems like the plugin has gone backwards.

We have checked all our permissions on the different folders and everything checks out. Additionally, our PHP-CLI line is correct based on our server settings.

Is there something we are missing?


Having the plugin get to "Completed" status is a good sign that your PHP-CLI settings are fine.

Can you share an example of a file that's not working for you?

The file is like the following (Pardon the messiness since the paths to the files are long):

1/1/2008,Communities and Schools,Dr. Fred Engle,http://library-old.eku.edu/new/content/archives/engle/2008/2008_001.jpg
1/15/2008,A Great Lady,Dr. Robert Grise,http://library-old.eku.edu/new/content/archives/engle/2008/2008_002.jpg
1/29/2008,The Poetry of the Game: Basketball at White Hall High School,Dr. Fred Engle,http://library-old.eku.edu/new/content/archives/engle/2008/2008_003.jpg
2/5/2008,Wilderness Road- Boone's Trail,Dr. Fred Engle,http://library-old.eku.edu/new/content/archives/engle/2008/2008_004.jpg
2/12/2008,The Boone Family,Dr. Fred Engle,http://library-old.eku.edu/new/content/archives/engle/2008/2008_005.jpg

Thanks for sharing that with us.

The first thing we noticed is that some of the URLs aren't correct in that list. For example, http://library-old.eku.edu/new/content/archives/engle/2008/2008_002.jpg goes to a page that basically says the URL is close, but wrong. It looks like some of the filenames use spaces, and some use underscores.

Note, if you're going to keep the URLs but update the CSV, you'd need to specify spaces in a URL as %20.

Okay, we changed the file names themselves from spaces to underscores to match the CSV but it still won't work. It still says "Completed" with 0 items imported, 0 rows skipped, and 0 items skipped. And we aren't getting an error message of any sorts. It just says "Successfully started the import. Reload this page for status updates."

Even with the file names correct with the previous version of CSVImport it would try to import but hang at the URL of the first record and never complete, but again, we would never get an error message.

We have also tried moving the files and changing the URLs to a different location and even that does not work.

Is there any other thoughts about what the issue could be?

With the modified URLs on the remote side, I have no problems importing the sample you posted above.

Are you having any errors logged, either from Omeka or PHP?

It's possible that some information about your server setup could be helpful here. You can access some of that information from the "More information about your system" link at the lower-right of every Omeka admin page.

Here is our server specs:

Browser: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
Role: super

Omeka: 1.4
PHP: 5.2.9 (apache2handler)
OS: Linux i686
MySQL Server: 5.0.77
MySQL Client: 5.0.88
Apache: Apache/2.2.14 (Fedora)

PHP Extensions:
Regular: apache2handler, bz2, calendar, ctype, curl, date, dbase, dom, exif, filter, ftp, gd, gettext, gmp, hash, iconv, imap, json, ldap, libxml, mbstring, mysql, mysqli, openssl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, posix, Reflection, session, shmop, SimpleXML, snmp, soap, sockets, SPL, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib

Comments: 1.0 (inactive)
Comments-1.3-1.0: 1.0 (inactive)
CsvImport: 1.3.2
Dropbox: 0.6
ExhibitBuilder: 1.1
HtmlPurifier: 0.1
ImageAnnotation: 1.0 (inactive)
SimplePages: 1.1
SiteNotes: 1.0
SocialBookmarking: 1.0.1

Berlin: 1.1 (current)
Thanks, Roy: 1.4

There are no errors logged that I can find.

The forum's spam filter did a number on your posts, I've unmarked them as spam and gotten rid of the extras.

There's nothing here that jumps out at me as something that would be causing this problem.

On the subject of error logs, did you turn on Omeka error logging before checking? That's what my link on the word "Omeka" was meant to help with.

For logs from PHP, the php.ini directives log_errors (an On/Off switch for whether errors should be logged) and error_log (which sets the file where errors should be logged to) are the controlling settings. On many systems using Apache through PHP, PHP by default (with no error_log setting) logs its errors in Apache's error log.