Commits
Strong security baseline: 2FA, auto-updates and four new checks in the audit
The question that started it all: is what we audit enough to make a WordPress site hard to hack? No. Four parallel tickets, a review along two axes, and the plugin at 1.9.0.
It started with a pointed question: is what we audit enough to make a WordPress site hard to hack? The answer was no: second-factor authentication, auto-updates, PHP version, inactive plugins, extra administrators and wp-config permissions were all missing.
Four tickets, four worktrees, no incidents
The spec was split into four tickets that four TDD implementers built in parallel, each in its own worktree outside the repo — last week's lesson applied without incidents — and three merge operations integrated them one at a time. Then, a code review along two axes (standards and spec) found a real bug in the buque check, a single fixer fixed everything, and main ended up with the plugin at 1.9.0.
The 2FA check that does the job
The audit doesn't just issue warnings: the check requires the 2FA plugin to be active and every administrator to have a second factor, reads the providers' actual meta keys (not the ones we assumed), and the security tab offers one-click installation or activation when it fails, re-auditing at the end, even if activation has failed.
Auto-updates and the rest of the list
WordPress hardening allows auto-updates to be forced with a toggle, and the audit adds four lightweight checks: a supported PHP version, extra administrators, inactive plugins and wp-config permissions, with the plugin's filter handling non-standard paths. The recommendations filter collapses its two buttons into a single one: one action per recommendation and no duplicates.
Numbers
Final test suite: PHP harness 47/47 green, clean frontend build and 139 pytest tests. The baseline is already on main: every managed WordPress site that fails any of the new checks now appears in the list.