WP-CLI » PHP 8.6 and WordPress: Check Your Plugins Before You Upgrade

PHP 8.6 and WordPress: Check Your Plugins Before You Upgrade

PHP 8.6 is close. The WordPress 7.2 Beta 5 announcement says it is scheduled for release on November 19, 2026, and that as of Beta 5 all known compatibility issues in WordPress itself are resolved. The same post is clear that you still need to verify your plugins and themes before you upgrade.

That last part is where sites break. Core being ready means nothing if an old slider plugin calls a function PHP 8.6 now complains about. If you manage WordPress sites and your host will offer 8.6 soon, this is the check I would run before flipping the switch.

As of 2026-11-13, php.net shows PHP 8.6.0RC7 available for testing, and 8.6 is not on the supported versions page yet. The details below come from the official PHP 8.6 migration notes and may still change before the final release.


The web server and the command line often run different PHP binaries. Check both:

wp --info
wp eval 'echo PHP_VERSION, PHP_EOL;'

wp --info shows the PHP binary and version WP-CLI runs on. For the version your visitors hit, open Tools > Site Health > Info > Server in wp-admin. If the two don’t match, see how to run WP-CLI with a custom PHP version so your tests run on the same version as the site.

The PHP 8.6 deprecations page lists, among others, the whole mbregex family (mb_ereg(), mb_eregi(), mb_ereg_replace(), mb_split(), mb_regex_encoding() and friends), is_double(), is_long(), is_integer(), doubleval(), metaphone(), strcoll(), mysqli_get_charset(), mysqli_stmt_init() and define() with a third argument.

The mbregex functions are deprecated because the Oniguruma library behind them is no longer maintained. That explains the “Does WP need oniguruma / mbregex?” question in the forums this week. The PHP docs say these functions are slated for removal in PHP 9.0.

From the WordPress root, grep for them:

grep -rnE --include='*.php' \
  '\b(mb_ereg[a-z_]*|mb_split|mb_regex_encoding|mb_regex_set_options|is_double|is_long|is_integer|doubleval|metaphone|strcoll|mysqli_get_charset|mysqli_stmt_init)\s*\(' \
  wp-content/plugins wp-content/themes wp-content/mu-plugins

Each hit prints as file:line:code. No output means none of these names appear, which is a good sign but not a full guarantee. A hit inside a vendor/ folder or behind a function_exists() check may never run, so judge each one.

A deprecation is a warning, not a fatal error. The site keeps working on 8.6, but your logs fill up and the code will break once the functions are removed. Report hits to the plugin author now, while it is cheap to fix.


Never test a new PHP version on the live site first. Clone the site to staging, switch only the staging domain to PHP 8.6 once your host offers it, and turn on debug logging there.

Back up the staging wp-config.php before you edit it, then add these lines above /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
php 8 6 wordpress plugin check wp config 1 - PHP 8.6 and WordPress: Check Your Plugins Before You Upgrade
Where it goes in wp-config.php: above the “That’s all, stop editing!” line

Errors now go to wp-content/debug.log instead of the screen. If the file never shows up, fix WP_DEBUG_LOG first.

See also  WordPress Backup Stuck on the Database? Export It With WP-CLI

Deprecations only fire when the code runs. Load the front page, a post, the shop and checkout, log in, save a post, and trigger the cron jobs:

wp cron event run --due-now

Then group the log by message, so you see which plugin is noisiest instead of scrolling through thousands of lines:

grep -E 'PHP (Deprecated|Warning|Fatal)' wp-content/debug.log \
  | sed 's/^\[[^]]*\] //' | sort | uniq -c | sort -rn | head -20

Each line shows a count and the message with the file path, which tells you the plugin or theme. Anything with PHP Fatal is a blocker for production. Deprecated lines are a to-do list for plugin updates.

💡 Run wp plugin update --all --dry-run on staging before you blame a plugin. Many authors ship PHP compatibility fixes quietly in minor releases.


One change does not throw any error at all. According to the PHP 8.6 backward incompatible changes, three session settings get new defaults: session.use_strict_mode is now 1, session.cookie_httponly is now 1, and session.cookie_samesite is now Lax (it was unset).

WordPress login uses its own cookies, not PHP sessions, so core is not affected. Plugins that call session_start() are.

With a Lax session cookie, the browser does not send the cookie on a cross-site POST. A payment or login provider that posts back to your site may then land on a page that has lost its session. Find those plugins quickly:

grep -rln --include='*.php' 'session_start\s*(' wp-content/plugins wp-content/themes

The output is a list of file paths. If a payment return breaks on staging and one of these plugins is involved, ask the author for a fix. You can set session.cookie_samesite back in your PHP settings as a temporary workaround, but I would not leave it that way.


Once staging runs clean, switch the live domain and watch debug.log for the first hour. Rolling back is just switching the version back, which is why I always change PHP per domain and not server-wide.

In OpenPanel this is PHP > Select PHP Version, where you pick the version for each domain from a dropdown and save, as described in the OpenPanel guide. It works like MultiPHP Manager in cPanel. One catch from the OpenPanel docs: on OpenLiteSpeed the version can’t be set per domain, so all domains share one version and staging has to live on another server.

If you run WooCommerce, keep its own PHP requirement in mind too. I covered the WooCommerce PHP 8.1 requirement separately, and sites still on PHP 8.0 have a much bigger jump to make than sites going from 8.5 to 8.6.

TL;DR: WordPress 7.2 is ready for PHP 8.6, but your plugins may not be. Grep wp-content for the deprecated functions, test on a staging copy with WP_DEBUG_LOG on, group the warnings, check plugins that use PHP sessions, and only then switch production. Don’t upgrade on release day just because the option appears in your panel.

Was this post helpful?

Leave a Comment

I enjoy constructive responses and professional comments to my posts, and invite anyone to comment or link to my site.

Recommended