[desrosj]

What?

unit-test.yml's unit-php job ran once, unconditionally, on whatever PHP version the pulled wordpress/wordpress:cli Docker images default to — this branch's .wp-env.json never sets a phpVersion, and the job has no matrix: block, no shivammathur/setup-php step, and no PHP-version selection of any kind. Adds a real strategy.matrix testing PHP 5.6, 7.0, 7.4, 8.0, and 8.1 (the lowest and highest supported minor of every major this branch supports), wires WP_ENV_PHP_VERSION: ${{ matrix.php }} at the job level so wp-env's Docker Compose config generation actually picks a wordpress:php${version}-tagged image per leg, and adds a multisite: [false, true] companion axis so the existing single-site/multisite unit test runs (previously two unconditional steps inside the same job, gated on if: success() || failure()) become independent matrix legs instead. Also removes the spatie/phpunit-watcher dev dependency before linting/testing on PHP versions below 7.2, which it doesn't support.

Why?

Without a pinned PHP version, unit-php currently floats to whatever PHP version Docker Hub's wordpress/wordpress:cli latest-family tags resolve to today. Testing a real matrix of this branch's actually-supported PHP versions gives accurate, deterministic PHP-version coverage instead of an unversioned float, and isolates any genuinely PHP-version-specific failure to the one leg it actually affects rather than hiding it behind (or wrongly blaming it on) whatever PHP happens to be current on the day the job runs.

WP_ENV_PHP_VERSION is read directly by packages/env/lib/config/config.js (config.env.development.phpVersion/config.env.tests.phpVersion = process.env.WP_ENV_PHP_VERSION || ...), which packages/env/lib/build-docker-compose-config.js then uses to select the wordpress:php${version} / wordpress:cli-php${version} / wordpressdevelop/phpunit:*-php-${version}-fpm image tags — this branch's own copy of packages/env (v4.1.3) already supports the variable, so no source change to packages/env itself is needed, only the workflow wiring.

5.6 is a notably old PHP release for a CI matrix; verified before adding it that Docker Hub still serves the wordpress:php5.6, wordpress:cli-php5.6, and wordpressdevelop/phpunit:5-php-5.6-fpm images this branch's packages/env would request for that leg (all four other legs' images verified to exist too), so the infrastructure this fix depends on genuinely exists. 8.1 isn't one of build-docker-compose-config.js's explicitly-mapped PHPUnit-image versions on this branch, so it falls through to that image's latest tag, same as every other unmapped version — confirmed that tag also resolves.

This branch's unit-test.yml doesn't have the separate test-php(matrixed)/phpcs(unmatrixed) job split some sibling branches have — lint-php (wp-env run composer run-script lint) and both single-site/multisite PHPUnit runs stay inside the one unit-php job, so no host-side shivammathur/setup-php step or composer config platform.php override is needed: composer/phpcs already run inside the wp-env Docker container, using whatever PHP that container has, which WP_ENV_PHP_VERSION now correctly selects. Checked composer.json directly: it has no static config.platform.php override on this branch, so the Composer-resolution conflict already found and being fixed elsewhere in this project on wp/6.1 doesn't apply here.

Use of AI Tools

This PR was created by Claude Code under my supervision. All code should be treated as AI-produced and not yet reviewed by a human until this PR is marked Ready for Review.

[desrosj]

Not actually merged. GitHub auto-closed this as merged during a reorder of the wp/5.9 stack: the branch below it was force-pushed to a commit that contained this PR's head, which GitHub interprets as "merged into base". Merged PRs cannot be reopened, so this layer continues as #392 with identical commits and description.

🤖 Generated with Claude Code