WordPress "There has been a critical error on this website"? Find and switch off the cause

What happened

A plugin or theme hit a PHP error that stops everything (a "fatal error"). In our test, the home page, /wp-admin and even wp-login.php all showed "There has been a critical error on this website", with status 500. So you can't just log in and switch the plugin off.

1. Find the cause in the log

PHP writes the real error to the web server's log:

sudo grep "PHP Fatal" /var/log/nginx/error.log | tail -n 3

In our test, it said exactly which plugin it was:

PHP Fatal error:  Uncaught Error: Call to undefined function fancy_gallery_missing_function() in /var/www/wordpress/wp-content/plugins/fancy-gallery/fancy-gallery.php:3

The folder name after plugins/ (here fancy-gallery) is the plugin. If it says themes/, it's the theme. On Apache, look in /var/log/apache2/error.log. If you can't find the log, see our database guide for how to write WordPress's errors to a log file of their own.

2. Check your email: recovery mode

WordPress also emails the site's admin address when this happens. In our test, the email came with the subject "Your Site is Experiencing a Technical Issue", named the plugin ("WordPress caught an error with one of your plugins, Fancy Gallery"), and had a special login link that works for one day.

With that link, you can log in even though the site is broken. In our test, the dashboard then worked, and the Plugins page showed the plugin as Paused. Deactivate it there, or update it if a fixed version is out.

But recovery mode only helps you. In our test, visitors still saw the error while we were logged in. The plugin is only paused for your session. You still need to deactivate it to bring the site back.

No email? Your server may not be able to send email that arrives (see emails from your PHP site land in spam). Use step 3 instead.

3. Switch the plugin off from the server

With WP-CLI, from the site's folder, as the user PHP runs as. Add --skip-plugins. In our test, a plain wp plugin deactivate failed with the same critical error, because WP-CLI loads all plugins first, including the broken one:

cd /var/www/example.com
sudo -u www-data wp --skip-plugins plugin deactivate fancy-gallery

That said Success: Deactivated 1 of 1 plugins., and the site loaded again for everyone.

No WP-CLI? Rename the plugin's folder, so WordPress can't load it:

sudo mv wp-content/plugins/fancy-gallery wp-content/plugins/fancy-gallery.off

Then log in and open the Plugins page once, before you rename it back. Otherwise WordPress still thinks it's active, and turns it back on. We saw that in our WordPress lockout guide.

4. If it's the theme

A broken theme also gave a 500 on every page in our test. Switch to one of the default themes, with --skip-themes so WP-CLI doesn't load the broken one:

sudo -u www-data wp --skip-themes theme list
sudo -u www-data wp --skip-themes theme activate twentytwentyfour

The site came back at once. Renaming the theme's folder also brought the site back in our test, but WordPress kept the old theme as its setting, so it breaks again when the folder comes back. Activating another theme is cleaner. Keep at least one default theme installed for exactly this reason.

5. Then fix the real problem

• Update or roll back the plugin. Check its page on WordPress.org for a fixed version. Many plugins list older versions under "Advanced View".
• Check the PHP version. Errors like "Call to undefined function" or a syntax error right after a PHP upgrade often mean the plugin is too old for the new PHP. See moving a site to a newer PHP version.
• Memory errors ("Allowed memory size exhausted") are a different problem: see the memory guide.
• Test updates first. A staging copy catches this before visitors see it, and a tested backup lets you go back in minutes.

Quick list

• Find it: grep "PHP Fatal" /var/log/nginx/error.log. The folder after plugins/ or themes/ is the cause.
• Email: the recovery mode link lets you in. Visitors still see the error until you deactivate the plugin.
• Plugin, from the server: wp --skip-plugins plugin deactivate name, or rename its folder.
• Theme, from the server: wp --skip-themes theme activate twentytwentyfour.
• Afterwards: update or roll back, check the PHP version, test updates on staging.

Official sources

• Fatal error recovery mode (WordPress.org)
• Debugging in WordPress (WordPress.org)
• wp plugin deactivate and wp theme activate (WP-CLI)
• WP-CLI global options (--skip-plugins, --skip-themes)

Next steps: go through the WordPress hardening guide, and set up uptime monitoring so you hear about the next error before your visitors do.

ServerNest is being built to take a snapshot before updates and undo them in one step if a site breaks. Join early access to try it first.

← Back to the security blog