How to Find the Source of a WordPress PHP Fatal Error

A WordPress PHP fatal error usually tells you more than just “the site is broken.” The error message can often identify the exact PHP file, line number, plugin, theme, or WordPress component involved. The challenge is reading the message correctly and separating the location where PHP stopped from the component that actually caused the failure.

The fastest approach is to work from the error evidence outward: check WordPress Recovery Mode, inspect the PHP error message and stack trace, enable logging when necessary, identify the first relevant plugin or theme path, and then isolate the failing component safely. This guide walks through that process without relying on guesswork.

What a WordPress PHP Fatal Error Actually Means

A PHP fatal error means execution cannot continue normally. Modern PHP reports many serious programming failures as Error or other Throwable objects, and an uncaught error can terminate the request with a fatal error. PHP also supports logging errors separately from displaying them. For production sites, PHP documentation recommends logging errors rather than exposing detailed errors to visitors.

In WordPress, a fatal error can be caused by a plugin, theme, custom code, WordPress core, or the PHP/server environment. WordPress has a built-in Recovery Mode that can pause a plugin or theme responsible for a fatal error and allow an administrator to access the dashboard for investigation.

See the official WordPress Recovery Mode documentation and the PHP error handling documentation for the underlying behavior.

The Most Important Part of the Error Message

Consider an error like this:

Fatal error: Uncaught Error: Call to undefined function px_example_helper()
in /home/example/public_html/wp-content/plugins/example-plugin/includes/admin.php:124

Several pieces of information matter:

• Error type: Call to undefined function
• File: wp-content/plugins/example-plugin/includes/admin.php
• Line: 124
• Likely component: the example-plugin plugin

The path is often the strongest clue. A path containing /wp-content/plugins/ normally points toward a plugin. A path containing /wp-content/themes/ normally points toward a theme. A path under /wp-includes/ may indicate WordPress core, but you should not automatically assume that core is the original cause.

A stack trace can reveal what called the failing code before PHP stopped execution. That is especially useful when the file named in the fatal message is only the point where an invalid call, missing class, or incompatible argument finally became fatal.

Step 1: Check WordPress Recovery Mode First

Since WordPress 5.2, Recovery Mode can detect some fatal PHP errors during normal page loads and temporarily pause the plugin or theme associated with the failure. WordPress can also send the site administrator an email containing information about the problem and a Recovery Mode login link.

When Recovery Mode is available:

1. Open the Recovery Mode link from the WordPress administrator email.
2. Log in to the dashboard.
3. Read the notice identifying the failed plugin or theme.
4. Inspect or deactivate the affected component.
5. Fix the underlying problem rather than treating deactivation as the permanent solution.
6. Exit Recovery Mode and test the site normally.

WordPress stores information about paused extensions so that a failing plugin or theme can be isolated without necessarily taking the entire site offline for the administrator. Recovery Mode is therefore often the lowest-risk first diagnostic step.

For implementation details, see the official WP_Recovery_Mode reference and wp_is_recovery_mode() documentation.

Step 2: Read the Exact Fatal Error, Not Just “Critical Error”

The WordPress message “There has been a critical error on this website” is only a generic symptom. It does not tell you the real cause by itself.

You need the underlying PHP message, which may look like one of these:

Do not treat every filename mentioned in a stack trace as equally responsible. The useful question is: which component introduced the invalid operation that caused the fatal condition?

Step 3: Enable WordPress Debug Logging

When the fatal message is incomplete, the site only shows a generic critical-error screen, or the failure occurs during an AJAX, REST, scheduled, or background request, WordPress debugging can provide much more useful evidence.

The official WordPress debugging documentation supports WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY. A practical configuration for troubleshooting a live site is:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Place these definitions in wp-config.php using the normal WordPress configuration location and make sure you do not create duplicate definitions that conflict with existing settings.

With WP_DEBUG_LOG enabled, WordPress normally writes logged errors to:

wp-content/debug.log

WordPress also supports specifying a custom log path instead of the default location. The official documentation notes that publicly accessible log files can expose sensitive information, so debug logs should not be left exposed to visitors.

See Debugging in WordPress and Editing wp-config.php for the documented configuration options and security considerations.

Step 4: Reproduce the Error and Match the Timestamp

Do not debug an old error when a new one is available. Clear or archive the existing log where appropriate, reproduce the failure once, and then inspect the newest entries.

A simple workflow is:

1. Record the exact action that triggers the fatal error.
2. Note the approximate time.
3. Reproduce the problem once.
4. Open the newest relevant entries in wp-content/debug.log.
5. Look for the fatal error and any immediately preceding warnings or errors.

This matters because a busy WordPress installation can produce many unrelated notices, warnings, and deprecation messages. The latest timestamp associated with the failed request is often more valuable than scanning thousands of old log lines.

Step 5: Find the Plugin, Theme, or Core Path in the Stack Trace

Suppose the log contains:

PHP Fatal error: Uncaught Error: Call to undefined method
Example_Helper::build_report()
in /home/example/public_html/wp-content/plugins/site-tools/includes/report.php:91

Stack trace:
#0 /home/example/public_html/wp-content/plugins/site-tools/includes/admin.php(210):
    Site_Tools_Report->generate()
#1 /home/example/public_html/wp-includes/class-wp-hook.php(326):
    site_tools_admin_page()
...

The key evidence is that the failure occurs inside wp-content/plugins/site-tools/. WordPress core appears later in the trace because core is executing the hook chain, but that does not automatically make core the source of the bug.

As a practical rule, inspect the first meaningful path that points to custom code, a plugin, a theme, or an external library. Then work backward through the stack trace to understand why that code was executed.

Why the WordPress Core File Is Not Always the Culprit

You may see an error such as:

/wp-includes/class-wp-hook.php

That file is frequently part of the execution path because WordPress uses hooks extensively. A plugin callback can be registered with a core hook, and the eventual fatal may surface while WordPress is dispatching that callback.

Before replacing WordPress core files, inspect the surrounding stack frames and determine which extension registered or triggered the failing callback.

Step 6: Check the Exact Line of Code

The reported line number is your next investigation point. Open the file at that line and inspect the surrounding code rather than changing the line blindly.

For example:

Fatal error: Uncaught Error: Call to undefined function px_parse_settings()
in /wp-content/plugins/example-plugin/includes/settings.php:147

Line 147 might contain:

$settings = px_parse_settings( $raw_settings );

Now the diagnostic question becomes much narrower: where should px_parse_settings() be defined, and why is that definition unavailable?

Possible causes include:

• A required PHP file was not loaded.
• An autoloader was not initialized.
• A dependency was removed or updated.
• A plugin update changed the API being used.
• Code execution occurs before a required component is registered.
• Two incompatible plugin or theme versions are being loaded together.

The line number narrows the failure. It does not, by itself, prove which change is the correct fix.

Step 7: Check What Changed Immediately Before the Fatal Error

Many production WordPress fatal errors appear immediately after a change: a plugin update, theme deployment, PHP version change, custom-code edit, dependency update, or configuration change.

Compare the failure against recent changes, but do not assume the newest change is automatically responsible. A recent update may expose an older incompatibility elsewhere in the stack.

Useful questions include:

• Was a plugin or theme updated immediately before the failure?
• Did the PHP version change?
• Was custom code added to functions.php or a plugin?
• Did a Composer dependency or bundled library change?
• Did a server extension, PHP setting, or deployment change?
• Did the fatal begin only on the frontend, only in wp-admin, or only on one endpoint?

Scope is a powerful diagnostic signal. A failure limited to one admin screen suggests a different execution path from a failure that occurs on every frontend request.

Step 8: Isolate Plugins and Themes Safely

When the source is still unclear, isolate the execution layer instead of randomly editing files.

Start with the narrowest change that tests your hypothesis. For example, if the log explicitly identifies a plugin, deactivate that plugin and retest. If the site becomes healthy, you have strong evidence that the plugin or its interaction with the current environment needs investigation.

For sites where the dashboard is inaccessible, WordPress documentation describes temporarily renaming a plugin directory through FTP or a hosting file manager. This can disable a plugin when normal WordPress administration is unavailable.

WP-CLI provides another controlled method:

wp plugin deactivate example-plugin

The official wp plugin deactivate documentation also supports broader isolation options. For diagnosis, avoid destructive options such as uninstalling unless you have a specific reason and a tested recovery path.

Testing All Plugins Without Permanently Changing the Site

When appropriate, WP-CLI can load WordPress while skipping plugins or themes for diagnostic purposes. The global options include --skip-plugins and --skip-themes. This can help determine whether the failure depends on one of those layers.

Remember that mu-plugins are still loaded when using the plugin-skip mechanism documented by WP-CLI, so a must-use plugin can remain part of the failing execution path.

Step 9: Check the Theme and Child Theme

If the error path points into:

wp-content/themes/

inspect the active theme and, when applicable, its child theme.

A common diagnostic mistake is to edit the parent theme when the actual custom code lives in the child theme, or to edit a theme file when a plugin is injecting the callback that eventually fails.

When a theme-related fatal makes the dashboard inaccessible, switching to a default WordPress theme can help determine whether the theme layer is responsible. Make a backup or use staging before making broader changes on a production site.

Step 10: Check Must-Use Plugins and Drop-Ins

Not every component appears in the normal Plugins screen. Must-use plugins are loaded automatically, and special WordPress drop-ins can also affect execution.

If normal plugin isolation does not explain the error, inspect areas such as:

wp-content/mu-plugins/
wp-content/db.php
wp-content/object-cache.php
wp-content/advanced-cache.php

The exact role of a drop-in depends on the file and the software installed on the site. Treat these files as part of the execution environment when the fatal stack trace points toward caching, database handling, object caching, or other infrastructure layers.

Step 11: Check the Server-Level PHP Error Log

WordPress’s debug.log is useful, but it is not the only source of PHP errors. PHP can send errors to the system logger or to a file configured by the error_log setting. WordPress may also be unable to log a failure in the way you expect if PHP fails before the normal WordPress bootstrap reaches the relevant configuration.

Check your hosting control panel, PHP-FPM logs, web-server logs, or system logs as appropriate for your environment.

Server logs are particularly important for failures such as:

• PHP startup or extension errors
• Memory-limit failures
• Execution-time failures
• PHP-FPM worker problems
• Requests failing before WordPress fully loads
• Configuration errors outside WordPress

The PHP error_log() documentation explains how PHP sends messages to its configured logging destination, while PHP’s configuration documentation covers settings such as max_execution_time.

Step 12: Understand “Unknown on Line 0”

An error such as:

Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0

is different from a normal source-code fatal that identifies a PHP file and line. In this case, the message tells you the execution limit was reached but does not identify a useful application source line.

For these failures, look beyond the final message and correlate:

• The request that was running when PHP terminated it
• The server and PHP logs
• Recent configuration changes
• Slow plugin operations
• Large database operations
• Infinite or unexpectedly long loops

PHP documents max_execution_time as the limit on how long a script is allowed to execute before it is terminated. The exact measurement behavior varies by environment, so increasing the limit without locating the expensive operation can hide the underlying problem rather than solve it.

Step 13: Treat Memory Exhaustion Differently

Consider:

Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes)
in /wp-content/plugins/example-plugin/includes/importer.php on line 388

The file and line are valuable evidence, but the problem may not be a single broken statement. The code path may be building a huge array, processing too many records at once, recursively loading data, or triggering an expensive chain of plugin operations.

WordPress has its own memory-related configuration constants, but simply increasing the PHP or WordPress memory limit should not be treated as the universal fix. First determine why the request consumes more memory than expected.

When memory is the issue, investigate the operation size, batching strategy, query results, recursive behavior, object retention, imports, image processing, and third-party integrations before changing limits.

Step 14: Use Query Monitor When WordPress Still Loads

When the site or affected admin screen remains accessible, Query Monitor can add useful diagnostic context. Its WordPress.org documentation describes support for PHP errors, hooks and actions, database queries, HTTP API requests, enqueued assets, capability checks, and other request-level information.

This is especially useful when the fatal is triggered by an interaction between components rather than a single isolated file.

For example, a plugin may register a callback on a WordPress action, trigger a database operation, and then call a class method from a library that is incompatible with the installed version. Looking only at the final fatal line can miss that chain.

Query Monitor should be treated as a diagnostic aid, not as proof that the component it reports is automatically the root cause. Trace the execution path and confirm the behavior independently.

How to Distinguish the Root Cause from the Last File in the Trace

This is one of the most important parts of debugging WordPress fatals.

Imagine this simplified trace:

#0 wp-content/plugins/a-plugin/includes/service.php(50)
#1 wp-content/plugins/another-plugin/includes/integration.php(210)
#2 wp-includes/class-wp-hook.php(326)
#3 wp-includes/plugin.php(205)
#4 wp-admin/admin.php(175)

The final request reached WordPress core, but that does not tell you that WordPress core is broken.

Instead, ask:

1. Where did the fatal operation actually occur?
2. Which plugin or theme owns that file?
3. Which callback invoked it?
4. Was another plugin responsible for creating the incompatible state?
5. Did a recent update change the interface between the two components?

This distinction prevents a common debugging mistake: replacing or modifying WordPress core when the actual incompatibility is in third-party code.

A Practical Fatal Error Decision Tree

What Not to Do When a Fatal Error Appears

Do Not Immediately Delete the Plugin

Deletion removes evidence and may also remove configuration or files needed for later investigation. Deactivation is usually a safer first diagnostic action.

Do Not Edit WordPress Core as the First Response

A core file appearing in the stack trace does not prove that WordPress core caused the problem. Inspect the complete trace first.

Do Not Permanently Display PHP Errors to Visitors

Detailed PHP errors can expose filesystem paths, implementation details, and potentially sensitive configuration information. WordPress and PHP both provide mechanisms to log errors without displaying them publicly.

Do Not Increase Memory or Execution Limits Without Investigating the Code Path

Higher limits may postpone the failure while allowing an inefficient operation to consume more server resources. Configuration changes can be appropriate in some environments, but they should follow diagnosis rather than replace it.

Do Not Trust a Single Log Line in Isolation

The preceding warning, stack frames, timestamp, request URL, and recent deployment history may explain why the final fatal happened.

How to Fix the Root Cause After You Find It

Once the failing component is identified, the safest fix depends on the error class.

Plugin or Theme Bug

Review the component’s update history, compatibility requirements, source code, and vendor documentation. If the problem was introduced by an update, compare the current release with the previous working version and use a tested rollback strategy when appropriate.

PHP Compatibility Problem

Confirm that the plugin, theme, and custom code support the PHP version actually running on the server. Do not change PHP versions blindly on a production store; test the change on staging first where possible.

Missing Dependency or Autoloader

Determine why the required class, function, or file was not loaded. Check include paths, Composer autoloading, plugin load order, and dependency initialization.

Custom Code Error

Review the exact failing line, the function arguments, variable state, hooks involved, and the code path that triggered the callback. Correct the root problem and then retest the original request that produced the fatal.

Server or PHP Configuration Error

Check the PHP version, extensions, memory limits, execution limits, PHP-FPM configuration, web-server logs, and other environment-level settings. This is particularly important when the failure cannot be mapped to a specific application file.

How to Verify That the Fatal Error Is Really Fixed

Removing the error message is not enough. A proper verification pass should reproduce the original failure conditions.

1. Repeat the exact action that originally triggered the fatal.
2. Check the WordPress debug log for a new fatal entry.
3. Check the server-level PHP error log when the issue involved PHP or infrastructure.
4. Test the affected frontend or admin URL.
5. Test related AJAX or REST requests if the problem was endpoint-specific.
6. Confirm that the suspected plugin or theme still performs its intended function.
7. Remove temporary debugging configuration when troubleshooting is complete, according to your environment and logging requirements.

A Production-Safe Workflow for Recurring WordPress Fatal Errors

For a production WordPress installation, a repeatable diagnostic process is more valuable than ad-hoc changes:

1. Preserve evidence. Save the exact error message, timestamp, URL, and stack trace.
2. Use Recovery Mode. When available, inspect the plugin or theme identified by WordPress.
3. Enable logging safely. Log errors while keeping detailed PHP output away from visitors.
4. Reproduce once. Correlate the new error with the exact request.
5. Trace the path. Identify the relevant plugin, theme, custom code, or server layer.
6. Isolate one variable at a time. Deactivate or bypass only what is necessary to confirm the hypothesis.
7. Fix the underlying cause. Do not stop at hiding the symptom.
8. Verify and document. Confirm the original request works and record what changed.

Frequently Asked Questions

How do I find which plugin caused a WordPress fatal error?

Start with the PHP error’s file path. A path containing wp-content/plugins/PLUGIN-NAME/ is a strong indication that the failure occurred inside that plugin. Confirm the diagnosis by checking the stack trace and, when necessary, deactivating the suspected plugin and reproducing the error.

Where is the WordPress PHP error log?

When WP_DEBUG and WP_DEBUG_LOG are enabled, WordPress normally writes the log to wp-content/debug.log. WordPress also allows a custom log path through WP_DEBUG_LOG.

What does “There has been a critical error on this website” mean?

It is a generic WordPress message indicating that a serious error prevented normal execution. The message itself is not the diagnosis. Recovery Mode, the PHP error details, WordPress debug logging, and server logs provide the information needed to identify the source.

Can WordPress core be responsible for a PHP fatal error?

Yes, but a core file in the stack trace does not automatically mean core caused the problem. Plugins and themes frequently execute through WordPress core hooks and APIs, so you should inspect the entire stack trace and identify the component that introduced the failing operation.

Conclusion

Finding the source of a WordPress PHP fatal error is primarily an exercise in reading evidence correctly. Start with Recovery Mode when available, obtain the complete PHP error, identify the file and line, inspect the stack trace, enable debug.log when necessary, and isolate plugins, themes, custom code, or server components systematically. The goal is not simply to make the critical-error screen disappear, but to identify the code path that failed, correct the underlying cause, and verify the original request under the same conditions that exposed the problem.

Useful official references include WordPress Recovery Mode, Debugging in WordPress, Editing wp-config.php, PHP Error Handling, and WP-CLI Plugin Deactivation.