How to Test WordPress PHP Compatibility Across Plugin Versions

WordPress PHP compatibility testing means checking whether your plugin behaves correctly on each PHP and WordPress version combination you support. With a WordPress sandbox on wp.run, you can launch clean test installs, such as PHP 8.4 with WordPress 6.9, then repeat the same smoke test without local servers or production risk.

You can start the first check now: press Launch WordPress at the top of this page, choose the PHP and WordPress versions you want to test, and run the plugin inside a disposable WordPress site with real wp-admin access.

Why WordPress PHP Compatibility Needs a Matrix

A plugin can pass on one stack and fail on another. PHP changes can expose deprecated syntax, stricter typing behavior, removed functions, or warnings that did not appear on an older runtime. WordPress changes can affect editor behavior, hooks, REST endpoints, admin screens, and bundled JavaScript.

That is why a single “works on my machine” check is not enough. Plugin compatibility testing should cover the combinations your users actually run:

The official WordPress Core handbook maintains a PHP compatibility table for WordPress itself. Treat that as your baseline for core. Your job is to test your plugin on top of those stacks, because WordPress core compatibility does not guarantee every plugin or theme behaves correctly.

Build a Small PHP x WordPress Version Matrix

Start with the smallest matrix that answers a real release question. For most plugin teams, that means three rows before every meaningful release:

1. Oldest supported stack. This catches syntax or API usage that breaks users who have not upgraded yet.
2. Recommended current stack. This is the stack you expect most new tests and demos to use.
3. Newest stack. This catches future-facing PHP and WordPress changes before users report them.

On wp.run, the launch modal supports explicit WordPress and PHP version choices. You can also use launch URLs when you want to launch a WordPress sandbox from a repeatable test link, for example:

https://wp.run/new?php=8.4&wp=6.9

For supported presets, add the plugin parameter to make the environment reproducible:

https://wp.run/new?plugin=woocommerce&php=8.4&wp=6.9

For your own plugin builds, upload the ZIP inside wp-admin and record the exact build in your notes. Each row in your matrix should have a stack, plugin version, checks run, and result.

How to Test Plugin PHP 8.4 Compatibility on wp.run

Use this workflow when you need to test plugin PHP 8.4 behavior without rebuilding a local environment.

1. Launch the target stack. Press Launch WordPress, choose PHP 8.4 and the WordPress version you want to validate, then create the sandbox. wp.run provisions a temporary WordPress install with admin credentials and a *.wp.run URL.
2. Confirm the environment. Open wp-admin, then check Tools -> Site Health -> Info to confirm the PHP and WordPress versions before you start testing.
3. Install or activate the plugin. Load a supported preset from a launch URL parameter, or upload your plugin ZIP in wp-admin. Keep the exact plugin build noted in your test record.
4. Run the activation check. Activate the plugin and watch for fatal errors, admin notices, missing dependencies, redirect loops, and setup wizard failures.
5. Exercise the core feature. Run the smallest real workflow the plugin exists to support: create a form, complete a checkout, add a block, generate a sitemap, import content, or trigger the scheduled task.
6. Check admin and front-end surfaces. Open the block editor, plugin settings, public page output, REST endpoints if relevant, and the browser console.
7. Repeat on the next stack. Launch the next PHP or WordPress version and run the same checklist. Change one dimension at a time when you are isolating a failure.

This gives you a manual compatibility signal quickly. It does not replace unit tests, integration tests, or static analysis, but it catches the product-level failures users actually see in wp-admin and on the front end.

Add Static Scanning, But Do Not Stop There

Static compatibility scanners are useful because they catch code patterns before runtime. The Learn WordPress lesson on testing products for PHP version compatibility covers two common approaches: manual testing in a target PHP environment and scanning with PHPCompatibility rules through PHP_CodeSniffer.

Use both signals together:

• Static scan first. Find obvious use of removed functions, deprecated signatures, and version-specific PHP syntax.
• Sandbox test second. Confirm the plugin boots, renders UI, writes expected options, and completes its real workflow on the target stack.
• Regression note last. Record what failed, the exact PHP/WP/plugin versions, and whether the issue is a warning, fatal error, broken UI, or data issue.

Static tools can tell you a line of code may be incompatible. A sandbox tells you whether the plugin still works as a WordPress product.

What to Check During WP Version Testing

WP version testing is not only about whether the plugin activates. The most expensive bugs often appear after activation, when a user edits content, configures settings, or upgrades from an older version.

Check these areas on every matrix row:

• Activation and deactivation. The plugin should activate cleanly, deactivate cleanly, and not leave the site in a broken state.
• Upgrade path. Install the previous plugin version first, create sample data, then update to the new plugin version and confirm migrations run.
• Admin and editor screens. Open every menu the plugin adds. If it touches blocks, shortcodes, embeds, custom post types, or meta boxes, test the editor on each WordPress version.
• Front-end output. Confirm templates, shortcodes, assets, redirects, checkout flows, forms, or widgets render as expected.
• REST, AJAX, and scheduled tasks. Submit relevant endpoint requests and inspect cron-dependent behavior where the plugin relies on background work.
• Uninstall hygiene. Deactivate and delete the plugin in a disposable sandbox to verify whether its cleanup behavior is acceptable.

Keep this checklist consistent. If every tester invents a new path through wp-admin, your matrix becomes harder to compare.

A Practical Matrix for a Plugin Release

Here is a compact matrix for a plugin team preparing a release:

Use the matrix as a release gate, not a documentation afterthought. If a row fails, copy the exact steps, include debug output or screenshots, and attach the temporary sandbox URL while it is still alive.

Common Compatibility Failures to Watch For

Most compatibility failures fall into a few patterns:

• Fatal error on activation. Usually caused by removed PHP functions, missing classes, dependency autoloading problems, or code that runs too early.
• Warnings that become noisy on newer PHP. Dynamic properties, nullable arguments, strict typing assumptions, and deprecated signatures can flood logs even when the page appears to work.
• Editor breakage. A plugin can work on the front end while its block editor integration fails on a newer WordPress version.
• AJAX, REST, or upgrade failures. Nonce handling, route registration, saved options, or custom tables can expose weak assumptions.
• Dependency conflicts. Two plugins can ship incompatible versions of a shared PHP library or JavaScript package.

When a row fails, do not jump straight to “PHP is incompatible.” Re-run the same plugin on the same WordPress version with the previous PHP version, then change WordPress while keeping PHP steady. Isolating one dimension is how you find the real fault line.

Where the Sandbox Fits

A disposable WordPress sandbox is ideal for compatibility smoke testing, release candidate checks, support reproduction, demo links, and quick plugin QA. Use staging or local development when the test depends on a production-shaped database, persistent files, custom server configuration, or long-running debugging.

The practical workflow is layered: scan the code, run automated tests, use wp.run sandboxes for product-level PHP and WordPress version checks, then move to staging only when you need to verify a specific site.

FAQ

What is WordPress PHP compatibility?

WordPress PHP compatibility is the ability of WordPress core, a plugin, or a theme to run correctly on a specific PHP version. For plugins, compatibility must be tested in a real WordPress environment because the plugin depends on WordPress hooks, admin screens, database behavior, and other active code.

How do I test a plugin on PHP 8.4?

Launch a wp.run sandbox with PHP 8.4, confirm the PHP version in Site Health, install the plugin, then run activation, admin, editor, front-end, REST/AJAX, and uninstall checks. Repeat the same checklist on the previous PHP version if you need to isolate a PHP-specific failure.

Does WordPress core compatibility mean my plugin is compatible too?

No. WordPress core can be compatible with a PHP version while a plugin still fails because of its own code, dependencies, admin UI, or upgrade logic. Use the WordPress core compatibility chart as the baseline, then test the plugin separately.

How many PHP and WordPress combinations should I test?

Test the oldest stack you support, the current default stack you expect users to run, and the newest stack you want to prepare for. Add rows for upgrade paths, dependencies, or customer-reported environments when they matter.

Make Compatibility Testing Repeatable

The best compatibility process is boring: one matrix, one checklist, one result log, repeated for every release candidate. wp.run gives you the fast environment layer for that process: clean WordPress, selectable PHP and WordPress versions, generated admin access, and temporary sandboxes you can discard when each row is done.