Releases

Fixed#

• Admin > Modules now shows Configure next to ResourceVersioning. The settings were only reachable from the Settings button on the Resource Versioning page.

Fixed#

• Users refused a Resource Versioning page (Authors and Researchers on any of them, Reviewers on a restore, Editors on a batch rollback or prune) got Omeka's error page Omeka S encountered an error with status 500. They now get Omeka's Forbidden page with status 403. Apart from prune (below), who may do what is unchanged.
• The Version History tab on item, media and item set pages linked Authors and Researchers to versions, diffs and the full history, which they may not open. The tab is still shown to them, with the version numbers as plain text and without the Diff and View all versions links.
• Supervisors can no longer run the prune job, which deletes old versions for good: as the documentation says, prune is for Global Admins. Omeka grants Supervisors everything it is not told to refuse them, so they saw the Prune button and could run it. The button is now hidden for them, and a prune request gets the Forbidden page.

Fixed#

• The versions of a deleted resource offered a Restore icon (and the snapshot and compare pages a Restore button) although a deleted resource cannot be restored, and the resource's title linked to its admin page, which no longer exists. Restore is no longer offered for them, a restore page opened for one returns to the resource's history with an explanation, and the title is marked "(deleted)" and links to the resource's version history.
• A deleted resource's history was headed "Item #315 (deleted)"; it now shows the title its last version recorded.
• The filter fields on the Resource Versions page stacked one per line at full width; they now sit side by side.
• A long resource title on a version's snapshot page ran under the page-action buttons. The heading now reads "Version N", with the title below it in the version's details.
• The raw JSON diff gave its line-number columns as much room as the content; they are now just wide enough for the numbers.
• A batch page said its versions were "written by System" when the batch's oldest version was a baseline (recorded without a user). It now names the user who made the batch.

Fixed#

• Restoring a version, or rolling back a batch, deleted the item's media, with their files, and took the item off every site. A restore is a full API update, and the snapshot's media and site keys were removed without anything in their place, which Omeka reads as "no media, no sites". An item's restore now passes its current media, primary media and sites, so they stay as they are. Media lost to an earlier restore cannot be recovered by the module; restore them from a backup.
• Batch rollback skipped every resource whose history began inside the rollback window ("No version exists before the rollback window"), so a bulk edit of resources edited for the first time could not be undone. Their baseline, written as that first edit ran, is now the target.
• Recent bulk operations listed a single resource's first edit (its baseline and the edit share one batch key). It now lists batches that changed more than one resource.
• The restore confirmation page said media are never modified; it now says an item keeps its current media and site assignments.

Fixed#

• Deleting an item, media or item set now records the deletion in its history, as 1.0.0 intended. The snapshot was taken after the delete, when the resource can no longer be read (its id is cleared, and an item set's items cannot load, so deleting an item set also logged "onApiPost failed"); it is now read just before the delete. Batch deletes record each resource under the batch's key.

Fixed#

• The Resource Versions entry in the admin menu showed its text in a serif fallback font: the link carried Font Awesome's fa class, which sets the whole link in the icon font. It now carries only the icon class, like the other menu entries.

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