How to Access WordPress Admin with a Fatal Error Warning
A fatal error that blocks the WordPress admin is one of the most alarming things a site owner can see, mostly because it looks worse than it usually is. The dashboard is unreachable, the front end might show a blank white screen or a raw PHP error message, and there’s no obvious “undo” button anywhere in sight. The good news: the overwhelming majority of these errors trace back to a small set of causes, and every one of them has a reliable fix that doesn’t require touching your database directly.
This guide walks through diagnosing what’s actually broken, the six most effective recovery methods in the order you should try them, and how to prevent the same thing from happening again next time you update a plugin.
What a Fatal Error Actually Means
PHP throws a fatal error when it hits code it cannot execute at all, as opposed to a warning or notice, which PHP can usually work around and keep running. A fatal error stops the script cold. In WordPress terms, that usually shows up as one of these:
Fatal error: Uncaught Error: Call to undefined function some_function() in /path/to/wp-content/plugins/example/example.php on line 42or
Fatal error: Allowed memory size of 268435456 bytes exhausted in /path/to/wp-includes/functions.php on line 123or simply a blank white screen with no message at all, which happens when your host has display_errors turned off (a sensible security default, but unhelpful when you’re trying to diagnose something). The message, when you get one, almost always tells you the exact file and line number where things broke, and that file path is the single most useful clue you have. If it’s inside wp-content/plugins/, a plugin is the likely cause. If it’s inside wp-content/themes/, look at your theme. If it’s inside wp-includes/ or wp-admin/, core files may be damaged, or something else (usually a plugin conflict or a resource limit) is corrupting behavior further upstream.
Before You Touch Anything: Check for Recovery Mode
Since WordPress 5.2, there’s a built-in safety net for exactly this situation. When WordPress detects a fatal error, it automatically emails the site administrator a special recovery link, and it also tries to keep the site accessible in a limited “recovery mode” that isolates the broken plugin or theme without fully disabling it. Check the inbox for the email address registered as your WordPress admin, including spam and promotions folders, before assuming you need to go the manual FTP route. If that email exists and the link still works, clicking it drops you into wp-admin with the offending plugin paused, which is the fastest possible fix and skips everything below.
If the recovery email never arrived (a common issue if your site’s outgoing mail isn’t configured, which is its own separate problem worth fixing with something like WP Mail SMTP), move on to the manual methods.
Method 1: Disable Plugins to Isolate the Problem
Plugin conflicts cause the majority of post-update fatal errors, so this is the right first move regardless of what the error message says.
Via FTP or File Manager
- Connect to your server with FileZilla, Cyberduck, or your host’s built-in file manager (cPanel and Plesk both include one).
- Navigate to
wp-content/plugins/. - Rename the entire
pluginsfolder to something likeplugins-disabled. WordPress can’t find any plugin files at that path, so it treats all of them as deactivated, without actually losing any of their settings. - Reload your site. If the fatal error is gone, a plugin was the cause.
- Rename the folder back to
plugins, then log into wp-admin. WordPress will show every plugin as deactivated even though the files are back; this is expected. - Reactivate plugins one at a time, reloading the site after each. The plugin that brings the error back is your culprit.
A faster variant if you have several dozen plugins: instead of renaming the whole folder, go into it and rename individual plugin subfolders in batches of five or ten, checking the site after each batch, then narrow down further once you’ve isolated which batch caused it.
Via WP-CLI (Faster If You Have SSH)
If your host gives you shell access, this whole process takes seconds instead of minutes:
wp plugin deactivate --allThen reload the site to confirm the error clears, and reactivate plugins one by one with wp plugin activate plugin-slug until you find the one responsible. WP-CLI works even when wp-admin is completely inaccessible, since it talks to the database directly rather than through the browser, which makes it the most reliable recovery tool when you have the option.
Method 2: Switch to a Default Theme
If disabling plugins didn’t fix it, the theme is the next suspect, especially after a theme update or a change to functions.php.
- Via FTP, navigate to
wp-content/themes/. - Rename your active theme’s folder, for example from
your-themetoyour-theme-old. - WordPress automatically falls back to a default theme it can find, typically one of the Twenty Twenty-X series, assuming one is still installed. If none of the defaults are present, download and upload one manually first.
- Reload the site. A resolved error confirms the theme was the problem.
If you’re using a child theme, check whether the error is actually in the child theme’s functions.php rather than the parent. It’s common for a copy-pasted code snippet in a child theme to reference a function that doesn’t exist yet, or to duplicate a function name already declared in the parent, both of which produce a fatal “cannot redeclare” error.
Method 3: Raise the PHP Memory Limit
“Allowed memory size exhausted” errors mean a script tried to use more memory than PHP is configured to allow. This happens with image-heavy plugins, large imports, or simply a site that’s outgrown its hosting’s default limits. Add this line to wp-config.php, above the line that reads /* That's all, stop editing! Happy blogging. */:
define('WP_MEMORY_LIMIT', '256M');If your host enforces a hard PHP memory cap lower than that at the server level, the wp-config.php constant won’t override it, and you’ll need to raise the limit through cPanel’s MultiPHP INI Editor, a custom php.ini file, or a support ticket with your host. Shared hosting plans commonly cap PHP memory at 128M or even 64M by default, which is genuinely too low for a modern WordPress install running more than a handful of plugins.
Method 4: Turn On Debug Mode to See the Real Error
If display_errors is off (standard on production sites for good reason), a fatal error just produces a blank white screen with zero information. Turning on WordPress’s debug log gets you the actual error text without exposing it publicly. Add these three lines to wp-config.php, again before the “stop editing” comment:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Setting WP_DEBUG_DISPLAY to false is deliberate: it keeps the error out of the visible page (where anyone browsing your broken site would see it) while still writing full detail to wp-content/debug.log. Open that file after reproducing the error once, and you’ll have the failing function name plus its exact file and line number. Remove or set these constants back to false once you’re done; leaving debug logging permanently on quietly bloats that log file over time and can leak information if the log location is guessable.
Method 5: Check for Corrupted Core Files
Less common than plugin or theme issues, but worth ruling out if the error points to a file inside wp-admin/ or wp-includes/ and nothing else has fixed it. An interrupted update, a bad file transfer, or in rarer cases a compromised site can leave core files missing or altered.
If you can reach Dashboard > Updates, click Re-install Now, which overwrites core files with a clean copy from WordPress.org without touching your themes, plugins, or database content. If wp-admin is unreachable, download the matching WordPress version as a zip from wordpress.org, extract it locally, and upload the wp-admin and wp-includes folders directly via FTP, overwriting the existing ones. Leave your wp-content folder and root-level wp-config.php alone; those are yours, not core’s.
Method 6: Use WP-CLI’s Fatal Error Handling
Beyond deactivating plugins, WP-CLI has a few commands specifically useful mid-crisis. wp plugin list --status=active shows exactly what’s currently active without needing the dashboard to load. wp theme activate twentytwentyfour switches themes from the command line in one step instead of the FTP rename dance. And wp core verify-checksums compares your core files against the official WordPress.org checksums and flags anything that’s been modified or is missing, which is the fastest way to confirm or rule out core file corruption without manually diffing files.
Decoding the Most Common Fatal Error Messages
The exact wording of a PHP fatal error tells you a lot before you even start troubleshooting. A few show up constantly across WordPress sites.
“Call to undefined function” usually means a plugin was deactivated or partially deleted while another plugin (or your theme) still expects a function it provided. It also shows up when a plugin update removes a function that a customization elsewhere on the site still calls. The fix is almost always reactivating the missing plugin or removing the code that depends on it.
“Cannot redeclare function” means the exact same function name was defined twice, typically because a snippet was pasted into functions.php that duplicates something the parent theme or a plugin already defines. This is common when copying code from tutorials without checking whether a similarly named function already exists somewhere in the stack.
“Class not found” is the object-oriented equivalent of the undefined function error, generally caused by a required plugin being deactivated, or by a plugin update changing its internal class structure in a way that breaks an integration relying on the old class name.
“Maximum execution time exceeded” is different from the memory error covered in Method 3. It means a script ran longer than the configured time limit (30 seconds by default on many hosts), usually during a large import, an unoptimized database query, or a poorly written loop somewhere in a plugin. Raising max_execution_time in php.ini or through your host’s control panel addresses the symptom; finding and fixing the slow code addresses the actual cause.
Syntax Errors vs Runtime Fatal Errors
Not every fatal error looks the same, and the distinction changes how you should approach fixing it. A syntax error, a missing semicolon, an unclosed bracket, a stray character left in functions.php after a copy-paste, gets caught by PHP before your site even tries to run anything. These typically say “Parse error” rather than “Fatal error” and point directly at the malformed line. If you just edited a file by hand through FTP or a code snippets plugin, this is almost always where to look first, and the fix is simply correcting the typo and re-saving the file.
A runtime fatal error, by contrast, only shows up once the script is actually executing and hits something it can’t complete, calling a function that doesn’t exist, running out of memory partway through, trying to use an object that was never properly created. These are the errors covered throughout this guide, and they’re the more common category after a plugin or theme update rather than a manual code edit.
A Decision Path When You’re Not Sure Where to Start
| What the error message shows | Start with |
|---|---|
| File path inside wp-content/plugins/ | Method 1, disable plugins |
| File path inside wp-content/themes/ | Method 2, switch theme |
| “Allowed memory size exhausted” | Method 3, raise memory limit |
| Blank white screen, no message at all | Method 4, enable debug log first |
| File path inside wp-admin/ or wp-includes/ | Method 5 or 6, verify core files |
| Error appeared right after a plugin or theme update | Method 1 or 2 depending on which was updated |
Preventing This From Happening Again
A staging site is the single biggest prevention tool available. Most managed hosts (Cloudways, WP Engine, Kinsta, SiteGround among them) include one-click staging environments, and updating plugins there first before pushing to production catches the majority of fatal-error-causing conflicts before they ever touch a live site.
A few smaller habits help too. Update plugins one at a time rather than in bulk, so if something breaks you already know which one caused it instead of guessing across a dozen simultaneous updates. Keep a recent backup on hand before any update, using UpdraftPlus, BlogVault, or your host’s built-in backup tool, so a bad update is a two-minute restore instead of a manual recovery. And check plugin changelogs for “requires PHP” or “requires WordPress” version bumps before updating, since a mismatch between your PHP version and a plugin’s new minimum requirement is a common, entirely avoidable cause of fatal errors.
Frequently Asked Questions
Why didn’t I get a recovery mode email?
WordPress’s built-in recovery email relies on your site’s outgoing mail working, and most shared hosting environments don’t reliably deliver mail through PHP’s default mail() function. If you’ve never configured an SMTP plugin like WP Mail SMTP or FluentSMTP, there’s a good chance the recovery email was silently dropped rather than delivered. This is worth fixing after recovery, not just for this scenario but for password resets and order notifications generally.
Will disabling all my plugins lose my settings?
No. Renaming the plugins folder or deactivating through WP-CLI doesn’t delete any plugin data or settings stored in the database. Reactivating a plugin restores it exactly as configured before. The only thing that resets plugin settings is deleting a plugin entirely (not deactivating it), which none of the methods above do.
The error is gone after reactivating one plugin, but it comes back randomly. What’s going on?
This pattern usually points to a resource limit issue rather than a straightforward code conflict, memory exhaustion or execution timeouts that only trigger under certain conditions (a specific page, a certain amount of traffic, a particular combination of plugins running together). Check your debug.log for repeated entries and consider raising both the PHP memory limit and the max_execution_time setting, which your host can usually adjust even on shared plans.
Can a fatal error damage my database?
Generally no. A PHP fatal error stops script execution, it doesn’t corrupt stored data. The database itself is almost always intact and untouched; the problem is purely that the PHP code trying to read or process that data is crashing before it can render a page. This is exactly why reinstalling core files or deactivating plugins is safe: none of it touches the actual content in your database.
I fixed the error but now the site looks different. Why?
If you switched to a default theme as part of troubleshooting and forgot to switch back once the real cause was found, that’s the most common explanation. Go to Appearance > Themes and reactivate your original theme once you’ve confirmed the underlying plugin or code issue is actually resolved, not just that the default theme happened to sidestep it.
Should I just contact my host instead of doing any of this myself?
If you’re on managed WordPress hosting, yes, reach out early. Many managed hosts (Kinsta, WP Engine, Pantheon) have support teams that will diagnose and often fix fatal errors directly, sometimes faster than doing it yourself, and they have direct server access you don’t. On basic shared hosting, support is more hit-or-miss, and the FTP-based methods above are usually faster than waiting on a ticket queue.
Interesting Reads
10 Best Free SEO Plugins for WordPress
