A PrestaShop error 500 or a blank white page almost always means a fatal PHP error that the shop hides from visitors. To find the cause, turn on debug mode (in the back office or in config/defines.inc.php), read the latest entries in the PHP log and in the var/logs folder, and then work through the usual suspects: clear var/cache, disable overrides and the suspect module, check the PHP version and the memory limit. Usually the error message names the guilty file. Here is the full checklist.
- What does a PrestaShop error 500 or blank page mean?
- Before you start: what changed recently?
- How do I enable debug mode in PrestaShop?
- Where are the PrestaShop error logs?
- The most common causes of error 500 and how to fix them
- When should you restore the shop from a backup?
- Checklist: fix a PrestaShop error 500 in 10 minutes
- Frequently asked questions
What does a PrestaShop error 500 or blank page mean?
Status 500 (Internal Server Error) is the server's generic "something went wrong". In PrestaShop it is usually a PHP Fatal error that stops the page from being built. On a live shop error display is off, so you get an empty page or a generic error screen instead of a message.
Typical triggers: a new or updated module or theme, a PrestaShop upgrade or PHP version change, manual file edits (overrides, templates, .htaccess), a full disk or an exhausted memory or time limit, and less often files modified after a hack.
Note where the error appears. If only one page fails (say, the product page or the cart), the culprit is usually a module hooked into that page. If the shop and the back office are both down, look deeper: an override, the PHP configuration or a broken cache.
Before you start: what changed recently?
What changed just before the outage? A new module, an update, a PHP change in the hosting panel, a file edited by an agency? If you know, undoing that one change is often enough.
Before you delete or rename anything: copy the file or folder you are touching. Do not uninstall modules or drop database tables while troubleshooting.
How do I enable debug mode in PrestaShop?
Debug mode replaces the blank page with the actual error: message, file and line number. It is the most important first step.
From the back office
If the back office still works, go to Advanced Parameters > Performance and in the Debug mode section set Debug mode: Yes, then save. The option works the same way in PrestaShop 1.7, 8 and 9, and under the hood it writes the setting to config/defines.inc.php.
PrestaShop 9 adds Debug cookie name and Debug cookie value fields there, so debug mode can be active only in a browser that has that cookie.
From config/defines.inc.php
If the back office is down too, open config/defines.inc.php via FTP, SSH or your host's file manager. Near the top you will find the line define('_PS_MODE_DEV_', false);. Change false to true, save and reload the page. The file path and the constant name are the same in PrestaShop 1.7, 8 and 9.
No effect? Check for a config/defines_custom.inc.php file: PrestaShop loads it first, so a _PS_MODE_DEV_ defined there wins.
Remember: debug mode shows error details to every visitor and slows the shop down. Turn it off once you have found the cause.
Where are the PrestaShop error logs?
If you would rather not enable debug mode on a live shop, read the logs. Look for entries from the time of the failure containing PHP Fatal error, Uncaught or CRITICAL.
| Log | Where to find it | What it contains |
|---|---|---|
| PrestaShop log (1.7) | var/logs/prod.log (dev.log in debug mode) |
Symfony errors, mostly from the back office and newer pages |
| PrestaShop log (8 and 9) | var/logs/prod-YYYY-MM-DD.log, one file per day |
same as above |
| PHP error log | the path set in error_log, usually shown in the hosting panel |
fatal PHP errors, including memory limit errors |
| Web server log | e.g. /var/log/apache2/error.log, /var/log/nginx/error.log |
.htaccess errors, PHP-FPM problems, timeouts |
| Back office logs | Advanced Parameters > Logs | events recorded by the shop and modules, if the back office works |
With SSH access, tail -n 50 /var/log/nginx/error.log safely shows the end of a log (adjust the path). On shared hosting the logs are usually in the control panel. Very old 1.7 releases (before 1.7.4) kept logs and cache in app/logs and app/cache instead of var/.
A path starting with modules/module_name/, override/ or themes/theme_name/ in the message points straight to the culprit.
The most common causes of error 500 and how to fix them
A broken or outdated cache
After an upgrade, a server move or a file change, the cache may point to missing classes. If the back office works, click Clear cache in Advanced Parameters > Performance. If not, delete the contents of var/cache/prod and var/cache/dev (keep the folders themselves). PrestaShop rebuilds it on the next request. Do not delete anything outside var/cache.
An override that does not match the PrestaShop version
Overrides (the override/ folder) replace core classes. After an upgrade, an old override often calls a method that no longer exists or has changed.
- From the back office: Advanced Parameters > Performance > Debug mode > Disable all overrides: Yes.
- In PrestaShop 1.7 the same section also has Disable non PrestaShop modules, which temporarily switches off every module that is not part of the core distribution. PrestaShop 8 and 9 no longer have this option.
- Without the back office: rename the specific file named in the error (for example
override/classes/Cart.phptoCart.php.off), then deleteclass_index.phpfromvar/cache/prod(andvar/cache/dev) so PrestaShop rebuilds its class map.
A module that crashed
If the error points to a module, disable it in Modules > Module Manager. If the back office is down, rename the module folder, for example modules/some_module to modules/some_module_off; PrestaShop will then skip it. Restore the name once the module is fixed.
Do not uninstall the module in a hurry: uninstalling can erase its data and settings. If it installed its own overrides, disable them as described above.
The PHP version does not match PrestaShop
A PHP version changed by the host, or a move to a new server, is a very common cause. PrestaShop 1.7 officially supports PHP up to 7.4 only, while PrestaShop 9 needs at least PHP 8.1. Check the requirements for your version in the official documentation and compare them with the version selected in your hosting panel. If the back office works, Advanced Parameters > Information shows the current PHP version and memory limit.
If your PrestaShop version does not support the current PHP, switch back to the previous PHP and plan an upgrade; our guide on how to upgrade PrestaShop step by step shows how to do it without losing data. Old modules can also break on a newer PHP even when the core is fine.
Out of memory or out of time
Allowed memory size of ... bytes exhausted means the memory_limit has run out. PrestaShop is usually given at least 256M; change it in the hosting panel or PHP configuration. If the error only appears during imports, thumbnail regeneration or large exports, max_execution_time may be the limit you are hitting. But if an ordinary category page needs hundreds of megabytes, a higher limit only hides a code problem.
.htaccess, permissions and disk space
On Apache, a broken .htaccess directive returns error 500 before PHP starts; only the web server log shows why. Regenerate it by saving Shop Parameters > Traffic & SEO > SEO & URLs (copy the old file first). Also check that the disk is not full and that var/ is writable by the web server.
Files nobody added or code nobody edited in the logs may mean a hack: see our post on PrestaShop security.
When should you restore the shop from a backup?
Restoring a backup makes sense when:
- the shop broke after an update and you cannot debug it during business hours,
- many things changed at once and the culprit is unclear,
- files or the database were damaged or modified by a third party.
Always restore files and database from the same point in time; mixing them causes new errors. Orders placed after the backup will have to be recreated. Make a backup before every update, and check what backups your host keeps and how to restore them.
Checklist: fix a PrestaShop error 500 in 10 minutes
- Find out what changed right before the outage, and whether the whole shop or one page is down.
- Enable debug mode (back office or
_PS_MODE_DEV_inconfig/defines.inc.php) and reload the page. - Read the latest entries in
var/logs, the PHP log and the web server log. - Clear the cache: the back office button, or the contents of
var/cache/prodandvar/cache/dev. - Disable overrides; without the back office, rename the file and delete
class_index.php. - Disable the module named in the error; without the back office, rename its folder.
- Check the PHP version and
memory_limitin your hosting panel. - Check
.htaccess, free disk space and write permissions onvar/. - If nothing helps, restore files and database from the same backup.
- Turn debug mode off and test a purchase from cart to payment.
Not comfortable editing server files, or need the shop back fast? Order the diagnosis as PrestaShop development work.
Frequently asked questions
Why does my PrestaShop shop show a blank page with no error?
Because error display is off in production. PHP stops on a fatal error and the browser gets an empty response or status 500. Enable debug mode or read the PHP error log to see the real error.
Can I leave debug mode on?
No. Debug mode slows the shop down and shows visitors technical details that make attacks easier. Turn it on only while troubleshooting, and in PrestaShop 9 consider limiting it with the debug cookie.
Is it safe to delete var/cache?
Deleting the contents of var/cache/prod and var/cache/dev is safe: PrestaShop rebuilds the cache by itself, so the first page load is just slower. Do not delete other folders in var/.
Error 500 appears only in the back office. What should I do?
Check var/logs: much of the back office runs on Symfony and logs its errors there. Common causes are a stale cache after an upgrade, a module that adds its own back office tab and a memory limit that is too low.
Still seeing error 500? Contact us and include the error message from the log.
Products in this article
