If WordPress shows "There has been a critical error on this website" after your host upgraded PHP, a plugin or theme is almost certainly using code that PHP 8 no longer accepts. To find it, check the admin inbox for WordPress's recovery mode email, or turn on the debug log with errors hidden from visitors and read wp-content/debug.log. The file path in the fatal error names the culprit. Roll PHP back in your hosting panel if you need the site up today, then update or replace that plugin or theme, test on staging and upgrade again.
What does the "critical error" message mean?
It means PHP hit a fatal error and stopped. Since WordPress 5.2, WordPress catches the fatal error and shows visitors a short message instead of a blank white page or a raw error. The exact wording varies. You might see "There has been a critical error on this website. Please check your site admin email inbox for instructions." The message does not say what broke. The details are in the recovery email and the error log.
Why do sites break after a PHP 8 upgrade?
PHP 8.0 removed functions that older plugins still used, and turned several warnings into errors that stop the page. The PHP 8.0 incompatible changes list has the full detail. These are the ones you are most likely to see in a WordPress log:
| What the log says | What it usually means |
|---|---|
Call to undefined function create_function() | Old code using a function removed in PHP 8.0 |
Call to undefined function each() | Another function removed in PHP 8.0 |
Attempt to assign property ... on null | Code that relied on PHP quietly creating an object, which is now an error |
A TypeError from count() | Code counting something that is not an array, which is now an error |
Undefined array key or Undefined variable | Warnings, not fatal errors. Worth fixing, but not the cause of the crash |
Recent versions of WordPress core run on PHP 8. The problem is nearly always an older plugin, theme or custom snippet.
How do you find the plugin or theme that broke?
- 1
Check the recovery mode email
WordPress emails a special login link to the site's administration email address when a plugin or theme causes a fatal error.
- 2
Turn on the debug log
Add the debug constants to wp-config.php with display switched off, so errors go to a file and not to visitors.
- 3
Reload the broken page
Load the page that shows the error, so the fatal error is written to the log.
- 4
Read debug.log
Find the line that starts with PHP Fatal error and read the file path in it.
- 5
Name the culprit
The folder after wp-content/plugins/ or wp-content/themes/ is the plugin or theme to deal with.
Step 1: check the recovery mode email
The email goes to the Administration Email Address in Settings > General, or to the address in the RECOVERY_MODE_EMAIL constant if your wp-config.php sets one, as the WordPress source shows. It names the plugin or theme that failed and includes a link that lets you log in with that extension paused, as described in the WordPress 5.2 recovery mode announcement. From there you can deactivate it and get the site working again.
By default WordPress sends this email at most once a day. If the admin email is an old developer's address or an inbox nobody reads, you will not see it, so go straight to the debug log.
Step 2: turn on the debug log
Open wp-config.php in your hosting file manager and add these lines above the line that says /* That's all, stop editing! */. This is the setup the WordPress debugging guide gives:
// wp-config.php: log errors to a file, never show them to visitors
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
If your wp-config.php already has a define( 'WP_DEBUG', false ); line, change that line rather than adding a second one.
WP_DEBUG_DISPLAY set to false matters on a live site. Without it, errors are printed into the page for every visitor to read. With it, errors go only to the log, which by default is wp-content/debug.log. WP_DEBUG_LOG also accepts a file path, so you can keep the log outside the public folder. Use this line instead of the WP_DEBUG_LOG line above, not as well as it:
// Optional: replaces WP_DEBUG_LOG above. Use a real path outside the public web folder
define( 'WP_DEBUG_LOG', '/home/youraccount/logs/wp-debug.log' );
Step 3: read debug.log
Reload the broken page, then open the log. Look for the line that starts with PHP Fatal error. Here is an illustrative example:
[26-Oct-2026 10:15:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined function create_function() in /home/youraccount/public_html/wp-content/plugins/old-slider/old-slider.php:42
The path tells you everything you need. Here the folder is plugins/old-slider, so the plugin called "old-slider" is the problem, at line 42 of its main file. If the path runs through themes/, it is the theme.
If the error is long or confusing, paste it into my free Error Message Explainer. It explains the error in plain English, ranks the likely causes and suggests the fix.
Step 4: deactivate it without the admin
If you cannot reach the admin at all, rename the plugin's folder in the file manager, for example from old-slider to old-slider-off. WordPress cannot find it, treats it as deactivated, and the rest of the site loads.
Should you roll PHP back?
As a stopgap, yes, if your host still offers the older version in its control panel. It gets the site back while you fix the real cause. Do not stay there. These are the end-of-support dates from php.net's supported versions and end-of-life pages:
| PHP version | Security fixes until |
|---|---|
| 7.4 | Ended |
| 8.0 | Ended |
| 8.1 | Ended 31 December 2025 |
| 8.2 | 31 December 2026 |
| 8.3 | 31 December 2027 |
| 8.4 | 31 December 2028 |
| 8.5 | 31 December 2029 |
WordPress itself recommends PHP 8.3 or greater. You can see your current version in Tools > Site Health > Info > Server.
How do you fix it for good?
- Update the plugin or theme. Most maintained plugins added PHP 8 support long ago, and an update is often the whole fix.
- Replace it if it is abandoned. If it has not been updated in years, find a maintained alternative. An abandoned plugin is a security risk as well as a compatibility one.
- Fix custom code. If the path points to custom code, such as a theme's
functions.phpor a custom plugin, a developer needs to update it. Replacingcreate_function()with an anonymous function is usually a small change. - Test on staging first. Copy the site to a staging site, switch staging to the new PHP version, and check the pages that matter: home, key landing pages, forms, checkout and the admin. Only then upgrade the live site, with a fresh backup taken first.
When you are done, set WP_DEBUG back to false, remove the other debug lines and delete debug.log.
What have PHP upgrades looked like on my client sites?
Not every PHP problem shows up as a critical error. On Samko Holdings and Crowne Plaza London Kingston, both on GoDaddy, form submissions started failing in July 2025. Nothing crashed. Leads just stopped arriving. It looked like a form plugin bug, but the cause was the host's cache layer, and upgrading PHP from 8.0 to 8.3 fixed it at the root on both sites. That also put both sites on a supported version.
On Easy Parenting Hub, I took the site live on the client's Hostinger server with PHP 8.3 from the start.
Two lessons from those jobs. First, staying on an old PHP version is not the safe option. It can cause quiet failures of its own. Second, after any PHP change, submit every form and check the email arrives, not only that the pages load.
How do you stop this from happening again?
Hosts upgrade PHP on their own schedule, and they do not always warn you. The protection is someone keeping plugins current, the site on a supported PHP version, and upgrades tested on staging before the host forces them. That is part of what I describe in what a WordPress maintenance retainer covers.
For a business site, typical market ranges that Indian freelancers and small agencies publish for a maintenance retainer are ₹5,000–₹10,000 a month, or £40–£80 ($55–$105) at October 2026 exchange rates (£1 = ₹127.2, $1 = ₹95.07). Freelancers publish ₹3,000–₹8,000. Sources: upgrowth.in and pegasusdigital.co.in. That is a market range, not my price. My own quote comes from a written scope, and the free Project Scope Generator helps you write one.
If your site is down now, or you want PHP upgraded before your host does it for you, I handle this through my hosting migrations, DNS and maintenance retainers service. Send me the error from your debug log and I will reply with what I would do. You can also book a call.
