Zotero Snapshot

I'm trying to understanding how Zotero snapshots work with the Omeka Zotero Import plugin. The webmaster at my university kindly rebuilt PHP on the shared server with the Zip extension enabled, but I'm still not sure whether it's working or not. On the Omeka public page for an item I've imported from Zotero, under the "Files" field, I see a link for the .ZIP file. But when I click on it, I get a "403 - Restricted" error--e.g., http://www.indiana.edu/~liblatam/researching-brazil/omeka/items/show/3292

In the Omeka Admin view, when I click on the .ZIP link, it opens to a page with metadata for my Zotero snapshot. I see that some of this same metadata also appears in the public view, so maybe the Zip extension IS working as it should?

I guess I'm not sure whether I really understand the purpose of a Zotero snapshot in the first place. In my Zotero library, none of my snapshots actually contain images of the webpage from which I've scraped my bibliographic data. But they do contain links to full-text PDFs. . .

Thanks in advance for your help!

To clarify, a snapshot is a directory containing most, but not necessarily all, files needed to render a web page. Snapshot directories that are synced to the Zotero server are compressed into zip files. The Zotero Import plugin pulls these zip files into Omeka.

The "403 - Restricted" error likely means that your domain www.indiana.edu restricts access to zip files and possibly other types.

The "Attachment URL" element in the "Zotero" element set are URLs that correspond to the snapshots.

Thanks for the clarification. So, if the PHP Zip extension were not working, I take it the "Attachment URL" would not show up?

The plugin downloads snapshots whether or not the zip extension is working. The extension is only used to automatically decode the file names within the zipped up directory, which are Base64 encoded.

What would I expect to see if the zip extension were working?

Regardless if the zip extension was working, you should expect to see zip files that, when downloaded and decompressed, become directories containing the files necessary to render the web pages represented by the Attachment URLs.

If the zip extension is not working, those filenames are Base64 encoded, e.g. "aW5kZXguaHRtbAo=%ZB64".

If the zip extension is working, those filenames are more-or-less human readable, e.g. "index.html".

The clear advantage of a working zip extension is that without it, the filenames will be obfuscated, breaking the relationships between the files.

My webmaster assures me that the zip extension has been installed on the version of PHP that I'm running (5.3.5). However, my zip files are still not being decoded upon import from Zotero.

One difference is that PHP 5.3.5 is not technically the default version on my server. The sys admins rebuilt PHP 5.3.5 with the zip extension, but it is not the default version (which is 5.2.14).

I have to use an .htaccess file to force execution as PHP 5.3:

<FilesMatch "\.php$">
AddHandler x-httpd-php5.3 .php

I'm also specifying the PHP 5.3.5 path in my config.ini file.

Could this method of running PHP be causing the zip files not to be decoded?

That AddHandler line shouldn't mess with the zip extension, assuming it's actually installed for the PHP version you're using.

Omeka gives you an easy way to check this: on the bottom of every admin-side page, there's a link for "More information about your system." That link takes you to a page that lists lots of information about your Omeka install, including what PHP extensions are installed.

If you could post that information (either the whole thing, or just the "PHP Extensions" section), that would help narrow down where your problem is.

Thanks for your reply. Here are the specs. It's showing that the zip extension is indeed installed:

    Omeka:              1.4.2
    PHP:                5.3.6 (cgi-fcgi)
    OS:                 Linux 2.6.9-101.ELsmp i686
    MySQL Server:       5.0.83
    MySQL Client:       5.0.45 

PHP Extensions:

Regular: calendar, cgi-fcgi, Core, ctype, curl, date, dba, dom, ereg, exif, fileinfo, filter, gd, hash, iconv, json, ldap, libxml, mbstring, mcrypt, mssql, mysql, mysqli, oci8, odbc, openssl, pcre, PDO, pdo_dblib, pdo_mysql, PDO_ODBC, pdo_sqlite, Phar, posix, Reflection, session, SimpleXML, soap, SPL, SQLite, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib

Hello, just wanted to check back to see whether there were any suggestions regarding my system configurations. Anything there that might be causing a conflict?

Judging by the other server settings you've mentioned in this thread, the server seems pretty locked down.

Maybe the server has PHP's safe_mode or some other setting enabled which is preventing the zip extension from opening or editing the files.

Your server admin should be able to tell you if safe mode or something similar is enabled and check PHP logs for related errors.

You do have the zlib library, but I wonder if you have the ZipArchive class installed, see:


The plugin checks to see if ZipArchive is installed before decoding the file names. It's unusual to have zlib installed but not ZipArchive, but not unheard of.

Just got this response from the webmaster:

"ZipArchive exists as part of PHP53. Running this PHP code echo class_exists('ZipArchive'); returns true. Do you know if this class is being used in a cron job?"

The class is not being used in a cron job, but it is being used by PHP CLI.

Still scratching my head on this one. Got this reply for my webmaster:

All php versions on the server in /usr/local/bin are cli versions. Omeka would need php5.3.

The VMs all run cgi versions of PHP out of /usr/local/bin. I'm curious how Omeka is attempting to use a CLI version...

PHP safe_mode is turned off. Furthermore, I ran this PHP sample code (http://davidwalsh.name/create-zip-php) for creating a zip file and it worked fine. It seems that the server does not have any issue with ZipArchive. Maybe the issue is with encoding/decoding the filenames. Do you know which PHP functions are doing the encoding/decoding?

What again is your problem with the plugin? I feel a need to refresh this discussion.

ZipArchive and Base64 decoding are invoked in this method (beforeInsertFile):


Thanks. My problem is that I seem to have all the correct settings (Zip extension, ZipArchive class, etc.), but when I do an import from Zotero, the snapshot URLs are not getting decoded....

Okay, this is odd, but I am now able to unzip the Zotero snapshot files and get the human-readable filenames. This wasn't happening before.

So, do the snapshot files have to be unzipped manually, or should I be able to access the contents, or view the shapshot itself, from within the Omeka UI?

Also, the snapshot zip files are getting imported with restricted permissions (600). Is this normal?

Users must unzip snapshots manually. I can't stress enough that a snapshot is a directory of files needed to render a webpage. Omeka does not recognize a directory as a file, so zipping up the directory is necessary. (Actually, Zotero saves snapshots as zip files on its remote server. Omeka just saves them as-is.)

Permissions may depend on whatever zip client you're using to extract the file.

Okay, so I think the issue has now been clarified/resolved. Thanks for your patience!

Regarding permissions, however, what I meant was that the snapshot zip files that are imported and saved in Omeka's archive/files directory are automatically being set to 600. I was wondering whether this could be changed to allow for less restrictive permissions upon import.

Omeka has nothing to do with file permissions. Files are saved using the default permission modes set by the server.