Common WordPress PHP Errors and How to Fix Them

If you’ve ever opened your WordPress site and seen a blank white screen, a cryptic message about “fatal errors,” or a notice that says something like “Parse error: syntax error, unexpected T_STRING” — you already know how stressful PHP errors can be. The site is down, customers can’t reach you, and you have no idea what broke or why.

I’ve been working with WordPress since 2016, and these errors are some of the most common reasons site owners reach out to me. This guide walks through the PHP errors you’re most likely to encounter, explains what each one actually means in plain English, and tells you what to do about it — whether you’re trying to fix it yourself or deciding when it’s time to hand it off to someone who does this every day.

---

What Is a PHP Error in WordPress?

WordPress is built on PHP — a programming language that runs on your web server and generates all the HTML your visitors see. When something goes wrong in that process, PHP stops and shows an error message instead of your website.

These errors can come from WordPress core, your theme, or (most often) a plugin. They can also appear after a WordPress update, a PHP version upgrade on your hosting account, or when two plugins conflict with each other.

The tricky part is that PHP errors aren’t always visible. Some show as a white screen with nothing on it. Others appear only in the admin dashboard. A few are “silent” — they only show up in server logs while your site limps along with broken functionality.

---

The Most Common WordPress PHP Errors

1. Parse Error / Syntax Error

What it looks like:

Parse error: syntax error, unexpected '}' in /wp-content/themes/yourtheme/functions.php on line 42

What it means:

PHP found something in the code that it can’t understand — like a missing semicolon, an extra bracket, or a typo in a function name. Think of it like a sentence with a missing period; the computer doesn’t know where one thought ends and the next begins.

How it usually happens:

The most common cause is editing a theme’s functions.php file directly — either pasting in a code snippet from a tutorial, or accidentally deleting a character while making changes. Even a single misplaced { or ; will bring the whole site down.

How to fix it:

If you edited a file recently, the fastest fix is to restore the previous version. If you have a backup (and you should — more on that in a moment), roll back. If you made the change through your hosting file manager or FTP, open the file and carefully look at the line number mentioned in the error. Compare it to a working copy if you have one.

If you don’t have a backup and aren’t sure what was there before, this is when it makes sense to get professional help with the fix rather than risk making things worse.

---

2. Fatal Error: Call to Undefined Function

What it looks like:

Fatal error: Uncaught Error: Call to undefined function get_field() in /wp-content/themes/yourtheme/page.php on line 18

What it means:

Your theme or a plugin is trying to use a function that doesn’t exist. Either it was never defined, it belongs to a plugin that isn’t active, or it was removed in a newer version of that plugin.

The example above (get_field()) is a classic one — it comes from the Advanced Custom Fields plugin. If someone deactivates that plugin, any theme that calls get_field() will throw a fatal error.

How it usually happens:

• A plugin was deactivated or deleted, but the theme still depends on it
• A plugin was updated and removed or renamed a function
• You switched themes and the new theme relies on a plugin the old one didn’t

How to fix it:

First, check if a plugin was recently deactivated or removed. If the function belongs to a plugin (you can search for the function name online to find out), reinstalling or reactivating that plugin will usually solve it immediately.

If the function is in a theme file, the theme may have been written with a dependency that wasn’t documented — a common problem with cheap or free themes downloaded from random sites.

---

3. Fatal Error: Maximum Execution Time Exceeded

What it looks like:

Fatal error: Maximum execution time of 30 seconds exceeded in /wp-includes/class-http.php on line 1743

What it means:

PHP has a built-in safety limit on how long a script can run. If something takes longer than that limit (usually 30 or 60 seconds depending on your host), PHP stops it and throws this error.

How it usually happens:

• An import or export operation (products, posts, orders) that involves a lot of data
• A plugin trying to connect to an external service that isn’t responding
• A WooCommerce store processing a large order batch
• Slow database queries on a site that hasn’t been optimized in a while

How to fix it:

You can increase the time limit in your php.ini or wp-config.php file, but that’s treating the symptom rather than the cause. If a script is regularly hitting 30–60 seconds, something else is wrong — a slow database, an unresponsive external API, or code that’s simply inefficient.

For WooCommerce stores in particular, I regularly see this error combined with other performance problems. If your store is slow and throwing these errors, a proper speed optimization will typically eliminate the issue entirely rather than just raising the timeout limit.

---

4. Fatal Error: Allowed Memory Size Exhausted

What it looks like:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 4096 bytes) in /wp-includes/class-wp-query.php on line 3494

What it means:

PHP ran out of memory trying to complete a task. The default limit is often 64MB or 128MB, which is enough for simple sites — but complex WordPress installs with many plugins, large images, or heavy WooCommerce catalogs can easily exceed it.

How it usually happens:

• Too many active plugins, each loading their own code into memory
• Importing a large CSV of products or posts
• Generating reports or exports in WooCommerce
• A poorly coded plugin that holds large datasets in memory

How to fix it:

You can increase the memory limit by adding this to your wp-config.php:

php

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

But again — if your site regularly needs 256MB+ of memory just to load a page, the real problem is plugin bloat or inefficient code. Sites I’ve built from scratch with custom themes and a minimal plugin stack rarely exceed 50–60MB. Sites I’ve inherited that were built with page builders and 40+ plugins regularly hit the ceiling.

If you’re at the point of raising memory limits every few months, it might be worth considering whether your current theme and plugin setup is sustainable long-term. Sometimes migrating to a more efficient stack is the better move.

---

5. White Screen of Death (WSOD)

This isn’t technically a single PHP error — it’s what happens when PHP encounters a fatal error and error display is turned off (which is the default on most production servers, for good reason).

What it looks like:

Just a blank white page. No error message, no text, nothing. Sometimes the admin dashboard is also blank.

How to fix it:

Turn on WordPress debug mode temporarily by adding these lines to wp-config.php:

php

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

With WP_DEBUG_LOG set to true, errors will be written to /wp-content/debug.log — even if they’re not displayed on screen. Open that file through your hosting file manager and you’ll see the actual error.

Once you know what broke, you can either fix it or bring in help. Just remember to turn debug mode off again when you’re done.

---

6. 500 Internal Server Error

What it looks like:

A browser error page saying “500 Internal Server Error” — though the exact design varies by browser and hosting setup.

What it means:

Something went wrong on the server, but it’s being vague about what. This can be caused by PHP errors, but also by .htaccess problems, exhausted resources, or server misconfigurations.

How to fix it:

Start by checking your error logs — either through your hosting control panel (cPanel, Plesk, etc.) or the WordPress debug log mentioned above. The most common causes I see:

• A corrupted or incorrectly modified .htaccess file (you can regenerate it in Settings → Permalinks)
• A plugin or theme causing a fatal PHP error
• PHP version mismatch — your hosting was upgraded to PHP 8.x but a plugin hasn’t been updated to support it

PHP 8.0 and 8.1 introduced strict changes that broke a lot of older plugins. If your host recently upgraded PHP and your site started throwing 500 errors, check the debug log for deprecated function warnings or strict type errors.

---

7. Warning: Cannot Modify Header Information

What it looks like:

Warning: Cannot modify header information - headers already sent by (output started at /wp-content/plugins/someplugin/file.php:1) in /wp-includes/pluggable.php on line 1394

What it means:

PHP sends HTTP headers before sending the page content. If something outputs text or whitespace before WordPress gets a chance to send those headers, you get this warning. Common consequences include broken redirects, login issues, and cookie problems.

How it usually happens:

• A plugin file has whitespace or a blank line before the opening <?php tag
• A file was saved with a BOM (Byte Order Mark) character that editors sometimes add invisibly
• A theme’s functions.php has an echo statement very early in execution

How to fix it:

The error message tells you exactly which file is causing the problem — look at the “output started at” part. Open that file and check for anything before <?php at the very start of the file. Whitespace, blank lines, or invisible characters are the usual culprits.

---

8. Deprecated Function Notices

What it looks like:

Deprecated: Function create_function() is deprecated in /wp-content/plugins/old-plugin/functions.php on line 29

What it means:

A plugin or theme is using a PHP function that still works but has been marked for removal in future versions. It’s not a fatal error yet — but it’s a warning that something will break.

How it usually happens:

Plugins that haven’t been updated in years often use functions that worked in PHP 5.x but were deprecated in PHP 7.x and removed in PHP 8.x. If your host upgrades PHP and you’re running old plugins, deprecation notices become fatal errors overnight.

What to do:

Don’t ignore deprecation notices. They’re your early warning system. If a plugin is throwing them, check whether there’s an update available. If the plugin hasn’t been updated in two or more years, consider replacing it with something actively maintained.

Keeping on top of this is exactly why I include regular plugin and PHP compatibility checks as part of ongoing WordPress maintenance — catching these before they become outages is much easier than fixing them after the fact.

---

Why PHP Errors Are Getting More Common

There’s been a big shift in PHP versions over the last few years. PHP 7.4 reached end-of-life in 2022, and PHP 8.0, 8.1, and 8.2 introduced breaking changes that affected thousands of plugins and themes.

Hosting companies have been pushing users to upgrade — which is the right thing to do for security — but if you have plugins that were last updated in 2019 or 2020, they may not be compatible with PHP 8.x at all.

The result is a lot of sites that were working fine until a hosting upgrade, and now have a mix of PHP 8 warnings, deprecated function notices, and the occasional fatal error.

---

Before You Try to Fix Anything: Check Your Backups

Every piece of advice in this guide assumes you have a working backup. Before you edit any file — wp-config.php, functions.php, .htaccess, anything — confirm that a recent backup exists and that you know how to restore from it.

If you don’t have backups running automatically, that’s the single most important thing to set up today. I use UpdraftPlus on most sites I manage, configured to back up to Google Drive or Amazon S3 daily. As part of any maintenance plan, backups are always the first thing I verify.

---

When to Fix It Yourself vs. When to Call Someone

Most of the errors above have clear causes and documented fixes. If you’re comfortable using FTP or your hosting file manager, reading error messages carefully, and making small targeted edits to configuration files — you can resolve a lot of these yourself.

But there are situations where DIY troubleshooting can make things significantly worse:

• You don’t know what changed. If the error appeared without any obvious trigger, there could be multiple issues layered on top of each other.
• You don’t have backups. Editing files without a restore point is risky.
• The site is an active WooCommerce store. Every hour of downtime has a real cost. It’s worth paying for a fast fix rather than spending hours troubleshooting.
• You’ve already tried a few fixes and it’s still broken. Sometimes what looks like a single PHP error is a symptom of something deeper — a corrupted database, a hacked file, or a plugin conflict that takes a systematic approach to untangle.

If you’re in one of those situations, you’re welcome to reach out to me directly. I’ll take a look, diagnose the actual cause, and fix it — usually same day for straightforward errors.

---

How to Prevent PHP Errors From Happening in the First Place

After years of maintaining WordPress sites, the pattern is clear: most PHP errors are preventable. Here’s what actually works:

Keep PHP up to date — but test first. Run a staging copy of your site and upgrade PHP there before touching production. Most good hosts offer staging environments. If yours doesn’t, consider switching.

Don’t install plugins you don’t need. Every additional plugin is another potential source of errors, conflicts, and memory consumption. If you installed something to test it and you’re not using it, delete it — not just deactivate.

Check plugin update dates before installing. A plugin that hasn’t had an update in 18 months is a risk. For anything that handles payments, forms, or authentication, being up-to-date is non-negotiable.

Use a child theme for any customizations. If you edit a parent theme directly and it gets updated, your changes — and potentially your site — are gone. Always use a child theme, or better yet, keep customizations in functions.php or a site-specific plugin.

Monitor your error logs. You don’t need to check them every day, but setting up a weekly habit of glancing at your debug log catches problems before they become visible to visitors.

If managing all of this sounds like more than you want to deal with, that’s what regular WordPress maintenance is for. I handle the updates, compatibility checks, backups, and monitoring so these issues get caught early — before your site goes down.

---

A Note on Performance and PHP Errors

There’s an overlap between PHP errors and performance problems that’s worth mentioning. A lot of the same root causes — too many plugins, outdated code, PHP version mismatches — also slow sites down significantly.

I regularly see sites where fixing a PHP compatibility issue also brings PageSpeed scores up 20–30 points, simply because the old code was running inefficient database queries or loading unnecessary scripts. If your site has been throwing warnings for a while and also feels sluggish, a proper audit often reveals that the performance issues and the PHP issues share the same source.

If that sounds familiar, speed optimization is usually the right starting point — it covers the full audit of what’s running on your site and why.

---

Summary

PHP errors in WordPress are almost always fixable. The ones covered in this guide — parse errors, fatal errors, memory issues, the white screen of death, deprecated functions — account for probably 90% of what I see in real sites.

The key things to keep in mind:

• Enable debug logging before you start troubleshooting — it gives you the exact file and line number
• Always work from a backup
• Treat deprecation notices as early warnings, not things to ignore
• If a plugin is regularly causing errors, the fix is usually to replace it, not to keep patching around it

And if you’d rather have someone handle it — whether it’s a one-off error, ongoing maintenance, or a deeper look at why the site keeps breaking — I’m available.

---

Vlad Lykhenko / Web Developer
lihenko.com.ua