The screen goes white with a message: “There has been a critical error on your website.” Or the entire front-end and admin vanish simultaneously. Or you just updated a plugin and everything broke instantly. A WordPress fatal error is one of the most alarming events on a WordPress site — it stops the entire site cold and leaves even experienced developers scrambling. But every fatal error has a specific cause and a specific fix, and WordPress 5.2+ includes a recovery mode that makes the fix safer than it used to be. For a broader walkthrough, our WordPress Errors Complete Guide is a good next read.
WordPress Fatal Error — Understanding What It Actually Is
A WordPress fatal error is a PHP error severe enough to halt execution entirely. Unlike warnings or notices (which are logged silently), a fatal error stops PHP mid-execution, preventing WordPress from generating any output. The “critical error” message visitors see is WordPress’s error recovery screen — a safer placeholder than a blank page that also sends an email to the admin with a link to the recovery mode login.
Fatal errors in WordPress have three main forms: Fatal error: Call to undefined function (a function was called that does not exist — typically because a plugin is calling a function from another plugin that is deactivated), Fatal error: Allowed memory size exhausted (PHP ran out of memory during execution — common after installing a memory-intensive plugin), and Fatal error: Maximum execution time exceeded (PHP took too long to process a request — common during import operations or when a plugin makes too many external API calls). Identifying which type appears in the error log narrows the fix immediately. Our guide on fixing WordPress memory exhausted errors covers the memory-specific fatal error in detail — this article focuses on the broader range of PHP fatal errors that cause the critical error screen.
WordPress 5.2 introduced a built-in protection system: when a WordPress fatal error occurs, WordPress emails the admin address with a “recovery mode” link. Clicking this link provides a special admin session where the broken plugin or theme can be deactivated even when the normal admin is inaccessible. Check the email associated with the WordPress admin account for a message from WordPress Recovery Mode — it arrives within seconds of the fatal error and provides the safest route to fixing the problem without FTP or database access.
Identifying the Cause Via Error Logs
The most efficient approach to a WordPress fatal error is reading the exact error message rather than guessing. The error log contains the complete error, the file that caused it, and the exact line number — information that makes the fix specific and fast.
Enable error logging by adding these lines to wp-config.php above the “That’s all, stop editing!” comment:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);WP_DEBUG_DISPLAY is set to false to prevent the error from being shown publicly to visitors. With logging enabled, reproduce the WordPress fatal error → check /wp-content/debug.log. The log entry shows the exact error type, the message, the file path, and the line number. A message like Fatal error: Call to undefined function wc_get_product() in /wp-content/plugins/some-plugin/some-file.php on line 47 tells you immediately that some-plugin is calling a WooCommerce function without WooCommerce being active. This specificity eliminates guesswork. Most WordPress fatal error log entries directly name the responsible plugin or theme file, allowing targeted deactivation rather than blanket disabling of everything.
Fixing the Fatal Error — Deactivation and Recovery
Once the cause is identified, fixing the WordPress fatal error follows a clear priority order: use built-in recovery mode first: use the built-in recovery mode first, then FTP plugin deactivation, then database plugin deactivation as a last resort.
Recovery Mode (safest, no technical knowledge needed): Use the link from the WordPress recovery email → log into the admin through recovery mode → the problematic plugin is flagged on the Plugins page → deactivate it → exit recovery mode → visit the site. Recovery mode is the cleanest fix because WordPress itself identified the problematic plugin and no file access is needed.
FTP deactivation for WordPress fatal error (when recovery email is unavailable): Connect via FTP or File Manager → navigate to wp-content/plugins/ → rename the folder of the suspected plugin from “plugin-name” to “plugin-name-disabled” → reload the site. WordPress deactivates any plugin whose folder has been renamed and the fatal error stops immediately. Rename the folder back to “plugin-name” once the issue is identified, then decide whether to update the plugin, contact the developer, or find an alternative. If no specific plugin is suspected, rename the entire plugins folder to plugins_old — the site loads with no plugins, confirming a plugin cause. Re-enable plugins one at a time until the WordPress fatal error returns.
Database deactivation (when FTP is unavailable): Access phpMyAdmin via your hosting control panel → select the WordPress database → find the wp_options table → search for the row where option_name is “active_plugins” → click Edit → clear the option_value field (change it to a:0:{}) → Save. This deactivates all plugins at the database level, allowing admin access. Navigate to WordPress admin → Plugins → reactivate plugins one at a time. This is the most invasive method but works on all hosting environments.
Fatal Errors From Theme Code
When plugin deactivation does not resolve the WordPress fatal error, the active theme’s PHP code is the cause. Theme-caused fatal errors are particularly common immediately after a theme update, when the updated theme code is incompatible with a PHP version or with a third-party library.
Switch to a default WordPress theme to confirm a theme-caused WordPress fatal error: via FTP, rename the active theme’s folder → WordPress automatically falls back to the most recent default theme (Twenty Twenty-Four or similar). If the fatal error disappears, the theme’s code is confirmed as the cause. The fix options are: wait for the theme developer to release a patch, revert to the previous version of the theme (reinstall the older theme version from the theme developer’s archive), or switch to an alternative theme. For child themes, the child theme’s functions.php or template files may contain the error — check the debug.log line number against the child theme files before blaming the parent theme.
PHP version incompatibility causes WordPress fatal error after updates after theme or plugin updates. A plugin or theme updated to use PHP 8.0 syntax (named arguments, match expressions, nullsafe operators) causes fatal errors on servers still running PHP 7.4. Check the PHP version: WordPress admin → Tools → Site Health → Info → Server → PHP version. If the PHP version is below what the updated plugin or theme requires, upgrade PHP through the hosting control panel (cPanel → Software → PHP Version Manager). Always test on staging before upgrading PHP on production to catch any other code incompatibilities before they affect live visitors. According to the PHP project’s documentation, PHP 7.4 reached end-of-life in November 2022 — sites still running PHP 7.4 are both vulnerable to security issues and increasingly incompatible with plugins and themes requiring PHP 8.x.
Preventing WordPress Fatal Errors
The most effective approach to WordPress fatal error prevention is a staging-first update workflow. Never update plugins, themes, or WordPress core directly on a production site without first testing on a staging environment. Most managed WordPress hosts provide one-click staging. Update everything on staging → test thoroughly → push to production. This workflow catches fatal errors caused by PHP version conflicts, plugin incompatibilities, and deprecated function calls before they affect live visitors.
Keep PHP up to date: the majority of WordPress fatal error reports involving “Call to undefined function” or “Call to a member function on null” errors occur on outdated PHP versions where newer code patterns are not supported. PHP 8.2 is the current recommended version for WordPress — it provides better error handling, faster execution, and compatibility with all actively maintained plugins. Schedule PHP version reviews quarterly alongside plugin updates to prevent version drift from accumulating.
Use a backup plugin that creates daily automated backups with off-site storage (UpdraftPlus with Dropbox/Google Drive, All-in-One WP Migration, or Jetpack Backup). When a WordPress fatal error cannot be resolved quickly through plugin deactivation — for example, when the error is in a custom-coded plugin or a deeply integrated theme — a clean restore from the previous day’s backup is often faster than debugging a complex PHP error in production. The backup restore point should be to a state before the update that triggered the error, confirming the update as the cause and providing a clean starting point for the fix. Our guide on backing up a WordPress site covers the backup strategies that make fatal error recovery straightforward rather than catastrophic. Reviews from the WordPress support community confirm that plugin PHP incompatibilities and memory exhaustion together account for the majority of WordPress fatal errors on sites running current WordPress versions.
The WordPress fatal error “Call to undefined function” is particularly common when WordPress plugins have dependencies on each other. A plugin that extends WooCommerce, WPML, or Advanced Custom Fields calls functions from those parent plugins — if the parent plugin is deactivated or deleted, every dependent plugin produces a fatal error when it tries to call those functions. The error log message names the undefined function, which reveals the missing parent plugin. Reinstalling or reactivating the parent plugin immediately resolves the fatal error for all dependent plugins that required it.
After resolving any WordPress fatal error, checking the Site Health report confirms that no secondary issues were introduced during recovery: Tools → Site Health → Status. The status page highlights any configurations that may have been altered during the recovery process — for example, if debug mode was left enabled (a security risk in production), the status report flags it. Also verify that all plugins are correctly active (Plugins → Installed Plugins → check for any showing as inactive that should be active) and that the theme is loading correctly (Appearance → Themes → confirm active theme). A clean Site Health report and a full front-end review confirm the site is fully functional after recovery.
Monitoring services that alert on WordPress fatal error occurrences prevent extended downtime that would otherwise go unnoticed between scheduled manual checks. Jetpack’s Downtime Monitor, UptimeRobot (free for basic monitoring), and Pingdom all send immediate email or SMS alerts when a site returns an error HTTP status. For production sites, a monitoring service that checks every minute means a fatal error caused by an automatic plugin update at 3 AM is caught and addressed before most visitors encounter it. Combining automated monitoring with automatic daily backups provides a complete safety net: the alert tells you something broke, and the backup provides an immediate recovery path if the fix is not immediately obvious.
Some WordPress fatal error scenarios involve corrupted core files rather than plugin or theme code. A failed WordPress auto-update that was interrupted mid-process can leave core PHP files in a partial or corrupt state, causing fatal errors that persist even after all plugins are deactivated and the theme is switched. The fix is to reinstall WordPress core files without affecting the database, wp-content, or wp-config.php: download the same WordPress version from wordpress.org → extract the archive → upload everything except the wp-content folder and wp-config.php to the server, overwriting existing files. This replaces all core PHP files with clean versions while preserving all content, plugins, themes, and configuration. After the core file reinstall, the fatal errors caused by corrupted core files disappear immediately.
For managed WordPress hosting environments where FTP access, direct file editing, and phpMyAdmin are restricted, resolving a WordPress fatal error may require contacting hosting support directly. Most managed hosts (WP Engine, Kinsta, Flywheel) have staging environments and snapshot restoration capabilities that allow instantly reverting to the pre-error state without any manual file manipulation. Providing the host’s support team with the exact error message from the debug log and the timestamp of when the error started allows them to identify the problematic plugin update in their own activity logs and either restore the snapshot or deactivate the plugin from the server side. For sites on managed hosting, leaning on the host’s support infrastructure is often faster than attempting manual FTP recovery through the restricted environment.
Understanding which WordPress fatal error types cannot be caught by WordPress’s recovery mode helps set expectations for the most severe cases. WordPress’s recovery mode only catches plugin and active theme errors — errors in must-use plugins (mu-plugins directory), sunrise.php in multisite, and wp-config.php itself are not caught and can cause a complete blank white screen with no recovery email. These files execute before WordPress’s error handler is initialised. For errors in these files, FTP access is the only recovery path — check the error log directly on the server (usually accessible via hosting panel → Logs → PHP Error Log) rather than /wp-content/debug.log, since WordPress’s logging system may also be unavailable. Rename or edit the problematic file via FTP, and the site recovers immediately. You might also run into WordPress Theme Broken After Update.
