Who Changed It/Docs/Guides
Per-family retention windows, the four IP privacy modes, and how erasure requests work without destroying the audit trail.
Everything the plugin records goes into one table in your own WordPress database, wp_whochita_log. The plugin makes no outbound network calls of any kind: no telemetry, no licence check, no external log store, nothing sent to us. We have no access to your log and no way to obtain it.
The corollary matters for compliance: you are the data controller for everything in that table. The plugin gives you the tools; the decisions about retention and lawful basis are yours.
Per event: the acting user's ID and username, their IP address (subject to the privacy mode below), a UTC timestamp, the event type and family, the object affected, and an event-specific context object which for content edits contains the changed fields and their old and new values.
Two things the plugin deliberately does not store: WooCommerce payment gateway secrets and API keys, and WordPress 7.0 AI connector API keys. Those options are audited as having changed without their values being read.
The global default is to delete events older than three months, pruned on a schedule. On top of that, each of the nine families — authentication, users, content, plugins, themes, core, settings, commerce and other — can keep the default, set its own window, or keep everything.
That is the setting to reach for when one family's retention needs differ sharply from the rest, which is the common case:
Data minimisation is a GDPR principle in its own right, so "keep everything forever" is not automatically the safest choice — the safest choice is the shortest window per family that still meets your actual needs.
Purges record an authorised gap in the hash chain, so pruning never makes the log look tampered with.
IP addresses are personal data under the GDPR. Logging them for security purposes is widely accepted as a legitimate interest under Article 6(1)(f) — you are protecting your site and your users' data — but that basis depends on you limiting retention and being able to answer requests about the data.
Four storage modes, set on the settings screen:
There is a button to apply masking retroactively to everything already recorded. Be aware of the trade: the new-IP and brute-force escalations compare the real address against history, so hashing or dropping addresses turns those rules off in practice.
The plugin plugs into WordPress's own Export Personal Data and Erase Personal Data tools, so a request handled through the standard WordPress flow includes the activity log automatically.
Erasure redacts rather than deletes. The row stays, the personal fields are replaced with a placeholder, a redacted_at marker is set, and a log_redacted event records who did it. Two reasons this is the right design:
Worth knowing when you answer a request: security logs can themselves be a legitimate reason to refuse or limit erasure. That is a judgement for you or your DPO, not something a plugin should decide.
Worth flagging because it catches people out: in much of Europe, logging staff activity engages employment and works-council law on top of data protection, and transparency obligations are stricter than for anonymous visitors. If the people whose actions you are recording are employees, tell them the log exists. That is usually all that is required, and it is far cheaper than discovering the requirement later.
Say that administrative activity, including IP addresses of people signing in, is recorded for security; state your retention windows; and say how someone exercises their rights. If you have set IPs to masked, hashed or dropped, say that too — it is a meaningful reassurance and it is free to state.
The settings screen has a Purge activity log button that empties the table irreversibly. It is recorded as log_purged, classified dangerous, and emails you — deliberately, since wiping an audit trail is also what an intruder would do. Deleting the plugin through wp-admin removes the table and settings entirely.