Steve Hanlon
4e030ae5ee
Step 3 (Core) now does three independent lookups: - Installed version (the truth, from $wp_version) - Latest per WordPress (via get_core_updates — what WP_Downgrade can manipulate) - Latest per wp.org (direct call to api.wordpress.org/core/version-check/1.7/ cached 1h, can't be cloaked from the server side) If 'Latest per WordPress' < 'Latest per wp.org', the finding is bumped to bad with a CLOAKED detail message. The wp_downgrade_core_version option is also surfaced verbatim so it's obvious where the pin lives. Step 4 (Plugins) similarly: - wp_org_info() now captures the version field from the WP.org plugins info API. Cache key bumped to wph_pi2_ so existing entries get re-fetched. - For each plugin: installed version vs wp.org reported version. - If installed < wp.org AND the WP update_plugins transient doesn't flag it, the row is bad with 'CLOAKED — WP says up-to-date'. - Cloaked count surfaces in the summary. Both steps also explicitly detect a roster of known cloaker plugins (WP Downgrade, WP Rollback, Easy Updates Manager, Disable Updates Manager, Stops Core/Theme/Plugin Updates, Companion Auto Update) and warn when any are active, so the technician sees the framing before diving into individual rows. Smoke-tested with WP Downgrade installed and wp_downgrade_core_version set: both findings fire correctly, target version is surfaced.
Site Healthcheck
Internal WordPress plugin that walks a technician through a structured healthcheck. Companion to wp-site-recovery, which it expects to be installed as step 0.
Install
ln -s ~/dev/wp-healthcheck /path/to/wp/wp-content/plugins/site-healthcheck
Then activate from Plugins. Settings appear under Tools → Site Healthcheck.
Use
- Open Tools → Site Healthcheck.
- Confirm the recovery plugin status panel shows ✓ active.
- Click Start new healthcheck.
- Work through each step card. For each: choose a status (done / skipped / blocked / n/a) and add notes.
- Click Finish & generate report.
- Download the Markdown report or copy it to clipboard.
One in-progress session per site at a time. Reports are not stored in the database (the plugin is meant to be uninstalled at the end of each engagement) — download them.
Adding, removing, reordering steps
Each step is a single file under includes/steps/ named <order>-<slug>.php.
<?php
// includes/steps/45-staging.php
return new class extends WPH_Step {
public function id(): string { return 'staging'; }
public function title(): string { return 'Step 4.5 — Verify Staging Sync'; }
public function sub_items(): array {
return ['Re-deploy from production', 'Run smoke tests'];
}
};
- Add: drop a new file.
- Remove: delete the file.
- Reorder: rename the numeric prefix (steps are loaded in
natsortorder). - Conditionally drop on one install: use the
wph_stepsfilter tounsetthe step by id.
Stable string IDs (returned by id()) are what's stored in session data, so renaming a file does not break in-progress sessions as long as the id stays the same.
Phase roadmap
Phase 1 (this) is a checklist + Markdown report. Phase 3 will add per-step automation — backup detection, env auto-collect, plugin update intelligence, PageSpeed Insights, SSL checks, etc. See beads epic hc-5ix for the full plan.
Distribution
Internal/agency tool — not a WP.org plugin (decision hc-5ix.26). Distributed as a built ZIP. A self-hosted update channel is hc-5ix.27 on the phase-3 backlog.
Tracking
cd ~/dev/wp-healthcheck
bd list --label phase-1 # MVP work
bd list --label phase-3 # automation backlog