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)
ftp (optional overlay)	atmoz/sftp	https://github.com/atmoz/sftp	https://github.com/atmoz/sftp/releases (image: https://hub.docker.com/r/atmoz/sftp)

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.
atmoz/sftp is pinned as the floating alpine tag (updated 2026-07-28, current as of 2026-08-21) — not a semver abra can evaluate, so it never contributes an upgrade candidate; verified current by direct Docker Hub tag check. Only bump if a real newer supported tag exists and the app needs it.