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.
Vendors YahnisElsts/plugin-update-checker v5.7 under vendor/ and wires it
to poll updates.json on the repo main branch. WP surfaces new versions
via Dashboard → Updates on its normal twice-daily cadence.
PUC is vendored (not a submodule) so Gitea's archive/main.zip — the
download target — includes it. Folder rename on install is handled by
PUC's built-in upgrader_source_selection filter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wholesale rename to avoid clashes with generic 'site healthcheck'
plugin names on a target site:
- Plugin Name: 'Site Healthcheck' → 'ATT Site Healthcheck'
- Main file: site-healthcheck.php → att-site-healthcheck.php
- Plugin folder: site-healthcheck → att-site-healthcheck
- Admin menu slug: site-healthcheck → att-site-healthcheck
- Settings slug: site-healthcheck-settings → att-site-healthcheck-settings
- PHP class prefix: WPH_ → ATT_HC_
- Function prefix: wph_ → att_hc_
- Option / transient: wph_* → att_hc_*
- Action/filter: wph_* → att_hc_*
- CSS class prefix: wph- → att-hc-
- Constants: WPH_GITEA_* → ATT_HC_GITEA_*
- Class file names: class-wph-*.php → class-att-hc-*.php
- Dev folder: ~/dev/wp-healthcheck → ~/dev/att-site-healthcheck
Existing in-progress sessions on installs that had the old wph_session
option will not migrate — they were intended for dev use only and the
user has confirmed this is OK for the rename window.
Smoke-tested on testsite: classes load, 14 steps discovered, save/load
round-trip works, admin page renders with new att-hc- CSS classes.
Recovery plugin detection unchanged — that lives in wp-site-recovery
and continues to be detected by Name + Author header.
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.
