✓ No commitment · ⚡ Reply within 24 h · 💬 WhatsApp
🚨 WordPress critical · Restore in under 1 hour

"There has been a critical error
on this WordPress site"?
we bring it back online today.

WordPress critical error diagnostic and resolution

Message visible to all your visitors, WordPress "recovery mode" email never received, guilty plugin unknown: no data is lost, just code to neutralise. We enable debug, isolate the culprit, restore your WordPress. Free diagnostic, firm quote within 24 business hours.

Or chat on WhatsApp
✓ No data loss ✓ Restore < 1 h in 9 out of 10 cases ✓ From €60/h excl. VAT on quote ✓ 30-day warranty
📩 The exact message

What WordPress shows your visitors

Since WordPress 5.2 (May 2019), this is what your visitors see when a fatal PHP error occurs.

There has been a critical error on this website.

Please check your site admin email inbox for instructions.

↑ The default WordPress message. In French: "Il y a eu une erreur critique sur ce site."

The "recovery mode" email WordPress claims to have sent? In 7 out of 10 cases, it never arrives — because wp_mail() isn't configured (no SMTP, server IP blacklisted, mail filtered as spam). We work around it by accessing WordPress via FTP/SSH: same result, without depending on the email.

🔎 Typical causes

The 6 most frequent causes

Across 40 WordPress emergency interventions in 2025-2026. One may be present, or several stacked.

1. Plugin incompatible with your PHP version

~40% of cases. You move from PHP 7.4 to PHP 8.1 (forced by your host), and an old plugin uses a removed function or deprecated syntax. Typical error: Fatal error: Uncaught TypeError: ... must be of type string, null given. Fix: disable the plugin, find a maintained alternative, or apply a local patch if the plugin is critical.

2. Plugin conflict

~25%. Two plugins declare the same global function, or plug the same hook with conflicting priorities. Typical error: Cannot redeclare function or Call to undefined function. Fix: identification by bisection (disabling in successive halves), choice of which plugin to keep, clean removal of the second.

3. Updated theme breaking a child function

~12%. You use a child theme that overrides a parent function. The parent theme is updated, the parent function signature changes, your child functions.php crashes. Fix: adapt functions.php, or temporary rollback to the previous parent theme version.

4. wp-config.php mis-edited

~8%. You added a line to enable debug but forgot the trailing ;. Or copy-pasted a snippet from a blog with typographic quotes instead of ". WordPress can no longer load its config and crashes at bootstrap. Fix: compare with wp-config-sample.php, restore syntax, validate PHP via command line (php -l wp-config.php).

5. Insufficient PHP memory

~8%. On WooCommerce sites with large catalogues + cache plugin + security plugin, the default 128MB PHP memory blows up in admin. Error: Allowed memory size of X bytes exhausted. Fix: raise WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT in wp-config.php, audit the guilty plugin.

6. WordPress core corrupted (incomplete FTP transfer)

~7%. Brutal FTP migration, interrupted transfer, partial backup restore. Missing or truncated core files. Fix: download a clean copy of WordPress, rewrite /wp-includes/ and /wp-admin/ without touching /wp-content/ or wp-config.php.

⚡ Typical intervention

Critical error resolved in 38 min

Real case · SME services site + WooCommerce · WordPress 6.4 + 32 plugins · March 2026.

11:02
Client call "Our site has been showing 'There has been a critical error on this website' since this morning. No email received, we can't access admin anymore."
11:08
FTP access retrieved · plugins neutralised Rename /wp-content/plugins/ to plugins_OFF/. Admin access restored immediately.
11:14
Enable WP_DEBUG_LOG Edit wp-config.php: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);. Restore plugins folder, refresh.
11:21
Guilty plugin identified /wp-content/debug.log: PHP Fatal error: Uncaught Error: Class "WC_Geolocation" not found in /wp-content/plugins/x-shipping/includes/Calculator.php:88. The x-shipping plugin depended on a WooCommerce class removed in WC 8.3.
11:34
Plugin cleanly disabled Deactivation via admin (not raw rename). Temporary patch to use WC_Geolocation_Loader instead. Checkout tests: OK.
11:40
Debug disabled · report sent Debug off, site OK for visitors. Email with timeline + cause + fix + recommendation (report the bug to the plugin vendor).
38 min
Total time
~ €40
Billed on quote
(38 min × €60/h excl. VAT)
0
Post / order lost
💰 Pricing

Pricing stated up-front

Free diagnostic. For the intervention, you know exactly what it costs before we touch the code.

🔍 Diagnostic

Diagnostic

find the guilty plugin
0free
30 min · no commitment
  • WP_DEBUG_LOG enabled + read debug.log
  • Faulty plugin or theme identified
  • Firm quote sent immediately
  • You decide if we continue
Start the diagnostic →
⚡ Most requested 🔧 Intervention

Targeted intervention

bring WordPress back online
from 60excl. VAT
per diagnostic · price stated up-front
  • Backup of files + DB before any intervention
  • Neutralisation of the faulty plugin / theme
  • Replacement or local patch if needed
  • Written report: cause + fix applied
  • 30-day warranty on the fix
🛡️ Maintenance

Monthly maintenance

plugin audit + controlled updates
from 50/ month
24/7 monitoring · no commitment
  • Monthly audit of WordPress plugins
  • Daily automatic backups externalised
  • Updates tested on staging before deployment
  • Priority intervention on critical error
❓ FAQ

WordPress critical error — frequently asked questions

This is the message WordPress has been showing since version 5.2 (May 2019) when a fatal PHP error is detected. WP refuses to show the technical stack trace to visitors for security reasons and instead sends an email to the admin with a magic recovery mode link. If you didn't receive the email, it's typically because wp_mail() isn't configured (no SMTP, server IP blacklisted).
Two options. (1) Retrieve the token from the wp_options table (option recovery_mode_token) via SSH or phpMyAdmin. (2) The fastest: bypass recovery mode by disabling plugins via FTP — rename /wp-content/plugins/ to plugins_OFF/, all plugins become inactive and admin access is restored.
Three methods: (1) Enable WP_DEBUG_LOG in wp-config.php, reload, read /wp-content/debug.log — file and line at fault are indicated. (2) Bisection disabling (in successive halves). (3) Read php-fpm.log or error_log directly — the stack trace shows the .php file. Method (1) is fastest with FTP access.
For 90% of cases, the site is restored in under one hour. For complex cases (corrupted core, multi-plugin conflict, PHP 7→8 migration breaking 5 plugins simultaneously), expect half a day. ETA stated after the initial free diagnostic.
No. A WordPress critical error is almost always a code issue (plugin, theme, PHP), never a database issue. Your posts, pages, media, WooCommerce orders, users remain intact. And the fix always starts with an externalised files + DB backup.
Free diagnostic (30 min) then intervention on quote, from €60/h excl. VAT. The majority of critical errors are resolved in under 2 hours once the cause is identified (faulty plugin/theme identification, clean disabling, replacement or patch if needed, regression test, written post-mortem). Firm quote sent within 24 business hours before any work starts. Included in maintenance.
Three causes: (1) The plugin left residues in DB or filesystem that crash another plugin. (2) Several plugins were at fault, you only identified one. (3) The plugin reactivates automatically (network-activated on multisite, or MU-Plugin). The clean fix requires a full audit of all loaded code.

Critical error right now?

Free diagnostic, firm quote within 24 business hours, intervention from €60/h excl. VAT on quote.

💬 Chat on WhatsApp
💬 Chat on WhatsApp — reply in minutes