How to Fix a WordPress PHP Fatal Error

A PHP fatal error usually means WordPress stopped loading because a plugin, theme, custom snippet, or PHP compatibility issue crashed the request. A common pattern is a site that worked normally until a cache plugin, plugin update, theme change, or PHP version change was enabled, then /wp-admin/ or the public site began showing “There has been a critical error on this website.”

Start with the recovery-mode email if WordPress sent one. If there is no recovery link or wp-admin will not load, use your host’s PHP error log first, then disable only the plugin or theme named in the fatal error through SFTP or File Manager.

Quick checks before changing anything

Check the exact symptom first:

• The public site shows “There has been a critical error on this website.”
• Only /wp-admin/ is broken.
• The error started after installing, updating, or enabling a plugin, theme, cache tool, or PHP version change.
• Your host’s PHP error log names a plugin, theme, or file path.

If WordPress emailed the site admin a recovery link, use it first. WordPress recovery mode is designed for fatal errors caused by plugins or themes and can let you log in while the broken extension stays paused. The official WordPress troubleshooting page explains the critical error message and recovery-mode path: WordPress troubleshooting documentation.

If you can reach wp-admin, go to Plugins first and deactivate the plugin that changed most recently. If the error began after a theme switch or theme update, go to Appearance > Themes and activate a default WordPress theme temporarily.

Find the failing file in the error log

When wp-admin is unavailable, do not start by deleting plugins at random. Open the PHP error log from your hosting panel. Common locations include:

• Hosting dashboard: Logs, Error Logs, or PHP Errors
• cPanel: Metrics > Errors
• Managed WordPress hosting: site dashboard error log or support panel
• SFTP: sometimes a debug.log, error_log, or host-specific logs folder

Look for the newest line containing PHP Fatal error. The useful part is usually the file path after in or the stack trace below it.

A plugin-related fatal error often points to:

wp-content/plugins/plugin-folder-name/

A theme-related fatal error often points to:

wp-content/themes/theme-folder-name/

A custom snippet may point to:

wp-content/themes/your-theme/functions.php

A fatal error mentioning a missing WordPress function, such as Call to undefined function __(), can mean plugin code is loading before WordPress is ready, a file is being accessed directly, or core/plugin files are incomplete. Treat that as a plugin or file-integrity issue first, not as a reason to edit WordPress core.

Safest fix order

1. Use recovery mode if available

Open the recovery-mode link from the WordPress email. After logging in, WordPress should show which plugin or theme was paused.

From there:

1. Deactivate the named plugin or switch away from the named theme.
2. Update it if an update is available.
3. Check the vendor’s changelog or support channel before reactivating it.
4. Reactivate only after you have a rollback path.

If the recovery email never arrives, check that the admin email is correct later, but do not wait on email to recover a broken site.

2. Disable the suspected plugin through SFTP or File Manager

If the log points to a plugin and wp-admin is down, connect with SFTP or your host’s File Manager.

Go to:

wp-content/plugins/

Rename only the plugin folder named in the fatal error. For example:

cache-plugin

to:

cache-plugin.disabled

Reload the site and wp-admin. If the site comes back, leave that plugin disabled and either update it, replace it, or contact the plugin developer with the fatal error line.

Do not rename the entire plugins folder unless the log does not identify a plugin and you need a broader isolation step. Renaming all plugins can bring a site back, but it also changes more behavior at once.

3. Switch away from the active theme if the log points to it

If the fatal error points to the active theme, use wp-admin if available and activate a default theme such as Twenty Twenty-Four or Twenty Twenty-Five.

If wp-admin is unavailable, use your hosting database tool only if you are comfortable with database edits. Back up the database first. In wp_options, the active theme is stored in the template and stylesheet option values.

For many site owners, the safer path is to ask the host to switch the theme after you provide the fatal error line. A wrong database edit can create a second problem.

4. Check the PHP version

A plugin or theme can fail after the host changes PHP versions, especially if old code uses removed PHP features or new code requires a newer PHP version.

In your hosting panel, check the PHP version assigned to the site. Compare it with:

• Your WordPress version requirements from the official WordPress requirements page
• The plugin or theme vendor’s stated PHP requirement
• Any fatal error text mentioning syntax errors, removed functions, or compatibility

If the error started immediately after a PHP upgrade, temporarily switch back to the previous supported PHP version in the hosting panel, then update the plugin or theme before trying the newer PHP version again. Avoid staying on an unsupported PHP version as a permanent fix.

5. Increase memory only when the error says memory was exhausted

Do not use memory-limit changes as a generic fatal-error fix. They help when the log says something like:

Allowed memory size of ... bytes exhausted

WordPress documents memory-related constants in its wp-config.php documentation. If your host allows it, add or adjust this line above the “stop editing” comment in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

If the error continues, remove the change and ask the host whether the account-level PHP memory limit is lower than the WordPress value.

Optional SSH method with WP-CLI

Use WP-CLI only if you already have SSH access and the site owner or host allows it. It is useful when wp-admin is unavailable but WordPress can still load far enough for commands to run.

Deactivate a named plugin:

wp plugin deactivate plugin-folder-name

WP-CLI’s official command reference covers the available options for wp plugin deactivate.

Switch to an installed default theme:

wp theme activate twentytwentyfive

See the official wp theme activate reference for syntax.

If WP-CLI itself fails with the same fatal error, go back to SFTP or hosting tools. A failed WP-CLI command is a sign that PHP is crashing before WordPress can complete loading.

How to confirm the fix worked

After each change, check only the affected path first:

• Public site home page
• /wp-admin/
• The page that originally triggered the error
• Checkout, forms, or login if the disabled plugin affected them

Then reopen the PHP error log and confirm no new fatal error appears with the current timestamp. Old fatal errors can remain in the log, so compare the time carefully.

If the site works only while a plugin is disabled, the site is recovered but the root cause is not fixed. Update, replace, or escalate that plugin before reactivating it.

Rollback and escalation notes

Keep every recovery change reversible:

• Rename plugin folders back only after you are ready to test.
• Remove temporary wp-config.php memory changes if they did not fix a memory-specific error.
• Restore the previous PHP version only as a temporary compatibility step.
• Keep a database backup before changing theme values in wp_options.

Contact the plugin or theme vendor when the fatal error points into their folder and the latest version still fails. Send the exact fatal error line, WordPress version, PHP version, and the action that triggered it.

Contact the host when the log points to server paths outside WordPress, PHP extensions, permissions, account memory limits, or a PHP version change you cannot control.