WordPress Site Not Working After a PHP Update
A PHP upgrade breaks code that used removed syntax or relied on loose behaviour. Read the fatal error, identify the responsible plugin or theme, and roll back the version while you fix it.
Quick fix: if the site is down and customers are affected, roll PHP back to the previous version in your hosting panel to restore service, then diagnose properly. Rolling back is a pause, not a solution — unsupported PHP versions stop getting security patches.
Read the actual error first
A PHP upgrade produces a specific fatal error naming a file and a line. Get that message before touching anything:
- Turn on debug logging with display off and logging on.
- Reload the failing page.
- Read the last entries of
wp-content/debug.log, or the server's PHP error log if WordPress dies too early to write its own.
The file path in the message tells you whether the fault is in a plugin, the theme or WordPress core. Core is rarely the problem if WordPress itself is current.
Errors you will actually see
| Message | Meaning |
|---|---|
Uncaught Error: Call to undefined function create_function() |
Removed in PHP 8; the plugin needs updating |
syntax error, unexpected '$' in old code |
Uses syntax removed in a newer version |
Uncaught TypeError: ... must be of type string, null given |
PHP 8 is strict where PHP 7 silently coerced |
Uncaught Error: Unsupported operand types |
Arithmetic on an array or null that used to be tolerated |
Call to undefined method after upgrade |
A library dropped in the new version, often a bundled extension |
| Blank page with nothing logged | PHP failed before WordPress loaded — check the server log |
PHP 8 turned many former warnings into fatal errors. That is why a site can run for years with sloppy code and die the moment the version changes.
Find the responsible extension
If the error names a file, you are done — the folder under wp-content/plugins/ or wp-content/themes/ identifies the culprit.
If it does not, isolate the usual way:
- Rename the
pluginsfolder over SFTP to disable everything at once. If the site loads, restore the name and disable plugins one at a time — see disabling plugins without admin access. - If the site still fails with no plugins, rename the theme folder so WordPress falls back to a default theme.
- If it still fails with a default theme and no plugins, the problem is core, a must-use plugin in
wp-content/mu-plugins/, or adrop-insuch asobject-cache.phporadvanced-cache.phpleft behind by a caching plugin.
That third case is easy to miss. Drop-ins load before almost everything else and are not affected by renaming the plugins folder.
Fix rather than pin
Once you know what broke, work through the options in this order:
- Update it. Most well-maintained plugins have supported the current PHP release for years. Update on staging and retest.
- Replace it. If the plugin has not been updated in years, the PHP upgrade has just told you it is abandoned. Find a maintained equivalent.
- Patch it. Only for code you own. A patch in a third-party plugin is erased by its next update, so keep any fix in a small custom plugin using hooks rather than editing files in place.
- Remove it. Ask whether it earns its place at all. An upgrade is a reasonable moment to delete features nobody uses — cleanly, via how to delete a WordPress plugin completely.
Custom code that breaks on modern PHP
If the theme is yours, the common causes are mechanical:
<?php
// PHP 8 fatals on null passed where a string is required.
$title = get_post_meta($id, 'subtitle', true);
echo strlen($title); // TypeError if the meta is missing.
echo strlen((string) $title); // Safe.
// Undefined array keys became warnings, and warnings often become
// fatal in strict setups. Check before reading.
$value = $options['maybe_missing'] ?? '';
Also check for functions removed across versions, each(), create_function() and the old mysql_* family among them, and for classes that now require explicit constructors.
Upgrade properly next time
- Copy the site to staging.
- Switch the staging copy to the new PHP version.
- Enable debug logging and browse the critical paths — homepage, a post, search, checkout, admin, forms.
- Read the log and fix or replace whatever appears.
- Update plugins and themes to current versions first; most incompatibilities disappear at this step.
- Take a backup of production, switch it over during a quiet period, and keep the rollback path open for a day.
Backups before any platform change are the difference between a bad hour and a bad week — see how to back up a WordPress site.
Verify the site after the upgrade
Check the pages that involve real work rather than just the homepage: a form submission, a login, a checkout, an upload, a scheduled task, and an email send. Then look at debug.log once more — a site can render perfectly while logging thousands of deprecations that will become fatal on the next version.
Frequently asked
- Usually yes, and it is the right emergency move to restore service. Treat it as temporary: old PHP versions stop receiving security fixes, so the incompatible code still has to be updated or replaced.
- Run the upgrade on a staging copy with WP_DEBUG on, browse the important pages and read the log. Static analysis tools that scan for deprecated syntax also catch most of it.
- Deprecation notices are being displayed instead of logged. Set WP_DEBUG_DISPLAY to false and WP_DEBUG_LOG to true so notices go to a file rather than the screen.