v1.30.0

New module: Agent Log

A log of what the automations did to this site — not a general activity log.

Digitizer sites are edited by software as much as by people. When a page is wrong, the first question is not "what happened here" but "did an agent touch this, and what did it touch". A general log answers that only by burying it.

So this one records anything that arrived over the REST API, WP-Cron, WP-CLI or XML-RPC, and records nothing at all for a change made by a person in a browser — including a save in the block editor, which reaches WordPress as a REST request and is told apart by its authentication. Reads are never recorded either: an API client that polls would fill the table in a day and drown the writes that were the reason to look.

• The fact, never the values. Each row names who, what, when, which channel, which application — and the names of the fields that changed. Never their contents, so the log does not become a second copy of the site's content, and there is nothing in it that hurts if it leaks.
• One row per object per request. A post update with eight meta keys is one row with eight names, not nine rows.
• GET /digitizer/v1/activity, requiring the capability to manage options, with the same pagination headers WordPress collections use. No route deletes anything — a log that can be erased through the API is a log an attacker erases on the way out.
• A screen, with filters for channel, object type and date range, reading in the site's own timezone.
• Kept for 30 days or 20,000 rows, whichever comes first. Both limits are filterable, and either can be switched off on its own.
• Switching the module off leaves the log where it is. Only uninstalling the plugin removes it — deactivating is reversible and routine, and a log destroyed by it would be gone exactly when someone was investigating.

It ships disabled, like every module here, and it stands down for nothing: it complements a general activity log rather than replacing one, and a site may run both.

Also in this release

Nothing else changed. The plugin now carries nineteen modules.

Upgrading

No settings change, nothing to migrate. The table is created the first time the module is switched on, not on upgrade — a module nobody enabled leaves nothing behind.