PHP Fatal Errors in WordPress: How to Read Them and What to Do

PHP fatal errors stop execution completely. Unlike warnings or notices, which PHP logs and continues past, a fatal error means the script stopped at the point of failure and returned nothing useful to the browser. WordPress typically shows this as a white screen, a generic "There has been a critical error" message, or a blank page. Here's how to surface the actual error, read what it's telling you, and fix it.

Enable debug logging first

You can't fix what you can't see. Before anything else, enable WP_DEBUG logging by adding these three lines to wp-config.php, above the line that reads /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Setting WP_DEBUG_DISPLAY to false keeps errors out of the browser output (important for live sites) while still writing everything to /wp-content/debug.log. Access that file via FTP, cPanel File Manager, or SSH. The error will be there with the exact file path and line number.

If you have SSH access, you can tail the log in real time: tail -f /path/to/wp-content/debug.log. Reproduce the error in your browser and watch the log update.

Types of PHP fatal errors in WordPress

Fatal error: Call to undefined function, A function is being called that doesn't exist in the current execution context. Usually caused by a plugin calling a function from another plugin that isn't active, or code written for a different PHP version than the one running on your server. The fix is to either activate the dependency or wrap the call in a function_exists() check.

Fatal error: Cannot redeclare, Two pieces of code are trying to define a function with the same name. Common when the same plugin is somehow loaded twice, or when a child theme's functions.php declares a function that already exists in the parent theme. Fix: wrap your function declarations in if ( ! function_exists( 'my_function' ) ) { ... }.

Fatal error: Class not found, Object-oriented code is instantiating a class that hasn't been loaded. This almost always means a plugin has a dependency on another plugin that isn't active, or an autoloader failed. Check the error file path to identify which plugin is responsible.

Fatal error: Allowed memory size exhausted, PHP hit the memory limit. The error message will include the limit (e.g. Allowed memory size of 67108864 bytes exhausted). You can raise the limit in wp-config.php with define( 'WP_MEMORY_LIMIT', '256M' );, but treat this as a diagnostic step, not a permanent fix, a plugin consuming 256MB per request has a real problem.

Parse error: syntax error, unexpected token, The PHP file contains invalid syntax. A missing semicolon, an unclosed bracket, or an incorrectly placed quote. This is the most common result of manually editing PHP files. The error message will include the file and line number. Open the file and look at the indicated line and the lines immediately above it.

Reading the error: a practical example

Here's a typical debug.log entry:

PHP Fatal error: Call to undefined function get_field() in
/wp-content/themes/mytheme/functions.php on line 47

This tells you four things: it's a fatal error, the undefined function is get_field(), the offending file is your theme's functions.php, and the problem is on line 47. get_field() is provided by Advanced Custom Fields (ACF). The theme is calling it but ACF isn't active.

You have two options: activate ACF, or make the call conditional so it only runs when ACF is present:

if ( function_exists( 'get_field' ) ) {
    $value = get_field( 'my_field' );
}

The conditional approach is more defensive and appropriate when ACF is optional functionality. If ACF is required for the theme to function at all, activate it and document that dependency.

PHP version compatibility errors

Many fatal errors surface after a PHP version upgrade because functions deprecated in older versions have been removed. PHP 8.0 removed several functions that were present in PHP 7.x, and PHP 8.1 and 8.2 introduced strict typing rules that break code relying on implicit type juggling.

Common removals that affect WordPress plugins: mysql_* functions (removed in 7.0), create_function() (removed in 8.0), and each() (removed in 8.0). If you upgraded PHP and started seeing fatals, check whether the function named in the error was removed from your target version. The PHP documentation lists the version each function was deprecated and removed in under the "Changelog" section of each function page.

The practical fix: update the plugin or theme. If the plugin hasn't been updated to support your PHP version and is no longer maintained, it needs to be replaced. Running outdated code on a modern PHP version is a reliable way to accumulate fatal errors.

The WordPress fatal error recovery mode

Since WordPress 5.2, when a fatal error is detected during a normal page request, WordPress automatically sends an email to the admin address with a special recovery mode link. This link lets you log in to wp-admin via a bypass URL that loads with the offending plugin or theme disabled, so you can deactivate it without needing FTP access.

Check your admin email inbox first before reaching for FTP, particularly if the error happened after an update. The recovery mode email arrives within seconds of the fatal being triggered. Once logged in via recovery mode, deactivate the plugin that caused the error, then update or replace it.

If recovery mode emails aren't arriving, check your spam folder and verify that your site's email delivery is working. On many shared hosts, transactional email from WordPress goes through PHP's mail() function, which is often blocked or unreliable. An SMTP plugin (Postman, WP Mail SMTP) with a real mail provider fixes this reliably.

Deactivating plugins via FTP or file manager

If recovery mode isn't available and wp-admin is inaccessible, you can force-deactivate plugins by renaming the plugins folder via FTP or cPanel File Manager. Navigate to wp-content/ and rename the plugins directory to plugins_disabled. WordPress will detect the missing plugins folder and deactivate all plugins, restoring access to wp-admin.

Once in wp-admin, rename the folder back to plugins. Then deactivate plugins one at a time, testing the site after each deactivation, until you identify the culprit. This binary-search approach is faster than testing plugins in random order on a large site.

Preventing fatal errors with staging

The majority of WordPress fatal errors that affect live sites happen because updates (plugin, theme, or core) were applied directly to production without testing. A staging environment where you push updates first catches these errors before they affect real visitors.

The workflow is: apply updates to staging, test critical functionality (checkout, contact forms, navigation, admin access), then push to production. This adds five minutes to your update process and eliminates the panic of a live site going down. Many managed WordPress hosts provide one-click staging. If yours doesn't, a staging subdomain with a separate database is straightforward to set up manually.