500 error or blank page: where the failure comes from
A 500 error is not a diagnosis, it is a polite admission of failure. The server received the request, started the programme, and the programme stopped before producing a valid response. A fully blank page comes from the same mechanism, simply displayed differently. The real reason was written somewhere — not on screen, for security reasons. Until you have read it, anything you try is guesswork.
What the 500 code already rules out
Before searching, it helps to note everything this code eliminates. The domain name resolves correctly, otherwise nothing would have answered. The web server is working, since it produced the error page itself. The network is fine. The hosting account is not suspended.
The field of causes therefore narrows to running the site: server configuration for this site, application code, or the resources allocated to that specific execution. That is good news, because those three families are distinguished by simple clues, and none of them requires waiting for a third party to reply.
This page describes the mechanism shared by every platform. On a PrestaShop shop, the exact locations — var/logs, the _PS_MODE_DEV_ constant, the override/ folder — and the platform’s own causes are covered on the page dedicated to the PrestaShop 500 error. On WordPress, the same symptom shows up as the WordPress critical error.
The causes I meet, in order of frequency
- Configuration: one invalid directive in a configuration file read by the server is enough to return a 500 on every page, even before the CMS starts. A line added by a cache or security module is often the origin.
- Application code: a call to a removed function, a module incompatible with the PHP version, an override written for an earlier core version, a compiled cache referring to files that no longer exist, or plainly a syntax error introduced by editing a theme file directly — one missing brace or semicolon is enough.
- Resources: insufficient memory allocated for the requested page, a process limit reached, a full disk preventing temporary files from being written.
- Permissions: a file or directory whose permissions are refused by the server, notably when they are too open under some shared hosting configurations.
Finding the real message
-
Note the scope first
The whole site, one page, only the admin, or only certain records? A global error points at configuration or the server; a targeted error points at one module or one piece of data.
-
Open the server error log
That is where the full message sits, with the file and the line. With most hosts it is reachable from the panel, with no support ticket needed.
-
Look for the application log too
The CMS keeps its own log, separate from the server’s. The two complement each other: the first gives the technical error, the second the functional context.
-
Enable debug mode for one attempt
It brings the message back on screen. Turn it off immediately afterwards: left on, it exposes paths and table names to every visitor.
-
Set the suspect configuration file aside
If the error affects the whole site, temporarily renaming the configuration file read by the server tells you in one second whether it is the origin.
-
Link it to the last intervention
An update, a module install, an edited theme file: the failure almost always follows an action, even one taken by someone else, and even days earlier if a cache delayed its effect.
When the same failure shows up as a blank page
Depending on server configuration, the same fatal error produces a 500 error screen on one setup and a fully blank page on another. A blank page is therefore not an absence of response: the server answered, the programme stopped partway, and the message went into a log. The method above applies unchanged.
One extra move halves the field of causes: view the page source. If the window is empty, execution stopped before writing anything — a fatal PHP error or a memory limit, exactly the same ground as a 500. If there is HTML but nothing visible, the programme worked and it is the display that is broken: a stylesheet that failed to load, an empty template, a script hiding the content. That second case is not read in the server log, but in the browser console.
Then there is the in-between case, the most informative of all: the page renders halfway then stops mid-sentence. Execution was interrupted while writing, and the exact point of the cut names the block of the page at fault.
The error that only affects part of the site
This is the most informative case, and the most often wasted. A 500 limited to one page means the faulty code only runs there. What distinguishes that page from the others is therefore the direct lead: a module hooked to that location alone, a particular record, an empty field, a malformed variant.
- On the admin only: almost always a module loaded on the admin side, or a page listing too many records.
- On a few product pages only: look for what those pages have in common, not what separates them from each other.
- At order validation: the field of causes narrows to the checkout and the payment or shipping modules.
- Intermittently: that is a resource limit, not a code defect.
Carry on with the right page
-
PrestaShop 500 error
The full PrestaShop diagnosis, from debug mode to overrides.
-
Critical error on WordPress
The same symptom on WordPress and WooCommerce, with its own causes.
-
Reading error logs
How to read an error trace without being a developer.
-
The 500 error explained
The definition of the code and its place among other server responses.
-
Enabling debug mode on PrestaShop
The exact steps to bring the hidden message back on screen.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.