WordPress Agent Changelog

Release notes for the Logystera Agent WordPress plugin. Only the change that affects how the plugin behaves on your site is described — internal test and build changes are omitted. The plugin also ships its full history in readme.txt, and every release is available from the plugin's releases page.

The version you have is shown in Logystera → Debug and on the Plugins screen.

0.11.2 — 2026-09-27

Updating a flagged plugin now shows Checking right away, without reloading the page. Clicking Update now used to leave the old vulnerability warning showing until you refreshed the Plugins screen yourself.

0.11.1 — 2026-09-26

After you update a flagged plugin, the Plugins screen says Checking instead of repeating the old warning. The warning is about the version Logystera checked; once Logystera has looked at the new version, the warning either clears or comes back if the new version is still affected. While the page is open it checks again in the background, and if no answer arrives within a day it says Not confirmed — never that the plugin is safe.
Every setting, status row and action in the plugin's admin now has a help icon.
Help popovers are no longer cut off at the edge of a settings card, and a popover you closed no longer reopens when the mouse moves away.

0.11.0 — 2026-09-26

New

The admin says when and why sending is paused. If Logystera asks the plugin to slow down, the notice shows when sending resumes; if the site reaches a daily limit, it says so and shows the reset time. Nothing is done on your visitors' page requests while sending is paused.
Help text can be updated without a plugin release, with a copy built into the plugin for when it can't be fetched.
More kinds of vulnerability findings: besides Wordfence matches, the Plugins screen and Status tab now show vulnerable libraries bundled inside plugins, outdated PHP or server versions, and versions visible from outside the site.
Blocks made by Wordfence Extended Protection can be read back from Wordfence's own block log (opt-in).

Privacy

A failed login against an existing account now reports that account's username (on by default). Attempted names that are not real accounts, e-mail-shaped names and non-ASCII names stay masked; readable e-mail usernames are a separate setting, off by default.

Reliability and security

Buffering is bounded during outages, and an interrupted send no longer delivers the same events twice.
The stored site secret no longer appears in page HTML.
Masking of e-mail addresses and database error values is stronger.
Uninstalling is safe even while a request is still running.

0.10.1 — 2026-09-11

Fixed a link on the Cloudflare notice that reloaded the page instead of opening the Visitor IP diagnostic.
Core-file integrity checks no longer report ordinary theme and translation housekeeping as changed core files. A result now names the affected files instead of a single count, and a genuinely modified core file now also raises a notice on your main WordPress dashboard, not only on the plugin's own Status tab.

0.10.0 — 2026-09-08

New

The plugin is now available from the WordPress.org plugin directory, with update notices for anyone who installed it by hand.
The regular check-in now reports whether data is actually being delivered, not just that the site is reachable — surfacing a stalled delivery queue earlier.
A notice when your site is behind Cloudflare and its visitor-IP detection needs a config change, with a link straight to the diagnostic that generates the exact wp-config.php line to add.
New coverage for sites running Wordfence: brute-force lockouts, blocks, and similar decisions Wordfence makes are now recorded as security signals, closing a gap where those attacks previously produced nothing.

Reliability

A billing hold on your account no longer disables the plugin. Previously, the regular status check could mistake a billing hold for a rejected login, and after about an hour of that the plugin would disable itself and stop monitoring your site entirely — even after the billing issue was resolved. A billing hold is now recognized for what it is, never disables the plugin, and delivery resumes automatically once the account is back in good standing. The Status tab also gained an Unfreeze ingest button, for resuming immediately instead of waiting on the next check-in.
Several delivery-timing edge cases that could drop or duplicate queued events — especially on a busy site or a WordPress multisite network — are fixed.
Turning Logystera off now clears anything still queued, instead of sending a backlog once you turn it back on.
Uninstalling now also clears cached copies of plugin data on sites using a persistent object cache (e.g. Redis, Memcached).
A corrupted stored credential is now reported clearly, instead of silently failing as if the connection were fine.
A disabled site with local history enabled no longer keeps sending data to Logystera in the background.
Logging is quieter by default — a new Logging detail setting under Settings → Debug Logging replaces the old all-or-nothing debug toggle.
Saving Settings could previously reset your gateway URL, batch size, or retention settings depending on which form you used; every field now saves correctly regardless.

Security

Your one-time connection code is now protected the same way every other request is if your gateway address is accidentally plain HTTP.
Error reports sent to Logystera no longer include e-mail addresses that could appear in a database or mail failure message.

0.9.3 — 2026-09-03

Fixed a display issue with the vulnerability-warning icon overlapping its tag in the Plugins list.

0.9.2 — 2026-09-03

Hovering a plugin's vulnerability tag now shows the CVE and severity, and a new Vulnerable plugin highlighting setting (on by default) tints the whole row for an at-a-glance warning.

0.9.1 — 2026-09-03

The per-plugin vulnerability tag no longer gets overwritten by WordPress's own "Updating…" indicator while you update that plugin.

0.9.0 — 2026-09-01

New

Daily core-file integrity verification: your WordPress installation is checked against the official wordpress.org files for your version, with results shown on the Logystera admin page.
A daily account-hygiene summary — admin count, how many admin accounts haven't signed in for 90+ days, and whether a two-factor plugin is detected. No usernames, emails, or user IDs are ever sent.
Known plugin vulnerabilities now surface directly on your Plugins page (and Network Admin, on multisite), alongside a summary on the Logystera admin page.

0.8.2 — 2026-08-27

Fixed a display glitch in the About tab's "Recent changes" list introduced in 0.8.1.

0.8.1 — 2026-08-27

The About tab's "Recent changes" list, which had fallen well behind, is up to date again.

0.8.0 — 2026-08-27

Tested up to WordPress 7.1.
Logystera's own health checks are no longer counted as visitor or bot traffic in your site's metrics.
A security finding that gets worse, or is reopened after being resolved, now reliably raises a fresh notice — previously an escalation to a more severe finding could be silently missed.
Hosting/server detection now reports facts about your environment rather than guessing a single provider label.

0.7.9 — 2026-07-30

New

Security findings from Logystera can now appear as a dismissible notice in your WordPress admin, alongside the existing "your site health report is ready" notice. A resolved finding clears its own notice automatically.

Reliability

Dismissing a Logystera notice from the Dashboard or Settings screen now actually sticks, instead of reappearing on the next page load.
Sites that are quiet, retrying, or paused for billing now still receive platform notices, including withdrawals of resolved findings.

0.7.8 — 2026-07-28

Requests your site makes to itself (WP-Cron, self-calls) are now flagged separately from visitor and bot traffic, so they no longer skew visit metrics.
Fixed the Anonymize IP setting: it is now actually applied when your site's IP-address data is sanitized before sending.

0.7.7 — 2026-07-25

New

Google's crawler is now also verified by IP range, not just by its user-agent string, catching some genuine Googlebot traffic that was previously missed.

Security

A misconfigured plain-HTTP gateway address can no longer send data unencrypted just because WP_DEBUG happens to be enabled — it now requires a deliberate opt-in, closing a gap common on sites that leave debug mode on in production.
Fixed two edge cases in how an IPv6-loopback gateway address is recognized for the local-development opt-in.

0.7.6 — 2026-07-23

Gravity Forms webhook-response signals now also record which form submission a delivery failure applies to, making failed webhook deliveries easier to trace to the right entry.
A "your site report is ready" notice can now appear in the plugin's admin screens.

0.7.5 — 2026-07-19

Reliability

The agent's PHP error handler no longer touches the database while an error is being raised. In a rare timing window, a PHP notice arriving mid-query could desynchronize the site's database connection and leave writes to the options table blocking for up to 50 seconds. The handler now captures errors into a small in-memory queue and processes them at the very end of the request, after every query has finished — the agent never issues a query from inside its own error handler.
Warnings captured just before a crash are no longer lost with the crash. The agent now processes its captured-error queue as its first action when an uncaught error reaches it, so the warnings that often best explain a fatal are shipped rather than discarded on WordPress's fatal-error page.
A noisy warning can no longer crowd out different ones: repeats of the same warning now collapse into a single counted entry, so the capture limit only ever applies to genuinely distinct warnings. Each captured warning also keeps the exact time it fired and, on multisite, the site that raised it.

New (both off by default)

Agent self-overhead reporting — an opt-in agent.overhead signal reports how many milliseconds the agent's own code spent in a sampled request, plus the single most expensive hook. This gives fleet-wide visibility into the agent's own footprint.
Per-hook circuit breaker — an opt-in per-hook wall-time budget (default 5 ms). If a single callback runs long, that hook is short-circuited for the rest of the request (filters pass their input through unchanged, so WordPress behaviour is never altered) and one summary signal is emitted.

New

Gravity Forms webhook response tracking — when the Gravity Forms Webhooks add-on is active, the agent records the response status of each webhook it sends, broken down by status class, form, feed, and destination host, so you can see which feed is failing to reach its destination. Only the destination host is recorded, never the webhook URL's path or query string.

Security

The agent's buffer directory now sits behind a per-install random path segment, so buffered signals and logs cannot be reached by guessing a URL on servers that ignore .htaccess (nginx). Apache installs were already protected and are unaffected.

0.7.2 — 2026-06-29

The Debug-tab buffer downloads ("Download JSONL" and the per-file buffer download) no longer save an empty file on sites whose serving stack compresses or proxies the response. The downloads now let the transport negotiate compression instead of double-encoding the body.

0.7.1 — 2026-06-25

Documented exactly which PHP errors the agent can and cannot capture — in SIGNALS.md, the readme FAQ, and a new "PHP Error Capture" card in the admin Debug tab. The agent records warnings, notices, deprecations, and uncaught exceptions, and makes a best effort on fatals, but cannot see process-level crashes (out-of-memory kills, segfaults, request timeouts) or errors that occur before the plugin loads. Documentation only; behaviour unchanged.

0.7.0 — 2026-06-22

New

Client IP & Proxy diagnostic in the Debug tab shows how the agent resolves the visitor IP for your setup, and generates the exact wp-config.php line to add when it's wrong — most commonly for sites behind Cloudflare, where the real visitor IP is otherwise missed. The card is read-only and changes no behaviour.

Security

X-Forwarded-For spoofing is now prevented: the real client IP is resolved from the right of the forwarding chain, not the left (which any client can append), so an attacker can no longer plant a forged IP in security signals. Common single-proxy setups are unaffected; multi-hop chains can be named with the new LOGYSTERA_TRUSTED_PROXIES constant.
Installing an mTLS client certificate when encryption is unavailable now fails with a clear error instead of storing the private key in plaintext. Certificate install also now rejects not-yet-valid (future-dated) certificates and encrypted (passphrase-protected) private keys, each with an actionable message.
A misconfigured gateway URL now properly engages the 5-minute backoff instead of retrying every tick.

Reliability

An XML-RPC request no longer risks a fatal on older WordPress cores or third-party XML-RPC dispatchers.
A fatal error is now correctly recorded as a fatal even when it renders through WordPress recovery mode, and the fatal-report path no longer blocks the recovery page for slow/unreachable gateways (delivery capped to ~1 second; the record is already durable on disk).
On a quiet site, heartbeats and other non-batch requests from an mTLS install are now certified correctly, avoiding a spurious gateway rejection.

0.6.1 — 2026-06-11

A permanently-disabled install no longer misreports itself as connected on the next pageload (capture and delivery were already correctly paused; this fixes the state the admin UI showed).
On multisite, every blog now contributes its ingest-latency sample each cron tick, instead of only the first blog flushed.

For releases before 0.6.1, see the changelog bundled with the plugin (readme.txt) or the plugin's releases page.