5 kinds of WordPress plugins that cause PHP upgrade errors (and how to fix them)

1. Abandoned plugins

What goes wrong: code written for PHP 5 or 7 uses things PHP 8.0 removed. Every call is a fatal error, and the page stops:

<?php
$slides = [['title' => 'Team', 'order' => 2], ['title' => 'Welcome', 'order' => 1]];
$by_order = create_function('$a, $b', 'return $a["order"] - $b["order"];');
usort($slides, $by_order);
echo 'First slide: ', $slides[0]['title'], "\n";

Deprecated: Function create_function() is deprecated in /var/www/html/wp-content/plugins/old-slider/old-slider.php on line 3
First slide: Welcome

Fatal error: Uncaught Error: Call to undefined function create_function() in /var/www/html/wp-content/plugins/old-slider/old-slider.php:3
Stack trace:
#0 {main}
  thrown in /var/www/html/wp-content/plugins/old-slider/old-slider.php on line 3

How to spot them: on wordpress.org, the plugin page shows when it was last updated and which WordPress version it was tested up to. In your admin, a plugin that never shows an update in years is a candidate.

The fix: replace it with a maintained plugin. Patching abandoned code yourself works until the next problem; create_function() and each() rarely come alone.

2. Custom plugins written for your site

What goes wrong: the same old code as above, with a twist: no update will ever arrive, because only the person who wrote it can change it. Some failures are silent: very old constructor syntax simply stops running on PHP 8.0, and the error appears somewhere else.

<?php
class Slider {
    private $slides;

    public function Slider() {
        $this->slides = ['welcome.jpg', 'team.jpg'];
    }

    public function count_slides() {
        return count($this->slides);
    }
}

$slider = new Slider();
echo 'Slides: ', $slider->count_slides(), "\n";

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; Slider has a deprecated constructor in /var/www/html/wp-content/plugins/old-slider/includes/class-slider.php on line 2
Slides: 2

Slides:
Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /var/www/html/wp-content/plugins/old-slider/includes/class-slider.php:10
Stack trace:
#0 /var/www/html/wp-content/plugins/old-slider/includes/class-slider.php(15): Slider->count_slides()
#1 {main}
  thrown in /var/www/html/wp-content/plugins/old-slider/includes/class-slider.php on line 10

The fix: a developer changes the code, from a list of exactly what breaks: custom plugins and PHP 8 explains how to get that list, and old-style constructors this particular case.

3. Plugins bought outside wordpress.org

What goes wrong: a premium plugin updates through its seller, not through wordpress.org. If the licence, account or seller is gone, updates quietly stop, and the site keeps an old version whose code was never adapted to newer PHP.

How to spot them: in Plugins, look at the version against the seller’s current one, and check whether the seller still exists and your licence is active.

The fix: renew and update, or replace. Never install copies from unofficial sources to get updates: you can’t know what was changed in them.

4. Plugins that need a PHP extension

What goes wrong: the code is fine, but the PHP version doesn’t include something it relies on. PHP 8.4 moved IMAP, OCI8, PDO_OCI and PSpell out of PHP: they “have been moved to PECL and are no longer part of the PHP distribution” (php.net). A plugin that reads a mailbox through IMAP works on PHP 8.3 and stops on 8.4 if the host doesn’t install the extension:

<?php
echo function_exists('imap_open') ? 'IMAP available' : 'IMAP missing', "\n";
$inbox = imap_open('{mail.example.com:993/imap/ssl}INBOX', 'user', 'password');

IMAP missing

Fatal error: Uncaught Error: Call to undefined function imap_open() in /var/www/html/wp-content/plugins/mail-inbox/mail-inbox.php:3
Stack trace:
#0 {main}
  thrown in /var/www/html/wp-content/plugins/mail-inbox/mail-inbox.php on line 3

The fix: ask your host to install the extension for PHP 8.4, or use a plugin that doesn’t need it. No code check can see this one: it’s about the server. IMAP and PHP 8.4 has the details.

5. Plugins with an old bundled library

What goes wrong: many plugins ship third-party libraries inside them, typically in a vendor folder. The plugin itself may be current while the copy of the library is years old. A library that still defines __autoload(), for example, makes PHP 8.0 refuse the file:

How to spot them: the path in the message or the finding continues into a vendor/ or lib/ folder inside the plugin.

The fix: the plugin’s developer updates the library. Don’t replace files inside a plugin yourself: the next update undoes it.

Find yours before you switch

Popular, maintained plugins are rarely the problem. CompatNav’s page on wordpress.org: “Well-maintained plugins often have nothing to report.” On three of the most-installed plugins together (about 7,800 PHP files), it reported 27 items for an upgrade from PHP 7.4 to 8.5, all of them deprecation notices.

To find the ones on your site, check every plugin and theme for the PHP version you’re moving to. CompatNav, free on wordpress.org, does it on your own server for PHP 8.0 to 8.5: per plugin and theme, whether an update is available, whether the code looks like your own, and each finding labelled “Will break” or “Deprecation notice”. Kinds 1, 2, 3 and 5 show up there; for kind 4, ask your host. Checking a plugin’s PHP compatibility covers the other ways to find out.