VizProof Timeline

1.3.19

• Wording: the accessibility-tree check is now called “Content” everywhere (“Contenu” in French): settings (“Verdict: SEO and content”), results screen badges and metrics (CONTENT instead of STRUCTURE), change summaries and wp vizproof checks. It measures what a page says — headings, links, texts and their structure, as a screen reader reads them — and the old names hid that. Nothing else changes: the setting keys (check_a11y) and the report cause (a11y) keep their names, so tools reading them are unaffected.

1.3.18

• New: an element hidden from the comparison (“selectors to hide”) is still checked for presence. Hiding a third-party widget or an animated block keeps it out of the pixel comparison, but until now it also took it out of every check: the widget could stop loading for good and no scan would ever say so. The VizProof service now records, before hiding them, whether these elements are present and non-empty; a page where an element present in the baseline is gone or empty fails. wp vizproof report names the cause masque and lists the elements under masked_missing; the results screen explains it in the change summary.

1.3.17

• New: SEO metadata and the accessibility tree can now weigh in the verdict. Until now a change of title, description, canonical, robots, H1 or Open Graph, or of the accessibility tree, could at most turn a visually clean page into a warning. Each site now chooses, for each of the two checks: fail (a change is a failure: it counts in the totals and the score, and an update tool that rolls back on failures rolls back), warn (the previous behaviour, still the default) or off (left out of the verdict). Set it in Automation > “Verdict: SEO and accessibility”, or with wp vizproof checks --seo=fail --a11y=fail; wp vizproof status reports the current levels under checks.
• wp vizproof report follows the same levels: a page whose only change is its SEO or its accessibility tree is a FAIL under fail, and a check set to off no longer appears in cause. Reports cached under other levels are not reused.

1.3.16

• Fix: no post-update scan after a bulk update. 1.3.15 waits for proof that a package reached the install step before scanning, and reads that proof in upgrader_pre_install. But a bulk update (the “Update selected” action in wp-admin, wp plugin update, wp theme update, and the hosting panels that drive WP-CLI, such as Plesk WP Toolkit’s automatic updates) does not put action or type in that hook, only the plugin or theme being installed. 1.3.15 skipped it, never saw the install, and cancelled the scan of every real update made that way. Seen on a fleet of sites updated each night by the hosting panel: eight sites updated, three scanned. The plugin now recognises a bulk update from the plugin or theme it names, so the update is scanned again, and its rollback context (previous version, local backup of premium plugins) is captured as it is for a single update. A bulk update still takes no “before” baseline, as in every previous version: hosting panels run it unattended, one plugin at a time under a hard timeout, and a baseline before each plugin could be cut off half-way.
• Fix: the update scan now knows what was updated for single updates too. WordPress names the item of a single update (its own automatic updates, the “update now” link) in plugin or theme, and lists the items of a bulk update in plugins or themes. Only the plural was read, so every automatic update was scanned with an empty list of updated items, and the report could not attribute its differences to the plugin or theme that changed.

1.3.15

• Fix: no post-update scan when nothing was updated. WordPress fires upgrader_process_complete even when a plugin or theme package could not be downloaded (an expired premium licence, a refused download), and the plugin then scanned the whole site as if an update had happened. Seen on a fleet site: a premium form plugin was “updated” every night for a week at the same version, and every night a full scan ran for nothing. The scan now waits for proof that a package actually reached the install step; core updates, which never go through that step, behave as before.

1.3.14

• Fix: a page that answers an HTTP error is no longer taken for a normal render. The VizProof API did not record the status of the pages it captured: a 404 or a 500 was photographed, compared and even promoted as a baseline like any healthy page. On a test site whose inner pages all answered 404 (rewrite rules never written), wp vizproof baseline promoted that reference twice without a word, and every later comparison measured the distance to an error page. The API now records the status of each capture and refuses to promote a capture of an error page as a reference; wp vizproof baseline reports that refusal with the pages at fault and their status, instead of a generic “promotion impossible”.
• wp vizproof report gives each line an http_status when the API recorded it, including for a baseline, and a page in error is a FAIL whose cause starts with http (http, http+pixel…). A capture of an error page with nothing to compare it to is a FAIL too, never OK. Captures taken before the status was recorded carry no http_status and behave exactly as before.