Skip to content
ThemesIonic — home
Troubleshooting

"There Has Been a Critical Error on This Website"

The message is deliberately vague because it is shown to visitors. The actual error is in the log, and recovery mode will email you the file and line that failed.

Updated 1 min read intermediate

The message is a placeholder, not a diagnosis. WordPress catches a PHP fatal error, hides the detail from visitors, and emails the specifics to the administrator address. Your job is to read that detail — from the email, from recovery mode, or from the error log — because it names the exact file and line, and the fix follows in seconds once you have it.

Do not start disabling plugins at random. The log already knows the answer.

Get the actual error, in order of ease

1. The email. WordPress sends "Your Site is Experiencing a Technical Issue" to the administrator address in Settings → General. It contains the plugin or theme name, the file, the line, and a recovery-mode link that logs you into an admin where the broken extension is paused.

2. Recovery mode. That link is the fastest route back in. It disables only the failing component, for your session only, so the site keeps serving visitors while you work.

3. The error log. If no email arrived — which is common, because many hosts do not send mail — read the log directly. Most panels expose it; otherwise turn on logging in wp-config.php:

<?php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
// Критично: не показувати помилки відвідувачам, лише писати у файл.
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

The log appears at wp-content/debug.log. Reproduce the error, then read the last entry. Turn all of this off again when you are done — the mechanics are in enabling WordPress debug mode.

Reading the log line

A fatal error names its own cause:

PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product()
in /home/site/public_html/wp-content/plugins/some-addon/init.php:42

Three facts are in that line. What failed — a function that does not exist. Where — a specific plugin, a specific file, line 42. Why — the add-on expected WooCommerce to be active and it is not.

The path is the important part. Whatever directory it points at is what to disable first.

The four causes, by frequency

Log says Cause Fix
Call to undefined function A plugin depends on something that is missing or deactivated Restore the dependency, or remove the dependent plugin
Allowed memory size exhausted The limit is too low for what the page does Increase the memory limit
syntax error, unexpected Code edited by hand, usually in functions.php or a snippet Undo the edit
Cannot redeclare The same function defined twice — often a parent theme's file copied into a child Remove the duplicate

The last one has a specific and very common origin: copying the parent theme's functions.php into a child theme. Both files load, so every function is declared twice — the loading order is explained in functions.php explained.

When you cannot get into the admin at all

Recovery mode needs email; without it, work from the files.

  1. Rename the plugins directory over SFTP — wp-content/plugins to plugins-off. That deactivates everything at once. If the site returns, rename it back and re-enable plugins one at a time. The full method, including doing it through the database, is in disabling plugins without admin access.
  2. If plugins are not the cause, rename the active theme's folder. WordPress falls back to a default theme.
  3. If it broke right after you edited a file, restore that file from a backup. This is the case where a recent backup turns an afternoon into a minute — see backing up a WordPress site.

When it appeared after a PHP upgrade

A host moving you to a newer PHP release is a frequent trigger, and the log will say so: a removed function, or a syntax that is no longer permitted. The failing extension is usually one that stopped being maintained. Rolling PHP back is a temporary measure, not a fix — the sequence is in WordPress not working after a PHP update.

Common mistakes

  • Deactivating plugins before reading the log. The log names the culprit; guessing does not.
  • Leaving WP_DEBUG_DISPLAY on. It prints file paths to visitors.
  • Editing files through the dashboard editor. A syntax error there removes the dashboard you would need to undo it.
  • Ignoring the recovery email as spam. Check the spam folder before concluding it was never sent.
  • Treating the fix as the end. A plugin that fatals on a supported PHP version is telling you it is unmaintained.

Verify

Load the site logged out, then load /wp-admin/. Confirm debug.log receives no new entries after a few page loads. Turn WP_DEBUG back off, and check that whatever the failing extension did is either working again or genuinely no longer needed. If the cause was a memory limit, load the heaviest page on the site rather than the homepage — that is where it will return.

Frequently asked

Because the page is served to visitors, and a PHP fatal error exposes file paths and code structure. WordPress replaces it with a neutral sentence and sends the detail to the site administrator by email instead.
That usually means the site cannot send mail, which is common on hosts without a configured mailer. Fall back to reading the PHP error log through your hosting panel, or enable WP_DEBUG_LOG and read the file directly.
Yes. A theme's functions.php, a code snippet added through a plugin, a PHP version upgrade, or an exhausted memory limit all produce the same message. The log entry names which one, which is why guessing wastes the most time.

Related guides