Upgrading to PHP 8.2: Compatibility Checks and Errors

Symptom Spotting and Fast Triage Commands

When a WordPress site breaks after a PHP upgrade, the browser usually shows either a blank page, a 500 status, or a partial render with missing blocks. Start by confirming which binary actually serves the request. On the server, run these immediately to isolate the layer.

# confirm web-facing version
php -v
php-fpm8.2 -v 2>/dev/null || php-fpm -v

# check WP-CLI context
wp cli info | grep -i php

# tail the live error log
tail -f /var/log/php8.2-fpm.log
tail -f /home/USERNAME/logs/error.log

# force WP to talk
wp eval 'echo PHP_VERSION;'
wp option get siteurl

If php -v says 8.2 but wp cli info says 8.1, your shell PATH differs from the FPM pool. Fix the pool config at /etc/php/8.2/fpm/pool.d/www.conf and restart with systemctl restart php8.2-fpm. A 500 with no log entry usually means a fatal error suppressed by display_errors=Off; set it to On temporarily in wp-config.php with ini_set('display_errors', 1); to see the message.

Deprecations vs Fatal Errors

Understanding the difference dictates your urgency. A deprecation notice means the code still runs today but will break in a future PHP version; PHP 8.2 emits these for dynamic properties, ${} string interpolation, and certain utf8_decode() calls. A fatal error stops execution instantly — undefined functions, removed extensions like mcrypt, or readonly class misuse.

In WordPress, deprecations surface in wp-content/debug.log when WP_DEBUG and WP_DEBUG_LOG are true. Fatals appear as HTTP 500 or a white screen. To separate them, grep the log:

grep -E 'Deprecated|Warning' wp-content/debug.log
grep -E 'Fatal error|Uncaught' wp-content/debug.log

Common 8.2-specific deprecations you will meet: creating dynamic properties on classes that do not declare them (very common in older plugins using stdClass patterns), and call_user_func_array() with named arguments. Fix deprecations by declaring typed properties with public string $name; or using #[AllowDynamicProperties] on legacy classes as a temporary bridge. Fatal errors require real code changes — replace removed create_function() remnants with anonymous functions and swap utf8_decode() for mb_convert_encoding().

Verifying the fix

After patching, clear the log, reload the page, and confirm the grep returns nothing. Use wp eval 'trigger_error("test", E_USER_DEPRECATED);' to prove logging is wired before you trust an empty result.

Step-by-Step Upgrade Process

1. Clone production to staging and point both CLI and FPM to PHP 8.2 binaries.
2. Run wp plugin list and wp theme list to inventory every extension and its version.
3. Scan with PHPCompatibility targeting php82 using the WordPress coding standards ruleset.
4. Fix fatals first, then deprecations, then re-scan until clean.
5. Exercise every page template, archive, single view, and admin screen with debug logging on.
6. Promote to production only when staging logs are empty and visual diffs match.

Testing Before Switching

Never flip PHP versions on production first. Build a staging copy — see our walkthrough on Setting Up a WordPress Staging Environment Safely — then switch the stack. Install PHP 8.2 alongside 8.1 so you can toggle pools per vhost.

Install the scanner once and reuse it:

composer require --dev phpcompatibility/php-compatibility
./vendor/bin/phpcs --config-set installed_paths vendor/phpcompatibility/php-compatibility
./vendor/bin/phpcs -p wp-content/plugins/my-plugin --standard=PHPCompatibility 
  --runtime-set testVersion 8.2- --extensions=php

Combine this with WordPress core rules via wpcs. Automate the loop using the patterns in WP-CLI Commands Worth Automating in 2026 so every deploy re-scans. Pitfall: scanning only wp-content/plugins misses must-use plugins in wp-content/mu-plugins and drop-ins like object-cache.php. Scan those paths explicitly.

Verify by running wp cron event run --all and wp media regenerate --yes; background jobs often break silently under new PHP versions because they run in a CLI context you forgot to upgrade.

Checking Theme and Plugins

Inventory everything with wp plugin list --fields=name,version,status and wp theme list. Cross-check each against the WordPress plugin directory for the latest release; as of 2026 most maintained extensions declare PHP 8.2 support in their readme. For commercial items, check the vendor changelog.

Then scan each directory:

for d in wp-content/plugins/*/ wp-content/themes/*/; do
  echo "SCAN: $d"
  ./vendor/bin/phpcs -p "$d" --standard=PHPCompatibility 
    --runtime-set testVersion 8.2- --extensions=php --ignore=*/node_modules/*
done

Pay special attention to page builders and form plugins, which historically use dynamic properties. If a plugin is abandoned and throws fatals, either patch it yourself, replace it, or engage our Custom WordPress Development team to fork and maintain it. Verify by deactivating suspects one at a time with wp plugin deactivate PLUGIN and reloading the failing URL; when the 500 disappears, you found the culprit.

When to Roll Back

Roll back the moment you see a fatal error you cannot patch within your maintenance window, when a payment or checkout path breaks, or when the admin dashboard is unreachable. Do not leave a broken cart live hoping to fix it later.

The rollback itself is a config swap, not a code change. On Nginx with FPM:

server {
    location ~ .php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        include fastcgi_params;
    }
}

Change the socket path back to 8.1, run systemctl reload nginx, and the old version serves instantly. Keep the previous PHP packages installed for exactly this reason. Verify with wp eval 'echo PHP_VERSION;' and a live checkout test. The pitfall is forgetting OPcache: run systemctl restart php8.2-fpm after switching so stale opcode does not mask the revert.

Frequently asked questions

Is PHP 8.2 safe for WordPress core in 2026?

Yes. WordPress core has supported PHP 8.2 since 6.1 and runs cleanly on it. The risk lives almost entirely in third-party themes and plugins, not in core itself.

How do I know if a deprecation will become fatal later?

Any notice marked deprecated in 8.2 is scheduled for removal in a future major version. Treat every one as a bug to fix now rather than later, especially dynamic properties.

Can I just suppress notices instead of fixing code?

You can set error_reporting(E_ALL & ~E_DEPRECATED) to hide them, but this only postpones the break. Use it as a stopgap on staging, never as a production strategy.

Action Checklist

• Clone to staging and switch both CLI and FPM to 8.2 before touching production.
• Scan all plugins, themes, mu-plugins, and drop-ins with PHPCompatibility at 8.2.
• Separate deprecations from fatals and patch fatals first.
• Exercise cron, media regeneration, and every template with debug logging on.
• Keep 8.1 packages installed and know your socket path for instant rollback.

Need hands-on help making your stack 8.2-ready? Explore our Custom WordPress Development services and ship the upgrade without the guesswork.

References & further reading

• WordPress Developer Documentation
• WordPress Theme Handbook
• WordPress Plugin Handbook