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?
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?
On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: > 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.
> -- > You received this message because you are subscribed to the Google Groups > "Omeka Dev" group. > To post to this group, send email to omeka-dev@googlegroups.com. > To unsubscribe from this group, send email to > omeka-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/omeka-dev?hl=en.
> 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.
On Dec 5, 1:39 pm, Jim Safley <jimsaf...@gmail.com> wrote:
> 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
> On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: > > 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.
> > -- > > You received this message because you are subscribed to the Google Groups > > "Omeka Dev" group. > > To post to this group, send email to omeka-dev@googlegroups.com. > > To unsubscribe from this group, send email to > > omeka-dev+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/omeka-dev?hl=en.
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
On Dec 5, 10:39 am, Jim Safley <jimsaf...@gmail.com> wrote:
> 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
> On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: > > 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.
> > -- > > You received this message because you are subscribed to the Google Groups > > "Omeka Dev" group. > > To post to this group, send email to omeka-dev@googlegroups.com. > > To unsubscribe from this group, send email to > > omeka-dev+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/omeka-dev?hl=en.
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?
On Mon, Dec 5, 2011 at 3:51 PM, ubu <eq...@red-shield.com> wrote: > 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
> On Dec 5, 10:39 am, Jim Safley <jimsaf...@gmail.com> wrote: >> 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
>> On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: >> > 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.
>> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Omeka Dev" group. >> > To post to this group, send email to omeka-dev@googlegroups.com. >> > To unsubscribe from this group, send email to >> > omeka-dev+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> >http://groups.google.com/group/omeka-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Omeka Dev" group. > To post to this group, send email to omeka-dev@googlegroups.com. > To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/omeka-dev?hl=en.
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-
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
On Dec 5, 1:12 pm, Jim Safley <jimsaf...@gmail.com> wrote:
> 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
> On Mon, Dec 5, 2011 at 3:51 PM, ubu <eq...@red-shield.com> wrote: > > 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
> > On Dec 5, 10:39 am, Jim Safley <jimsaf...@gmail.com> wrote: > >> 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
> >> On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: > >> > 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.
> >> > -- > >> > You received this message because you are subscribed to the Google Groups > >> > "Omeka Dev" group. > >> > To post to this group, send email to omeka-dev@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > omeka-dev+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> >http://groups.google.com/group/omeka-dev?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups "Omeka Dev" group. > > To post to this group, send email to omeka-dev@googlegroups.com. > > To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/omeka-dev?hl=en.
> 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:
On Mon, Dec 5, 2011 at 5:42 PM, ubu <eq...@red-shield.com> wrote: > After import the Abstract.php is modified by a secondary function, as > shown below (abridged). Are the code changes a normal routine?
> 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
> On Dec 5, 1:12 pm, Jim Safley <jimsaf...@gmail.com> wrote: >> 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
>> On Mon, Dec 5, 2011 at 3:51 PM, ubu <eq...@red-shield.com> wrote: >> > 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
>> > On Dec 5, 10:39 am, Jim Safley <jimsaf...@gmail.com> wrote: >> >> 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
>> >> On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: >> >> > 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.
>> >> > -- >> >> > You received this message because you are subscribed to the Google Groups >> >> > "Omeka Dev" group. >> >> > To post to this group, send email to omeka-dev@googlegroups.com. >> >> > To unsubscribe from this group, send email to >> >> > omeka-dev+unsubscribe@googlegroups.com. >> >> > For more options, visit this group at >> >> >http://groups.google.com/group/omeka-dev?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google Groups "Omeka Dev" group. >> > To post to this group, send email to omeka-dev@googlegroups.com. >> > To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. >> > For more options, visit this group athttp://groups.google.com/group/omeka-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Omeka Dev" group. > To post to this group, send email to omeka-dev@googlegroups.com. > To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/omeka-dev?hl=en.
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.
On Dec 5, 3:28 pm, Jim Safley <jimsaf...@gmail.com> wrote:
> > 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:
> 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
> On Mon, Dec 5, 2011 at 5:42 PM, ubu <eq...@red-shield.com> wrote: > > After import the Abstract.php is modified by a secondary function, as > > shown below (abridged). Are the code changes a normal routine?
> > 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
> > On Dec 5, 1:12 pm, Jim Safley <jimsaf...@gmail.com> wrote: > >> 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
> >> On Mon, Dec 5, 2011 at 3:51 PM, ubu <eq...@red-shield.com> wrote: > >> > 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
> >> > On Dec 5, 10:39 am, Jim Safley <jimsaf...@gmail.com> wrote: > >> >> 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
> >> >> On Mon, Dec 5, 2011 at 12:47 PM, afr <eq...@red-shield.com> wrote: > >> >> > 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.
> >> >> > -- > >> >> > You received this message because you are subscribed to the Google Groups > >> >> > "Omeka Dev" group. > >> >> > To post to this group, send email to omeka-dev@googlegroups.com. > >> >> > To unsubscribe from this group, send email to > >> >> > omeka-dev+unsubscribe@googlegroups.com. > >> >> > For more options, visit this group at > >> >> >http://groups.google.com/group/omeka-dev?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google Groups "Omeka Dev" group. > >> > To post to this group, send email to omeka-dev@googlegroups.com. > >> > To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. > >> > For more options, visit this group athttp://groups.google.com/group/omeka-dev?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups "Omeka Dev" group. > > To post to this group, send email to omeka-dev@googlegroups.com. > > To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/omeka-dev?hl=en.
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.
> 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.
> On Dec 5, 3:28 pm, Jim Safley<jimsaf...@gmail.com> wrote: >>> 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:
>> 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
>> On Mon, Dec 5, 2011 at 5:42 PM, ubu<eq...@red-shield.com> wrote: >>> After import the Abstract.php is modified by a secondary function, as >>> shown below (abridged). Are the code changes a normal routine?
>>> 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
>>> On Dec 5, 1:12 pm, Jim Safley<jimsaf...@gmail.com> wrote: >>>> 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
>>>> On Mon, Dec 5, 2011 at 3:51 PM, ubu<eq...@red-shield.com> wrote: >>>>> 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
>>>>> On Dec 5, 10:39 am, Jim Safley<jimsaf...@gmail.com> wrote: >>>>>> 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
>>>>>> On Mon, Dec 5, 2011 at 12:47 PM, afr<eq...@red-shield.com> wrote: >>>>>>> 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.
>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google Groups >>>>>>> "Omeka Dev" group. >>>>>>> To post to this group, send email to omeka-dev@googlegroups.com. >>>>>>> To unsubscribe from this group, send email to >>>>>>> omeka-dev+unsubscribe@googlegroups.com. >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/omeka-dev?hl=en.
>>>>> -- >>>>> You received this message because you are subscribed to the Google Groups "Omeka Dev" group. >>>>> To post to this group, send email to omeka-dev@googlegroups.com. >>>>> To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. >>>>> For more options, visit this group athttp://groups.google.com/group/omeka-dev?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups "Omeka Dev" group. >>> To post to this group, send email to omeka-dev@googlegroups.com. >>> To unsubscribe from this group, send email to omeka-dev+unsubscribe@googlegroups.com. >>> For more options, visit this group athttp://groups.google.com/group/omeka-dev?hl=en.
