SpawnWP 0.5.20¶
All of this comes from @wpeasy's reports in discussion #8 — thank you. Four findings, and underneath them two causes that had been there far longer than anyone thought.
Deploys stop rebuilding the PHP image every time¶
The symptom: "every deploy rebuilds PHP" — the five-minute build that was supposed to happen once.
The cause: the image tag was keyed on the PHP version alone, but the image contents also
depend on the WordPress version (the Dockerfile bakes it in). So a site on latest and a
blueprint that pins, say, WordPress 7.0.1 were fighting over one mutable tag: each deploy re-tagged
wp-dev-php:8.4 from under the other, the other's cache key stopped matching, and they rebuilt each
other forever.
The tag now carries the WordPress version — wp-dev-php:8.4 for latest, wp-dev-php:8.4-wp7.0.1
when a blueprint pins one. They coexist instead of overwriting each other, and the cache does what
it always claimed to.
This also quietly fixes something nobody had reported: because the two sites shared one tag, a site brought Down and back Up could come back on another site's WordPress core.
A second, independent cause of the same symptom: switching a site's PHP version built the image
without stamping its cache key, labelling it dev. Every later deploy on that PHP version then saw
a mismatch and rebuilt. The build key now lives in exactly one place
(scripts/lib-image.sh), and CI fails if a second copy of it ever appears.
A deploy could die with "This does not seem to be a WordPress installation"¶
bootstrap waited for the database and then ran wp core install — but nothing waited for
WordPress itself. On a first start the container spends a while extracting the whole install
into an empty volume, and the health check (php-fpm -t) is a config syntax test that passes
instantly and says nothing about it. Win the race and the deploy failed outright and rolled the site
back — most likely right after an image rebuild, when the extraction is slowest.
Bootstrap now waits for the core files. The nginx health check gets the same 60-second grace as PHP, which is the other half of the "container was not healthy" report.
System → Refresh works again¶
Refreshing a PHP image failed with a bare Exited with code 2. On an install where the primary
project has no .env, a grep for the WordPress version exited non-zero and — under
set -euo pipefail — killed the script before its own fallback could run. Exactly as @wpeasy
diagnosed. The same trap was lurking in the image garbage collector; both are fixed.
Stray files no longer cost you a five-minute rebuild¶
The cache key was computed over every file in the image build directory. A single editor backup or
.DS_Store changed it — invalidating the cache, and propagating into every site created afterwards.
It is now computed over the files the Dockerfile actually uses, and CI fails if a new build input is
added without being registered.
Every site gets HTTP/2¶
nginx here was already built with HTTP/2 and terminating TLS with ALPN — it was simply never switched on, so every site was served over HTTP/1.1. It is enabled now, for sites and for the cockpit. Existing installations are migrated automatically on update; HTTP/1.1 clients are unaffected.
What you need to do¶
Nothing. Sites created before this release keep working exactly as they are.
The first deploy on each PHP version after updating pays a one-off image rebuild (the cache key changed shape), which also clears out any image left holding the wrong WordPress core. After that, deploys reuse the image the way they were always meant to.