← All articles

WordPress

There has been a critical error on this website

"There has been a critical error on this website." One sentence on a white page, no detail, and your site is gone. It is a deliberately unhelpful message, and it appears at the worst possible moment — usually right after an update, and usually on a Friday.

The good news: it is almost never as bad as it looks. In the overwhelming majority of cases it's a single PHP fatal error, caused by one plugin, and the site is entirely intact behind it. Nothing is lost. You just can't get at it yet.

What the message actually means

WordPress hit a PHP fatal error and stopped. Rather than show you a stack trace — which would leak file paths and software versions to anyone who visited — it shows the generic sentence and, since WordPress 5.2, tries to email you the details.

That last part is the important bit, and most people miss it.

Step 1: check the admin email

WordPress sends a message to the site's admin email address with the subject line "Your Site is Experiencing a Technical Issue". It contains two genuinely valuable things:

Check spam. Check whether the admin email is an address anyone still reads — on sites I take over it's routinely a previous developer's address or an info@ mailbox nobody opens. If the email never arrives, the site may also have broken email delivery, which is a separate problem you now know about.

If you got the email, you are probably ten minutes from a working site. If you didn't, keep going.

Step 2: try wp-admin directly

Go to yoursite.ie/wp-admin/. Sometimes the front end is broken and the dashboard still loads, which makes everything easier. If you can get in, go to Plugins and deactivate whatever you updated most recently.

If the dashboard shows the same critical error, the failing code is loading on every request, and you'll need file access.

Step 3: turn on the error log

You want to see the actual error rather than guess. Edit wp-config.php via your host's file manager or FTP, and find the line that says /* That's all, stop editing! */. Above it, add:

That last line matters: it keeps the errors out of the page your visitors see and writes them to wp-content/debug.log instead. Reload the site once, then open that file. The last few lines will name the plugin, the file and the line.

A typical entry looks like PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/some-plugin/includes/thing.php on line 214. The plugin folder name in that path is your culprit. Remember to set WP_DEBUG back to false when you're done.

Step 4: disable the plugin without a dashboard

You don't need wp-admin to deactivate a plugin. Using your host's file manager or FTP, go to wp-content/plugins/ and rename the offending folder — some-plugin becomes some-plugin-off. WordPress can no longer find it, so it treats it as deactivated, and the site should come back immediately.

If you don't know which plugin it is, rename the whole plugins folder to plugins-off. That disables everything at once. If the site returns, it's definitely a plugin. Rename the folder back, then rename plugins one at a time until it breaks again. Tedious, but conclusive.

Same technique for themes: if it's the theme, put a copy of a default theme such as twentytwentyfour in wp-content/themes/ and rename your active theme's folder. WordPress falls back to a default theme when the active one goes missing.

The five causes, in order of likelihood

  1. A plugin update. Something like 70% of the ones I'm called about. A plugin shipped code that conflicts with another plugin, your theme, or your PHP version.
  2. A PHP version change. Your host upgraded PHP — sometimes automatically, sometimes with an email you didn't read — and an old plugin or theme uses a function that PHP has since removed. The site was fine yesterday and nothing on it changed. Hosts in Ireland and the UK have been moving accounts to PHP 8.x, and this is the usual fallout.
  3. A theme or child-theme edit. A stray character in functions.php. If you edited a file in the dashboard right before it broke, that's your answer.
  4. Exhausted memory. "Allowed memory size of X bytes exhausted" in the log. Raising WP_MEMORY_LIMIT is a valid short-term step, but a site that suddenly needs far more memory usually has something wrong with it rather than something missing.
  5. A hack. Less common as a cause of this specific message, but it happens — injected code with a syntax error, or a security plugin's cleanup that removed a file something else depended on. If you find PHP files in wp-content/uploads, stop treating this as a broken update and treat it as a compromise.

What not to do

Why this keeps happening

Every instance of this error is a plugin update applied without a backup taken first and without anyone looking at the site afterwards. That's it. That's the whole pattern.

The fix isn't "update less" — out-of-date plugins are how sites get hacked, and that's a worse outcome. The fix is that updates need a backup immediately before and a check immediately after, which is dull, manual, and exactly the kind of work that doesn't get done when the person responsible is also running a business. That's the entire reason my €49/month care plan exists, and why the plan takes a backup before it touches anything.

If your site is showing this right now and you'd rather not go near wp-config.php, I fix these for €250, usually the same day. Send me the site address and, if you have it, the text of that email from WordPress — it often means I already know what's wrong before I log in.

WordPress PluginsWooCommerce Plugins WordPress & WooCommerce Plugins Partner 🎯 SEO & PPC Partner