Releases

Initial release.

Features#

• Automatic version capture — a full JSON-LD snapshot of every item, media, and item set is stored on every create, update, and delete via the Omeka S API layer. No workflow changes required.
• Bulk edit coverage — batch operations (admin Bulk Edit, batchUpdate API calls) are captured per resource and grouped under a shared batch key, so an entire bulk operation can be reviewed — and rolled back — as one unit.
• Baseline snapshots — the first time a pre-existing resource is edited after install, its pre-edit state is captured automatically, so there is always a state to roll back to.
• Deletion snapshots — the final state of a deleted resource is preserved in its history (read-only; undelete is not supported in this release).
• Visual diff — side-by-side structured comparison of any two versions: changed fields, property values added/removed, item-set membership, visibility, class/template changes. Reference ids are resolved to live labels (e.g. Image (dctype:Image) (#2)). A raw line-by-line JSON diff of the stored snapshots is shown below the structured view.
• One-click restore — restore any version from the compare view, the resource's Version History tab, or the browse page. A confirmation page previews exactly what will change. Restores are themselves recorded as new versions, so they can be undone the same way.
• Batch rollback wizard — undo a whole bulk edit (by batch key) or all edits by a user in a time window. Always shows a dry-run preview of affected resources before dispatching the rollback as a background job.
• Version History tab — added to every admin item, media, and item set show page.
• Retention controls — max versions per resource (default 50), optional age-based retention with a background prune job, and a switch to pause capture during large imports.

Safety design#

• Capture listeners never break a save: all failures are logged and swallowed.
• No-op saves are deduplicated by payload hash — saving without changes writes nothing.
• Restores never touch media attachments, ownership (unless enabled in settings), or timestamps; property values pointing at since-deleted resources are dropped with a visible warning.
• History survives resource deletion (no foreign keys into core tables).

Permissions#

• View history and diffs: reviewer and up
• Restore a single resource: editor and up
• Batch rollback: site admin and up
• Prune / settings: global admin

Known limitations#

• Media edited inline within an item edit form does not produce a media revision (Omeka core bypasses the API layer for these); the item's own revision still records its media list. Planned for 1.1 via entity listeners.
• Deleted resources cannot be recreated from their deletion snapshot (undelete) in this release.
• Module-added JSON-LD keys (e.g. from mapping modules) are stored in snapshots but are only restored if the owning module's adapter hydrates them.

Requirements#

• Omeka S 3.x or 4.x, PHP 8.1+
• No external dependencies, no CDN assets