No versions are being recorded
Check, in order:
- Record versions is on, and the kind of record is checked under Record types, in the plugin's Configuration.
- The save changed something. A save that leaves the record as its newest version has it is skipped on purpose.
- For a batch edit, an import or a script, Record bulk operations is on.
- The change went through Omeka's save of the record. Changes made straight in the database, and some made by Omeka without saving the record (see Snapshot Storage), are not recorded.
- Look for lines starting with
[ResourceVersioning]in the PHP error log. Errors are logged there and never shown, so that a save never fails because of the plugin.
An item's history does not show the file I added
Files added to an existing item from code (an importer adding files to items it created earlier, for example) are saved without saving the item. Each file has its own created version at once; the item's list of files is updated at its next save. Files added from the item's edit form are recorded with the item.
The first version of an old record is called "baseline"
Records older than the plugin have no history until they are edited. The baseline is their state just before that first edit, so restoring it undoes the edit. See Version History.
The Restore link is missing
- Researchers can look at histories but not restore.
- Contributors can restore only the records they may edit: their own items and collections, and the files of their items.
- The newest version has no Restore link in the panel: it is the record as it is.
- A
deletedversion has a Recreate link instead, on the deleted record's history page, for those who may recreate it.
"This record was already recreated"
A deleted item or collection can be recreated once. The first recreation is linked from the deleted record's history; restore that record instead.
A deleted file cannot be recreated
Omeka deletes a file's stored file with its record, so there is nothing to bring back. Its history stays.
A restore dropped some values
The restore page and the message after it list what was dropped: texts of an element that has since been deleted, an item type or collection that no longer exists, an owner whose account was deleted. Everything else in the version is restored.
A restore changed nothing
The record already matched the version. Nothing is written, and the message says so.
A batch rollback or prune does not start, or stays "waiting"
Both run as Omeka background jobs. If a run stays waiting on the Bulk Operations or Retention tab, the PHP command-line path Omeka uses for background jobs is not working (Omeka's log says so). Fix it and start again. A single restore does not need jobs.
A batch rollback undid a change that was not part of the batch
A rollback returns each record to its newest version from before the cutoff. A record changed by the batch and again later loses the later change too. Check the preview, or restore records one by one.
A batch rollback skipped records "created in the window"
A rollback never deletes records. Records created by the batch (an import, for example) have no earlier version to go back to. Delete them from the items page if you need to.
The diff shows "#6" instead of a name
Item types, collections, users and files are named as they are now. When one has been deleted, the name kept in the snapshot is shown; a bare number means even that is unknown.
Old versions disappeared
Versions kept per record (50 by default) deletes a record's oldest versions as new ones are recorded. Raise it, or set it to 0 to keep everything. Old versions are deleted by age only when a super user runs the prune. See Retention and Pruning.
Uninstalling deleted the history
Uninstalling drops the history tables. Deactivate the plugin instead, or turn Record versions off, to stop recording and keep the history.