Who Changed It? – Activity Log & Audit Trail

Open the Activity Log screen and search for the page title, or filter the event family to "content". Each edit shows the user, the time, the IP address, and a field-level diff of what actually changed — title, slug, excerpt, author, content length, password protection, parent.

Deletions are recorded like any other event, with the user who did it and the name of the thing that was deleted. Filter by the "content" family, or search the title of the missing item. A burst of deletions by one user is escalated to Dangerous automatically.

Filter the log by the "plugins" or "themes" family. Installs, updates, activations, deactivations and deletions are all recorded with the user who performed them. Use of the built-in theme and plugin file editor is classified Dangerous on sight, because that is how a compromised administrator account usually plants code.

Failed logins are recorded with the username tried and the originating IP. A burst of failures from one IP is escalated to Dangerous and triggers an email alert — throttled, so an attack sends you one message rather than hundreds.

It writes one row to its own database table when something happens, and nothing at all on ordinary page views by visitors. There are no external calls to wait on, and retention keeps the table from growing without limit. The reporting and diff work happens on the admin screen, not on the front end.

Three things. Every event is classified as Normal, Strange or Dangerous with a stated reason, so you are not scanning thousands of identical rows. The log is hash-chained, so an attacker who cleans up after themselves is detected instead of trusted. And exports are cryptographically signed, so what you hand an auditor or an insurer can be shown not to have been edited afterwards.

No. It records events as they happen, starting at activation.

3 months by default. Configure the retention window (or keep all data forever) on the settings screen; developers can additionally use the whochita_retention_days filter.

Yes. Events are grouped into families — authentication, users, content, plugins, themes, core, settings, WooCommerce, and a catch-all — and each family can keep the default window, use its own, or keep everything forever.

Yes — override the base severity of any event type with the whochita_base_severity_map filter, and extend the list of audited options with whochita_watched_options.

Yes. When WooCommerce is active, the plugin automatically also records product price changes (a price drop of more than 50% raises the severity), coupon amount changes, order status changes, refunds, store settings, and payment gateway configuration changes. Gateway secrets and API keys are never stored in the log.

Not unless you ask it to. Out of the box everything stays in your own WordPress database and the plugin makes no external calls whatsoever. If you turn on Slack, Discord or Telegram notifications, it sends alert messages to that service and nothing else — see "What it does not do" above for exactly what each message contains.

Yes. Create an Incoming Webhook for the channel you want, paste the URL into the plugin settings, and choose whether you want dangerous events only, dangerous and strange, or everything. Discord webhooks and Telegram bots work the same way. Alerts are throttled per event type, so a brute-force attack sends one message rather than hundreds, and several events in the same request arrive as a single grouped message.

Yes, automatically, as soon as those plugins are active. Yoast: SEO titles, meta descriptions, focus keyphrases, canonical URLs, the noindex and nofollow switches, and the site-wide Yoast settings. ACF: field group saves and deletions. Elementor: page and template saves. Nothing is registered when the plugin in question is not installed.

Filter the log by the "SEO, fields & builders" family, or search the page title. Switching noindex on is classified Strange in its own right, because the page still loads normally afterwards — the damage usually surfaces weeks later as a traffic drop, by which point nobody remembers the edit.

WordPress records the post update, and Elementor's own save is recorded separately. They are genuinely different facts: Elementor keeps the page content in post meta, so the WordPress-level record honestly shows almost nothing changed. If you only want one, mute either event type on the settings screen.

Yes. Switch on the digest and choose weekly or daily. It covers the whole period in one email: totals by severity, every dangerous and strange event with the reason it was flagged, the ten most frequent event types, and confirmation that the audit chain still verifies. It is sent on schedule even when nothing happened, so a digest that stops arriving is itself a signal. The digest and the per-event alerts are independent — run either, both, or neither.

Not directly. WhatsApp has no webhook, and business-initiated messages need a message template pre-approved by Meta, which does not suit alerts whose content changes every time. Telegram is the closest equivalent and takes about a minute to set up.

The log screen shows the chain status every time you open it. "Verify now" re-runs the check on demand, walking every record and confirming its position, its link to the previous record, and that its stored fields still match the hash written when it was recorded.

Yes. Reading the log is governed by the whochita_view_log capability. Switch read access to capability mode and grant it to the roles you choose; administrators then see the log only if you grant it to them. Changing plugin settings still requires the administrator role, so you cannot lock yourself out.

Yes. IP addresses can be stored whole, masked to /24 (IPv4) or /48 (IPv6), stored as a keyed digest, or not stored at all, and everything already recorded can be masked with one button. The plugin answers WordPress's own Export and Erase Personal Data tools; erasure redacts records rather than deleting them, so evidence about other people's actions survives and the chain still verifies.

The records with their chain hashes, plus a manifest recording the site, the filters and time bounds you exported, the record count, the chain positions covered, and whether the chain verified at that moment. The manifest is covered by an HMAC-SHA256 signature, so neither the records nor the stated bounds can be altered afterwards without invalidating it.

Records written before this version are sealed into the chain on upgrade, oldest first. That proves they have not changed since the upgrade — it cannot prove anything about what happened before it, and the plugin records that boundary rather than blurring it.