Does anyone know how to freeze an Omeka S installation as a static webpage that can be kept online for the long term?
We’ve been running several Omeka installations on virtual machines, which require ongoing maintenance to keep the VMs updated and secure. Since most of our projects are funded for fixed terms, there’s always the risk that the websites won’t be sustained much beyond the project duration.
Inspired by the Endings Project, I believe the best way to achieve longevity is to limit server-side components to static files and the necessary images in different sizes. This approach would significantly reduce the effort required to maintain the site and ensure its long-term availability.
Ideally, this process would avoid web crawling, which can be error-prone and somewhat inelegant. In a perfect world, the static site would not only include the basic HTML, CSS, and JS files but also JSON-LD data, enabling visualization prototypes that rely on semantic data to remain functional.
If you have any insights, experiences, or modules related to turning Omeka instances into readable, static versions that can be hosted on a simple static web server, I would greatly appreciate your input!
Hi Marian, this topic seems to be of great interest for a huge part (if not all) of Omeka users, thanks for the link! I am facing this situation with a couple of recent projects I worked on (even if the CMS was not Omeka in these cases)…
However the principles of the Endings Project team include specifications for technologies that may themselves be outdated in a not-so-far future (see point 4. under https://endings.uvic.ca/principles.html).
Having not the slightest idea of what the web will consist of in, say 10 years, I would not invest in a stack of technos built on the current web architecture, be they the less dependant right now.
Instead, I’d think of separating the actual data from the presentation layer, like 1. “archiving” the site to a kind of static format files inspired by PDF (well, call it a book ) to freeze the visual aspect of the site at the time it was released, and 2. migrating the raw data to an updated storage format as often as new data exchange standards are adopted by the community.
Thank you for your enthusiastic response, Christian! Considering that this is probably a concern for many Omeka users, I am actually surprised that there is so little information on how to freeze an Omeka instance for long-term preservation. If anyone else from the Omeka team could chime in, I would greatly appreciate any pointers and learn about future plans on this topic.
Speaking of specific technologies: HTML, CSS, and Javascript have been around for about 30 years. Sure, there have been updates and extensions to the specs and standards, but the web pages of the 1990s (if they did not rely on Java or Flash plugins) can still be accessed and appreciated with today’s browsers. So I am actually quite confident that the web stack will remain a solid foundation going forward. To be honest, I am not sure what else to invest in besides the web stack.
Separating the data from the presentation layer is definitely something that we would also like to do. I am not entirely on the same page (literally speaking) with regards to printing out an Omeka instance into PDFs. I really would like to preserve front-end interactivity and visual design as much as possible. There has to be a way!
The container approach is certainly one way to go and we’ve seen lots of people do take that route.
One of the development priorities for the Omeka Team for 2025 is to tackle the site-flattening issue. We are musing on what might be the best way to do this, and how we can help users in this effort. There are some very complicated things about the way that items in an Omeka S installation interact with sites and modules that make producing a flat version of an instance much more complicated than it might appear at first glance.
I think it’s also useful to think about producing multiple artifacts for preservation so that a flattened version of a site might also be accompanied by a web crawl, a json export or perhaps a full database export, and that together they manage to represent the original instance with some fidelity.
Thank you, Sharon, for sharing your perspective on this.
Yes, we already have our Omeka instances running on self-hosted VMs, but this not absolve us from updating the server-side part of the stack - MySQL, PHP, and Omeka itself. The maintenance of the update cycle is what may not always be possible.
Your plans for site flattening sound really promising. From our perspective both preserving the human-facing version of an instance as well as the data side (images and metadata) in some form would be super.
I like the idea of multiple preservation artifacts that would serve distinct functions:
static site for continued web-based availability of collection,
data exports for prototypes or other third-party applications, and
full database export (with image files backup) for option to unfreeze the instance
) to freeze the visual aspect of the site at the time it was released, and 2. migrating the raw data to an updated storage format as often as new data exchange standards are adopted by the community.