Learn how to fix common WordPress PHP errors with this practical guide. From fatal errors to syntax issues, discover effective troubleshooting steps to get your site back online fast.
Sooner or later, WordPress hands you a PHP error. Maybe it is a cryptic line of red text, maybe it is the infamous White Screen of Death, where your site just goes blank and your stomach drops with it. Either way, the feeling is the same: something broke, and you are not sure what. Here is the part nobody tells you in the moment. Almost every PHP error in WordPress is fixable, and most are more predictable than they look. You do not need to be a developer. You need a flashlight and a method. This guide gives you both, so you can find the problem, understand it, and fix it without the panic.
Table of Contents
- Essential First Step: Seeing the Error (Debugging Tools)
- Decoding Common WordPress PHP Error Messages
- A Practical Troubleshooting Workflow
- Preventative Measures
- Conclusion
Essential First Step: Seeing the Error (Debugging Tools)
You cannot fix what you cannot see, and by default WordPress hides most errors from you, especially on live sites. So the very first move is always the same: turn the lights on. Do this in a safe place if you can, a staging site or a local copy, not your live store on a Friday afternoon.
Enabling WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY
Open your wp-config.php file and add (or adjust) these lines:
<?php
// Enable debugging mode
define('WP_DEBUG', true);
// Log errors to wp-content/debug.log
define('WP_DEBUG_LOG', true);
// Show errors on screen (turn this off on production)
define('WP_DEBUG_DISPLAY', false);
// Force WordPress to use the "WP_DEBUG_DISPLAY" setting
@ini_set('display_errors', 0);Here is what each one is doing for you:
- WP_DEBUG: switches on PHP error reporting inside WordPress.
- WP_DEBUG_LOG: writes the errors to
wp-content/debug.log. This is the one that saves you, because it captures the full detail even when the screen shows nothing. - WP_DEBUG_DISPLAY: controls whether errors print on-screen. On a live site keep this
falseso you are not leaking sensitive paths to visitors.
Server-Level PHP Error Logs
Sometimes WordPress crashes so early it never gets the chance to log anything. That is where your host’s own PHP error logs come in. Most hosts keep them, usually reachable from your hosting control panel, and the location varies. When you are staring at a White Screen of Death and WordPress has gone silent, the server log is often the fastest way to the truth.
Decoding Common WordPress PHP Error Messages
PHP errors sound scarier than they are once you learn to read them. Here are the ones you will actually run into, what they mean in plain English, and how to fix each.
Fatal Errors (Often Causing a White Screen of Death)
Fatal error: Allowed memory size of X bytes exhausted…
What it means: a script asked for more memory than PHP was allowed to give it, usually a heavy plugin or a big import pushing past the limit.
How to fix it:
- Raise the WordPress memory limit in wp-config.php:
<?php define('WP_MEMORY_LIMIT', '256M'); - Raise the PHP memory limit in php.ini or your host’s panel (256M or 512M is common).
- If it keeps happening, the real fix is usually a plugin or theme eating memory it should not. Go find it.
Fatal error: Maximum execution time of X seconds exceeded…
What it means: a script ran longer than PHP’s max_execution_time allows, which tends to happen during heavy operations like imports or backups.
How to fix it:
- Raise
max_execution_timein php.ini or your host’s panel:
<?php max_execution_time = 300 - Then ask why it took so long in the first place. A slow plugin or inefficient code is the usual culprit.
Fatal error: Call to undefined function function_name()…
What it means: something is calling a function that does not exist right now. Often a plugin or theme is missing or deactivated, there is a typo, or your PHP version is too old to know that function.
How to fix it:
- Make sure the plugin or theme that provides the function is installed and active.
- Check the function name for typos.
- Confirm your server’s PHP version actually supports it.
- If it is a core WordPress function, repair or replace your core files.
Fatal error: Cannot redeclare function function_name()…
What it means: the same function or class got defined twice, usually from a double include or two plugins stepping on each other.
How to fix it:
- Use
include_onceorrequire_onceso a file cannot load its definitions twice. - Hunt down the duplicate definition in your plugins or theme, then rename or remove the conflicting piece.
Fatal error: Class ‘ClassName’ not found…
What it means: the file that defines ClassName was not loaded, or something is off with your namespaces or autoloading.
How to fix it:
- Make sure the file defining the class loads before anything tries to use it.
- Double-check your namespaces and autoloader setup.
- Confirm the plugin or theme that provides the class is active.
Syntax Errors (Parse Errors)
Parse error: syntax error, unexpected T_STRING…
What it means: the PHP itself is malformed. A missing semicolon, a mismatched bracket, a typo in a keyword. The good news is PHP tells you exactly where to look.
Example:
<?php
// Incorrect:
if ( $condition ) {
echo \"Hello World\" // Missing semicolon
}
// Correct:
if ( $condition ) {
echo \"Hello World\";
}How to fix it: go straight to the file and line number in the error, then read the few lines above it for a missing semicolon, an unclosed bracket, or a stray character. Syntax errors are annoying, but they are honest. The location is right there.
Warnings & Notices
These usually will not take your site down, but they are your code telling you something is not quite right. Do not ignore them forever.
Warning: Cannot modify header information – headers already sent by…
What it means: something got sent to the browser (HTML, a blank line, a stray space) before your code tried to set an HTTP header, like a cookie or session_start(). PHP will not let you send headers once output has started.
How to fix it:
- Remove any extra spaces or a BOM at the very start of your files.
- Move your
echostatements after any header or session calls, not before. - Save your files as UTF-8 without a BOM.
Undefined variable/array key notices
What it means: your code is reaching for a variable or an array key that has not been set yet.
How to fix it:
- Give variables a starting value before you use them (
$var = '';). - Check array keys first with
isset()orarray_key_exists(). - Or reach for the null coalescing operator (
$value = $array['key'] ?? '';), which handles the missing case cleanly.
A Practical Troubleshooting Workflow
When something breaks, resist the urge to change ten things at once. Work the problem in order. This is the same path a seasoned developer takes, just written down:
- Don’t panic. Nearly every error has a fix, and you are about to find it.
- Turn on debugging (WP_DEBUG, WP_DEBUG_LOG), or go straight to your server logs.
- Read the error for the message, the file, and the line number. That is your map.
- Search the exact text in quotes. Someone has almost certainly hit this before you.
- Think back to the last change you made: an update, a code edit, a theme switch. That is your prime suspect.
- Deactivate plugins one at a time, or rename the plugin folder, to isolate a conflict.
- Switch to a default theme if you suspect the theme is the problem.
- Review your custom code on the line the error points to.
- Ask for help on the WordPress forums or with your host, and bring the full error details when you do.
Preventative Measures
The best PHP error is the one that never reaches your live site. A few habits keep most of them off your plate:
- Use a staging environment: test updates and new code somewhere safe before it ever touches production.
- Use version control: Git lets you undo a bad change in seconds instead of rebuilding from memory.
- Write clean code: following the WordPress coding standards quietly prevents a whole class of these errors.
- Stay updated: keep core, themes, and plugins current so small issues never grow into big ones.
Conclusion
PHP errors are not a sign you are doing WordPress wrong. They are just part of building things, and every developer you admire has stared at the same white screen you did. What separates the calm ones is not that they never see errors. It is that they have a method: turn on debugging, read the message, change one thing at a time.
Do that, lean on staging and version control so mistakes stay cheap, and the White Screen of Death stops being a crisis and starts being a puzzle. And when you get truly stuck, the WordPress community is right there. Show up with your exact error and line number, and someone will help you home.


