# Upstream sources — wordpress

| service | image | source repo | releases / changelog |
|---------|-------|-------------|----------------------|
| app | wordpress | https://github.com/WordPress/WordPress | https://wordpress.org/news/category/releases/ (image: https://hub.docker.com/_/wordpress) |
| db | mariadb | https://github.com/MariaDB/server | https://mariadb.com/kb/en/release-notes/ (image: https://hub.docker.com/_/mariadb) |

## Standing notes
- Enrolled 2026-08-03 (operator request). Recipe = coopcloud `wordpress`; mirror
  `recipe-maintainers/wordpress` synced from upstream `adcd0e9f` (recipe 3.0.3+7.0.2:
  wordpress 7.0.2, mariadb 12.3).
- The CI env runs NO `POST_DEPLOY_CMDS core_install` — a fresh deploy serves the install
  wizard, and `tests/wordpress/custom/_wp.py` completes it with run-scoped credentials.
- The recipe templates `.htaccess` via `htaccess.tmpl` (config `htaccess_conf`) — the pretty
  REST route `/wp-json/` depends on it; `tests/wordpress` asserts both it and the
  rewrite-independent `?rest_route=` fallback so a broken overlay names the right layer.
- XML-RPC (`xmlrpc.php`) ships enabled and is used by the §4.3 post round-trip test with the
  admin user/password. If a future recipe version disables XML-RPC (a common hardening), the
  test must move to REST + application-passwords — that would be a legitimate stale-test fix,
  not a regression.
- WORDPRESS image tags: the recipe pins `wordpress:<major.minor.patch>` (Docker official
  image). mariadb major bumps (e.g. 12.x→13.x) need the usual dump/restore caution if the
  recipe ever pins a non-`mariadb`-auto-upgrading setup; the official image handles minor
  bumps in place.