I was wondering if someone has best-practices or read-to-use solutions for migrating (import/export) Omeka S pages to another Omeka S instance.
Our current situation is the following:
Multiple pages, consisting of various blocks (HTML, Division, Mirador Viewer, Line break, etc.) are created on acceptance environment.
After several modifications, the pages are considered mature and production ready.
All pages have to be manually recreated on the production environment. This involves a lot of drag-and-drop of blocks in the page editor, which is tedious work and prone to error.
I have found these forum topics that describe a somewhat similar situation:
I was one of those who suggested we’d try an API-based approach, and I have made a start on a Module to do so, but not got too far as yet. I have a site to deploy some point this month and would like to have it ready for that, but so far there’s not enough hours in my day!
My start is at https://gitlab.com/arklab/omeka-s-module-Deploy where I have a skeleton module that takes the credentials for the remote site and runs a job that pings the remote site’s API. That’s the easy part, as are adding the post calls to add sites, pages, custom vocabs, etc. You simply get the JSON-LD representation from the PHP API then post that to the REST API. I might get that part done next week.
The hard part is the resource mapping required, for instance if a site or page config refers to a Resource Class or Template or Property by the Resource ID, then I need to map the ID from the source site to the target site, as you can’t guarantee they will be the same. And I need to do that for every module the site might have installed, so Advanced Resource Template, Block Plus, Custom Vocabs, Faceted Browse, Inverse Properties, etc, all add stuff to the config that refers to Resource ID’s rather than say Class or Property terms. That’s a lot of slow detective work…
So, I might have something by the end of the month, or I may just run out of time and have to clone the dev database and finish it later!
Thanks for the reply and your efforts to create a module.
I’ve just tried the module on a dev-environment. Is it true that the code (main branch) currently only starts a job that lists the API resources from the Omeka S target instance and prints that to the logs?
You’re right about the resource mapping . I’ve also identified that as a challenge when I was thinking about developing some script that would create pages using the REST API.
Furthermore, do you expect to make the module configurable in such a way that the user (admin) can select which pages / resource templates / custom vocabs / … to deploy to the target instance?
Yes, it’s only a skeleton for now that simply pings the API, nothing more. Not had time for anything else as yet.
Plan is to build it with customisation and selection coded in to the Job, but I’m not yet sure how to best present that in the front-end, it will be quite complex to build I suspect. The backend may need some careful checks around dependencies to ensure pushing a Page without associated Resources doesn’t break things. Something we’ll discover along the way I guess!