PHP 7.4 reached end of life on 28 November 2022, and it is still the minimum version WordPress 7.0 accepts. Both of those are true at once, which is why "just upgrade" is not an answer for everybody.
If you maintain client sites you inherited, or you publish a plugin with Requires PHP: 7.4 in its header, someone is running your code on 7.4 today. This post is about testing against it honestly, and about not confusing that with running on it.
Why anyone still tests on PHP 7.4
There are two separate reasons, and they need different tests.
The first is the inherited site. An agency takes over a site on a host that has not moved, or with one paid plugin that breaks above 7.4, and the upgrade is a project rather than a checkbox.
The second is distribution. If your plugin declares support for PHP 7.4, that declaration is a promise to every user on it, and the only way to keep the promise is to execute the code on that runtime.
WordPress core makes the second case concrete. Since WordPress 7.0 the minimum supported PHP version is 7.4, while the minimum recommended version is 8.3 (Make WordPress Core, 22 May 2026). The compatibility table in the core handbook lists PHP 7.4 as supported for every WordPress release from 5.6 through 7.0 (PHP compatibility and WordPress versions).
That same May 2026 post retired the "beta" label for newer PHP versions entirely, and removed it retroactively from all versions. The stated reason is worth reading if you support a plugin: the label "has made some end users and web hosts reluctant to update to newer versions of PHP, and caused some developers of plugins and themes to delay testing and supporting newer versions."
The honest part: test on it, do not run on it
PHP 7.4's last release was 7.4.33, and there have been no security fixes since November 2022 (php.net end of life). Nothing in this post makes that acceptable as a production runtime.
The useful distinction is direction. Testing against 7.4 is compatibility work, and it is legitimate. Leaving a client on 7.4 is a security decision with a date attached to it, and it should have an exit plan written down.
So if you are here because a client is stuck, the test is not the goal. The test is what buys you the evidence to move them.
What a compatibility scanner will and will not tell you
Most advice on this topic stops at "run a scanner", so it is worth being precise about what one is.
The best known option is WP Engine's PHP Compatibility Checker, which has over 200,000 active installs. Its own plugin page now carries a warning: "PHP Compatibility Checker is no longer actively maintained", and "No additional releases, including security releases, will be made available" (wordpress.org plugin page).
More important than its maintenance status is what it says about its own method. "This plugin does not execute your theme and plugin code, as such this plugin cannot detect runtime compatibility issues." It also warns that it "cannot detect unused code-paths that might be used for backwards compatibility, and thus might show false positives."
The Learn WordPress lesson on the subject makes the same point about PHPCompatibilityWP, the PHP_CodeSniffer ruleset behind most of these tools. It notes the sniffs cannot pick up every error, and gives the example of a variable passed to array_key_exists(): static analysis cannot know whether it holds an array or an object, so only executing the code finds the problem (Learn WordPress).
That is the whole argument for a real runtime. A scanner reads your code. A 7.4 interpreter runs it, including the branch you forgot exists.
Use both. The scanner is fast and finds the obvious syntax and removed-function problems in seconds. The runtime is what confirms the result.
The 10-minute routine
The version of this that people avoid is the setup: keeping a Local or MAMP profile on 7.4, or maintaining a Docker image nobody has rebuilt since last year.
A disposable sandbox removes that step. SandyWP offers PHP 8.5, 8.4, 8.3, 8.2, 8.1 and 7.4, with 8.3 as the default, and the version is a dropdown at creation time or on an existing sandbox in Site settings.
For a plugin, the shortest path is to create a fresh sandbox pinned to PHP 7.4, install the plugin, and exercise the paths that actually matter: activation, the settings screen, the cron job, the REST route, and the uninstall.
For an inherited client site, start from a copy instead. Clone production with the Cloner, then switch the copy's PHP version and watch what changes. Same content, same database, same plugin set, which is the only way a compatibility test tells you anything about that site.
Two details worth knowing before you start:
- Switching PHP on a ready sandbox restarts it for a few seconds and leaves files and database untouched. That makes an A/B cheap: reproduce on 7.4, switch to 8.3, reproduce again.
- PHP 7.4 is deliberately excluded from the warm pool, along with 8.5 and 8.4. A 7.4 sandbox always provisions cold, so it takes noticeably longer to create than a default 8.3 one. Plan for the wait rather than assuming something has hung.
Turn on Debug mode before you test, not after. A deprecation notice on an old runtime is usually written to the log and never to the screen, and reading the log after the fact is faster than reproducing the click that caused it.
Test both directions in one sitting
While you have the copy, run the other test too. The backward one asks whether your code still works on the oldest thing it claims to support. The forward one asks what breaks when the host finally moves the site to 8.3 or 8.4.
The forward test is the one that changes a client conversation, because it converts "we should upgrade PHP" into a list of three specific plugins with named errors. That list is the argument. Upgrade testing is the page that walks through the whole clone-and-upgrade shape of it.
If you publish a plugin, the same sandbox gives you the honest answer to the header question. If it does not survive a real 7.4 runtime, raise Requires PHP rather than leaving the promise in place, and see what plugin developers get for the rest of the release loop.
What this test does not cover
A sandbox proves your code runs on a PHP version. It does not reproduce the host.
Object caches, edge caches, a WAF, open_basedir restrictions and a stale OPcache all live at the host layer, and several of the nastiest PHP-version bugs live there too. If a plugin works on 7.4 in a sandbox and fails on 7.4 at the client's host, the difference is the host, and that is where to look next.
Nor does it cover load. A deprecation that only appears under concurrency, or a memory limit that only bites on a real traffic pattern, needs staging on the real infrastructure.
And anything bound to the domain will not behave: licence checks, payment gateways, OAuth callbacks and email deliverability all key off a hostname the sandbox does not have.
The short version
Run the scanner, then run the code. Static analysis cannot see runtime, and its own authors say so.
Test against PHP 7.4 for as long as you promise to support it, and treat that promise as something with an end date rather than a permanent feature. The test that proves compatibility is also the test that shows you what an upgrade would cost, which is the more useful of the two answers.
