How to Access WordPress Admin with a Critical Error Warning
“There has been a critical error on your website” is one of the most alarming messages WordPress can show you, mostly because it tells you almost nothing. No stack trace, no filename, no line number, just a generic notice sitting where your dashboard used to be. The good news is that the error itself is a symptom with a fairly short list of common causes, and working through them systematically almost always gets you back in.
Why WordPress Shows This Message Instead of the Real Error
Since WordPress 5.2, a feature called fatal error protection catches PHP errors that would otherwise produce a raw, ugly PHP error dump, and replaces it with this generic critical error message instead. That’s a reasonable default for visitors, since a raw PHP stack trace leaking file paths and code snippets to the public is a minor security risk on its own. But it also means the person who actually needs to fix the problem, you, sees the same unhelpful message a random visitor would.
The underlying cause is almost always one of a handful of things: a plugin conflict, a broken theme, exhausted PHP memory, a corrupted core file, or a PHP version mismatch between your code and your server. The rest of this guide walks through diagnosing and fixing each one, starting with the step that gives you the most information for the least effort.
Step 1: Turn On Debugging to See What’s Actually Broken
Before touching plugins or themes, get WordPress to tell you what’s actually failing. This step alone often narrows the problem down to a single file in under a minute.
Connect to your site via FTP using a client like FileZilla, or use your host’s File Manager through cPanel. Find wp-config.php in your site’s root directory and open it in a plain text editor.
Look for this line:
define( 'WP_DEBUG', false );Change it to true, and add two more lines directly beneath it if they aren’t already there:
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Setting WP_DEBUG_DISPLAY to false keeps errors out of the public-facing page (important, since your site might still be reachable by visitors while you’re troubleshooting) while WP_DEBUG_LOG writes every error to a file at wp-content/debug.log. Save the file, re-upload it if you edited a local copy, and reload your site.
Open debug.log through FTP or File Manager and look at the most recent entries. You’re looking for a line mentioning a specific plugin folder name, a theme file, or a PHP function that doesn’t exist, that’s your starting point for the next steps.
Reading the Debug Log Like It Actually Means Something
A raw debug.log entry looks intimidating on first read, but the structure is consistent enough to parse quickly once you know what to look for. A typical fatal error line reads something like:
PHP Fatal error: Uncaught Error: Call to undefined function some_function() in /wp-content/plugins/some-plugin/some-file.php:42Break that down left to right. “PHP Fatal error” tells you the severity, this is the kind that stops execution entirely, as opposed to a warning or notice that WordPress would normally just log and continue past. “Call to undefined function” tells you what specifically broke: code is trying to call a function that doesn’t exist in the current environment, often because a plugin update dropped a function another plugin still expects, or because a PHP version change removed something deprecated. The file path tells you exactly which plugin folder to look at, and the number after the colon is the line number inside that file.
You don’t need to read PHP to get value from this. The plugin folder name alone, “some-plugin” in the example, is usually enough to know exactly which plugin to deactivate or update first, skipping the trial-and-error of the full plugin-disable process entirely.
Common error types and what they usually mean
Memory exhaustion errors mention “Allowed memory size” explicitly in the log, naming a specific byte limit that was exceeded. This points you straight to the memory limit fix further down rather than a plugin conflict.
Undefined function or class errors, as shown above, almost always mean two pieces of code expect each other to exist and one of them is missing or outdated, classic plugin conflict territory, or a plugin conflicting with a theme’s custom functions.
Syntax errors reference a specific line and typically say something like “unexpected token” or “syntax error, unexpected.” These usually follow a manual edit to a theme or plugin file, someone editing functions.php directly and leaving out a semicolon or bracket, and they’re some of the easiest to fix once you know exactly which line to check.
Database connection errors look different from the classic critical error screen and instead show “Error establishing a database connection,” which points toward wp-config.php credentials, a database server outage, or a corrupted database table rather than anything covered in the plugin or theme troubleshooting steps below.
Step 2: Rule Out a Plugin Conflict
Plugin conflicts cause the majority of critical errors, and the fastest way to confirm or rule this out is by disabling everything at once rather than guessing which plugin is responsible.
Connect via FTP or File Manager and navigate to wp-content/plugins. Rename the entire plugins folder to something like plugins-disabled. WordPress can’t find any plugin files under that name, which effectively deactivates every plugin on the site without deleting anything.
Visit yoursite.com/wp-admin. If the critical error is gone, a plugin was the cause. Rename the folder back to plugins, then go to the Plugins screen in your dashboard and reactivate them one at a time, checking the site after each activation. When the error reappears, you’ve found the culprit. Deactivate that one plugin, update it if an update is available, or find a replacement if it’s abandoned.
This process is slower with a large plugin count, but it’s more reliable than guessing based on which plugin “seems likely,” since conflicts often come from unexpected combinations rather than an obviously suspicious plugin.
Step 3: Rule Out a Theme Problem
If disabling plugins didn’t fix it, or if you want to check the theme in parallel, switch to a default WordPress theme like Twenty Twenty-Four.
Navigate to wp-content/themes via FTP. Rename your active theme’s folder, for example my-theme becomes my-theme-broken. WordPress will fall back to a default theme automatically if one is installed, or you may need to upload one manually if you’d previously deleted all the default themes (a common cleanup step that occasionally backfires here).
Check the site again. If the error clears, the problem lives in your theme’s functions.php or another core theme file. If you’re using a child theme, check the child theme’s functions.php first, since that’s where most custom code tends to accumulate over time.
Step 4: Increase the PHP Memory Limit
WordPress, plugins, and themes all draw from a shared pool of PHP memory. If a page’s total memory demand exceeds the limit your hosting environment allows, PHP kills the request, and that shows up as a critical error rather than a clear “out of memory” message in most cases.
Open wp-config.php again and add this line just above the comment that says “/* That’s all, stop editing! Happy publishing. */”:
define( 'WP_MEMORY_LIMIT', '256M' );Save and re-upload. This raises the limit WordPress requests, though your host’s server-level PHP configuration can still cap it lower regardless of what wp-config.php asks for. If increasing this value doesn’t help, contact your host and ask what their actual PHP memory_limit is set to at the server level, since that’s the real ceiling.
Step 5: Check Your PHP Version
A theme or plugin built for an older PHP version can throw fatal errors on a newer one, and the reverse is also true: old plugins sometimes use deprecated syntax that a current PHP version rejects outright. Check your current PHP version under Tools, then Site Health, in your WordPress dashboard, or ask your host directly if you can’t reach the dashboard.
WordPress.org recommends PHP 7.4 or higher, though most current best practice points toward 8.1 or newer for both performance and security patch support. If you’re running something noticeably old, a version bump through your hosting control panel might resolve the error, but do this on a staging copy first if you have complex custom code, since a PHP upgrade can just as easily surface a different one.
Step 6: Restore From a Backup
If none of the above resolves it, roll back to your most recent known-good backup. Most managed hosts keep automatic backups accessible through their control panel; if you’re using a plugin like UpdraftPlus or BackupBuddy, restoration usually runs from inside the plugin’s own interface, assuming you can still reach wp-admin, or manually via FTP if you can’t.
Restoring undoes whatever recent change triggered the error, a plugin update, a theme edit, a bad file upload, but it also undoes any legitimate work done since that backup was taken. Weigh that trade-off before restoring blindly; sometimes it’s faster to find and fix the specific broken file than to lose a day of content changes.
Step 7: Get Your Host Involved
If you’ve worked through debugging, plugins, theme, memory, and PHP version without success, the issue may sit at the server level: a corrupted core file, a resource limit your host enforces silently, or a server misconfiguration that only shows up under specific conditions. Hosting support teams that specialize in WordPress can pull server error logs you don’t have access to and often spot the cause in minutes.
Have your debug.log excerpt ready when you contact them. It saves a round of back-and-forth and gets you a faster answer.
A Realistic Troubleshooting Case
A site owner updates three plugins in a routine maintenance pass, then the dashboard immediately shows the critical error screen. Following the process above: WP_DEBUG_LOG gets turned on, and the log points to a specific WooCommerce extension calling a function that no longer exists after a WooCommerce core update earlier that same week. The extension hadn’t been updated to match. Deactivating that one extension through the plugins-disabled folder trick restores access immediately, and checking the extension’s changelog confirms a compatibility update was released two days later, just not yet installed. The fix ends up being: update the extension once compatible, or find a replacement if the developer has gone quiet.
This is the typical shape of most critical errors. Not a single catastrophic failure, but a small compatibility gap between two pieces of code that used to agree with each other and stopped.
Preventing This From Happening Again
A handful of habits meaningfully reduce how often this error shows up.
Keep everything current. WordPress core, plugins, and themes that are behind on updates accumulate compatibility gaps that eventually surface as fatal errors, usually at the least convenient moment.
Trim your plugin list. Every additional plugin is another dependency that can conflict with something else, and most sites accumulate plugins they installed once and forgot about.
Test on staging before touching production. A staging environment lets you catch a plugin update that breaks something before it takes down the live site, rather than after.
Keep backups on a real schedule, not just whenever you remember. Daily backups for an active site, weekly at minimum for something quieter, stored somewhere other than the same server the site lives on.
Mistakes That Slow Down Troubleshooting
Skipping the debug log and jumping straight to guessing is the most common one. Renaming plugin folders at random based on a hunch wastes time that reading one log entry would have saved.
Restoring a backup before diagnosing anything is a close second. It fixes the immediate problem but throws away the information about what actually broke, so the same error tends to resurface the next time that plugin or theme gets updated again.
Editing files directly on a live production site without a local backup of the original file is a third. If a manual edit to fix one problem introduces a syntax error, you want the previous working version of that file one click away, not buried in a much older full-site backup.
When It Keeps Coming Back
Some sites hit this error repeatedly, weeks apart, with no obvious pattern. That usually points to something systemic rather than a one-off conflict: a hosting plan with a PHP memory limit set uncomfortably close to what the site actually needs, a plugin that reintroduces the same bug with every update because its developer never fixed the root cause, or a theme with genuinely fragile custom code that breaks against nearly every WordPress core update.
If the error recurs three or more times in a few months, it’s worth stepping back from firefighting individual incidents and doing a proper audit instead. List every plugin, note the last time each was meaningfully updated, and flag anything that hasn’t shipped a real update in over a year. Check your hosting plan’s actual PHP memory allocation against what a Site Health check recommends for your specific combination of plugins. And if the recurring source is your theme’s custom functions.php, that’s a strong signal it’s time to move that logic into a small, properly maintained site-specific plugin instead, since theme files are more prone to getting overwritten or mishandled during updates than a dedicated plugin file.
Frequently Asked Questions
Why does the critical error message not tell me what’s wrong?
WordPress deliberately hides the specific error from public view for security reasons, since a raw PHP error can expose file paths and code structure. Enabling WP_DEBUG_LOG writes the real error to a private log file only you can access.
Can a critical error happen from a WordPress core update itself, not a plugin or theme?
It’s rare but possible, usually from an incomplete update where the upload was interrupted partway through. Re-uploading WordPress core files manually via FTP, without touching wp-content, can fix this without affecting plugins, themes, or media.
Is it safe to leave WP_DEBUG turned on permanently?
Not on a live site. Leave WP_DEBUG_DISPLAY off at all times so errors never show to visitors, and turn WP_DEBUG itself back to false once you’ve resolved the issue, since debug logging adds unnecessary overhead and can grow the log file to an unwieldy size over time.
What if renaming the plugins folder doesn’t fix the error at all?
That rules out a plugin conflict, so move on to the theme test next. If neither plugins nor theme resolves it, the cause is more likely memory, PHP version, or a corrupted core file, worth checking in that order.
Does the critical error only affect wp-admin, or can it take down the whole site?
It can appear on both. Sometimes only the admin dashboard is affected while the public site loads fine, if the failing code only runs in an admin context. Other times, especially with theme-level fatal errors, the entire front end goes down too.
Should I contact the plugin developer directly if their plugin caused the error?
Yes, especially if it’s a compatibility issue following a WordPress or WooCommerce core update. Developers often aren’t aware of a break until users report it, and a clear bug report with your debug.log excerpt helps them fix it faster for everyone else running the same plugin.
Getting Back to a Working Dashboard, for Good
Most critical errors resolve within the first two or three steps here, usually at the plugin conflict stage. The process feels slow because it’s methodical rather than a single quick fix, but methodical is what actually works when the error message itself refuses to tell you anything useful. Once you’re back in, take the ten minutes to figure out what specifically failed so you’re not troubleshooting the exact same thing again in a month.
