All,
I'm stumped! I'm running Omeka 1.4.1 and am trying to install the latest version of the OAIPMHHarvester plugin. I've unzipped it and have copied the correct directory tree up to my /plugins/ directory. I've recursively chown'ed and chgrp'ed it so the Apache user owns it (just like all my other installed plugins). And yet, when I go to the Omeka plugins page via the Web admin interface, it does not show up! So I'm kind of in a holding pattern here. Is there something else I need to do?
Confused in Baltimore,
Mark Cyzyk
If you click the "more information about your system" link at the bottom of any Omeka admin page, you'll get a page that contains a bunch of information about your Omeka installation.
If you could share at least the Plugins section of that page, as well as ls -l output or some other directory listing for your "plugins" directory, that'd be helpful for figuring out what's up here.
Thanks, John,
Problem solved, sort of. A colleague of mine "reinstalled" that plugin and now it's working.
...
I'm attempting to use it to transfer a set of Items from one instance of Omeka to another. Do you know of any other way to do this, though? This harvesting plugin is doing what it should, transferring the metadata -- but I'd really like to transfer both metadata and files for a select set of Items from one Omeka to another, then delete them from the originating instance. I was looking at the Advanced Search interface on Instance #1 and thought I'd search for the Items I'm interested in, export as XML, then be able to slurp them in on the other side -- but it doesn't really look like that's what the Omeka XML output is designed to do.
Looking into this some more...
Mark
Update: All my metadata for the Items I wanted to transfer is now in Omeka Instance Number Two. I wrote some database script-fu to massage it all into place. (The autoincrement IDs were off, naturally... They are now in line with those in Instance Number Two.)
I copied my Archive directory from Instance One to Instance Two and chmodded -R 777'end it. Some more DB scripting to create corresponding, linked records in the omeka_files table, and all is well.
So now all is in alignment. Just one problem: I don't actually see any images! When I try to go to one directly over the Web I get a Permission Denied error.
I must admit to being worried about the Authentication field in the omeka_files table. What is that?
Thanks,
Mark
The plot thickens! So I'm getting a 403 error when trying to get to my images. BUT when I try to hit the index.html file in the root of any of the image directories I don't actually get the index.html file (with its custom 403 error), rather, I get an Apache 403 error: "You don't have permission to access /archive/square_thumbnails/ on this server." So I'm now thinking this is an Apache problem. Looking into it....
The "Authentication" field sounds scary and important, but it's really just a hash of the uploaded image file.
Its purpose is to let users check to make sure their data is exactly the same as it was when it was first stored (by checking if the hash of the actual file matched the "authentication" one). Omeka doesn't directly use it for anything.
If your server permissions are really that locked down, you might need an additional .htaccess file in the "archive" directory with content like:
Allow from all
But, if your server was really denying access to basically every file under the Omeka root by default, you should also be seeing (at least) a bunch of problems with images and CSS from themes not loading. Your problem might be more subtle.
Fixed! SELinux was overriding things.