Working with Omeka(.org) and the IIIF Toolkit Plugin

After dabbling with setting up an install of on localhost, we decided that setting it up with a hosting service was a faster and more efficient way to go. We used reclaim hosting, which provides an easy install feature for Omeka Classic already built-in. After a little bit of initial setup we were ready to get started working with Omeka Classic with all the unrestricted functionality.

We knew we needed Plugins to make our Omeka look and behave the way we wanted so we checked out the Omeka documentation for Plugins ( to search for some that might be good. When we had a list of the plugins we wanted and had them downloaded, we had to send them to our file manager on reclaim hosting through our FTP software (I was using FileZilla on Ubuntu, Marc went with Cyberduck for Mac). How to download, install, transfer, and use Plugins is all well documented on the Omeka Classic User Manual and is what we used to get them up and running.

We ran into an issue when attempting to install the IIIF toolkit, one of the tools we were most eager to use. We transferred the plugin over, and when it appeared on the plugin page, clicked “install”. But we received this error message:

Omeka has encountered an error
To learn how to see more detailed information about this error, see the Omeka Codex page on retrieving error messages.

There was a link provided leading us to a page on how to send error messages, but gave no clues as to why the toolkit wasn’t installing properly.

So the first thing to do was find out what there error was, but Omeka disables error reports automatically. To enable error reports, I had to find the .htaccess file in the root directory of our Omeka install and edit the line:

#SetEnv APPLICATION_ENV development

By changing it from a comment (by removing the #) to a line.

I attempted the IIIF toolkit install again and received this error message:


The configured PHP path (/bin/php) does not point to a PHP-CLI binary.

Now it was just a matter of fixing the problem, which is that our plugin needs to execute code using the command-line version of PHP. I followed the instructions on this forum to fix this problem. 

The Journey Begins…

It is your first day on the job at a small heritage site. You discover incredible artefacts in the basement of the site. Untouched for years, two medieval folios sit in a dark corner gathering dust. You are fortunate to find them in decent condition and know something must be done with these unique pieces. But you also understand the limitations of this small heritage site. To ensure these objects reach a wide audience you resolve to create a digital collection. But where to begin?

This kind of scenario was the basis for our brainstorming session today. We attempted to create a list of things one ought to know before jumping into a digital humanities project. We considered the sorts of digital tools that would lend themselves to the various components of manuscript studies: writing supports, codicology, genre, paleography, transcription, and cataloguing. We discussed many online tools and databases that would be helpful in the creation of a digital collection by a scholar at any technical skill level. We assessed sites such as:

  • The Cantus Database, for the study and cross-referencing of medieval chants.
  • T-PEN, a web-based transcription tool.
  • Mirador, an open-source image viewing and annotation platform.

These tools, that are used for the research, transcription, and description of medieval materials, seemed a logical place to begin linking the digital world and the physical. More challenging, however, was trying to understand which of the multitude of digital humanities tools out there can lend themselves best to the task of creating an online archive. We had to ask ourselves some unfamiliar questions on topics such as: copyright, collaboration, the value of open-source tools, the importance of transparency and longevity, and other potential roadblocks for researchers who do not necessarily know how to code.

  • Twitter, as a collaborative space for academics. (See Medieval Twitter)
  • Omeka, an open-source tool for creating a digital collection or online exhibition.
  • Humanity Commons, (You are Here) as a space to keep a manifest of our project.

These sorts of tools can be used across a variety of digital humanities projects and provide benefits to any discipline such as creating collaborative spaces and being easy to use at all experience levels.

In the end these tools are all about balancing the Digital Humanities aspect of creating an digital manuscript collection with Medieval Studies. There are still more exciting tools out there with tremendous pedagogical potential to explore and that may better answer our question, “But where to begin?”