Zotero import plugin: fatal error (redirect from Omeka forum)

[afr]

We are not able to use the Zotero import plugin v. 1.2 following upgrade to Omeka v 1.4.2.  Execution of the import function generates  Fatal Error message:

Class 'Zend_Service_Abstract' not found in /omeka/application/libraries/Zend/Rest/Client.php on line 40.

The error is not logged to the Omeka application/error.log or /processes.log files and does not appear in the cPanel error log. 

Any thoughts as to the source of error and possible solution?

Thanks.

[Jim Safley]

Do you have error and process logging turned on? Check
/application/config/config.ini for log.errors and log.processes and
mark them true. Make sure the log files in /application/logs/ have
write permission. Run the import again and see if anything is logged.

This is an odd error. The Zend/Service/Abstract.php file obviously
exists, because it would've failed while requiring a non-existent
file, but the Zend_Service_Abstract class is somehow not in that file.

You mentioned that you upgraded to Omeka 1.4.2. From what version of
Omeka did you upgrade?

Jim

> --
> You received this message because you are subscribed to the Google Groups
> "Omeka Dev" group.
> To post to this group, send email to omek...@googlegroups.com.
> To unsubscribe from this group, send email to
> omeka-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/omeka-dev?hl=en.

[Jim Safley]

Omeka definitely should not be deleting content from files. I'd
reinstall Zend 1.11.6 and try again.

Jim

On Mon, Dec 5, 2011 at 3:13 PM, afr wrote:
> Jim,
>
> The Abstract.php file exists but all content has been deleted -- i.e. ,  the
> file page is blank.   We reinstalled the Zend library in entirety twice
> prior to posting the error on the Omeka Forum, in case the problem occurred
> during the initial upgrade.  The Abstract.php was intact at the time of
> re-installment. The Zend const VERSION is set to '1.11.6'.
>
> Thanks,
>
>
>
> Jim Safley wrote on 12/5/2011 11:33 AM:
>
>> Check to see if /application/libraries/Zend/Service/Abstract.php
>> exists (it should). Now check to see if that file contains the
>> abstract class Zend_Service_Abstract. Also, what is const VERSION set
>> to in /application/libraries/Zend/Version.php?
>>
>> Jim
>>
>> On Mon, Dec 5, 2011 at 2:26 PM, ubu  wrote:
>>>
>>> Thanks for assisting.  Error and processes logging are set to "true"
>>> with full write permission. The import error is not being logged to
>>> either file.
>>>
>>> We upgraded from Omeka 1.4.1. To date, the only persistent problem we
>>> have had with the Zotero import function is failure to unpack file
>>> attachments Zotero zip archive with the PHP Zip extension.

[ubu]

Jim,

The Zotero import plugin is functional following replacement of the
erased Abstract.php file. Curiously, the Collections admin page in
Omeka now shows the original Zotero import that generated the fatal
error message as a partially completed Collection with the correct
name and date of import. Apparently, the Abstract.php was somehow
deleted of contents during the import process, though nothing was
logged to indicate the source of error.

Regarding the issue with "unzip" of the Zotero archives, the import
plugin functions correctly in decoding the Base64 files. The problem
we encountered is a subsequent failure to unpack and remap the files
from the zip archive to the Omeka directory. Any ideas as to possible
corrections?

Thanks,

--Frank

[Jim Safley]

Check to see if Zend/Service/Abstract.php contains the
Zend_Service_Abstract class. If so, redo the import. If the contents
are subsequently deleted then we can assume something very wrong is
going on. Though I find it hard to believe it has anything to do with
Omeka, given that web servers usually don't have permissions to delete
files.

Are you saying that the ZIP archive is not being saved to the item as
a file (as expected)? Or do you expect the plugin to unpack the ZIP
and save each file to the item separately?

Jim

[ubu]

After import the Abstract.php is modified by a secondary function, as
shown below (abridged). Are the code changes a normal routine?

/**
* Zend_Server_Abstract
*
* @category Zend
* @package Zend_Server
* @copyright Copyright (c) 2005-2011 Zend Technologies USA Inc.
(http://www.zend.com)
* @license http://framework.zend.com/license/new-bsd New BSD
License
* @version $Id: Abstract.php 23775 2011-03-01 17:25:24Z ralph $
*/
abstract class Zend_Server_Abstract implements Zend_Server_Interface
{

[. . .]

Re: the zip archive, the below process and error logs were generated
during test import of Zotero biblio data with standard PDF
attachments. The listed exceptions and errors have not occurred
before. Previous to now, PDFs were imported and saved to the Omeka
Item as files in the original PDF format, not as Base64-encoded zip
archives. The problem I was referring to earlier is the unpacking of
the ZIP and save function, as you described in the last sentence of
your most recent reply. At the moment, imported files do seem to be
saved correctly in either case (?)

Processing.log:

ZoteroImport_ImportProcess (130) 2011-12-05T15:14:31-05:00 ERR (3):
exception 'Exception' with message 'Cannot get the local path for a
stored file.' in /public_html/omeka/application/models/File.php:110
Stack trace:
#0 /home/equus/public_html/omeka/plugins/ZoteroImport/models/
ZoteroImport/ImportProcess.php(209): File->getPath('archive')
#1 /home/equus/public_html/omeka/plugins/ZoteroImport/models/
ZoteroImport/ImportProcess.php(180): ZoteroImport_ImportProcess-
>_base64DecodeZip(Object(Item))
#2 /home/equus/public_html/omeka/plugins/ZoteroImport/models/
ZoteroImport/ImportProcess.php(57): ZoteroImport_ImportProcess-
>_import()
#3 /home/equus/public_html/omeka/application/core/background.php(75):
ZoteroImport_ImportProcess->run(Array)
#4 {main}

Error.log

2011-12-05T15:14:18-05:00 INFO (6): getID3: Unable to determine file
format
2011-12-05T15:14:18-05:00 INFO (6): getID3: Unable to determine file
format

[Jim Safley]

> After import the Abstract.php is modified by a secondary function, as> shown below (abridged).  Are the code changes a normal routine?

No. Nothing should be changing the Zend library. I don't see any thing
unusual with the code snippet. What exactly has changed?

> Re: the zip archive, the below process and error logs were generated
> during test import of Zotero biblio data with standard PDF

The errors in the error log should have no effect on the import. I've
reproduced the error in the process log. Long story short, the current
version of the plugin is incompatible with Omeka 1.4.2. I should've
picked up on this earlier, so I apologize. We plan to release an
updated version soon, near the release of Omeka 1.5. The master branch
of the plugin has been updated to work with Omeka 1.4.2+, so, if you
must, you can download the repository here:

https://github.com/omeka/plugin-ZoteroImport

I don't recommend it though, since it is still unreleased and liable
to be changed without warning. But test away if you're willing.

Jim

[ubu]

In reviewing the dates/times of modifications to the Zend library
files I noticed a concurrence of the content deletion to Service/
Abstract.php and online payment to Zotero for storage of library data
via "Google Checkout,' the only method accepted by Zotero. The
timing of the two events might be random but a report of a possible
conflict may be useful to other Omeka users who encounter this
particular error when using the Zotero import plugin.

Thanks, Jim.

[John Flatness]

So, just to be clear, is your Zend/Service/Abstract.php file still
getting periodically blanked, or has the problem gone away?

I'd say it's _very_ unlikely that Google Checkout or payments to Zotero
have anything to do with this. I'd chalk it up to coincidence. A file
continuously disappearing or getting corrupted could be a sign of
hardware failure or some local code (or local users) gone awry, but
probably not a web service, whether it's Google or Zotero.

-John