What actually breaks in WordPress when you upgrade PHP (and how to check before your host does it)

WPTOOLS — Fri, 02 Oct 2026 09:50:03 +0000

PHP 8.2 reaches end of security support on 31 December 2026 (php.net). Your site won't switch off on January 1st, but many hosts will start moving sites to newer PHP versions around then, often with nothing more than an email you might skim.

If you maintain WordPress sites, here's what's worth knowing before that happens.

1. Most "PHP 8 errors" aren't errors

After an upgrade, most of what fills your log looks like this:

PHP Deprecated: Creation of dynamic property My_Class::$foo is deprecated

Deprecated means "this will change in a future version". The site keeps working. It's a to-do item, not an emergency. The same goes for the PHP 8.1 notices about passing null to built-in functions:

PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated

Fix them eventually. Don't panic about them.

2. What actually takes a site down is a short list

The real danger is fatal errors. Coming from PHP 7.4, the classic ones are functions removed in PHP 8.0:

// Removed in PHP 8.0: fatal "Call to undefined function"
$callback = create_function( '$a', 'return $a * 2;' );

while ( list( $key, $value ) = each( $array ) ) {
    // ...
}

Either of these, in any active plugin, gives you the famous white page:
"There has been a critical error on this website."

3. The sneaky one: old-style constructors

Before PHP 8.0, a method named like its class acted as the constructor:

class Old_Widget {
    function Old_Widget() {   // a constructor on PHP 7, a normal method on PHP 8
        $this->settings = array();
    }
}

On PHP 8.0+ this is just a regular method that never runs. There's no error on that line: the object simply isn't set up, and something breaks much later, somewhere else. It's one of the hardest upgrade bugs to trace by hand.

4. Don't hide warnings on a broken site

Turning off error display is right for visitors. Turning off error logging just hides the evidence. In wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // visitors see nothing

5. The safe upgrade order

Back up the site.
Make a staging copy (most hosts have a one-click button).
Switch the staging copy to the new PHP version.
Check every plugin and theme for the target version.
Update or replace what will break.
Switch the live site, then watch debug.log for a few days.

Step 4 is the painful one. Clicking through pages only tests the pages you visit; code behind cron jobs, imports or payment callbacks can still fail later.

How I check step 4 now

That gap is why I built a free plugin, CompatNav – PHP Upgrade Checker. It reads the code of every installed plugin and theme, including custom ones, and reports:

what will break vs. what only shows deprecation notices, for PHP 8.0 to 8.5
only what changes between your current PHP version and the target, so you get a short list, not thousands of warnings
nothing for code that's already guarded by version checks like PHP_VERSION_ID or function_exists()

It runs entirely on your own server: no external service, no tracking, read-only, and it never modifies code.

Honest limit: it's static analysis. It reads code; it doesn't run it. Problems that depend on real data at runtime can still slip through, so step 6 (watching the log) still matters.

I also write free, plain-English guides for the most common errors (the critical error after a PHP update, "Creation of dynamic property is deprecated", and more) at compatnav.com/guides.

Disclosure: I'm the developer. It's free, with no ads and no upsell inside the plugin. If it flags something wrong on your site, I'd really like to hear about it in the comments.