CSV Import says status "completed," but no results

Hello, I am experiencing something strange with the CSV Import since yesterday. The module was working just fine three days ago. Now, when I attempt to create records using CSV Import, the job lists Status as “completed,” but no new records are actually created. The Result column is blank. I also tried to run a Revise import job, with the same outcome: Status “completed,” but there’s nothing in the Result column, and the records have not been revised (I checked the records). Plus there is no “Log” link displayed in the Action column.

I am running Omeka S version 3.2.0. I was running CSV Import version 2.3.1 as of this morning when this problem first occurred. I just upgraded to CSV Import version 2.3.2 and tried to do an import again, but got the same outcome. The site is https://records.njslavery.org/

I would appreciate any help figuring out what the problem is.

– Jesse

The only way I can think of that you’d get it marking “completed” but nothing happening and no log would be if the system thinks there aren’t any rows… if it were just not starting the import you wouldn’t get that “completed” status.

Is there anything different about how you’re making these CSVs? Anything odd on the mapping screen?

Nope, nothing different about the CSV files. There are definitely rows in the CSV file. I’m using the same template as before. I tested with multiple CSV files. I even tried to import the same CSV file that I had already used successfully to revise several records last week, but it’s not working now.

Nothing odd on the mapping screen. The whole process looks the same as always from the time I click “CSV Import” and go to the Import Settings screen to the time that the job runs.

I wonder if I should be contacting Reclaim Hosting to see if something changed with the server, but not sure what to ask them exactly.

Reclaim Hosting has this message regarding PHP:

Updates to PHP Versions:
As of October 2022, the default PHP version on all cPanel servers is PHP 8.0. This means that any account or application set to use the server default (inherited) version will also be updated to PHP 8.0. Please note that PHP changes can sometimes lead to errors at the application level, so if you are experiencing this, we recommend reverting to an earlier PHP version and begin working to make your site compatible with a newer PHP version.

Any chance this is what’s causing the problem? Are Omeka S version 3.2.0 and CSV Import module version 2.3.2 supposed to be compatible with PHP 8.0?

I’m aware that Omeka S 3.2.3 is out, but I heard that 4.0 is on the horizon, so I was waiting to upgrade.


I just rolled back to PHP 7.4 using instructions in this article: https://support.reclaimhosting.com/hc/en-us/articles/4405522991255-Changing-Your-PHP-Version-in-cPanel

After rolling back, I was able to run a test revision import (small CVS file with only 2 records), and the records were successfully updated.

There shouldn’t be an incompatibility issue with PHP 8.0.

It’s possible that something else about the server setup on 8.0 is changed and that’s causing a problem, though. My immediate guess would be something about where temporary uploaded files are saved and permissions on those… maybe the import process is simply not able to read the CSV file, for example. Your host might have PHP logging that could indicate a problem like that.

Update on this. I put in a support ticket with Reclaim Hosting about this issue and got a response this morning saying:

“we have just run some apache updates across our servers to ensure better compatibility with PHP 8.0. This was only done today, and there should have been no other major changes besides the switch to PHP 8.0 as the default that could be impacting this.”

After receiving this message, I changed PHP for my site to PHP 8.0 and tested the CVS Import module, and it ran successfully. So it seems to be working with PHP 8.0 now.

1 Like

Good to hear that you got it working.

Not sure what the problem here would have been, but an issue with opening the uploaded CSV file during the background job seems most likely. Ideally it’s something the module could log so the problem wasn’t so mysterious, though not knowing quite what went wrong here exactly on the older setup makes that difficult.