Adds a Reopen button on the session-detail view for finished sessions.
POSTs to /dashboard/healthchecks/{id}/reopen with a per-session CSRF
token; on success clears finished_at and redirects back to the session.
Also tightens Controllers/Healthchecks::update so a PUT with no
finished_at key is a no-op instead of silently setting it to NULL —
otherwise an empty PUT would reopen any completed healthcheck.
After reopening, the WP-side Session::resume($id) flow pulls the now-
active session back into an editable local session on the client site.
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/att-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 ATT_HC_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
att_hc_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). Installed sites auto-update from Gitea via Plugin Update Checker (vendored under vendor/plugin-update-checker/). PUC polls updates.json on the repo's main branch twice a day; new versions appear in Dashboard → Updates.
Releasing a new version
- Bump
Version:in theatt-site-healthcheck.phpheader andATT_HC_VERSION. - Bump
versionandlast_updatedinupdates.json. - Commit + push to
main.
Installed sites pick it up on their next update check (or immediately if an admin clicks Check again on the Updates screen). The download_url points at archive/main.zip, so whatever's on main at fetch time is what gets installed.
Updating PUC itself
PUC is a vendored copy, not a submodule (so Gitea's archive/main.zip includes it). To update:
cd /tmp && git clone --depth 1 https://github.com/YahnisElsts/plugin-update-checker.git puc-new
rm -rf vendor/plugin-update-checker
cp -R /tmp/puc-new vendor/plugin-update-checker
rm -rf vendor/plugin-update-checker/{.git,.github,build,vendor,examples,composer.json,phpcs.xml}
Tracking
cd ~/dev/wp-healthcheck
bd list --label phase-1 # MVP work
bd list --label phase-3 # automation backlog