FizteQ Pulse – Monitoring and error tracking

1.0.22

• Fix: an update was reported only when it first appeared. If a newer release came out while it was still pending — or the site updated to a version short of the latest — the dashboard kept naming the old version and never heard about the new one. It also stopped recognising the update as installed once it was, so it stayed listed as pending. Every change in the offered version is now reported, and the one it replaces is closed
• Fix: the same for WordPress itself — a site offered 7.1.1 was never told about 7.1.2
• Change: updates are reported as soon as WordPress learns of them — its own twice-daily check, or opening the Updates screen — instead of once a day, so a release found in the morning is not left out of that day’s summary
• Fix: in the moment after an install, before WordPress rebuilt its list of available updates, a check could read “no list” as “nothing pending”, resolving every open update and then reporting them all again

1.0.21

• Fix: when a plugin or theme update was installed, the dashboard was told once and never again. If that one message did not get through — the dashboard busy, briefly unreachable, or refusing the request — the site had already forgotten, and the dashboard went on listing an update as pending on a site that had installed it. The message is now kept until it is acknowledged

1.0.20

• Fix: installing this plugin twice no longer reports everything twice. WordPress identifies a plugin by its folder, and this one arrived under two — fizteq-pulse from WordPress.org, wppulse from the dashboard download — so installing the second over the first added a copy instead of updating it, and both ran. The extra copy now stops itself and says so on the Plugins screen, rather than doubling every report and exhausting the dashboard’s rate limits
• Change: the zip downloaded from the dashboard now unpacks as fizteq-pulse, matching the WordPress.org install, so uploading it by hand updates the plugin instead of adding a second one beside it
• Fix: the uninstall report named a fixed plugin folder that was only ever right for one of the two installs, so uninstalling from a WordPress.org install reported a folder that was not there

1.0.19

• Fix: while the dashboard could not be reached, every PHP error on a page made the visitor wait for the connection to time out — up to ten seconds each, and up to five errors on one page load. Reports are now handed to the scheduler instead of being sent mid-page, so nothing this plugin does can slow a site down, whatever state the dashboard is in
• Fix: the plugin no longer keeps resending reports the dashboard has already refused. Repeating a rejected request changes nothing and, to a firewall, looks like an address worth blocking — which is how a site could end up unable to report at all
• Change: only the request headers that help explain an error are reported. The full set carried ordinary browser headers that security filters read as an attack, which was enough to get a reporting site blocked
• Fix: on a busy site WordPress can run its scheduler several times at once, which sent several heartbeats within the same second. The surplus was refused and then recorded as a failed report, so a healthy site accused itself of being unreachable
• Fix: the Flush button now says what actually happened. It reported “sent successfully” whenever the queue ended up empty, which is also what happens when the dashboard refuses the events outright — the one place an admin can check whether reporting works was capable of confirming it while nothing arrived

1.0.18

• Fix: a plugin or theme replaced on disk — over FTP, by a host’s own updater, or by a deployment — was not reported until the next daily check, because WordPress announces no change in those cases. The installed list is now compared on every heartbeat, so an update made any way at all reaches the dashboard within minutes and clears any security advisory it fixes
• New: a Sync now button on the settings page reports the installed plugins and themes immediately
• The settings page now says when the installed list was last checked, not only when it was last sent. A site that has not changed in weeks was correctly showing a weeks-old report, which read exactly like reporting having stopped

1.0.17

• Fix: database errors were almost never reported. WordPress clears the last error every time it runs another query, so the old check — which ran once at the end of the request — could only ever see a failure from the very last query. Errors are now caught as they happen
• New: a database error arrives with the query that failed, the tables it touched, and the plugin or theme line that ran it, instead of just WordPress’s own wording. Values in the query are replaced with ? before it leaves the site
• New: database and REST API errors say what the site was doing at the time — a page on the front end, wp-admin, an admin-ajax action by name, a REST route, WP-Cron, or WP-CLI
• Database errors that name a table, column or key now keep that name in the message. It used to be blanked along with the row data, which left errors such as “Table ‘[value]’ doesn’t exist” with the one fact they existed to report removed
• Each distinct failing query is now its own issue, rather than every database error on a site collapsing into one