Common PHP errors and how to fix them without breaking your live site

A PHP error can feel like the site just fell over for no reason. In reality, PHP is usually telling you quite precisely what went wrong. The trouble is that on a live site that message is either hidden behind a blank page or, worse, printed straight onto the screen for everyone to read.

This guide does two things. First, it shows you how to make PHP tell you what's wrong, safely. Then it walks through the errors we see most often, what causes them, and what to do.

Step zero: make PHP show you the real error

Before you change any code, find the message. Visitors shouldn't see errors, but you need them somewhere. The standard setup for a live site is to hide them from the page and write them to a log file:

; php.ini on a live site
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log
error_reporting = E_ALL

The log path varies by host. If you're unsure where yours lives, run phpinfo() on a private page (and delete it afterwards) and look at the error_log value, or ask your host. On a local or staging copy, you can safely set display_errors = On to see problems right in the browser.

A related tip: a 500 error with no PHP message at all often comes from the web server, not PHP. A typo in .htaccess is a classic cause on Apache. Check the web server's error log as well.

The errors you'll meet most

"Allowed memory size of … bytes exhausted"

A script tried to use more memory than memory_limit allows. The common culprits are loading a whole table into an array, resizing very large images, or a loop that keeps growing a list.

• Fetch in pages or chunks (LIMIT and OFFSET) instead of everything at once.
• Free large variables you're done with, or process files line by line.
• On WordPress, you can raise the limit with define('WP_MEMORY_LIMIT', '256M'); in wp-config.php. Treat this as a patch, and find which plugin or page is hungry.

"Maximum execution time of 30 seconds exceeded"

The script ran longer than max_execution_time, which defaults to 30 seconds for web requests. Slow database queries and calls to other services with no timeout are the usual reasons. Set a timeout on outgoing requests (for cURL, CURLOPT_TIMEOUT), add indexes where queries are slow, and move heavy jobs such as report generation or bulk emails to a background task instead of the page request.

"Call to undefined function"

PHP can't find a function you used. There are three typical reasons:

• A missing extension. Functions like mb_strlen() or curl_init() only exist if the mbstring or curl extensions are installed. Install and enable them (on Ubuntu the package is usually named something like php-mbstring), then restart PHP.
• A version change. The function was removed or renamed in the PHP version you upgraded to. Check the migration notes for that version.
• A file that wasn't loaded. The code lives in a file that never got included. With Composer, running composer dump-autoload often solves it.

"Call to a member function something() on null"

You tried to use an object that doesn't exist. A database lookup found no row, or a variable was never set, and the code went on as if it had. Check the value before using it. On PHP 8 and later, the null-safe operator keeps things tidy:

// Stops with a fatal error if $user is null
$name = $user->getProfile()->name;

// Returns null instead (PHP 8.0+)
$name = $user?->getProfile()?->name;

That removes the crash, but you still need to decide what the page should do when there's nothing there. Show a friendly message, not a blank space.

"Class not found"

Often a spelling or capitalisation problem. Windows doesn't care whether it's User.php or user.php; a Linux server does. Code written on a laptop can break the moment it's deployed. Check the namespace, the file name's case, and your autoloader settings.

"Cannot modify header information: headers already sent"

PHP must send headers (for redirects, cookies and sessions) before any page content. If anything has been output earlier, even a single space, it fails. The usual causes are whitespace or a hidden byte-order mark before the opening <?php tag, an echo that runs before header() or session_start(), and blank lines after a closing ?> tag. The error message even names the file and line where the output began, so start there. In files that contain only PHP, leaving off the closing tag avoids the trailing-whitespace trap altogether.

"Parse error: syntax error, unexpected …"

A typo: a missing semicolon, an unclosed bracket, or a stray quote. If the code ran fine elsewhere, suspect a version mismatch. Newer syntax such as the match expression (PHP 8.0) will produce a parse error on an older server.

"Undefined variable" and "Undefined array key"

These are warnings, so the page often keeps working, which is exactly why they pile up unnoticed. Since PHP 8, a missing array key is reported as a warning rather than a quiet notice. Give the value a fallback:

// Warns if 'phone' is missing
$phone = $_POST['phone'];

// Safe default
$phone = $_POST['phone'] ?? '';

"Deprecated" notices

The code works today but won't forever. Two you'll likely meet on newer versions: passing null to a built-in function parameter that doesn't accept it (deprecated in PHP 8.1), and creating properties on an object without declaring them (deprecated in PHP 8.2). They're warnings that an upgrade is coming, so fix them before it does.

Database connection errors

Messages like "Access denied for user" or "Connection refused" mean the host, username, password or database name in your settings is wrong, the database server is down, or you've hit the connection limit. Check the credentials first, then your host's status page. And note that this type of message can contain your database host and username, which is one more reason not to show errors on screen.

Why errors on screen are a security problem

A visible error isn't only embarrassing. It can show the full path of your files on the server, the names of your database and tables, fragments of the query, and the exact versions and libraries you use. That's a free map for anyone planning an attack, and it costs them nothing to read. Keep display_errors off, log everything, and set up an alert when the error count jumps.

Keep your PHP version supported

Old versions stop receiving security fixes. PHP 7.4 and 8.0 are both long past end of life, and sites still running them are exposed to every flaw found since. Check the official supported versions page, then plan an upgrade. Our walkthrough of what to check on your site covers this alongside everything else.

When to ask for help

If errors keep coming back after you've fixed them one by one, there's usually an underlying issue: an unsupported version, a plugin that doesn't get on with another, or code that was never written to handle the unexpected. That's the kind of thing an audit turns up quickly, and it's cheaper to fix when you can see the full list in priority order.