ReportedIP Hive 2.1.62: An Audit Trail That Answers the Support Ticket
ReportedIP Hive 2.1.62 turns the audit trail from eight account hooks into a record of who changed what on a WordPress site: settings with the old and the new value, plugins and themes, pages and posts, menus and widgets, files saved in the built-in editor, user accounts and, on a network, sites and super admins. Every row names the acting user, how the request came in and the affected object, so the next support ticket about a broken permalink or a vanished page has an answer before anyone starts guessing.
Update from the WordPress admin or download the ZIP from the v2.1.62 release on GitHub. The audit trail is part of the Business plan; the feature list per plan is on the Hive plugin documentation page.
What the audit trail records in 2.1.62
Until now the trail listened to sign-ins, password resets, profile and role changes. That answers “who signed in”, but not the questions a maintenance case actually turns on: who switched the permalink structure the night every old link started to fail, who deactivated the shop plugin, who moved the imprint to the trash, who saved a theme file minutes before the white screen. The new trail covers eight trigger groups, 48 event types in total.
| Trigger group | Recorded events | Default |
|---|---|---|
| Sign-ins and sign-outs | Sign-in, sign-in from a new address, failed attempt, sign-out | off |
| User accounts | Registration, deletion, profile, e-mail and password changes, role changes with the acting user, password resets, account blocks, ended sessions, edited role capabilities | on |
| Pages and posts | Published, unpublished, trashed, restored, deleted, URL slug changed | on |
| Plugins, themes and core | Installed, updated, activated, deactivated, deleted, theme switched, WordPress core updated, with the version before and after | on |
| Site settings | 26 core options such as site address, permalinks, reading, discussion, registration and update settings, plus every one of the 170 Hive settings, each with old and new value | on |
| Menus and widgets | Menus created, changed and deleted, menu locations, widgets added to or removed from a sidebar | on |
| Theme and plugin file editor | A file saved through the built-in editor, recorded only when the file actually changed | on |
| Network (Multisite) | Sites created, changed, archived and deleted, users added to or removed from a site, super admin granted or revoked | on |
Sign-ins stay off by default because they are the loudest rows by a wide margin, and failed attempts are already in the security log with the block ladder behind them. The other seven groups are what a support case needs, so they start switched on.
Every row names the actor, the agent and the object
An audit row now carries three things it did not carry before. The acting user is the signed-in account that made the change, not the account the change was about; that one moved into the new object columns (object_type, object_id, object_label, schema version 17, added by dbDelta on upgrade). The agent says how the request came in: browser, WP-CLI, cron, REST or AJAX, so an automatic plugin update at three in the morning is told apart from an administrator clicking the button. And the object is linked while it still exists: a page opens in the editor, a user on the profile, a menu on the menu screen.
Old and new values are stored for setting changes, cut to 500 characters, with a list stored as what was added and what was removed rather than truncated into something that reads wrong. Secrets never reach the table: a data key or an option name that names a password, token, key or code keeps its values out, which covers the Community Access Key as well as any third-party credential a whitelisted option might hold.
What is deliberately not a row
- Autosaves, revisions and auto-drafts, and the internal post types the block editor and the Customizer write on their own.
- The Customizer’s repeated writes of one option during a single save, and the second hook WordPress fires for the same action. Menu locations and widget placement are stored as a diff and deduplicated on that diff, so a real second change in the same request still lands.
- The slug WordPress appends when an entry goes to the trash, the role WordPress assigns while an account is being created, and the per-site removals a network-wide user deletion fires for every site.
- A file-editor save that was rejected: the editor group hashes the file before core writes it and compares on shutdown, and only a changed hash produces a row.
Triggers and retention are settings
The eight groups are switches on the Protection page’s Privacy and Logs card, stored as reportedip_hive_audit_triggers and managed like every other registry setting, so MainWP and Cloud Fleet Management push the same value across a fleet. The retention default moved from 30 to 90 days and can be set between 1 and 365. The nightly sweep no longer deletes one bounded batch a day; it runs in the same 5,000-row chunks under the same 20-second budget as the security log, so a table that grew for months is cleared over a few nights without holding a long lock.
The audit tab reads like a record
The table under Activity shows the user with their address, the event with its group, the object and a sentence with the old and the new value. The filter selects one event or a whole group, a user, an address, an object title and a date range, and the CSV and JSON exports carry the active filter, the object columns and the sentence, so what an administrator filtered onto the screen is exactly what lands in the file. A link at the bottom opens the trigger and retention settings.
Labels follow the reader, not the writer. A setting row written by a WP-CLI or cron request resolves its option label again at display time, so a German administrator sees “Permalink-Struktur” for a change an English-speaking colleague made from the command line.
Multisite: network rows, site rows and a page for every site administrator
On a network, events that belong to the network as a whole are stored as network rows: network-wide plugin activation, installs and updates, network options, sites created, changed or deleted, super admin grants. Events on a site carry that site. The Network Admin sees everything in the Activity tab with a Site column and a site filter that narrows the list to one site or to the network rows. Every site administrator gets an Audit Trail page under the site menu that shows that site’s rows and nothing else, with the same filters and export. A “site deleted” row survives the cleanup that removes the deleted site’s own rows, with the site’s id in the object column.
Below Business the tab shows what it would answer
On the Free, Contributor and Professional plans the tab keeps the plan marker and adds four questions the trail settles, a link to the plan and the same table over five sample rows. Nothing is queried on those plans, the export answers 403, and the security events every plan has stay in the event log.
The event log filter can be searched and picks whole groups
The activity filter of the security log used to offer a fixed list of 30 event types that had not grown with the sensors: a failed form proof, an adapter threshold hit or a comment honeypot could not be selected, and the search box does not look at the event type at all. Every event type the plugin writes, operational ones included, now lives in one registry with its label, its filter group and its threat family, grouped into thirteen sections. A box above the list narrows it by label, slug or group name, each group has an entry that selects everything in it, and the box stays out of sight when the browser runs no JavaScript.
Fixes that matter on a real install
- Form spam was missing from both dashboard charts. The base type
form_spamwas absent from the taxonomy, which dropped every adapter threshold hit from the threat distribution and the event timeline. - Three chart entries pointed at slugs nobody writes (
geo_anomaly,reputation_threat,admin_scanning), so geo anomalies and reputation blocks appeared in no chart. Five slugs that are written were missing altogether. - An event type nobody registered now shows up as “Other” instead of being dropped from the charts without a trace, which is how a new sensor could stay invisible for several releases.
- The log badge takes its colour from the threat family, so every sensor is told apart at a glance instead of the four that happened to have a rule.
- A regression guard now runs in both directions: every slug a logging call writes must have a registry row, and every row must have a writer. The same guard exists for the audit trail.
What it changes for a managed fleet
One key was added to the remote settings schema, reportedip_hive_audit_triggers, and nothing was removed or changed in kind, so the schema version stays at 1 and a dashboard that has not reloaded the schema keeps working. Rows written before the upgrade keep their meaning, and the GDPR exporter and eraser cover both the old and the new row shape.
2.1.62 follows 2.1.57, which put every setting on one Protection page, and 2.1.54, which replaced the setup wizard with a one-page quickstart. The plugin documentation carries the current feature list per plan, the sensors and their defaults.