PHP Errors in WordPress: What They Mean and What to Do First

You did not break your site because you do not understand PHP. You broke your site because something in the system failed, and the system left you a note you did not know how to read.

PHP errors are that note. They are not accusations. They are evidence. Once you know what each type means and where to look first, they stop being intimidating and start being useful.

This is not a PHP tutorial. This is a translator.

Where PHP errors live

Before you can read a PHP error, you have to be able to see one. By default, WordPress hides them. The errors are still happening. They are just not being recorded anywhere you can access.

To turn on error logging, enable the WordPress debug log. Once it is on, every PHP error your site generates gets written to /wp-content/debug.log with a timestamp, an error type, a message, and the file and line number where it happened. That file is where this post starts.

The four error types, in plain terms

Fatal error

A fatal error means PHP hit something it could not work around and stopped executing entirely. The page did not finish loading. The function did not run. The order did not save.

This is the error type you look for first whenever something on your site simply does nothing. A button that produces a blank screen, a form that submits and then nothing happens, a checkout that looks like it processed and left no record anywhere: these are the signatures of a fatal error upstream.

In the log it looks like this:

[21-May-2026 03:14:22 UTC] PHP Fatal error: Call to undefined function wc_get_order() in /wp-content/plugins/my-plugin/functions.php on line 84

The useful parts: the error type (Fatal error), what it could not do (call to undefined function), the specific function it tried to call (wc_get_order()), the plugin file where it happened, and the exact line number. That is enough for a developer or an AI assistant to locate and fix the problem without asking you a single follow-up question.

Warning

A warning means something unexpected happened, but PHP kept going. The page probably loaded. The function probably ran. But something was wrong with the inputs or the data it encountered, and it handled it badly rather than stopping.

Warnings are the most underestimated error type. Because the site appears to work, they get ignored. They should not be. A warning frequently signals a condition that will corrupt data silently, or that will become a fatal error the moment traffic or data volume increases slightly.

If you have a situation where WooCommerce inventory looks right on the product page but reports a different number at checkout, or a form appears to submit but the entry never appears in your database, look for warnings in the debug log from the time of the failure. Silent WooCommerce failures in particular almost always have a warning in the log that points directly at the cause.

Notice

A notice is PHP flagging something that is technically imprecise but not necessarily broken. A variable that was used before it was assigned a value. An array key that does not exist. Code that will probably work but is written in a way that relies on assumptions PHP does not guarantee.

On a mature WordPress site, notices are noise. The debug log will be full of them from core WordPress files and plugins you did not write. For diagnostic purposes, focus on notices from your own plugin files or your active theme. A notice in a plugin you installed is worth investigating. A notice in wp-includes/ is almost always safe to ignore.

Deprecated

A deprecated notice means a plugin or theme is calling a WordPress function that still works today but has been marked for removal in a future version. It will not break anything right now. It will break when WordPress eventually removes the function, which could be one major version away or several.

When you see a deprecated notice, note which plugin or theme file it is coming from. If the plugin has not been updated recently, that is a signal to look for an alternative before the next major WordPress release.

The most common errors and what causes them

“Call to undefined function”

Something tried to use a function that does not exist yet. Either the plugin that defines the function is not active, the function is being called before the plugin has loaded, or a recent plugin update renamed or removed the function.

First check: is the plugin that should define this function active? Go to your plugins list and verify. If it is active and the error persists, there is a load order conflict: the function is being called before the plugin that defines it has initialized. This is a plugin conflict, and the fastest resolution is to deactivate recently updated or installed plugins one at a time until the error stops.

“Undefined variable” or “Undefined array key”

Code tried to use a variable or access a value that was never set. This is almost always a warning, not a fatal, so the site keeps running. But the behavior downstream of it will be wrong: a field that should contain a customer email contains nothing, a calculation that expected a number received null.

These errors spike after plugin updates when a developer changed a data structure and the code that reads that data was not updated to match.

“Maximum execution time exceeded”

A process ran longer than your server allows and was forcibly stopped. The most common causes: a plugin trying to import a large file, a database query that is scanning too many rows, or a loop in custom code that ran far more iterations than expected.

This one often appears as a timeout on the front end with no visible error message. Check the debug log if a page simply stops loading after a consistent amount of time.

“Allowed memory size exhausted”

A process tried to use more memory than your server has allocated for PHP. Usually caused by a plugin processing large images, a query that loaded too much data into memory at once, or a conflict between plugins that are both loading large libraries simultaneously.

Your hosting provider can increase the PHP memory limit if needed, but it is worth identifying which plugin or process is causing the spike before treating memory as the solution.

How to use a PHP error to get a fix

The mistake most people make when they find a PHP error is describing it in their own words rather than sharing the actual text. “There’s a PHP error when I try to checkout” tells a developer almost nothing. The exact error text, the file path, and the line number tells them precisely what broke and where.

Copy the complete log entry. Paste it directly into your message to a developer, or directly into your AI assistant’s prompt. Do not summarize it. Do not translate it first. The raw text is what produces a specific fix rather than a generic investigation.

If you have the WordPress debug log enabled, finding the relevant entry is a matter of noting the time the failure occurred and looking at the entries from that window. Loupely captures the debug log automatically as part of every diagnostic, reads the entries from the time of the failure, and explains what each one means in terms you can act on, with a copy-paste block formatted for developer or AI handoff. If you are doing this manually every time something breaks: useloupely.com