# 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
```