PHP Errors: What Each One Means and How to Read Them

PHP errors frighten site owners because they all look alike: long, English, full of file paths. Yet these lines are not random. Each error type tells you something different, and telling apart what stops the site from what is merely noise is the difference between a day of work and a week of it.

This article is written for two audiences at once: the owner who wants to know what is serious, and the developer who wants to read the error correctly.

Error Types, in Order of Severity

Fatal error — execution stops

The most serious. PHP cannot complete the request and halts; the visitor sees a blank page or an HTTP 500. A typical line reads: "Fatal error: Uncaught Error: Call to undefined function ... in /path/file.php on line 42". Three pieces of gold there: what is missing, which file, and which line. Simply noting that down halves the time your technical team needs.

The three most common causes: a plugin was removed but references to it remain, a function was dropped in a newer PHP version, or two plugins define a function with the same name.

Warning — it runs, but something failed

The page loads while an operation silently failed — a file could not be read, a connection could not be made. Visitors usually notice nothing, but work is not getting done in the background. Form email that never sends typically hides here: delivery fails, a warning hits the log, and the visitor sees a success message.

Notice and Deprecated — not today, but tomorrow

A notice means "you touched something that does not exist, but I coped". Deprecated means "this usage is obsolete and will stop working in a future version". Neither stops the site. But letting deprecation warnings pile up is exactly what makes the next PHP upgrade take the whole site down. Silencing them as "noise" is common and expensive.

Memory exhausted — the limit ran out

"Allowed memory size of X bytes exhausted" means PHP ran out of allocated memory. The first instinct is to raise the limit, and that is usually wrong. The real question is why this page wants that much memory. The answer is normally a query loading thousands of rows at once, an oversized image being processed, or a hook stuck in a loop. Raising the limit postpones the symptom; the cause returns bigger.

Maximum execution time — the clock ran out

Raised when an operation exceeds its allowed time. Normal during bulk imports, backups and large data jobs; on an ordinary page view it signals a real performance problem.

How to Actually Read the Log

Errors should never be displayed to visitors — file paths and code structure hand information to attackers. The correct setup writes errors to a log file and shows visitors a generic error page.

1. Start from the oldest error, not the newest. Most later errors are consequences of the first one.
2. Read the stack trace bottom-up. The last line shows where execution began, the top line where it exploded. The culprit is usually in between.
3. Look at repetition counts. A warning repeating thousands of times an hour can burn more resources than a one-off fatal error.
4. Is it your code or third party? A path inside a plugin directory makes it that developer's responsibility; a path inside your theme makes it yours.

What Breaks on a PHP Version Upgrade

• Removed functions. Functions that were once everywhere were deprecated and then removed. Old themes that use them raise fatal errors.
• Stricter typing. Type mismatches that were silently tolerated now produce errors. Old code passing a string where a number is expected breaks here.
• Dynamic property creation. Assigning to a property that was never declared now raises a warning, and the pattern is very common in older plugins.
• Database driver changes. Very old code uses connection methods that no longer exist, so the connection simply never opens.
• Changed defaults. Shifts in error display, session handling and character encoding change behaviour without a single line of code changing.

The correct migration: run a copy of the site on the new version in a separate environment, clear the error log, exercise the critical flows one by one — forms, payment, search, login — and only then go live. It takes a day, and it prevents a week of downtime.

Diagnosis When There Is No Error Message

Sometimes the screen shows nothing at all — no error, no content. Then you work through the server's own error log, the PHP-FPM pool log, the web server access log (to confirm the request even arrived) and the database slow query log. We walked through this order step by step in our white screen article.

How We Approach It

On every project we take over, the first thing we read is the error log, because the log is the site's real health report. If a site whose owner says "everything is fine" is generating hundreds of warnings an hour, there is a failure approaching that has simply not surfaced yet.

On our own projects we aim to keep the error log at zero. Lines collected as "harmless warnings" turn into a mass breakage at the next version upgrade. That is why error log monitoring is a standard item in our maintenance subscription — we intervene when a fault signals, not when it lands.

Where the Logs Actually Live, Layer by Layer

"Check the log" is useless advice if you do not know which log. A single request writes to several, and each describes a different layer:

• Application log: the site's own error record, usually in the root or content directory. Most PHP errors land here.
• PHP process pool log: kept on the PHP-FPM side. Memory exhaustion, timeouts and worker crashes appear here and may never reach the application log.
• Web server error log: configuration errors, permission problems and requests that returned 500.
• Web server access log: proof that the request reached the server at all. If a visitor says the page will not load and there is no entry here, the problem sits before the server — network or DNS.
• Database slow query log: records queries above a time threshold. The first place to look for slowness complaints.

Starting in the right layer shortens diagnosis dramatically. Hours spent reading the wrong log is the most commonly wasted time in this work.

Catching Errors Before They Reach Production

Keep error display on in staging. Every warning should be visible in development and log-only in production, so deprecation notices reach the developer and never the customer.

Rehearse version upgrades on a copy. The site loading on the new PHP version does not mean the job is done; you have to check whether new lines appeared in the log. A site that runs quietly while generating warnings is the site that will fall over at the next upgrade.

Track the error count. The daily error count is the most honest measure of code health. If it starts climbing, something has begun to break even though nobody has complained yet. On projects we take over, driving that counter to zero is the first thing we do.

What Would It Cost If We Fixed It?

You do not have to guess, and you do not have to ask us. Tick the items you need in the calculator on our site and the total appears instantly. No forms, no waiting for a quote.

Calculate your price in one minute →