Dragon Activity Log - Audit Log, User Activity Tracking & Security Audit Trail

Logging is a single indexed database write per action. The tamper-evidence hashing runs separately: an hourly WP-Cron job, plus a short end-of-request pass on roughly one request in twenty (capped at 200 events and two seconds) after the page has been generated.

Each event stores a SHA-256 hash computed over its own contents plus the previous event's hash, forming a chain. Editing or deleting any event breaks the chain from that point on, and the integrity check reports the first broken link. This is tamper evidence: it detects edits and deletions made outside the plugin, it does not prevent someone with database access from making them. Use it alongside normal access control and backups.

Two things, by design. First, events are hashed into the chain by a background pass (hourly, plus a short end-of-request pass), so a row deleted before it is sealed leaves no trace; on a quiet site without WP-Cron traffic that window can be up to an hour. Second, someone with write access to your database who also recomputes every later hash and the stored chain head can hide an edit from the self-check. That is what the off-site anchor is for: compare the log against an anchor you received earlier and such a rewrite is caught. Clearing the log or erasing someone's data rebuilds the chain; the event that records it says whether the chain was intact beforehand.

On the Settings tab, choose daily or weekly. On that schedule the plugin seals the chain and emails the chain head (an event number and a hash, never any event data) to the address you choose; ideally one outside this site. You can also have it posted to an https webhook you control, signed with a per-site secret. Keep those messages. At any time, paste an anchor reference into Integrity > "Compare with an anchor" (or run wp dragon-activity-log verify --anchor=<reference>): the plugin recomputes the chain up to that event and confirms it still produces the anchored hash. "Send anchor now" takes one immediately. When the anchored events are no longer in the log because retention cleanup, Clear log or a privacy erasure removed them, the check cannot be completed. It says so and names the event in the log that recorded the removal, with its date, so you can confirm it was one you made. It never reports such an anchor as a match. On the command line, a match exits with 0, an anchor that cannot be checked exits with 2, and anything else (a mismatch, a broken chain, a busy or unreadable log) exits with 1. The webhook must use https, and redirects are not followed. The signing secret is stored encrypted and shown on the Settings tab so your receiver can verify the X-Dragon-Signature header.

Open "Full details" on a log row. A changed setting can be put back to its previous value, and a role change can be undone (the roles it took away are given back and the roles it gave are taken away, nothing else). The rollback is refused, with the reason, when the setting or the user's roles have changed again since the event, when it was already rolled back, when the previous value held a hidden secret or data that cannot be stored exactly, when you are not allowed to give that role, or when it would take away your own permission to change roles. A change that created a setting is not rolled back (that would delete the setting), and neither is a change that deleted one (a deleted setting is not re-created). After a permalink setting (the permalink structure, category base or tag base) is restored, WordPress rebuilds its permalink rules on the next page load; when the restore leaves plain permalinks, the dialog asks you to save Settings > Permalinks once so the server's rewrite rules are written too. Restoring a setting needs the Manage options permission (on a network, the super admin's Manage network options), and undoing a role change also needs permission to change that user's role. Every rollback is recorded in the log, even when your role is excluded from logging. Post edits and trashed posts are not rolled back here: use WordPress's own revisions and Trash. Rollback is available for changes recorded since version 1.1.0, because the previous value is kept from that version on.

Switch them on under Settings > Security alerts and pick which ones you want. A new-address alert is sent when a user logs in from an address that is not among the last 20 they used on this site; their first login only starts that list. It uses the address the log records, so with IP capture off there are no new-address alerts and with anonymization on only a new masked address counts. A burst alert is sent when one address reaches the number of failed logins you set (5 by default) inside the window you set (5 minutes by default); an IPv6 address counts together with the rest of its /64 network. At most one burst alert is sent per window for the whole site: addresses that reach the limit in the meantime are listed in the next burst alert (up to 10, plus a count of the rest), and every failed login is in the log anyway. To count the attempts, the connecting address is kept as a hashed key that expires with the window, even with IP capture off; the alert, and the list held for the next one, show addresses only when capture is on. An administrator alert is sent when a user is given the administrator role, or super admin on a network. Alerts go to the site admin email unless you list up to 10 addresses, and are sent at the end of the request through your site's normal email delivery. A failed delivery is recorded in the log, at most once an hour.

Not to us or to any third party. Events are stored in dedicated wp_dal_events and wp_dal_snapshots tables in your own database. The only things that ever leave your site are the optional off-site anchor described above (an event number and a hash), to the email address and webhook you configure, and, if you switch them on, security alert emails to the addresses you choose.

By default the connecting address (REMOTE_ADDR). Proxy headers such as X-Forwarded-For are ignored unless you enable "Trust proxy headers", because visitors can forge them. You can also anonymize IP addresses or turn capture off entirely.

Yes. Set the retention to 0 days on the Settings tab.

Editor autosaves, background (cron) option writes other than core settings, the plugin's own bookkeeping options, first/last name, nickname and biography changes (email, display name, URL, password and roles are covered), network-wide (multisite) settings, and the success of each package in a bulk plugin or theme update (the update run is recorded per requested package). Settings that plugins use for their own bookkeeping are skipped too: names containing _cache or _last_, or ending in _version, db_version or _lock, the options WordPress writes during a theme switch, and the routine licence re-checks that Dragon Core's paid add-ons save. When "Trust proxy headers" is on, the address appended by the single proxy in front of the site is used (a port it appends is ignored); chains of several proxies are not walked.

Option and field names that look like secrets are recorded as "[redacted]" and their values are never read by the plugin: anything containing password, pass, pwd, secret, token, auth, nonce, salt, private, api, license, licence or credential, or containing _key. Password changes are recorded as "(changed)", never the hash. In the log row, a post body is only flagged as changed and settings stored as JSON or serialized text are summarised like arrays. For the full diff and rollback, a copy of the state before and after the change is kept in the separate wp_dal_snapshots table: for posts the title, content, excerpt, status, type and slug; for settings the whole value. Settings whose name looks like a secret (the list above, plus key) and the anchor webhook address are never copied. Inside a setting's value, and before a change is handed to other code listening for events, nested keys with a secret-shaped name segment (for example api_key, smtp_pwd, client_secret, access_token, Authorization) are replaced by "[redacted]", and a value holding such a key is never rolled back. Serialized values that refer to themselves are redacted whole, and nested keys ending in key, pass or passphrase count as secret too. A side larger than 256 KB is not kept. On a network, the full value of a setting is shown only to super admins. Each copy is deleted with its event: by retention cleanup, Clear log or a privacy erasure. The anchor webhook address is recorded as its host only. The username typed into a failed login is recorded as typed. For the new-address alert, the last 20 login addresses of each user are kept as user data on each site; they are included in personal data exports and removed by erasure requests.