Steve Hanlon
3d67b94896
Some managed hosts (WPE and various resellers, plus some clients' own ops teams) don't let us edit wp-config.php. Add a settings-screen alternative so the plugin can be configured without touching filesystem constants. Storage + resolution: - Two new options: att_hc_api_url and att_hc_api_key, autoload=false on the key so it isn't loaded on every request. - ATT_HC_Api::url() and ATT_HC_Api::key() are the single source of truth now — they return the wp-config constant when defined+non-empty, else the option, else ''. Everything else (request(), config_error(), is_configured(), the admin config-error notice) uses these accessors. - url_from_constant() / key_from_constant() drive per-field locking on the settings page and are also checked by the save handler so a constant-locked field can't be overridden by a crafted POST. UI: - New "Central history server" card at the top of Tools → Site Healthcheck → Settings with URL (type=url) and API key (type=password) inputs. When a constant is defined the field is disabled with a "Set via <constant> constant" hint. - Separate form action/nonce (att_hc_save_api_settings) so it doesn't tangle with the existing Gitea recovery save. - The blocking config-error notice on the main page now offers an "Open settings" button alongside the wp-config.php snippet. Verified with an 18-assertion test suite covering no-config, options- only, http-blocked-with-clear-message, loopback-http-allowed, and constant-wins-over-option. Both PHP 8.3 and PHP 7.4 parse cleanly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
- 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
natsortorder). - Conditionally drop on one install: use the
att_hc_stepsfilter tounsetthe 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). Distributed as a built ZIP. A self-hosted update channel is hc-5ix.27 on the phase-3 backlog.
Tracking
cd ~/dev/wp-healthcheck
bd list --label phase-1 # MVP work
bd list --label phase-3 # automation backlog