FAQs

Troubleshooting

The Audit Trail entry is missing from the admin sidebar

The menu entry is shown only to site administrators and global administrators. Editors and lower roles cannot view the log. Also check Admin > Modules to confirm the module is installed and active.

Nothing is being logged

  • Check that Enable audit trail is on under Admin > Modules > AuditTrail > Configure.
  • Check that the resource type is ticked under Events to log. Properties and resource classes are off by default.
  • Only successful create, update and delete operations are logged. Reads, searches and failed saves are not.
  • Look in the PHP error log for lines starting with [AuditTrail]. The module never interrupts a request when logging fails; it reports the error there instead. A common cause is a missing audit_trail table after a partial install: reinstall the module or create the table from modules/AuditTrail/sql/install.sql.

Media changes made while editing an item are not logged, or appear twice

Media edits made on the item form are captured through Doctrine entity events rather than API events, and direct media API calls are deduplicated against them so each change appears once. If media entries are missing, check that Media is ticked under Events to log. See Logged Events for how media capture works.

Failed login attempts are not shown

The module records logins only when Omeka S reports a successful authentication. Failed attempts do not fire an event and are not logged.

The Actor column is blank

The action was performed without an authenticated user session, for example by a command-line script. Entries created this way also have no IP address or user agent.

All entries show the same IP address

The server is behind a proxy or load balancer that does not send X-Forwarded-For, so every request appears to come from the proxy. Configure the proxy to pass the client address in X-Forwarded-For; the module reads the first address in that header when present.

IP addresses look truncated

Redact IP addresses is on. IPv4 addresses end in .0 and IPv6 addresses end in :****. Turn the setting off to store full addresses for new entries. Existing entries are not changed either way.

The Retention Purge section is not on the log page

Only global administrators can run the purge job. Site administrators can view and export the log but do not see this section.

I clicked Run purge now but old entries are still there

  • Check the Retention period setting. If it is 0, purges do nothing.
  • Open Admin > Jobs and find the AuditTrail\Job\PurgeAuditLog job. If it is stuck at Starting, Omeka's background job runner is not working on your server (usually the PHP CLI path in config/local.config.php). Run the CLI script instead; see Purging Old Entries.
  • Entries are only deleted when they are older than the retention period, counted from the moment the purge runs.

The CLI script prints "cannot find Omeka bootstrap"

The script expects to be at modules/AuditTrail/bin/purge-audit-log.php inside the Omeka S installation and finds bootstrap.php three directories up. Do not copy the script elsewhere; call it by its full path instead.

The CLI script says the module is disabled

Enable audit trail is off, so the script skips the run. Either enable the module or pass --days N to purge anyway.

An export is missing older entries

Exports are limited to 10,000 rows, newest first. Use the From and To date filters to export in smaller ranges. See Exporting the Log.

Does uninstalling delete the log?

Yes. Uninstalling drops the audit_trail table and all entries with it. Export the log first if you need to keep it.

Log in for Support