feat: apply configured php_version to the WordPress image

[kjellbergzoey]

Summary

WordPressConfig.php_version was written to kiqr.yaml by kiqr init but never read — BitnamiRuntimeProvider.getWordPressImage() hardcoded PHP 8.3. This wires the configured php_version through RuntimeConfig so the config key actually selects the image.

Image tag mapping:

WordPress version	Image
latest	wordpress:php<php_version> (e.g. wordpress:php8.3)
pinned <ver>	wordpress:<ver>-php<php_version> (e.g. wordpress:6.7-php8.3)
wp-cli service	wordpress:cli-php<php_version> (kept in sync with the runtime PHP)

Tag verification

Before relying on these schemes I verified the tags exist on Docker Hub via the registry API:

• bare php8.2, php8.3, php8.4, php8.5 ✅
• 6.7-php8.3 (and the general <ver>-php<ver> scheme) ✅
• cli-php8.2 … cli-php8.5 ✅

Safety

• The default php_version is '8.3', so the default image becomes wordpress:php8.3, which is functionally equivalent to the previous wordpress:latest — no surprise upgrade for existing users.
• This is a pure image-tag string change; it does not change how docker compose / docker compose run are invoked.

Tests

tests/providers/BitnamiRuntimeProvider.test.ts updated to cover both the latest and pinned-version paths plus the wp-cli image; phpVersion added to the RuntimeConfig fixtures in the provider and compose tests.

npm run typecheck, npm test (72 passing), and npm run build all green.

🤖 Generated with Claude Code

[kjellberg]

Make sure this work with different combinations of wordpress + php version? @kjellbergzoey what do you think?

[kjellbergzoey]

Great catch @kjellberg — I verified against the Docker Hub library/wordpress tag list and you're right that not every WordPress × PHP combination is published, so naively building wordpress:<ver>-php<php> can produce a tag that doesn't exist (the pull then fails). Sample of what actually exists today:

WordPress	Published PHP variants
latest	php8.2, php8.3, php8.4, php8.5
6.7	php8.1, php8.2, php8.3, php8.4
6.4	php8.0, php8.1, php8.2, php8.3
6.0	php7.4, php8.0, php8.1
cli	php8.0 → php8.5

So e.g. wordpress:6.4-php8.5 and wordpress:6.7-php8.5 don't exist.

Plan (follow-up PR): add a small, best-effort preflight that resolves the configured combo against the Docker Hub tags API before kiqr up pulls:

• If the exact <ver>-php<php> tag is missing, fail fast with a clear message listing the PHP versions that are available for that WordPress version (so the user can fix php_version in kiqr.yaml).
• Best-effort only: if the API is unreachable (offline), skip the check rather than block up.
• Pure, unit-tested helper (mocked fetch) so it's covered without a live network/Docker.
• Bonus: surfaces nicely in kiqr doctor too (feat: add kiqr doctor preflight command #12).

This keeps the php_version feature here as-is (it's correct for valid combos) and adds the guardrail separately. I'll open that PR shortly. 🤖

[kjellberg]

Make it validate the config before "up" @kjellbergzoey

[kjellbergzoey]

On it, @kjellberg. I'll add the validation as a fail-fast preflight step inside the up flow itself (not a separate doctor-only path), so a bad php_version in kiqr.yaml stops the run before Docker tries to pull a non-existent tag.

Concrete plan

1. New helper src/lib/image-tags.ts:

   • resolveWordPressTag(version, phpVersion) → builds the expected tag (wordpress:php<php> for latest, wordpress:<ver>-php<php> otherwise — same logic as BitnamiRuntimeProvider.getWordPressImage).
   • assertImageAvailable(version, phpVersion) → queries the Docker Hub tags API for library/wordpress, and if the exact tag isn't published, throws with a clear message listing the PHP versions that are available for that WordPress version. Best-effort: on fetch failure/timeout (offline) it resolves silently rather than blocking up.

2. Wire into up.tsx: insert a 'Validating configuration...' step in the steps array — right after 'Loading project...' (where pc/lc are read) and before 'Preparing site...' (where writeProjectCompose runs). It calls assertImageAvailable(pc.wordpress.version, pc.wordpress.php_version). Since StepRunner already surfaces thrown errors, a bad combo shows a clean failure instead of a confusing docker pull error.

3. Same guard in restart.tsx for consistency (it shares the same compose-write path).

4. Tests: unit-test the helper with a mocked fetch — valid combo passes, invalid combo throws with the available-versions list, network error is swallowed. No live network/Docker needed in CI.

This keeps the php_version feature in this PR correct for valid combos and adds the guardrail on top. I'll flag Rasmus to open the implementation PR.

🤖 (auto-reply via Zoey)