Test a WordPress plugin across multiple PHP versions.
Use the same WordPress baseline and plugin commit, combine PHPCompatibilityWP and PHPStan with real runtime behavior, then compare warnings and failures without sharing state between tests.
PHP 7.4, 8.2, 8.3 and 8.4.
SpawnWP provides the same extension set and development tools on every supported runtime. PHP 7.4 is end-of-life and exists only to investigate legacy compatibility; PHP 8.3 or newer remains the sensible baseline for new projects.
Change one variable at a time.
Prepare a baseline
Choose Development or create a blueprint with the WordPress version, settings, dependencies and test content required by the plugin.
Create the first site
Spawn an isolated environment on the first target PHP version. Record the exact blueprint and WordPress version.
Install one plugin commit
Use the same source revision and fixtures in every environment. Do not mix a code change into the runtime comparison.
Run automated checks
Run Plugin Check, PHPCS/WPCS, PHPCompatibilityWP for the declared range and PHPStan with WordPress stubs.
Verify runtime behavior
Activate the plugin, execute its critical flows and inspect the debug log, Query Monitor, WP-Cron events and Mailpit messages.
Repeat the matrix
Create a separate site for each runtime when parallel comparison matters, or snapshot and switch PHP when sequential testing is enough.
Compare and clean up
Record version-specific failures, keep a snapshot only when it helps reproduce the issue, then reset or destroy the environments.
Evidence from both code and behavior.
| Check | What it catches | Evidence to record |
|---|---|---|
| PHPCompatibilityWP | Removed syntax, functions and version-dependent APIs | Rule, file, line and target range |
| PHPStan | Types, impossible branches and unsafe calls | Level/config and baseline diff |
| Plugin Check / PHPCS | WordPress.org requirements and coding standards | New errors versus known warnings |
| Runtime activation | Fatal errors, deprecations and bootstrap order | PHP version, WordPress version and debug log |
| Functional flows | Hooks, queries, cron, HTTP and email behavior | Expected result and observed difference |
Choose isolation based on the investigation.
Separate sites make side-by-side comparison and destructive tests easier. Switching one site's PHP runtime is faster when the database and files must remain exactly the same. Snapshot before a risky change and avoid treating a restored snapshot as an independent test baseline.
Make compatibility failures reproducible.
Start with one clean blueprint and an explicit list of supported PHP versions.