We’re happily using Omeka S as collection management system for heritage data for a couple of years now. Recently we’ve revamped our Omeka S frontend site, whereby we switched from a multi-site to a single-site setup and started to create some simple pages.
Although the page creation workflow in the admin panel feels quite cumbersome for complex pages, we’re happy with the result it gives us for the few simple pages we’ve created.
Examples here and here.
However, we’re planning a new project that will be relying more on a frontend website and will possibly consist of many pages. I foresee that this will exceed the Omeka S page builder’s capabilities.
I’m now thinking about using a different system - i.e. content management systems like Wordpress, Drupal, etc. - to create, manage and publish the frontend pages whereby the data itself (i.e. the items, media and metadata) is being served by Omeka S, either via the REST-API or IIIF.
I’m curious to hear if other people in the community have faced and solved the same challenge and if there are any best-practices to share.
Thank you in advance,
Best regards,
Maarten Coonen
p.s. In preparation of this post I already had a look at the online resources:
Hi Marteen, your project is of great interest for people looking to get the best of both worlds - a modern frontend querying a powerful backend.
Having myself often faced this issue working with Drupal (my favorite CMS with one of the ugliest built-in front IMO), I am used to (almost randomly) choosing between 1/ create a new theme based on the Drupal default one, 2/ design a WP front with Divi and query Drupal through JSON:API via a PHP proxy, and 3/ write a front from scratch - or based on a JS framework - and again query Drupal through JSON:API. Nevertherless, I think the biggest challenge when it comes to designing a front is related to the presence or absence of a graphic designer by your side
As a newcomer in the world of Omeka-S, I faced the same issue when I found that Omeka’s vintage theming system has way more drawbacks than Drupal’s one, the first of them being a lack of an exhaustive documentation of its API
So for my first project with Omeka-S, I went through solution 1/ and I’m still on this way a few months later. I must admit that if you are creative there are a lot of ways to hack it properly without depending on exotic or unmaintained modules. I’d be likely sharing my experience with you, should you need it.
Disclaimer: I have worked with Omeka-S for some time, but only as a “harvester” in an aggregation project and have been looking at it more “from the outside” as we haven’t hosted an instance ourselves in my former workplace. Now I am working at another university where we now start to host some Omeka-S instances ourselves for cultural heritage projects. We still try to figure everything out - with three instances (some still in beta mode) so far.
We usually work with headless solutions with Django + Vue or Wagtail (CMS) + Vue and try to keep frontend and backend separated. But when we work with institutions from the GLAM sector, we decided to use Omeka-S for it. I thought it might be interesting to hear about our decisions.
As our two frontend developers are used to working with Vue, we first started to use the Omeka-S REST API only and a Vue frontend on top. It worked okay-ish, but we noticed that for smaller projects it just adds a lot of overhead to make this work. The nested structure, long complex queries and a bit less flexibility than in our Django REST projects, made our frontend developers a bit… frustrated We noticed that with all the modules that Omeka-S offers, we are way faster with Omeka-only projects to create much functionality and only fix minor details in modules and the CSS and JS parts of the theme (we build on top of freedom currently). But we are still trying to find the right workflow of what our researchers and involved parties want, and what we can make happen without changing too much of the underlying code so we don’t get in trouble when upgrading later. So no year-long experience here.
Another aspect was that we are a small group at the university supporting researchers and other institutions to get their applications running. If one of these institutions ever decides to host their instance themselves, it is way easier to just give them the Omeka-S instance + database. I guess they could even use the hosting service that I have seen on Omeka’s website. But if we have this intricate version with several parts it would be harder to get it to run somewhere else (unless you build everything in docker/podman maybe?), maintain it, get help from the community. This might not affect your decision, but it was something we discussed here.
The good thing about Vue and similar is that you can also combine these approaches. And only create a single page application with Vue for a more complex page when Omeka just isn’t enough, but still use the Omeka frontend capabilities for the other parts. I am not quite sure about “big” CMS like Wordpress or Drupal though. It seems like those would also need a lot of effort to create a good plugin for it to work with the Omeka-S API and keep up with changes in both Omeka-S and the CMS? But maybe if you join forces with other Drupal/WP people from the Omeka-S community (if there are any?).
We have one Omeka-S+Vue combination running (https://dh.gu.se/). We wanted to try Omeka-S in our own “safespace”, so it is actually our own documentation platform where we use Omeka-S to document the projects we are working on and use it as test instance for new functionality in the background. There we only use Omeka’s REST API and the whole frontend is Vue. Our other two instances are Omeka-S-only (but not live yet).
Hope it helps.
First of all, thank you for your elaborate answers. Those are really helpful!
Ah, good to know that you went for the Omeka-S-only way, Chris. Indeed, building your own theme (or customizing an existing theme) is the approach we’ve also took for our previous and ongoing projects. In fact, I kinda like the way one can override core-/module-code with custom code in your own theme. FYI: this is our theme, which is build on top of the “Omeka-S-theme-ExploreGrid” theme by “hxsllc”.
This approach works very well for us. However, the limitations I’m currently describing are mainly for the page builder in the admin panel. Less technical colleagues would like to use this panel to create many pages that all have similar layout, yet different contents (text, images, etc.). The panel has a drag-and-drop interface, but for each new page you need to recreate all drags and drops from scratch. This is where a template would come in handy and that’s what lead me to the idea to use a separate CMS as frontend.
Congratulations on the Omeka-S+Vue combination Julia. I’ve clicked around a bit and that looks really beautiful!
Thanks for sharing the benefits and drawbacks of Vue and Omeka S. I can imagine that long complex queries and deployability for researchers would make the Omeka-S-only approach preferred.
a lot of effort to create a good plugin for it to work with the Omeka-S API and keep up with changes in both Omeka-S and the CMS
I found this HTTP client which is part of the Wordpress core and is able to send requests to a (REST-)API using the ‘wp_remote_get’ function. In theory it wouldn’t be that much effort to maintain the connection between Wordpress and Omeka S.
Best regards,
Maarten
p.s. I’m still happy to receive more experiences from other community members
We use Omeka S for the Gouda Timemachine. As we were unfamiliar with the site page functionality we also use Wordpress for newsitems and project information. Although Wordpress has nice features for SEO and CSS/JS optimization, we did end-up with 2 themes to maintain. I think the page functionality of Omeka S suits most of my needs, for example it doesn’t mess with inline CSS and JS like Wordpress does.
Apart from the site pages, I wonder if the public item(set)pages are suited for end-users. It’s a lot of linked metadata, where most endusers get lost or just don’t understand. So I do think there’s a desire to make other kind of front-end visualisations of digital heritage data.
For the Gouda Timemachine I have all of the linked data available in a triplestore, so I can SPARQL the data to be shown in a front-end. As the Gouda Time machine has to do with a lot of geo data, I made a “mapping Omeka S data to GeoJSON” functionality (not yet a proper Omeka S module). Example usage on Referentiedata » Panden Matthijs · Data · Gouda Tijdmachine (which works on https://www.goudatijdmachine.nl/geojson/2960669 - data originates from Omeka S).
And of course IIIF is excellent for presenting media (and metadata) in standard IIIF viewers. Every front-end should use IIIF!
I have no experience with using the Omeka S REST API. All I can say is that REST is one of the standards which is also pushed a lot in the Netherlands.
To illustrate my point, I will first begin with a famous quote from Jamie Zawinski:
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
If you mix two systems, you will now need to maintain two systems. Long time maintainability is hard and you will possibly get into intergration-hell.
Ask yourself if the benefits of integrating two systems and maintaining them is worth the possible headaches.
I have another suggestion and this is to create on Omeka-S custom code and design for very specific needs when you need them. You can use Javascript to make the API calls and processing. This way, you will need to maintain only one system and your own (hopefully not many) custom code.
Here is a naïve page I created as my project for the Intensive Omaka-S course. It replaces faceted search. You can view source. Everything is on one page.
omeka-s [dot] info [dot] org [dot] il [slash] s [slash] kos [slash] page [slash] welcome
I use omeka as a backend to manage data in a standard modern way and another tool for front end in some cases.
You can see Drupal in Manioc: the university merged a digital libary with some blogs and they have other tools too. They think that Drupal was not good to manage librarian and researcher data in a simple, standard and persistent way, so a mix of omeka and drupal was the right solution.
Another case is Omeka as a backend and a full javascript front-end, for example in Vue for HyperOtlet.
I know another example with an android app as a frontend too, but it is proprietary.
Hello Daniel, the Manioc website demonstrates an impressive cooperation between Drupal and Omeka-S. Can you tell us a bit more about what’s happening behind the scenes, like how Omeka-s gets queried, how the items get retrieved, indexed etc.?
We noticed that with all the modules that Omeka-S offers, we are way faster with Omeka-only projects to create much functionality and only fix minor details in modules and the CSS and JS parts of the theme (we build on top of freedom currently). But we are still trying to find the right workflow of what our researchers and involved parties want, and what we can make happen without changing too much of the underlying code so we don’t get in trouble when upgrading later. So no year-long experience here.