Plugins and Third-Party Tools

Omeka Plugins

Collection Tree

Rationale: In DocTracker, Civil War Governors of Kentucky simulates a hierarchical organizational structure (Source / Collection / Document). When migrating to Omeka, Early Access required a similar hierarchical structure in its back-end architecture and its front-end navigation. By default, Omeka offers two levels of hierarchy (Collection / Item). And the organizational structure of Omeka collections is flat, by default. Installing and activating the Collection Tree plugin meets the Early Access requirement by adding  additional levels to Omeka’s hierarchical structure. After configuring the Collection Tree plugin, the Early Access structure looks like this: Parent Collection / Child Collection / Item. The parent collection is a CWGK repository, equivalent to “Source” in DocTracker. And the child collection is a CWGK collection, equivalent to “Collection” in DocTracker. The Collection Tree is visible in front-end repository pages, like this one:, as an alphabetical list of collections housed in the repository.

Configuration: The default Collection Tree plugin output is an un-ordered list of nested collections. The plugin has been modified to instead output divs for each child collection on the parent collection (repository) page. By default the “tree” displays on every front-end collection page, but it has been hidden on child collection pages like this one:


CSV Import

Rationale: Early Access required migrating ~10,000 TEI documents from DocTracker to Omeka and importing ~10,000 pdf files from Kentucky Historical Society shared drives to Omeka. Files are to be migrated/imported in batches. Each TEI document and its respective PDF file should map to the same Omeka item. Installing and activating this fork of the CSV Import plugin meets these requirements as it adds the options to upload pdf files in batches, to map each pdf file in the batch to an existing Omeka item, and to choose the match point between pdf file and Omeka item. The CSV Import plugin follows the Dropbox TEI plugin (below) in the migration workflow from DocTracker to Omeka (see 5.0 User Guide for more information about the migration process)


Dropbox TEI

Rationale: In DocTracker, CWGK editors transcribed tens of thousands of documents and encoded them for export as TEI documents (XML). Early Access required migrating ~10,000 of these documents from DocTracker to Omeka. Files are to be migrated/imported in batches, and metadata from the TEI header should map to Dublin Core metadata fields in Omeka. Once populated, Omeka metadata fields become access points for CWGK documents. And these access points enable researchers to discover documents of interest. In addition to data mapping, Early Access required that the marked-up transcription (the TEI text element) displays as styled HTML. In order to meet these requirements, Dehner investigated several potential solutions:

  • The Bookmeka plugin has potential. It offers several formats of the TEI transcription, and its file promises CSV Import integration. It currently exists as a beta option, but could be explored further in the future.
  • In 2012 the TEI Display plugin was updated to be compatible with Omeka 2.x, but it was never publicly released. Dehner hoped that its beta status would be sufficient for the needs of Early Access, but the plugin did not correctly map metadata from the TEI header to Omeka and the plugin does not support batch imports.
  • The XML Import plugin requires converting XML files to CSV files before batch importing. And because CWGK sought a more streamlined process, Dehner eliminated this option.
  • TEI Boilerplate does an excellent job transforming TEI to HTML, and Dehner adapted its functionality for Early Access (see XSLT below)
  • Sue Hemmens, of Dublin Ireland’s Marsh Library, developed a plugin that combines aspects of the TEI Display and Dropbox plugins, but it is only compatible with Omeka 1.x, an older and vastly different version of Omeka. Her unreleased plugin batch uploads TEI files, creating Omeka items and mapping the TEI header to Omeka metadata fields upon import. She graciously shared her notes with me, and Dehner rewrote the plugin to be Omeka 2.x compatible and to map fields identified by the CWGK team (see Data below). Dehner also added functionality to render the TEI transcription as HTML (see XSLT below). This solution meets the requirements of Early Access. (see User Guide below for the workflow process)

This plugin was written by Anneliese Dehner. It is a mash-up of Omeka’s Dropbox and TEI Display plugins. The Dropbox plugin brings batch upload functionality while the TEI Display plugin brings XML mapping and also renders the TEI transcription as HTML.


Clean Url

Rationale: By default, Omeka identifiers and terms (items, collections, etc.) are combined to create a url template. For example, the default url for an Omeka item is: and the default url for an Omeka collection is Early Access required a url structure that includes the CWGK accession number. Installing and activating the Clean Url plugin meets this requirement. After configuring the Clean Url plugin, the front-end url template for a CWGK Omeka item is and the front-end url template for an Omeka collection is The back-end url structure, however, follows the default Omeka template.


Default Sort

Rationale: Early Access required that documents be sorted by CWGK accession number (eg. KYR-0001-001-0001), in ascending order. By default Omeka sorts items by the date they were added to Omeka, in descending order. While it is possible to configure sorting options (sort by accession number, title, date, etc.) in some front-end Omeka page templates; it is only possible to change the default sort field by editing Omeka’s core files. Editing Omeka’s core files is not recommended because it complicates the process of upgrading to new versions of Omeka. Installing, activating, and configuring the Default Sort plugin meets this requirement. In front-end pages, items are sorted by ascending CWGK accession number.


Solr Search

Rationale: Early Access required faceted navigation. Omeka’s default search includes pre-filtered searching in the form of advanced search, but it does not include faceted navigation. Solr Search is a popular and powerful search platform, offering endless configuration possibilities. Installing, activating, and configuring the Solr Search plugin meets the faceted search requirement and gives the CWGK staff the flexibility to improve search results in the future if they choose to investigate Solr’s configuration options. Activating the Solr Search plugin replaces Omeka’s simple search box with Solr’s search box. This action also replaces Omeka’s default search results page with Solr’s results page, which includes a left sidebar of facet options. The Solr Search plugin does not offer an advanced search. This has been added back in separately (see Data & Directories below) and Omeka’s Advanced Search has been disabled.


PDF Embed

Rationale: Early Access requires presenting the scanned document beside the document’s transcription. The document viewer should be clean and minimal so the viewer’s frame does not interfere with the user’s interaction with the document. The viewer should allow the user to zoom in and out, to rotate the document, and to pop-out the document in another window. The viewer should also protect the security of the document, not allowing the user to download or print an original copy. All of this should work smoothly across devices and browsers. Dehner explored several possibilities to meet this requirement:

  • Dehner first installed the Docs Viewer plugin because of its responsive, minimal appearance. However this viewer allows the user to open the pdf in Google Drive, making the original pdf available for download or printing. Because the entire viewer is packaged as a Google product, it is not possible to limit these functions. Due to security issues, this viewer was abandoned.
  • The OpenSeadragon plugin has potential for image files, but it is not compatible with multi-page pdfs.
  • While the Universal Viewer plugin offers many features, the viewer frame is overloaded with buttons. Dehner eliminated this viewer due to its bulk, which detracts from the document itself.
  • The PDF Embed plugin is based on pdf.js and is simple in appearance but feature-rich. Its configuration is flexible; features can be disabled and customized without slowing the viewer’s functionality. Dehner chose this plugin, as it meets the project requirements. The plugin can be configured to allow user download and printing. But these features have been disabled in Early Access to meet the document security requirement.


Simple Pages

Rationale: The CWGK staff writes historical and editorial information that supports and complements the collection. Early Access should include web pages that house this information. The Simple Pages plugin meets this requirement. The plugin provides a WYSIWG text editor to easily create rich text web pages, and it allows staff users to simply add these pages to the navigation menu. The WYSIWG text editor can also be disabled so staff users can build pages with HTML, if they prefer.


Exhibit Builder

Rationale: CWGK is interested in considering Omeka as a platform for future curated exhibits and lesson plans drawn from its documents. The Exhibit Builder plugin meets this requirement as it offers endless template options for laying out text, images, and Omeka items.


Simple Contact Form

Rationale: Because Early Access publishes transcriptions which are not yet considered authoritative, the editors invite users to suggest transcription corrections. This requirement is met by the installation and activation of the Simple Contact Form plugin, which creates a contact form on a page of the Omeka website. A link to the contact form is located below each document transcription. The form forwards each form submission to a staff email account. Recaptcha has been activated in Omeka to prevent spam submissions via the form.


Third-Party Tools


Rationale: Early Access required that TEI document transcriptions display as HTML. XSLT is required to transform XML to HTML. The TEI Boilerplate simplifies the rendering process by handling many basic transformations. The boilerplate XSLT is built out to transform special CWGK cases like stamps, columns, and marginalia. The stylesheet is called by the Dropbox TEI plugin (above) to render the transcription of the XML file uploaded to the Omeka item via Omeka’s dashboard.



Rationale: Early Access required making documents available for public viewing. The documents can be downloaded if they are kept within the context of the collection. This is achieved by adding the KHS logo, the CWGK logo, and a right to use statement to the pdf file at the point of download. TCPDF is a PHP class for generating PDF documents. This is one part of the solution to create branded PDFs on the fly. The process also requires TCPDI, TCPDI_PARSER, and FPDF_TPL (all below)



Rationale: Because TCPDF does not import existing PDF documents, an importer is required. CWGK PDF documents are version 1.6. And TCPDI can import existing PDF documents up to version 1.7. However TCPDI requires TCPDI_PARSER and FPDF_TPL to import PDF documents.



Rationale: The parser is required by TCPDI to import existing PDF documents.



Rationale: This class is required by TCPDI to read pages from existing PDF documents.


Google Analytics

Rationale: CWGK is interested in capturing how users interact with the site. Do users enter the site from Facebook, from the CWGK WordPress site, from Google searches, etc.? Where do users go after viewing an Omeka exhibit? Do they browse or search? Do they start with an advanced search or a simple keyword search? Do they download xml files? Do they download pdf files? These are some of the questions CWGK staff hope to answer with site metrics. Adding Google Analytics tracking code to the footer of Early Access meets this requirement as it gathers data about site visitors and their behavior as they navigate the website.


Omeka Report Table of Contents

Omeka Report Home

Civil War Governors of Kentucky requirements from Omeka

Plugins and Third-Party Tools

Design and Functionality

Future of this Site