--- title: "There Has Been a Critical Error on This Website: How to Fix It in WordPress" description: "There has been a critical error on this website? Learn why the recovery email may never arrive, how recovery mode works, and how to find the faulty plugin." url: "https://skybootstrap.com/there-has-been-a-critical-error-on-this-website/" canonical_url: "https://skybootstrap.com/there-has-been-a-critical-error-on-this-website/" date: "2026-11-12T06:22:00+06:00" modified: "2026-11-05T17:23:08+06:00" author: Skybootstrap Team type: article site: SkyBootstrap language: en-US --- # There Has Been a Critical Error on This Website: How to Fix It in WordPress “There has been a critical error on this website” means a PHP fatal error stopped WordPress, usually in a plugin or theme. To fix it, use the recovery link WordPress emails you, or read the debug log and rename the plugin or theme folder it names. The site comes back once that code stops loading, even before you fix the underlying bug. The email is the quick route, but it often never arrives. We caused this error on our own WordPress 7.1.3 lab site to find out why, and what recovery mode really does. ## What “There has been a critical error on this website” means The critical error screen is WordPress’s replacement for a raw PHP error, and a PHP fatal error is an error that stops the code from running at all, such as a call to a function that doesn’t exist. WordPress catches it, sends HTTP 500, and shows a short message instead of the technical one. On our test site, a test plugin that calls a missing function produced two versions of the message, and the front page showed only this: ![WordPress critical error message on the front page with no mention of email](https://skybootstrap.com/wp-content/uploads/2026/11/critical-error-front-page.webp "Test site, 2 Nov 2026: WordPress 7.1.3, nginx 1.24.0, PHP 8.3. Front page, HTTP 500, no email sent.") The login page added “Please check your site admin email inbox for instructions” after the same sentence, a difference the email section below explains. The [WordPress handbook’s common errors page](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/) says the message means something “prevents WordPress from running as expected”. ## Log in with the recovery link Recovery mode is a WordPress feature, around since version 5.2, that pauses the failing plugin or theme while you sign in. The email WordPress sends contains the link, the name of the plugin or theme, the file and line of the error, and your WordPress and PHP versions. 1. Open the email. On our site its subject was “[Errors Lab] Your Site is Experiencing a Technical Issue”, with the site name in brackets. Check that the link points to your own domain. 2. Click the link. The login page shows “Recovery Mode Initialized. Please log in to continue.” 3. Log in with an administrator account. If you’ve lost the password, get back into wp-admin first. 4. Go to **Plugins** (or **Appearance > Themes** if the email named your theme). 5. Click **Deactivate** under the paused plugin, then **Exit Recovery Mode** in the admin bar. ![WordPress login page with the notice Recovery Mode Initialized, please log in to continue](https://skybootstrap.com/wp-content/uploads/2026/11/critical-error-recovery-login.webp "Test site, 2 Nov 2026: WordPress 7.1.3. The recovery link opens this login page.") After login, our Plugins screen marked the plugin in red with “This plugin failed to load properly and is paused during recovery mode”, with the PHP error printed below: ![Paused plugin shown in red on the Plugins page during a recovery session, with the PHP error printed below it](https://skybootstrap.com/wp-content/uploads/2026/11/critical-error-paused-plugin.webp "Test site, 2 Nov 2026: WordPress 7.1.3. Paused only for the recovery session.") Don’t stop there, because paused means paused for you: while we were in recovery mode, visitors without the recovery cookie still got the 500 error. The site is only fixed once you deactivate, update or replace the plugin. ## Why the recovery email didn’t arrive WordPress only sends the recovery email when the fatal error happens in wp-admin, on the login page or on a similar protected page, and only once a day. Open `/wp-login.php` or `/wp-admin/`: if the same error appears there, WordPress sends the email. In our test the error ran on every page, so the login page sent it while the front page sent nothing. If the login page loads normally, the failing code only runs on the front end, so no email will come; use the debug log below. The daily limit catches people out too: when a second plugin failed a few minutes later, WordPress sent no new email, yet the screen still said “Please check your site admin email inbox for instructions”. If you already used or deleted today’s email, that’s why nothing new arrives. ![Critical error box on wp-login.php that tells the visitor an email with instructions was sent to the admin](https://skybootstrap.com/wp-content/uploads/2026/11/critical-error-login-page.webp "Test site, 2 Nov 2026: WordPress 7.1.3. This version appears on wp-admin and the login page.") Three more things to check: - **Where it went.** The email goes to the address in **Settings > General > Administration Email Address**, unless `RECOVERY_MODE_EMAIL` is set; RECOVERY_MODE_EMAIL is a wp-config.php setting that sends recovery emails to a different address. - **Spam and mail delivery.** Check the spam folder first. If your server’s mail isn’t delivered at all, no recovery email arrives; we couldn’t test delivery, because our test server has no mail server. - **The daily limit.** WordPress stores the time of the last email in an option called `recovery_mode_email_last_sent`. If you have SSH access, deleting it with `wp option delete recovery_mode_email_last_sent --skip-plugins` let the next error send a fresh email on our test site. Without SSH, skip straight to the debug log. To send future emails somewhere you’ll see them, add this to wp-config.php above “That’s all, stop editing”: ``` define( 'RECOVERY_MODE_EMAIL', 'you@example.com' ); ``` ## Find the plugin or theme without the email When the email is gone, the debug log names the culprit. The file to edit is wp-config.php, the settings file in your site’s main folder next to `wp-admin` and `wp-content`. Open it with your host’s file manager and download a copy before you edit it. Find `define( 'WP_DEBUG', false );`, which the standard file already has, and replace it so the lines read: ``` define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); ``` Don’t paste these under the old line: PHP keeps the first WP_DEBUG value, so a second one is ignored and nothing gets logged. Reload the broken page, then open `wp-content/debug.log`. Look for the line that starts with “PHP Fatal error”; the folder after `wp-content/plugins/` or `wp-content/themes/` in it is the one to switch off. When you’re done, set WP_DEBUG back to `false`, remove the two added lines and delete `debug.log`: on our test sites anyone could download it. Our guide to WordPress errors shows how to log to a private folder instead. Then switch that code off. Before you rename anything, copy the folder somewhere safe, so you can put it back: - **A plugin:** rename its folder in `wp-content/plugins`, for example to `plugin-name.off`. Our site came back at once; the plugin was deactivated the next time we opened the Plugins screen, and renaming the folder back left it inactive, so reactivate it once it’s fixed. - **All plugins:** the WordPress handbook advises renaming the whole `plugins` folder (to `plugins_old`) when the log doesn’t name one; we tested single-plugin renames only. - **With SSH:** run `wp plugin deactivate plugin-name --skip-plugins --skip-themes`. Without `--skip-plugins`, WP-CLI loaded the broken plugin and crashed too. - **Code you edited:** if you just changed a file, open it in the file manager and undo the change on the line the email or log names. Restoring our edited functions.php brought the site straight back. - **The theme:** the handbook suggests activating a default theme; in recovery mode that’s under **Appearance > Themes** (we didn’t test this route). Renaming the active theme’s folder gave us a blank page until we opened wp-admin, so keep a second default theme installed. ## Common causes of the PHP fatal error Four different causes of a PHP fatal error gave the same critical error screen on our test site, and the debug log told them apart: - **A plugin calling a missing function:** “Call to undefined function lab_missing_function()”. The WordPress handbook links this message to failed updates, incompatible plugins and misspelled functions. - **A syntax error in the theme’s functions.php:** the email said “WordPress caught an error with your theme” and named E_PARSE and the line. - **Old code on a new PHP version:** a plugin using `create_function()`, which [PHP 8.0 removed](https://www.php.net/manual/en/function.create-function.php), failed with “Call to undefined function create_function()”. If the errors started after your host upgraded PHP, update the plugin or replace it. - **Running out of memory:** “Allowed memory size of 134217728 bytes exhausted”. Our memory error guide covers raising the limit. The handbook’s own list adds theme compatibility and corrupted WordPress files. ## When the error won’t go away If the error stays and neither the error line nor its stack trace names a file in `wp-content/plugins` or `wp-content/themes`, the cause may be WordPress itself or the server. Restore your latest backup, or ask your host to: - reinstall the WordPress core files for your version; - confirm which PHP version the site runs and whether it changed recently; - check the server’s PHP error log for the same time. If you see a blank page instead of this message, the error handler may be off; our [white screen guide](https://skybootstrap.com/wordpress-white-screen-of-death/) covers that case. ## Frequently Asked Questions ### Does the critical error mean my site was hacked? Not by itself. The handbook’s list of causes covers plugins, themes, PHP, memory and corrupted files, not attacks, and the errors in our lab were code we broke on purpose. If the debug log points at files you didn’t install, treat it as a possible hack and follow our [hacked site guide](https://skybootstrap.com/wordpress-site-hacked/). ### Can I turn off the critical error screen? Yes, with `define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );` in wp-config.php, but it doesn’t help. On our test site the same error then returned an empty HTTP 500 page: a blank screen with no message and no recovery email. Leave the handler on and read the debug log instead. ### How long does recovery mode last? The link in the email expires after 1 day, and WordPress sends at most one recovery email a day by default. Once you log in, the plugin stays paused for your session until you deactivate it or click Exit Recovery Mode. ### Why does wp-admin show the error but the front page works? The failing code only runs in the admin area. On our test site, an error placed on an admin-only hook gave HTTP 500 in wp-admin for a logged-in admin while the front page loaded normally. Rename the plugin’s folder, or use the recovery link, which comes from exactly these wp-admin errors. ## How we tested Our test site ran WordPress 7.1.3 with only the Twenty Twenty-Five theme, on nginx 1.24.0, PHP 8.3 and MariaDB 10.11. We broke it on 2 November 2026 in three ways: a test plugin calling a missing function, one using the old `create_function()`, and a syntax error in the theme’s functions.php. Each time we noted the status code, the screen and the email. That server can’t send real email, so a mail-logging plugin caught every message WordPress tried to send, and we read the recovery email there. The debug.log download check ran again on an Apache 2.4.58 copy of the site. We confirmed the recovery mode limits, one email a day and the link’s lifetime, in WordPress 7.1.3’s source code.