Lint new PHP code on the oldest runtime which needs to execute it. A development machine can accept syntax that a test server, production host or scheduled job cannot even parse. I record the supported versions and make that oldest one part of the release check.
Write down the versions that matter
I keep a short environment table covering local development, the test site, production and command-line jobs. It includes the PHP version and important extensions. “The site is on PHP 8” is too broad when a language feature appeared part-way through that series.
The oldest supported runtime sets the syntax floor. Newer local tools are fine, but they do not remove the need to test that floor. If I decide to raise it, that becomes an explicit upgrade and deployment task rather than an accidental side effect of a code tidy-up.
Lint what will run
For a small PHP change, syntax checking the deployed file with the correct binary is a quick, useful canary. For a plugin, I check all changed PHP files and run the relevant test suite under the minimum supported version as well.
# Use the binary for the version you actually support.
php8.1 -l path/to/changed-file.phpThe version in this example is illustrative, not a recommendation to keep an old runtime indefinitely. Use a supported release suitable for the application, and keep the project’s declared requirements aligned with its tests.
Parsing is only the first check
Lint will not tell me whether a newer library function exists, whether an extension is loaded, or whether a hook runs correctly in WordPress. I follow it with a representative page request and the feature’s actual workflow. A scheduled task deserves its own check because command-line PHP may be configured differently again.
For deployment automation, I want a failed compatibility check to stop promotion before the new release receives traffic. If the site has already switched, the health check needs a real rollback path and a useful error record.
Keep the environment difference useful
A test environment on the minimum supported PHP version can be a valuable canary. It only helps if I actually inspect the result after deployment. A pipeline saying it copied the files successfully says nothing about whether PHP can execute them.
I do not try to make every environment identical at all costs. I make the differences explicit and test the ones that could change behaviour. That gives me a practical compatibility check rather than a hopeful assumption based on whichever machine I happened to write the code on.