Omeka: a PHP publishing platform for library, museum and scholarly collections

Omeka as a publishing layer for collections and exhibitions

Omeka is described as a flexible web publishing platform for the display of library, museum and scholarly collections, archives and exhibitions. That description sets the scope precisely: the software publishes a body of described material over the web, and the flexibility comes from a plugin and theme system rather than from a general purpose content management feature list. The people it is written for are cultural heritage and scholarly institutions that already hold digital objects and metadata and now need a public interface for them, typically alongside a themed front end. The project is PHP, released under the GNU General Public License version 3, and the README attributes the copyright to the Corporation for Digital Scholarship for 2016 onwards, with earlier years to the Roy Rosenzweig Center for History and New Media.

A PHP application split into admin, application and install

The repository layout describes the architecture more clearly than the README does. At the top level there is index.php, which in this style of PHP application is the single front controller, and bootstrap.php, which loads the framework and the configuration before anything else runs. The admin/ directory holds the back office where records and files are added and described, application/ holds the core application code, and install/ holds the setup routine that a new deployment runs before the site is opened to the public. The files/ directory is the place for uploaded media, and plugins/ and themes/ are the two directories an adopter touches most often. A .gitmodules file sits at the root, which is the marker for git submodules, so parts of the tree are pulled in as separate repositories rather than living in this one.

db.ini.changeme and .htaccess.changeme mark the manual setup step

Two files in the root directory carry the same .changeme suffix: db.ini.changeme and .htaccess.changeme. The naming is the documentation. A .changeme file is a template that has to be copied to its real name and edited before the application will work, which means Omeka has no unattended install and no first-run web wizard that writes the database credentials for you. db.ini.changeme is the database settings file, and .htaccess.changeme carries the Apache rewrite rules that route requests through index.php. The consequence for an adopter is concrete: the person deploying Omeka needs shell or FTP access to the server, needs to know which MySQL credentials to write into the configuration, and needs to be able to place the rewrite rules in the document root. The README does not document these steps, and the project points to its own site for release notes.

build.xml and composer.json describe how the code is assembled

Two build artefacts sit at the root of the repository. composer.json is the standard PHP dependency manifest, and its presence indicates that the third party PHP packages Omeka depends on are pulled with Composer rather than vendored by hand. build.xml is the conventional file for an Apache Ant build, and its presence points to a repeatable build task for the assets and the application code. The presence of a .tx/ directory is consistent with a translation workflow, since Transifex keeps its configuration in a directory of that name. None of this is described in the README, so it is inference from the file names rather than documented behaviour. What can be said plainly is that this is a source distribution intended to be built and configured, and that the accompanying web site at omeka.org, plus the release notes linked from the README, are where the actual instructions live.

plugins/ and themes/ carry the work most adopters will do

The two directories that decide how a particular Omeka installation looks and behaves are plugins/ and themes/. A plugin in this arrangement extends the behaviour of the application, and a theme controls the public facing pages. For an institution that has already chosen a metadata schema, a lot of the practical work sits in these two places: importing existing records in the shape the institution uses, and matching the public site to the brand and accessibility requirements of the project. The README does not describe the plugin interface, the hook names, or how a plugin is registered, so anyone planning to write one is dependent on the source of the plugins directory and on the documentation outside this repository. The same gap applies to theming. The takeaway is simple: Omeka is extensible by directory convention, and that convention is the first thing to look at in a specific installation.

Bundled Zend Framework, getID3, jQuery, TinyMCE and Silk Icons

The README lists what it includes, and the list is a snapshot of the stack rather than a dependency manifest: Zend Framework, getID3, jQuery, jQuery UI, TinyMCE and Silk Icons. getID3 is the metadata reader for audio and video files, and TinyMCE is the rich text editor, so the list is consistent with an application that ingests media and lets editors write descriptions. The README also states a condition that matters for anyone planning a redistribution: use and modifications of these libraries must comply with their respective licenses. Each of those projects carries its own licence, and the GPL-3.0 terms of Omeka do not override them. This is not legal advice and the point is not legal, it is practical: a bundle assembled from six upstream libraries inherits six sets of terms, and the versions actually shipped should be checked before a commercial deployment depends on them.

Three releases across 2025 and 2026, with release notes kept elsewhere

The maintenance record is short but clear. The repository is not archived, the last push was on 2026-10-16, and three tagged releases are visible: v3.2 on 2025-08-28, v3.2.1 on 2026-06-18 and v3.2.2 on 2026-09-25. The gaps between those dates are wide, roughly ten months then three months, so a reader should not expect a monthly release train or assume that every patch version changes much. The README states that release notes for Omeka are available at omeka.org/codex/Release_Notes, which is the file to read before upgrading an existing installation, particularly given that v3.2 moved the code base forward from an earlier line. The copyright line in the README also names the Corporation for Digital Scholarship as the holder from 2016 onwards, which is where questions about the road map and about support for an institutional deployment would start.

Editorial conclusion

Omeka fits an institution that needs a PHP application it can extend with plugins and a custom theme, and that is prepared to run its own server and edit configuration files by hand. It does not fit a team wanting a hosted catalogue with a vendor handling upgrades, and it is a poor fit for anyone unwilling to read the release notes at omeka.org/codex/Release_Notes before moving between versions. Verify first that the database settings in db.ini and the rewrite rules from .htaccess.changeme are in place on your target host, then check which plugins the theme you need expects.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. omeka/Omeka on GitHub
3. Project website
4. README
5. Releases