PHP Errors

PHP Fatal Error

Intermediate Risk: medium

Last reviewed August 8, 2026

Hosting access often needed Database access usually not needed

Direct answer

A PHP fatal error stopped the request before WordPress could finish loading—read the exact fatal from the server or debug.log, disable the named plugin/theme via recovery mode or FTP, then fix or replace that code (or roll back PHP) before re-enabling it.

WordPress Repair for PHP fatals starts with the log line, not random reinstalls. Fatals often appear as the critical-error screen, a white screen, or HTTP 500 after a plugin update or PHP version change. This guide shows how to identify E_ERROR / uncaught Error failures, restore the site safely, and confirm the fix without stacking more production changes.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

PHP documents E_ERROR as a fatal run-time error where script execution is halted, distinct from warnings and notices. (PHP.net — Error level constants)
WordPress debugging documentation explains enabling WP_DEBUG_LOG to record PHP errors such as fatals to debug.log without displaying them to visitors. (WordPress — Debugging)
WordPress common-errors guidance covers critical errors and related PHP failures that stop pages from loading after plugin, theme, or environment changes. (WordPress — Common Errors)

What the error means

PHP throws a fatal when the engine cannot continue the current request—undefined function, uncaught Error/Exception that ends the run, exhausted memory (a specific fatal), or other non-recoverable conditions. On modern WordPress, many uncaught fatals become the “There has been a critical error on this website” screen with an optional recovery-mode email; older setups or hosts that hide errors show a blank page or generic 500. The authoritative detail is always the log: file path under wp-content/plugins, wp-content/themes, or a must-use plugin. A fatal is not a DNS or SSL problem and not “WordPress deleted itself.” WordPress Repair work focuses on isolating the crashing code, restoring service, then updating or replacing that component on a controlled path.

Common symptoms

“There has been a critical error on this website” on front end and/or wp-admin
White screen of death with empty HTML body while HTTP status is 200 or 500
Host or PHP log shows “PHP Fatal error” or “Uncaught Error” with a file and line
wp-content/debug.log records the same fatal when WP_DEBUG_LOG is enabled
Failure started immediately after a plugin/theme update or PHP version change
Recovery-mode email names a plugin or theme once WordPress can send mail
Only certain URLs fail (checkout, builder, wp-admin) while others still load

Most likely causes

01 Plugin or theme code incompatible with the current PHP or WordPress version
02 Incomplete/corrupt plugin files after a failed update or disk-full write
03 Bad edit to functions.php, a code-snippet plugin, or an mu-plugin
04 Call to removed PHP functions or classes after a PHP upgrade
05 Allowed memory size exhausted or other resource fatals during bootstrap
06 Must-use plugin or drop-in (object-cache.php, advanced-cache.php) fataling on every request
07 Malware or injected PHP that fatals when partially cleaned

What changed before the problem started

Plugin, theme, or WordPress core update (manual or automatic)
PHP version change in cPanel, Plesk, or host selector
New snippet, mu-plugin, or child-theme code deploy
Host migration that left mismatched plugin/theme versions
Object cache drop-in enabled or Redis/Memcached extension removed
Partial file restore from backup

Troubleshooting steps

01
Read the fatal before changing anything else
Open the hosting error log or wp-content/debug.log and copy the first PHP Fatal error / Uncaught Error for the outage window. Note the plugin or theme directory in the path. If the line is parse error or memory exhausted, use those specialized playbooks. Success signal: you can name the file/plugin responsible.
02
Use WordPress recovery mode when the email arrives
Open the “Your Site is Experiencing a Technical Issue” message and follow the recovery link. Deactivate the paused plugin or switch away from the paused theme, exit recovery mode, and retest the front end in a private window. Success signal: homepage and wp-admin load without the critical-error screen.
03
Disable the culprit via FTP or File Manager
If admin is unreachable, rename the failing plugin folder under wp-content/plugins (or the active theme folder after confirming a default theme like twentytwentyfive exists). For mu-plugins and drop-ins, rename the specific file. Success signal: the site loads; only the renamed component stays off.
04
Roll back PHP if the fatal started at a version change
In MultiPHP Manager / Plesk PHP settings, return to the last known-good PHP version, wait a minute, and retest. Leave a sticky note to update the incompatible plugin on staging before raising PHP again. Success signal: fatals disappear on the rolled-back handler.
05
Enable WP_DEBUG_LOG without displaying errors publicly
Set WP_DEBUG true, WP_DEBUG_LOG true, and WP_DEBUG_DISPLAY false in wp-config.php while reproducing once. Confirm the new log lines, then keep display off so visitors never see paths. Success signal: debug.log captures the fatal with a clear stack path.
06
Update, replace, or remove the failing code deliberately
After the site is up, update the plugin/theme from a clean source, restore a known-good copy of the file, or delete abandoned code. Retest the URL that previously crashed before enabling anything else. Success signal: the former failing page loads and the fatal does not return in logs.

Read the fatal before changing anything else

Open the hosting error log or wp-content/debug.log and copy the first PHP Fatal error / Uncaught Error for the outage window. Note the plugin or theme directory in the path. If the line is parse error or memory exhausted, use those specialized playbooks. Success signal: you can name the file/plugin responsible.

Use WordPress recovery mode when the email arrives

Open the “Your Site is Experiencing a Technical Issue” message and follow the recovery link. Deactivate the paused plugin or switch away from the paused theme, exit recovery mode, and retest the front end in a private window. Success signal: homepage and wp-admin load without the critical-error screen.

Disable the culprit via FTP or File Manager

If admin is unreachable, rename the failing plugin folder under wp-content/plugins (or the active theme folder after confirming a default theme like twentytwentyfive exists). For mu-plugins and drop-ins, rename the specific file. Success signal: the site loads; only the renamed component stays off.

Roll back PHP if the fatal started at a version change

In MultiPHP Manager / Plesk PHP settings, return to the last known-good PHP version, wait a minute, and retest. Leave a sticky note to update the incompatible plugin on staging before raising PHP again. Success signal: fatals disappear on the rolled-back handler.

Enable WP_DEBUG_LOG without displaying errors publicly

Set WP_DEBUG true, WP_DEBUG_LOG true, and WP_DEBUG_DISPLAY false in wp-config.php while reproducing once. Confirm the new log lines, then keep display off so visitors never see paths. Success signal: debug.log captures the fatal with a clear stack path.

Update, replace, or remove the failing code deliberately

After the site is up, update the plugin/theme from a clean source, restore a known-good copy of the file, or delete abandoned code. Retest the URL that previously crashed before enabling anything else. Success signal: the former failing page loads and the fatal does not return in logs.

When to stop troubleshooting

Escalate if logs are inaccessible, fatals move across unrelated plugins after each disable, core files themselves fatal, checkout remains down during business hours, or you suspect a wider compromise. Bring the exact fatal line, PHP version, and recent update list for WordPress Repair.

Information to collect before requesting help

01 Exact PHP Fatal error / Uncaught Error line with file path
02 Whether visitors see critical error, white screen, or HTTP 500
03 PHP version and WordPress version
04 Plugins/themes updated in the last 24–48 hours
05 Whether a PHP version change happened in the host panel
06 Whether a recovery-mode email was received
07 Hosting provider and access level (wp-admin only vs FTP/cPanel)

How a professional repairs the problem

We treat this as WordPress Repair: capture the fatal, restore front-end and admin by disabling the crashing plugin/theme or rolling PHP back, then repair or replace the incompatible code on a controlled path. We verify key templates, wp-admin, and logs are clean, and we document what broke so the next update does not repeat the outage.

Frequently asked questions

Is a PHP fatal error the same as WordPress critical error? +

Usually the critical-error screen is WordPress’s user-facing wrapper around a PHP fatal. The log still shows the underlying PHP Fatal error or Uncaught Error—that line is what you fix.

Can I fix a fatal by reinstalling WordPress core only? +

Rarely. Most fatals live in plugins, themes, mu-plugins, or drop-ins. Reinstall core after you know core files are damaged—not as step one.

Why did this start after changing PHP? +

Newer PHP removes legacy syntax and turns some notices into errors. Old plugins may fatal immediately on the new handler until updated or replaced.

Does WP_DEBUG fix the fatal? +

No. Debug logging only reveals it. Leaving WP_DEBUG_DISPLAY on can expose paths to visitors—log to file instead.

What if every plugin rename still fatals? +

Check the active theme, mu-plugins, drop-ins, and custom code in wp-config.php. A fatal in those paths survives normal plugin disables.

Is memory exhaustion a fatal error? +

Yes, it is a specific fatal. Use the memory-exhausted guide to raise limits and find the heavy plugin rather than only disabling random extensions.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.