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

1. Open Tools → Site Healthcheck.
2. Confirm the recovery plugin status panel shows ✓ active.
3. Click Start new healthcheck.
4. Work through each step card. For each: choose a status (done / skipped / blocked / n/a) and add notes.
5. Set Next healthcheck due to when the site should be looked at again. It's stored centrally and shows against the site on the dashboard, flagged when it's within a fortnight or overdue. Settable before or after finishing; leave it empty (or clear it) if nothing is scheduled.
6. Click Finish & generate report.
7. 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 natsort order).
• Conditionally drop on one install: use the att_hc_steps filter to unset the 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

1. Bump Version: in the att-site-healthcheck.php header and ATT_HC_VERSION.
2. Bump version and last_updated in updates.json.
3. 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