Releases: ovos/console-client-wordpress
Release list
0.5.8 — the release announce
0.5.8
New: the release announce. When the configured release label changes, the plugin tells the console once, on the next admin request (POST /api/v1/ingest/release), so the console knows the deploy the minute it happened instead of learning it from the first tagged error — the STATS rail shows the release before any error names it, and the verified close measures "silent since" from the real deploy moment. The label announced last is remembered in the ovos_console_announced_release option (removed on uninstall); a refused or unreachable console is simply retried on the next admin request. Sender::announceRelease($release = '', $options = []) is there for deploy hooks that want to say it themselves — with an optional moment, ref and source. Older consoles answer 404 and nothing else changes.
No configuration change. Update by replacing the plugin directory with the zip below, or through your usual deployment.
Requires PHP 8.1+, WordPress 6.0+.
Full changelog: readme.txt.
0.5.7 — every web report carries the response status
0.5.7
New: every web report carries the HTTP status the response ended with. The plugin reads http_response_code() at its shutdown flush, after the response went out, and sends it as status — 500 for the fatal, 404 for the not-found page WordPress rendered, 403 for a refused request. The console (2026-09 release) indexes it: a STATUS column in the ERRORS grid, a filter by code (500) or class (5xx), the statuses an issue produced in its detail, and "all 403 responses" in the AI search and the MCP tools. Only a status in 100..599 is sent; CLI runs and requests with no status decided send none, so the console never guesses one. Older consoles ignore the field.
No configuration change. Update by replacing the plugin directory with the zip below, or through your usual deployment.
Requires PHP 8.1+, WordPress 6.0+.
Full changelog: readme.txt.
0.5.6 — dependency failures marked for the console to drop
0.5.6
New: dependency failures are marked, so the console can drop them. The bundled browser client now records when one of the site's own scripts failed to load and marks every report that follows (scriptsFailed), beside the existing mark for scripts a bot never fetched (scriptsNotLoaded). The console (2026-09 release) flags such rows scripts_failed / scripts_missing and ships an installation rule that drops both shapes at the door — the "jQuery is not defined" and "Site is not defined" noise from bots that run a page's inline code without its bundles — counting them on the rule instead of filling the grid. Older consoles ignore the new key.
No configuration change. Update by replacing the plugin directory with the zip below, or through your usual deployment.
Requires PHP 8.1+, WordPress 6.0+.
Full changelog: readme.txt.
0.5.5 — the plugin names itself on every report
0.5.5
New: every report names the plugin that sent it. Each payload carries client: wordpress/0.5.5. The console (2026-09 release) shows the last reporting version per project in its PROJECTS grid and the report's own version in the error detail's META, so a site running an outdated or misbehaving plugin can be told apart at a glance. Older consoles ignore the field.
No configuration change. Update by replacing the plugin directory with the zip below, or through your usual deployment.
Requires PHP 8.1+, WordPress 6.0+.
Full changelog: readme.txt.
v0.5.4
The reports name what ran, how it was entered and what they are — and the security events carry their evidence.
New: the three axes on every report
The console's 2026-09 release replaced its mixed type field (http, cli, js, 404, security) with three closed vocabularies it groups and filters by: runtime (what ran the code), entry (how it was entered) and kind (what the event is). Every report from this plugin now names them: runtime: php; entry: web, or cli under WP-CLI and cron; kind: error, not_found for the 404 reports, security for the refusals and audit lines.
What you see in the console: command-line errors wear a PHP·CLI badge, a web request and a cron hitting the same bug are one issue instead of two, and the TYPE filter groups by runtime, entry and kind. The old type field is still sent, so a console that has not updated yet keeps working exactly as before; it will be dropped in a later release once the consoles this plugin talks to have moved.
New: evidence on the security events
The console's event rules can ask failures >= N and action = X — and its seeded defaults page on a login that succeeded after three or more failures and on a save through the theme/plugin file editor. The plugin now sends what those rules read:
auth_successcarries failures — the number of recent failures the success followed (the larger of the per-account and per-address counts).- every
privileged_actionnames its sub-kind as action:admin_created,user_created,role_change,file_edit,app_password,plugin_activated,upgrade_plugin/upgrade_theme/upgrade_core,option_change.
Changed: the log-level gate judges only errors
The client-side log_level setting is a severity filter. The 404 and security reports are kinds, not severities — they ride the INFO band by design — so they now pass the gate regardless of the setting, as the console's own gates already treated them.
The bundled console-client.js is unchanged in this release.
v0.5.3
Streams no longer skew response times.
Changed: a streaming response counts as traffic, not as a duration
When rollups are on, every request's wall time (PHP start to shutdown) feeds the console's duration histograms. A server-sent-events response (Content-Type: text/event-stream) is held open for as long as the browser listens, so its wall time measured the subscription rather than the work — every stream landed in the slowest bucket, and a single SSE endpoint could own the site's average response time in the console's STATS and PERFORMANCE views.
Such a response now still counts as a request — status, method, route and logged-in split are unchanged — but contributes no duration. Detection is the media type the response declares (any case, with or without a charset), so nothing needs configuring. Sites without SSE endpoints see no difference.
The same rule ships in every ovos/console sender (php-library, the CMS senders, the node client). The bundled console-client.js is unchanged in this release.
v0.5.2
One project, every stage — and masks that state their length.
New: the deployment environment rides every report
Every report (PHP and browser) now carries the site's deployment environment — wp_get_environment_type(): production, staging, development or local — so one console project can tell its stages apart. The console shows non-production values as a badge beside the project name and lets you filter and sort by them; production is stored and filterable but never badged. An explicit value can be set on the settings page or via the OVOS_CONSOLE_ENVIRONMENT constant. Older consoles simply ignore the field.
Changed: the e-mail mask says how long the address was
d***@hotmail.com said nothing about whether it hid "dave" or a 40-character address. E-mail local parts are now masked the way usernames already are — every fourth character revealed, the rest starred, exactly as long as the original (john.doe@example.com → j***.***@example.com). The domain stays, as before, and re-masking any shape (including a one-character local part, whose mask is the value itself) changes nothing.
The bundled console-client.js is re-synced from ovos/console and carries both changes.
v0.5.1
The site's speed, measured where the traffic is already counted.
New: request-duration histograms ride the traffic rollups
When rollups are enabled, every request now also counts its wall time — PHP start to shutdown — into 12 fixed buckets (25 ms … 30 s, then everything slower), per site and per route. The console reads them back as ≈p50/≈p95 trends with release markers and a slowest-routes table on its new PERFORMANCE panel, so "did the update make the site slow?" is answered by looking at the chart.
What leaves the site: bucket counts only, riding the same once-a-minute rollup fragment that already flows. A raw timing never sits in APCu and never crosses the wire, and the payload grows by a few hundred bytes a minute. Older consoles simply ignore the new key; if APCu evicts part of a minute, the plugin ships no histograms for it rather than a fragment the console would refuse — the traffic counters riding beside it are never collateral.
Requires a console with the PERFORMANCE panel (2026-08-31 or later) to display the data; sending is harmless against older consoles.
v0.5.0
The login that worked, and two more moves an intruder makes.
New: the success after the failures (auth_success)
Failed logins each report auth_failure — but in a credential-stuffing run the one presentation that succeeds is the only one that matters, and it was silent. The plugin now remembers failures for 15 minutes — per account and per source address, as counters in transients keyed by hash, never the username itself — and when a login lands on the heels of failures it reports a single auth_success security event carrying both counts: login succeeded for m***i* after recent failures (account: 3, address: 7).
A clean login reports nothing, ever: that would be surveillance, not security. In the console, a watch rule on class auth_success is the "page me when a spray works" switch.
The kind joins the closed security-event vocabulary on both sides (console, php-library and node senders updated in lockstep); an older console refuses the unknown kind wholesale and everything else keeps working.
New: two more post-compromise moves in the privileged_action audit family
- File-editor saves (
wp_ajax_edit-theme-plugin-file) — the classic webshell-by-editor move, legitimate on almost no production site. The file name is reported, the content never; even a refused attempt is worth the line. - Application passwords minted for administrators — persistent API access is what an intruder creates for durability. App passwords for non-admin service users stay unreported.
Changed: role changes say created vs promoted
WP core fires set_user_role for brand-new users too, so a born-admin account was always seen — but it read like any role change. Now the message says which move it was: user created: #12 as administrator vs user role changed: #12 subscriber -> administrator.
Full Changelog: v0.4.9...v0.5.0
v0.4.9
The site tells the console what it runs.
New: software inventory (opt-in) — the CVE sensor's sending half
When enabled (Settings → ovos console → Software inventory, off by default, lockable via OVOS_CONSOLE_INVENTORY in wp-config.php), the plugin reports the installed plugin/mu-plugin/theme list with versions — plus WordPress core and PHP versions — once a day and after anything that changes it: installs, updates, (de)activations, deletions, theme switches, core updates.
The console matches the inventory nightly against the Wordfence Intelligence vulnerability feed and shows CVE findings on its SECURITY view — installed version, the version that fixes it, CVSS, and a PROBED count when the console has already seen requests naming that plugin's path. "You run X, and someone is looking for it" is the signal worth acting on first, and it is what alerts.
Exactly what each entry carries: type, directory slug, version, display name, active flag — never paths, options or user data. Double opt-in: this setting and the project's CVE switch in the console; either one off keeps the feature fully inert. The report is a single fire-and-forget request at shutdown (300 ms connect / 1 s total), never a slowdown; an unchanged report costs the console one timestamp update.
New: automation evidence in the bundled browser client
Reports now carry two zero-config signals: a webdriver admission (headless browsers and the AI agents built on them set it by default) and the external scripts the visitor never even attempted to load — the signature of bots that execute a page's inline JS without fetching its script files, which is what a "jQuery is not defined" from a plain Chrome UA usually is. The console indexes both as the flags field: bot-caused issues facet and filter apart from real-user ones. Evidence only, never suppression.
Changed: the username mask says how much it hides
Masked usernames keep every fourth character instead of collapsing to a fixed m*** (marcin → m***i*), so the mask is as long as the value it replaced — and past 24 characters it states the real length in brackets, because a login field holding thousands of characters is someone trying something. Applied identically in the PHP reporter and the bundled browser client.
Full Changelog: v0.4.8...v0.4.9