No versions are being recorded
Check, in order:
- Enable version capture is on and the resource type is checked under Resource types to version in Configuration.
- The save actually changed something. Saves whose payload matches the latest version are skipped on purpose.
- If the edit was a Bulk Edit or a REST
PATCH, Capture versions during batch operations is on. - The save went through the Omeka S API. Direct database writes and some module code that hydrates entities directly are not captured.
- Look for lines starting with
[ResourceVersioning]in the PHP error log. Capture errors are logged there and never shown in the interface.
I edited a media file inside the item form and there is no media version
Media edited within an item's edit form are saved by the item adapter without going through the API manager, so no media version is written. The item's own version records the list of attached media. Edit the media on its own page to get a media version.
The first version of an old resource is called "baseline"
Resources that existed before the module was installed have no history until they are edited. The baseline version is the state captured just before that first edit, so restoring it undoes the edit. See Version History.
The Restore link is missing
- Restore requires the editor role or higher; reviewers can view history and diffs only.
deletesnapshots have no Restore link because deleted resources cannot be recreated from a snapshot.
Restore says the resource no longer exists
The resource was deleted after the version was written. The module does not undelete resources. Its history remains viewable from the Resource Versions browse page.
The restore dropped some values
The confirmation page and the success message list values whose linked resource or item set has since been deleted. They are removed from the restore because Omeka would reject a link to a missing resource. Everything else in the snapshot is applied.
A restore or rollback failed with a validation error
Restores run through the normal API, so Omeka's own validation applies: a resource template with required properties, or a class constraint, can reject the snapshot. Fix the template or the resource, then restore again. Nothing is changed when a restore fails.
Batch rollback or prune shows a job number but nothing happens
Both run as Omeka S background jobs. Open Admin > Jobs: if the job stays at Starting, the PHP CLI path in your Omeka S configuration is not working. Fix the job runner, then dispatch again. Single restores do not use jobs.
Batch rollback undid an edit that was not part of the batch
Rollback restores each affected resource to its last version before the cutoff. If a resource was edited in the batch and again afterwards, the later edit is undone too. Use the preview to check the target versions, or restore the resources individually.
The compare page shows "#2" instead of a label
Labels for classes, templates, assets, users, sites, and linked resources are looked up when the page renders. A bare id means that target no longer exists.
Old versions disappeared
The per-resource cap (Maximum versions per resource, default 50) deletes the oldest versions of a resource as new ones are written. Raise it or set it to 0 to keep everything. Age-based deletion only happens when someone runs Prune old versions. See Retention and Pruning.
Uninstalling deleted my history
Uninstalling drops the resource_version table. Deactivate the module instead if you want to stop capturing but keep the history.