Who Changed It? – Activity Log & Audit Trail

Who edited that page? Who deleted the post that was there yesterday? Who installed that plugin, switched open registration on, or created a new administrator account at three in the morning?

Who Changed It? answers those questions. It records what happens on your WordPress site and shows it as one searchable, filterable list: logins, failed logins and logouts, user and role changes, plugin and theme installs, updates, activations and deletions, core updates, theme and plugin file editor use, post, page and media edits — with the exact fields that changed — and changes to sensitive site settings.

Every event is classified

Most activity logs hand you a wall of identical rows and leave you to spot the one that matters. This one sorts every event into three levels:

• Normal — routine operation.
• Strange — unusual but not necessarily harmful (a failed login, a settings change, a login at 3 AM).
• Dangerous — high-risk activity you should look at now (brute-force login bursts, new administrator accounts, theme/plugin file editor use, open registration being switched on).

Classification is a two-stage process: every event type has a base severity, and contextual heuristics can escalate it — logins at unusual hours, logins from IP addresses never seen for that user, bursts of failed logins from one IP, bursts of deletions by one user. Every escalation is stored with a human-readable reason shown in the log and in alert emails.

Tamper-evident by design

An activity log is only worth as much as its resistance to being edited. Every record here stores a hash of its own contents plus the hash of the record before it, so changing or removing an entry breaks every link that follows and is reported on the log screen.

Legitimate deletions are not silent either: retention purges, manual purges and GDPR erasures record the span they removed, so the chain still verifies across the gap. Anything else is flagged. Redaction rewrites what a record shows while leaving the hash that sealed it intact, so honouring a privacy request never costs you the audit trail.

For evidence that holds up against database-level access, move the chain key out of the database by adding define( 'WHOCHITA_CHAIN_KEY', 'a long random string' ); to wp-config.php. The settings screen tells you which mode you are in.

Features

• Color-coded log screen with severity icons and per-severity count chips, free-text search, and filters for severity, event family, event type, user and date range
• Field-level change diffs shown inline: see exactly what changed in a post, a profile, or a setting
• Immediate email alerts for dangerous events, throttled so a brute-force attack sends one email, not hundreds
• Append-only and hash-chained. Each record hashes the one before it. Deleted or altered rows are detected and flagged on the log screen.
• Stays on your server. No telemetry, no third-party log store. The only thing that ever leaves your site is a notification you switched on yourself.
• Alerts where you already work. Forward flagged events to email, Slack, Discord or Telegram. Every channel is off until you paste in a destination, and a burst of events becomes one message, not hundreds.
• Retention and redaction. Per-family retention windows; mask, hash, or drop IP addresses; redact personal data to satisfy GDPR requests without breaking the chain.
• Scoped access. Reading the log is its own capability. Even administrators can be excluded from it.
• Evidence you can hand over. Export a signed, time-bounded record set as CSV or JSON for auditors and incident reports.
• Answers WordPress’s own Export/Erase Personal Data tools
• Mute individual event types to keep the log signal-heavy (events about the plugin itself can never be muted)
• WooCommerce support: prices, coupons, orders, refunds, store and payment gateway settings
• Lockora integration: record completed security-audit scores, finding counts, and score deltas when Lockora is active
• Extensible: log custom events, adjust severities, watch extra options, or forward events to external systems via hooks

What gets audited

Authentication (logins, failed logins, logouts, password resets), users and roles, plugin and theme installs/updates/activations/deletions, WordPress core updates, WordPress 7.0 AI connector and feature changes, theme/plugin file editor use, posts, pages and media (with field-level diffs of what changed), a watched list of sensitive site options, and data exports. On WooCommerce shops: product price changes, coupon amounts, order status changes, refunds, store settings, and payment gateway configuration.

What it does not do

It does not phone home, does not require an account, and does not send your log to anyone else’s servers. On a default install it makes no outbound network requests at all — a regression test over every shipped file enforces that, and asserts that every notification channel ships switched off.

The single exception is the one you configure. If you enable Slack, Discord or Telegram notifications, the plugin posts to that service and only that service:

• Slack — messages go to the incoming webhook you paste in, on hooks.slack.com. Terms · Privacy
• Discord — messages go to the channel webhook you paste in, on discord.com. Terms · Privacy
• Telegram — messages go to the chat ID you name, via api.telegram.org, using your own bot token. Privacy

Webhook URLs are pinned to those hosts, so a compromised settings screen cannot redirect your log somewhere else. A notification carries the event type, object, user, IP address and time — the same fields the alert email sends, with the IP already masked to whatever privacy setting you chose. Field-level diffs are never sent.