Friends,
Based on the conversations in our recent community call, I’d like to raise visitors’ awareness of this section of the forums as a space for those who maintain and support installations to discuss their issues, approaches, and lessons learned. We’re eager to hear about your successful strategies for managing your installations and keeping your systems rolling!
Take care,
Sharon
4 Likes
Dear maintainers,
I manage a small but growing number of Omeka S installations, one per customer, all of them being hosted by the same local provider on individual plans. The configs differ slightly by the set of modules in use but all of them need an image server (IIIF Server + Image Server at the time of writing).
My strategy until today has been to upgrade every component of the system as soon as a new release is available, after a validation phasis on a test environment. With the number of instances growing regularly, this task is becoming exhausting and boring, increasing the risk of quality loss over time.
I am also considering a way to pool the different services provided to my customers, like building a multisite Omeka server, installing a Cantaloupe server that would manage the images and a SolR server for the search. A POC of this architecture is currently a work in progress.
I’d be glad to learn from more experimented maintainers concerning the different ways to keep systems up to date and if the pooling strategy is a relevant approach in relation to potential security issues.
Thanks for reading 
One issue I have encountered is modules may not always be downgradable to an earlier version if the database structure of that module has been changed. This means that time consuming backups have to be made before updating the modules in case it is necessary to go back to an earlier version if problems arise.
Also, some platforms like Wordpress make it easier to perform updates with a simple update button on the backend, whereas in Omeka updating is a very manual process of downloading from the developer and replacing directories the terminal. Introducing a simple update button that does updates automatially would save time and reduce the chance of mistakes.
1 Like
I totally get the annoying workflow to update modules and themes. A slightly more convenient way is using the CLI tool built by persons from the university of Ghent: GitHub - GhentCDH/Omeka-S-Cli: Omeka-s-CLI: a command line tool to manage Omeka S instances. · GitHub
At least I don’t have to download and upload anymore, but enter two terminal commands. Still not Wordpress flavored convenience though. But good enough to not ignore updates…
2 Likes
Thank you @evansad and @cutterkom for pointing these issues. Did both of you design an upgrade procedure (manual or automated)? What sort of indicators do you consider before deciding to upgrade a module or the entire platform?
I mainly use the Omeka-S-Cli tool to install and maintain Omeka S environments at Ghent University. I deliberately disable updating modules through the web interface. It’s convenient but it’s a security risk I’m not willing to take on production sites.
More generally, updating modules is always a bit of a gamble in Omeka S. Not all of these issues are Omeka’s fault — some come down to individual module developers’ practices — but together they make updates hard to trust. The main issues I run into:
- Versioning: there’s no clear distinction between major, minor, and patch releases. Some modules introduce major and/or breaking changes in a patch release, which makes it hard to trust that a patch update won’t break something.
- Changelogs: frequently missing or incomplete, so you’re often left guessing what actually changed.
Update urgency: it’s often hard to tell why a release exists at all — a security patch that should be applied immediately looks no different from a routine feature release, so you can’t easily prioritize which updates actually need urgent attention.
- Dependencies: there’s currently no way to detect a module’s dependencies before installing it. It would be great if Omeka S adopted Composer for managing modules and themes.
- Module discoverability: not all modules are listed in the official module directory.
Beyond module management, my biggest recurring headache is synchronizing configuration between a dev environment and production. Right now this has to be done entirely by hand. There are tools that let you export/import parts of the setting and site_setting tables, but these don’t cover the full scope of a site’s configuration.
1 Like