# Parity — wordpress

The recipe-maintainer corpus has **no** `recipe-info/wordpress/tests/` directory — wordpress was
not in the recipe-maintainer parity suite. This PARITY.md documents the Phase-2-style
recipe-specific tests + health_check as the parity-aligned baseline (enrolled 2026-08-03 on
operator request).

## Recipe-specific tests (≥2 beyond parity)

wordpress is a classic PHP CMS on mariadb. A fresh CI deploy serves the install wizard (the CI
env sets no `POST_DEPLOY_CMDS core_install`); the custom tier completes the wizard itself with
run-scoped credentials (`custom/_wp.py`) and then exercises the installed site's real APIs.

| cc-ci file | what's verified | rationale |
|---|---|---|
| `custom/test_health_check.py` | GET `/` → 200 or 302 (install-wizard redirect). | traefik → app wiring floor. |
| `custom/test_install_and_api.py` | Completes the install wizard (writes site options + admin user to mariadb), then asserts `/?rest_route=/` AND `/wp-json/` both return the configured site name. | Non-vacuous: the name only comes back if the install round-tripped through the DB. The two REST routes split failure layers: `?rest_route=` isolates "REST + DB", `/wp-json/` additionally proves the recipe's `.htaccess` rewrites are live. A DB-wiring failure is caught earlier by the installer's own "database connection" error, asserted in `_wp.ensure_installed`. |
| `custom/test_post_roundtrip.py` | §4.3 create-an-object + read-it-back: publish a post with a unique marker via **XML-RPC** `wp.newPost` (admin user/pass), read it back via the **public REST API** (`/wp/v2/posts/<id>`, title must contain the marker), then fetch the public permalink `/?p=<id>` and assert the marker in the served HTML. | The marker round-trips app → mariadb → app across three distinct subsystems (XML-RPC write, REST read, themed HTML render). A post that didn't persist, a broken DB, or a wedged PHP fails at the layer that broke. |

## Backup data-integrity (P4)

The recipe stores content in the `wordpress_content` volume + mariadb; backup-capable detection is
automatic (compose.yml `backupbot.backup` labels via the standard recipe mechanism). Lifecycle
overlays not yet authored — catch-up if backup data-integrity proves needed for this recipe.

## Playwright (P6)

Not authored. The install + post round-trip is API-driven; a Playwright pass over wp-admin would
add browser coverage of the dashboard. Follow-up if wanted.