PHP 8.6 ships on 19 November. 39 of the top 100 WordPress plugins contain deprecated code

TL;DR

PHP 8.6 ships on 19 November 2026. A week before release, someone tested the hundred most popular WordPress plugins against the release candidate and found deprecated code in thirty nine of them. WooCommerce, Elementor and Yoast are on that list, plugins with millions of installs. It sounds alarming and it is not, which is the point of this article. Being marked deprecated breaks nothing today. The code keeps running, and the consequences arrive with PHP 9. Three other changes can affect you immediately, and one of them can lose the cart of a customer returning from a payment provider. The recommendation at the end is simple: do not switch now. The release lands in the middle of the pre-Christmas season, eight days before Black Friday, which is the worst possible moment to change your interpreter version.

Deprecated does not mean broken

This distinction decides whether this article worries you or reassures you.

When the PHP team marks something as deprecated, the code still executes and your site behaves exactly as before. One thing changes: the interpreter starts writing a notice every time that code runs. If you have diagnostic logging turned off, you will not even notice.

The real cost shows up in two places. First, with debug logging on, the log file can grow by hundreds of megabytes in a week, because the notice is written on every request. Second, and more importantly, in PHP 9 those same constructs stop working and turn into fatal errors. That is a warning, not a sentence, but a warning with a date attached.

In other words: you have time, but now you know what for.

The study behind the 39 out of 100

The number is not an estimate. It comes from a test run on 28 October 2026 against the PHP 8.6 release candidate and WordPress 7.1.1.

The method had three stages. First, a syntax check across every file, meaning 55,760 PHP files from the hundred most popular plugins in the WordPress.org directory. Then a scan of the code for calls to functions deprecated in 8.6. Finally, activating each plugin on its own against a working installation and opening the home page, a post, the dashboard and the plugins list.

The most frequent findings look like this:

Construct	Occurrences
spl_object_hash()	58
return value from a constructor	55
is_integer()	28
namespace as a class constant	12

The first two entries are worth understanding, because they explain the scale. Returning anything from a constructor was always pointless, since PHP silently discarded the value anyway. Only now does it say so out loud. And is_integer() is simply a longer name for is_int(), kept around for years for compatibility. Neither of these is a bug in the plugin, they are leftovers from an era when PHP was more forgiving.

The study data is published as downloadable files under an open licence, so anyone can verify it. That is rare for reports of this kind and the reason I take the number seriously.

Three changes that can affect your site immediately

This is the part that genuinely needs attention. Unlike the deprecation notices, these three things change behaviour from day one.

Safer session defaults

PHP 8.6 changes three defaults around session cookies. Strict mode is switched on, which blocks hijacking someone else's session. The session cookie stops being readable by scripts in the browser, limiting the damage from injected code. The attribute controlling whether the cookie travels between sites is set to Lax.

The first two are a pure win and require nothing from you. The third is the one to watch in a shop.

A value of Lax means the browser will attach the session cookie on an ordinary navigation from an external site, but will not attach it when that site returns the user via POST. Some payment providers return exactly that way. The result can be that the customer completes the payment, comes back to the shop and lands on an empty session, with no cart and no order confirmation. The money has been taken and the customer sees no sign that anything succeeded.

If you run a shop, this is the one item in this article you have to test yourself, by walking the full payment path after changing versions.

A cap on filter chains when reading files

PHP used to allow chaining an unlimited number of filters that process a data stream. It sounds harmless, but that capability was a real tool in attacks that trick an application into loading somebody else's file and then executing code. We wrote about exactly such a vulnerability when covering the critical hole in WordPress 7.1.2.

From 8.6 the chain is capped at sixteen filters. For normal code that is a limit nobody will ever reach. For an attacker it closes a convenient route.

Faster outbound connections

Until now, every encrypted connection made PHP perform a full handshake from scratch. It can now resume an earlier session. The gain shows up mainly on sites that frequently query external services: courier integrations, payment systems, stock synchronisation. The more such calls you make, the clearer the difference.

When to switch

Not now, and for a reason that has nothing to do with the quality of the release itself.

PHP 8.6 arrives on 19 November, eight days before Black Friday. The accepted rule in the trade is that for two weeks before the sales peak you deploy nothing to a shop but critical security fixes. Changing the interpreter version is the opposite of a critical fix. It is a large change that touches everything at once, and its side effects prefer to surface under load.

In our September article on choosing a PHP version we wrote that the sensible moment for 8.6 is spring 2027. The plugin study confirms that advice. Not because the release is bad, but because plugin authors need a few months to clear their notices, and you have no reason to do it for them.

For today the right choice remains PHP 8.4, with full support until the end of 2028. If you are on 8.2, a completely different date matters more to you than 8.6: on 31 December 2026 that version stops receiving security patches.

How to check your own site today

You do not have to wait for the release to find out how many notices are coming. Just turn on the diagnostic log on a staging copy, never on production.

In the wp-config.php of your staging environment:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Then click through the home page, the dashboard and the plugins list, and in a shop the cart and checkout as well. Afterwards, count what piled up:

grep -c "Deprecated" wp-content/debug.log
grep -o "Deprecated:[^ ]* [^,]*" wp-content/debug.log | sort | uniq -c | sort -rn | head -20

The second command shows which messages repeat most often. If one plugin dominates, you have a concrete candidate for an update or a replacement. Turn the log off after the test, because with debug mode on it grows at a rate that can fill a disk.

Bear in mind that today you are measuring behaviour on your current PHP version. The full picture for 8.6 only arrives once your host offers that version on staging.

Sources

• What's New in PHP 8.6, a summary of the changes, support timeline and new session defaults.
• RFC: Deprecations for PHP 8.6, the official list of accepted and rejected deprecations with voting results.
• php86-wordpress-plugin-deprecations, the hundred-plugin study with its method and files for independent verification.

What you do not have to do yourself

Changing the PHP version is reversible and takes fifteen minutes on a typical business site. The catch is that you have to find those fifteen minutes when it is not peak season, and that somebody has to watch the logs for a week afterwards.

Under our care plans we track PHP support deadlines, test plugin compatibility on a staging copy and carry out the change in a window when nothing important is happening. If you do not know which version you are on or when it stops receiving patches, get in touch.

PHP 8.6 is a good release that will arrive at the right moment. That moment simply is not in November.