We checked the 30 most popular WordPress plugins against PHP 8.4

Why this matters

Hosts are moving sites off old PHP versions, and PHP 8.2 stops getting security fixes on 31 December 2026. On 21 October 2026 PHP released fixes for two critical security vulnerabilities, as new releases of PHP 8.2 to 8.5 only: PHP 8.1 and older got no release from the PHP project. Before you switch, you want to know which plugins will break. Compatibility scanners read a plugin's code and flag anything PHP has removed. The trouble is how much they flag: across these 30 plugins, a basic scan reports 163 errors in 8 plugins. Faced with a list like that, it's easy to either put the upgrade off or stop reading the report. Neither is good, because one of those 163 errors was real.

That isn't a fault in the scanner. PHPCompatibility, the open-source project behind most PHP compatibility checks (Airworthy included), is very good at its job: finding code that a PHP version changed or removed. What it can't tell, reading one file at a time, is whether that code will ever run on your site. That's the part Airworthy adds.

The real problems

Essential Addons for Elementor 6.8.4

implode() with its arguments in the old order, in the Advanced Data Table widget. PHP 8 stops with a fatal error when that code runs. Reported to the authors on 28 September 2026; fixed in 6.8.6 on 15 October 2026.

PHP 7.4 only gave a deprecation notice for this. PHP 8 turns it into a fatal error. The Essential Addons team confirmed it the day after we reported it, and the fix shipped in 6.8.6. A basic scan does report it, but as 1 error among 163, with nothing to set it apart from the false alarms around it.

UpdraftPlus - Backup/Restore 1.26.8

implode() with its arguments in the old order, in a bundled Rackspace library file that UpdraftPlus doesn't currently call. Reported to the authors on 28 September 2026. Everything else the basic scan flags is old fallback code (mcrypt in the bundled phpseclib library, only used if that extension exists; mysql_* functions its authors marked as intentional).

This one would only fail if that library code were called, which UpdraftPlus doesn't do today, so it's no reason to hold back a PHP upgrade. The UpdraftPlus team passed our report to their developers. Airworthy still flags it as a Blocker, because a scan that reads code can't prove a function is never called, and the code is in the plugin.

What a false alarm looks like

Plugins that have been around for years often keep code for old PHP versions, so that sites on old servers keep working. That code sits behind a check, and on PHP 8 the check makes sure it never runs:

if ( PHP_VERSION_ID < 70000 ) {
	return new Legacy_MySQL_Database(); // Uses mysql_*, removed in PHP 7.
}
return new MySQLi_Database();

A basic scan reads each file on its own and sees mysql_query() in the legacy class, so it reports the plugin as broken. Airworthy follows the check, including when it's in another file, as it is in All-in-One WP Migration, and marks that code as guarded. The other false alarms here are the same idea in different forms: an extension check (extension_loaded( 'mcrypt' )), a function check (function_exists()), a polyfill that defines what PHP removed, or lines the plugin's authors marked as intentional.

To be clear: none of the false alarms below is a problem in the plugin. It's careful, backwards-compatible code doing exactly what it should. The only thing wrong is the alarm.

All 30 plugins

Plugin versions as current on 27 September 2026, checked against PHP 8.4. "Basic scan" is what PHPCompatibility reports on its own; "Airworthy" is the same engine plus Airworthy's checks. Results are for the versions listed; later versions may differ.

Found since

While testing on a real site in October, Airworthy flagged Contact Form 7 6.2.2 (released 11 October 2026). Five of its REST API permission checks are static closures that use $this, which PHP doesn't allow on any version. It's a small mistake and an easy one to make: when a visitor without permission calls those routes, they get a server error instead of a clean "not allowed". Access is still refused, so it isn't a security problem, and we reported it in the open: contact-form-7#1891. Takayuki Miyoshi, Contact Form 7's author, confirmed it the next morning and merged a fix the same day (#1893). The fix shipped in Contact Form 7 6.2.3 on 21 October 2026.

It also taught us something. The code fails on every PHP version, so it isn't caused by upgrading, and it shouldn't hold an upgrade back. Airworthy 1.0.2 now lists problems like this as "already applies on your PHP" instead of as a Blocker.

How we tested

• Plugins: the 30 most installed plugins on WordPress.org, at the versions that were current on 27 September 2026, on a local WordPress site.
• Basic scan: PHP_CodeSniffer 4.0.4 with PHPCompatibility 10.0.0-alpha2 (the version Airworthy bundles), with the plugin authors' phpcs:ignore comments respected:
  phpcs --standard=PHPCompatibility --runtime-set testVersion 8.4 --extensions=php <plugin folder>
• Airworthy: version 1.0.2, wp airworthy scan --target=8.4 --from=5.6 --no-wporg. Comparing from PHP 5.6 counts every PHP change, like the basic scan does.
• Both bugs were confirmed in the code, and reported privately to the plugins' authors on 28 September 2026, before this page was published. The Essential Addons team confirmed theirs the next day.

A scan that reads code without running it can't catch everything: some problems only show up when code runs, or come from your server's set-up. Whatever a scanner says, back up your site and try the new PHP version on a staging copy first.

Spotted a mistake, or maintain one of these plugins and want something corrected? Email hello@airworthywp.com and we'll fix it.