Steve Hanlon
631385721f
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.
85 lines
3.6 KiB
Markdown
85 lines
3.6 KiB
Markdown
# Site Healthcheck
|
|
|
|
Internal WordPress plugin that walks a technician through a structured healthcheck. Companion to [`wp-site-recovery`](../wp-site-recovery/), which it expects to be installed as step 0.
|
|
|
|
## Install
|
|
|
|
```sh
|
|
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
|
|
<?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](https://github.com/YahnisElsts/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:
|
|
|
|
```sh
|
|
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
|
|
|
|
```sh
|
|
cd ~/dev/wp-healthcheck
|
|
bd list --label phase-1 # MVP work
|
|
bd list --label phase-3 # automation backlog
|
|
```
|