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.
Plugin skeleton, drop-in step registry, option-backed session, single-page
checklist UI, downloadable Markdown report. Steps live as one file each
under includes/steps/ — adding/removing one is a single file change.
Step IDs are stable strings so renaming files preserves session data.
Architecture (hc-5ix.3): WPH_Steps singleton globs includes/steps/*.php,
natsort-orders by filename, requires each file (which returns a WPH_Step
instance), then applies a 'wph_steps' filter so installs can drop steps.
Session (hc-5ix.4): option-backed (per decision — plugin is installed
per-engagement, so DB-resident history would be lost on uninstall).
Single in-progress session per site; finished sessions render a report
that the user downloads/copies.
Recovery bootstrap (hc-5ix.1): detects whether wp-site-recovery is
installed + active, surfaces state on the start panel and in every
active session. Manual install for now; private update channel deferred
to hc-5ix.27.
Smoke-tested on testsite: registry discovery (13 steps in correct order),
start → update_step → progress count → finish → 8KB Markdown report →
discard cycle.
