Cancel a queued/failed CSV import

I’ve got a number of CSV Imports queued up and all of them seem to have failed. How can I unqueue/cancel the imports and what should I look for in troubleshooting?

(test.csv doesn’t work either, though it could be because it’s queued up behind another failed import)


I just remembered this trick from the codex, but it only changes the status to “Queued Undo”… the process still seems to be stalled/aborted.

Uninstalling the plugin effectively removes the failed imports, but it doesn’t change the larger issue that the plugin doesn’t seem to work.

So just to restate the question: what should I look for in troubleshooting the issue?

Thanks and sorry for the multiple posts!

Are they all stopped at “Queued”?

Yes, I just have the one now (using test.csv) and it’s stopped at “queued”

Queued pretty much always means the process never started running, or it died very early.

Is there anything interesting looking in your Omeka or PHP logs?

I have log.errors set to true but the log is empty.

The problem is probably that whatever’s failing is a PHP fatal error that we don’t log. Under normal circumstances for most people those PHP-level errors show up in their Apache logs, but this is happening in a separate process, so it’s not covered by Apache’s log either.

You can try setting PHP’s error_log setting in php.ini (you set it to the path to some writable file that PHP will log to), and trying to run the import again. Some systems have different php.ini files for different PHP environments. If this is the case on your system, make sure you’re making the change in the CLI’s php.ini.

The other alternative way to get at those messages is to manually run the process on the command line, but that involves its own complications (for example, you need to look up the process ID in the database).

I edited php.ini and checked the log and didn’t find any errors related to the import (though I did get one related to the theme so I know it’s working).

How would I go about trying to run the process via command line?

The first step would be to look at the process table in the database: the most recent row should be the last job that we tried to run. You’ll want to get the ID of that row, and looking at the other data could be useful too (like the status column, for example).

With that process ID, you can run the job manually by running

php application/scripts/background.php -p <process ID>

I got the id (11) and tried running php application/scripts/background.php -p 11 from the root of the installation. It doesn’t seem to have had any effect. See screen below of processes table. Any thoughts?

You might need to run it like this:

APPLICATION_ENV=development php application/scripts/background.php -p 11

in order to get output.

Ok, here’s what I’m seeing now…

Fatal error: Uncaught exception 'Zend_Exception' with message 'No entry is registered for key 'view'' in /path/to/application/libraries/Zend/Registry.php:147

Stack trace:
0 /path/to/application/libraries/globals.php(1625): Zend_Registry::get(‘view’)
1 /path/to/plugins/CuratescapeJSON/CuratescapeJSONPlugin.php(15): get_view()
2 /path/to/application/libraries/Omeka/Plugin/Broker.php(157): CuratescapeJSONPlugin->hookInitialize()
3 /path/to/application/libraries/Omeka/Application/Resource/Plugins.php(25): Omeka_Plugin_Broker->callHook(Array)
4 /path/to/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(695): Omeka_Application_Resource_Plugins->init(Array, Array)
5 /path/to/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(644): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource(‘initialize’)
6 /home/mh in /path/to/application/libraries/Zend/Registry.php on line 147

What version of Omeka is this? This is a somewhat commonly seen problem with the “View” resource not being available in the background, but that was changed way back in Omeka 2.1. It’s possible this is a slightly different problem, though.

Deactivating the CuratescapeJSON plugin would probably resolve the import problem as a workaround.

I’m using Omeka 2.4.

Deactivating CuratescapeJSON did the trick. But why is that?

Is there something I should do to that plugin to prevent this issue in the future?

It looks like the error refers to the CuratescapeJSON init hook:

public function hookInitialize()
	get_view()->addHelperPath( dirname( __FILE__ ) . '/views/helpers', 'CuratescapeJSON_View_Helper_' );

I’ll have to look into it a little more, but this is likely an Omeka bug: View is getting loaded too late, so code that works in initialize under normal circumstances fails if run in the background.

It’s possible to work around it in the plugin probably, by catching the exception or moving the code that uses the view to somewhere later than initialize.

1 Like

Actually, you have a better option: you don’t need to have the initialize hook there at all.

If your view helpers are under views/helpers and follow the standard naming (<YourPlugin>_View_Helper_*), then Omeka should automatically add the helper path for you. At a glance CuratescapeJSON looks like it’s set up fine for that and removing the initialize hook entirely should work fine.

1 Like


I’m suddenly having what appears to be the same problem; however, I’m not a script writer/editor, so the discussion and eventual solution is meaningless to me.

My site is I’m using Omeka 2.5 and CSV Import 2.0.3. Can you suggest a possible solution?