"Omeka has encountered an error" when installing API plugin

I am trying to install the Api Import plugin. Every time, I get the dreaded "Omeka has encountered an error" message. The error log says:-

2015-10-12T14:01:55+00:00 ERR (3): exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli prepare error: Table 'omeka.omeka_omeka_api_import_record_id_maps' doesn't exist' in /var/www/omeka/application/libraries/Zend/Db/Statement/Mysqli.php:77
Stack trace:
#0 /var/www/omeka/application/libraries/Zend/Db/Statement.php(115): Zend_Db_Statement_Mysqli->_prepare('SELECT

omeka_a...')
#1 /var/www/omeka/application/libraries/Zend/Db/Adapter/Mysqli.php(388): Zend_Db_Statement->__construct(Object(Zend_Db_Adapter_Mysqli), 'SELECT `omeka_a...')
#2 /var/www/omeka/application/libraries/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Adapter_Mysqli->prepare('SELECT `omeka_a...')
#3 [internal function]: Zend_Db_Adapter_Abstract->query(Object(Omeka_Db_Select), Array)
#4 /var/www/omeka/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)
#5 /var/www/omeka/application/libraries/Omeka/Db/Table.php(648): Omeka_Db->__call('query', Array)
#6 /var/www/omeka/application/libraries/Omeka/Db/Table.php(648): Omeka_Db->query(Object(Omeka_Db_Select), Array)
#7 /var/www/omeka/application/libraries/Omeka/Db/Table.php(281): Omeka_Db_Table->fetchObjects(Object(Omeka_Db_Select))
#8 /var/www/omeka/plugins/OmekaApiImport/OmekaApiImportPlugin.php(113): Omeka_Db_Table->findBy(Array)
#9 [internal function]: OmekaApiImportPlugin->hookAfterDeleteRecord(Array)
#10 /var/www/omeka/application/libraries/Omeka/Plugin/Broker.php(157): call_user_func(Array, Array)
#11 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(295): Omeka_Plugin_Broker->callHook('after_delete_re...', Array)
#12 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(593): Omeka_Record_AbstractRecord->runCallbacks('afterDelete')
#13 /var/www/omeka/application/libraries/Omeka/Plugin/Installer.php(133): Omeka_Record_AbstractRecord->delete()
#14 /var/www/omeka/application/controllers/PluginsController.php(97): Omeka_Plugin_Installer->install(Object(Plugin))
#15 /var/www/omeka/application/libraries/Zend/Controller/Action.php(516): PluginsController->installAction()
#16 /var/www/omeka/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('installAction')
#17 /var/www/omeka/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#18 /var/www/omeka/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#19 /var/www/omeka/application/libraries/Zend/Application.php(382): Zend_Application_Bootstrap_Bootstrap->run()
#20 /var/www/omeka/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#21 /var/www/omeka/admin/index.php(28): Omeka_Application->run()
#22 {main}`

(Hopefully the error log appears as sanely - this is my first post to the Omeka forums.)

I take it that the plugin is trying to access a non-existent table. I have tried this installation on two systems, including a newly created one, and the error is the same. The table certainly does not exist in the database, but my php knowledge does not extend to debugging exactly where the error occurs.

The only similar error I have found on the forums is someone who was trying to install simple pages, and the error occurred because the plugin had already been installed. This is not the case with the problem I am having.

Has anyone got any pointers for me?

The background to this requirement is that I have multiple groups wanting to archive information while remaining autonomous of each other, but we want to aggregate the results. The granular control over "communities" is available in dspace, but we are trying to replicate the facility in Omeka. Happy to accept procedural suggestions in the absence of a technical resolution to the API plugin problem.

Many thanks

Apologies for the poor formatting - I put the error log between backticks, but the log extract must have contained a backtick too.

This looks like an unusual case where there's an underlying problem during the installation process that results in this particular error due to another issue in the plugin.

So, this change in OmekaApiImportPlugin.php should address this issue, but will probably only reveal something else underneath.

Basically, it just adding

if ($record instanceof Omeka_Plugin_AbstractPlugin) {
            return;
        }

to the hookAfterDeleteRecord function, right after it looks up the record.

Then, hopefully we can figure out the underlying problem to installing the plugin.

Thanks for the quick response, Patrick. I made the change at line 112 as suggested, and as you expected, the problem persists. The log now reads:-

2015-10-12T15:03:19+00:00 ERR (3): exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli prepare error: Table 'omeka.omeka_omeka_api_import_record_id_maps' doesn't exist' in /var/www/omeka/application/libraries/Zend/Db/Statement/Mysqli.php:77
Stack trace:
#0 /var/www/omeka/application/libraries/Zend/Db/Statement.php(115): Zend_Db_Statement_Mysqli->_prepare('SELECT `omeka_a...')
#1 /var/www/omeka/application/libraries/Zend/Db/Adapter/Mysqli.php(388): Zend_Db_Statement->__construct(Object(Zend_Db_Adapter_Mysqli), 'SELECT `omeka_a...')
#2 /var/www/omeka/application/libraries/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Adapter_Mysqli->prepare('SELECT `omeka_a...')
#3 [internal function]: Zend_Db_Adapter_Abstract->query(Object(Omeka_Db_Select), Array)
#4 /var/www/omeka/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)
#5 /var/www/omeka/application/libraries/Omeka/Db/Table.php(648): Omeka_Db->__call('query', Array)
#6 /var/www/omeka/application/libraries/Omeka/Db/Table.php(648): Omeka_Db->query(Object(Omeka_Db_Select), Array)
#7 /var/www/omeka/application/libraries/Omeka/Db/Table.php(281): Omeka_Db_Table->fetchObjects(Object(Omeka_Db_Select))
#8 /var/www/omeka/plugins/OmekaApiImport/OmekaApiImportPlugin.php(116): Omeka_Db_Table->findBy(Array)
#9 [internal function]: OmekaApiImportPlugin->hookAfterDeleteRecord(Array)
#10 /var/www/omeka/application/libraries/Omeka/Plugin/Broker.php(157): call_user_func(Array, Array)
#11 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(295): Omeka_Plugin_Broker->callHook('after_delete_re...', Array)
#12 /var/www/omeka/application/libraries/Omeka/Record/AbstractRecord.php(593): Omeka_Record_AbstractRecord->runCallbacks('afterDelete')
#13 /var/www/omeka/application/libraries/Omeka/Plugin/Installer.php(133): Omeka_Record_AbstractRecord->delete()
#14 /var/www/omeka/application/controllers/PluginsController.php(97): Omeka_Plugin_Installer->install(Object(Plugin))
#15 /var/www/omeka/application/libraries/Zend/Controller/Action.php(516): PluginsController->installAction()
#16 /var/www/omeka/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('installAction')
#17 /var/www/omeka/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#18 /var/www/omeka/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#19 /var/www/omeka/application/libraries/Zend/Application.php(382): Zend_Application_Bootstrap_Bootstrap->run()
#20 /var/www/omeka/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#21 /var/www/omeka/admin/index.php(28): Omeka_Application->run()
#22 {main}

This is the same on both systems I am trying. I can't identify much in that error log to provide a clue, so any other suggestions welcome.
Also, the table that I think ought to be created, starting omeka_api... does not exist in the database.
Perhaps I should add that I am using MyISAM rather than InnoDB, but I would not have thought that should not make a difference.

Sorry, it looks like it should be

$record instanceof Plugin

instead of

$record instanceof Omeka_Plugin_AbstractPlugin

I'll still expect a new error, though.

The quick response is much appreciated, Patrick.

As you thought, the error continues, but now it has shifted to a a MySQL problem. The error log now reads:-

2015-10-12T17:58:06+00:00 ERR (3): exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli statement execute error : Specified key was too long; max key length is 1000 bytes' in /var/www/omeka/application/libraries/Zend/Db/Statement/Mysqli.php:214
Stack trace:
#0 /var/www/omeka/application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)
#1 /var/www/omeka/application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#2 [internal function]: Zend_Db_Adapter_Abstract->query('\n CR...')
#3 /var/www/omeka/application/libraries/Omeka/Db.php(79): call_user_func_array(Array, Array)
#4 /var/www/omeka/plugins/OmekaApiImport/OmekaApiImportPlugin.php(29): Omeka_Db->__call('query', Array)
#5 /var/www/omeka/plugins/OmekaApiImport/OmekaApiImportPlugin.php(29): Omeka_Db->query('\n CR...')
#6 [internal function]: OmekaApiImportPlugin->hookInstall(Array)
#7 /var/www/omeka/application/libraries/Omeka/Plugin/Broker.php(145): call_user_func(Array, Array)
#8 /var/www/omeka/application/libraries/Omeka/Plugin/Installer.php(130): Omeka_Plugin_Broker->callHook('install', Array, Object(Plugin))
#9 /var/www/omeka/application/controllers/PluginsController.php(97): Omeka_Plugin_Installer->install(Object(Plugin))
#10 /var/www/omeka/application/libraries/Zend/Controller/Action.php(516): PluginsController->installAction()
#11 /var/www/omeka/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('installAction')
#12 /var/www/omeka/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#13 /var/www/omeka/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#14 /var/www/omeka/application/libraries/Zend/Application.php(382): Zend_Application_Bootstrap_Bootstrap->run()
#15 /var/www/omeka/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#16 /var/www/omeka/admin/index.php(28): Omeka_Application->run()
#17 {main}

After googling the first line error, it looks like a MySQL issue possibly related to indexing. But what is odd is that I still see no additional tables in the database.

Is this just some weird oddity in the way I do LAMP applications, or is there something going on with the API import plugin? All other plugins install perfectly.

It looks like a mix of MySQL config and the plugin itself, though the plugin probably should be set up so that that db config doesn't cause the error.

At this stage it isn't odd that the tables aren't appearing. That error occurs while the plugin is in the process of trying to create the tables.

I'll have to do a little research to find the best workaround or, ideally, bugfix to the plugin.

Thanks Patrick. This is just in the demo/testing stage for a potential use by a local history society here in Scotland, so is not live concern.

BTW, I am hopeful that this use case may be addressed by Omeka-S. When communities run an archive for multiple groups, those groups tend to want control over their bits, while the community ideally wants sight of everyone's work. But I am not sure that such aggregation is not in the roadmap.

Something very close to that is in the roadmap. Items will all be in a shared pool, with some visibility controls. Sites will be built separately, with users having different permissions for different sites.

Your case is exactly what Omeka S is being built for.

Thanks. If the project goes ahead, it would seem OK to start with separate Omeka instances, then hope for a smooth update path to Omeka S when it is released. Great stuff. But mostly thanks for your willingness to look at the plugin issue.

Stevan

No problem. I'm asking the big guns to help with the MySql nuances about creating indexes.

There won't really be an upgrade path from Omeka 2.x to Omeka S -- they are very different products, that will continue to coexist. There will, however, be an importer from Omeka 2.x to Omeka S which will cover most of the basic content.

Back to the original issue....

The big guns (aka zerocrates -- thanks!) gave some suggestions. A quick fix to try might be to go into OmekaApiImportPlugin.php, and at line 22, replace the record_type table definition with

record_type varchar(50) COLLATE latin1_general_ci NOT NULL,

And try installing again.

Could I also ask you to pass along the MySql version you are using? It should be easily available in the System Info link at the bottom of the Omeka admin screen.

Thanks!

Success! Many thanks, Patrick, and zerocrates. Would be interesting to know if it's the field length or the collation that resolves it, but that's really great. Thank you for such quick response.

Stevan

System info as requested: It's Debian Wheezy, but with the updated php from dot-deb. MySQL is as per standard Wheezy.

Omeka 2.3.1
PHP 5.5.29-1~dotdeb+7.1 (fpm-fcgi)
OS Linux 3.2.0-4-686-pae i686
MySQL Server 5.5.44
MySQL Client 5.5.44

Would be interesting to know if it's the field length or the collation that resolves it

To a certain extent, it's both. The error message makes it clear: the maximum key length is 1000 bytes. "utf8" columns in MySQL reserve 3 bytes per character, so that's 765 bytes or so for each text column, and there are 2 of those in this single index so we're easily over the limit without even including the integer column. Shortening the column and changing to a single-byte character set makes the index much smaller.

The reason you're seeing this specifically is because, as you mentioned, you changed the engine from InnoDB to MyISAM. The key length limits differ between those engines. Particularly relevant in this case is that InnoDB allows longer indexes across multiple columns than MyISAM does. In other words, the install should have worked without any changes if it was still using the InnoDB engine.

Aha, thanks for that understandable explanation. I disable InnoDB mostly to reduce system resources, as many of the systems are tight on resources, and rarely run into issues, but it's fully understandable that the plugin expects the most common environment.
I thought I tried one system with MariaDB's XtraDB, but perhaps not.