Files

Steve Hanlon 631385721f Next healthcheck due date, plus a test suite (hc-nkq)

Lets a technician record when a site should next be looked at, and surfaces
that in the dashboard so it can be used for planning.

Server:
- migration 0002 adds healthchecks.next_due, a VARCHAR(10) 'YYYY-MM-DD'
  calendar date rather than a timestamp — it's a diary date with no
  time-of-day, and a timestamp would render as the wrong day off-server.
- Kept per-session rather than on a sites table, so the history of what was
  scheduled when is preserved. A site's current next-due is the value on its
  most recent session: if the latest visit scheduled nothing, the site reads
  as unscheduled rather than showing the just-completed visit as overdue.
- Validate::optionalDate() round-trips through createFromFormat, which
  rejects both '2026-2-3' and '2026-02-30' (silently rolled to March 2nd).
- next_due follows the same missing-vs-null PUT contract as finished_at, and
  lives in its own Store::setNextDue() so finishing or reopening a session
  never disturbs the date and vice versa.
- Dashboard shows it on the site list, the per-site session table and the
  session detail, flagged overdue / today / soon (within a fortnight).

Plugin:
- Date control on both the active and finished panels — the moment you know
  when to return is often wrap-up, after the report is generated.
- Write-through like every other mutation. Bad input is rejected with a
  notice rather than silently clearing an existing date.
- Included in both the Markdown and HTML reports.

Tests (new — tests/, export-ignored from the plugin zip):
- Hand-rolled harness, no composer/PHPUnit, in keeping with the repo.
- 42 tests: plugin-side date parsing units, plus server integration tests
  driven over real HTTP against a temp `php -S` instance with a throwaway
  SQLite DB, so a real server/config.php is never touched.
- Mutation-checked: dropping the array_key_exists guard on PUT fails three
  tests, as intended.

2026-07-23 12:02:39 +01:00

3.6 KiB

Raw Blame History

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.
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.
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 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

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

3.6 KiB Raw Blame History