A PHP version upgrade broke your site because newer PHP releases drop deprecated functions, change syntax rules, or introduce stricter error reporting that legacy code cannot handle. The fix involves identifying the specific compatibility issue—usually fatal errors in logs—then either patching the code, downgrading PHP temporarily, or updating plugins and themes to compatible versions.
Over 77% of WordPress sites still run PHP 7.4 or older as of early 2026, according to WordPress.org statistics. That means millions of sites face breakage the moment a host auto-updates to PHP 8.0 or later. One misconfigured plugin can take down your entire storefront or blog in seconds.
I’ve seen this scenario dozens of times in support tickets. The pattern is always the same: a well-intentioned server upgrade, then a white screen and a flood of panic emails.
Three things usually fail first.
Deprecated functions get removed. PHP 7.4 dropped each() and create_function(). PHP 8.0 killed mysql_* extensions entirely. If your theme or a plugin calls any of these, you get a fatal error and the site stops rendering.
Type declarations become strict. PHP 8.x enforces argument and return types that older code ignored. A function expecting an integer but receiving a string will throw a TypeError instead of silently casting.
Error reporting tightens. Warnings that used to hide in logs now bubble up as fatal errors depending on your error_reporting directive. A missing array key that was harmless in PHP 7.2 can crash execution in 8.1.
Check your error log immediately. Most hosts store it at /var/log/php-fpm/error.log or inside your public directory as error_log. WordPress also writes to wp-content/debug.log if you enable WP_DEBUG_LOG.
Look for the first fatal error timestamp that matches your upgrade window. The stack trace will name the file and line number. That’s your smoking gun.
If the site shows a white screen with no clue, enable debug mode by editing wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Reload the page. The log will populate with the exact error message and context.
In one case I handled, a popular SEO plugin was calling create_function() buried in an admin panel metabox. The site worked fine on the front end but admin pages threw HTTP 500 errors. The log revealed the culprit in under a minute.
Downgrade PHP via your hosting control panel if you need the site live again in the next five minutes. cPanel, Plesk, and most managed WordPress hosts let you switch PHP versions with a dropdown. Pick the last version that worked—usually 7.4 if you jumped to 8.0 or higher.
This buys you time to patch the real issue without losing traffic or sales.
Disable the broken plugin or theme through FTP if you can’t access the WordPress admin. Rename the plugin folder inside wp-content/plugins/ from problematic-plugin to problematic-plugin.disabled. WordPress will deactivate it automatically. Do the same for themes in wp-content/themes/ and switch to a default like Twenty Twenty-Four.
Revert to a backup if your host provides automatic snapshots. Restoring a pre-upgrade state gives you a clean slate to test the upgrade in a staging environment instead.
Update every plugin and theme to the latest version first. Developers release compatibility patches specifically for new PHP releases. Check the changelog on WordPress.org or the vendor’s site to confirm PHP 8.x support before updating.
If no update exists, search the plugin’s support forum or GitHub issues for “PHP 8” or “fatal error.” Odds are someone already posted a workaround or a patched file you can swap in manually.
Replace deprecated functions yourself if the plugin is abandoned. Open the file named in the error log and locate the offending function. For example, replace each() with a foreach loop:
// Old (PHP 7.4 and earlier)
while (list($key, $val) = each($array)) {
echo "$key => $val\n";
}
// New (PHP 8.0+)
foreach ($array as $key => $val) {
echo "$key => $val\n";
}Save the file and test. Document your change in a comment so you remember it during the next update cycle.
Hire a developer if the code is complex or mission-critical. PHP Compatibility Checker plugins like PHPCompatibility can scan your entire codebase and flag issues before you upgrade, but interpreting the results and applying fixes often requires someone who reads PHP fluently.
Page builders and SEO suites top the list. Elementor, WPBakery, Yoast, and Rank Math have all shipped versions with PHP 8 incompatibilities at some point. Always check the plugin’s tested-up-to version in the WordPress repository sidebar before upgrading your server.
Legacy contact forms and sliders are common culprits too. Plugins that haven’t seen an update in two or three years almost certainly rely on deprecated code. If the last update date predates PHP 8.0’s release in November 2020, treat it as a red flag.
Custom themes written before 2020 often fail as well. Freelancers and agencies sometimes hardcode outdated syntax that worked in PHP 5.6 or 7.0 but breaks spectacularly in 8.x.
Spin up a staging site with the new PHP version. Most managed hosts offer one-click staging environments. Clone your production site, flip the PHP version to 8.1 or 8.2, and click around every page, form, and admin screen. Check the error log after each action.
Use Local by Flywheel or DDEV for offline testing. Both tools let you specify the exact PHP version in a config file and preview your site on your laptop without touching the live server. That way you catch fatal errors before they reach visitors.
Run PHP_CodeSniffer with the PHPCompatibility ruleset if you have command-line access. Install it via Composer:
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.1 wp-content/The output will list every deprecated function, syntax issue, and type mismatch across your entire WordPress installation. Fix those first and your production upgrade will be uneventful.
Yes. Most hosting control panels let you switch PHP versions instantly. Look for a “Select PHP Version” or “MultiPHP Manager” option in cPanel, or contact support if your host manages server settings for you. Downgrading takes effect within seconds and will restore your site while you investigate the root cause.
A white screen usually means a fatal error is stopping PHP execution before WordPress can render anything. The error is logged but not displayed. Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php, reload the page, then check wp-content/debug.log for the exact file and line number causing the crash.
PHP 8.1 or 8.2 is recommended. WordPress officially supports PHP 8.0 and higher as of version 5.9, and most popular plugins have caught up. PHP 7.4 reached end-of-life in November 2022 and no longer receives security patches, so staying on it exposes your site to vulnerabilities.
Read the error log path in the fatal error message. It will reference a file inside wp-content/plugins/plugin-name/. That’s the plugin at fault. If the path shows wp-content/themes/, your active theme is the problem. Disable that plugin or theme by renaming its folder via FTP, then reactivate one at a time to confirm.
Yes, measurably. PHP 8.1 is roughly 20-30% faster than PHP 7.4 in benchmark tests, and PHP 8.2 brings additional JIT compiler improvements. You’ll see faster page loads and lower server CPU usage, especially on sites with heavy plugin stacks or complex queries. Just fix compatibility issues first so you actually benefit from the speed gain.