# PrestaShop shop stuck on a 500 error or blank page

> A blank page or a 500 error on PrestaShop tells you nothing on its own: it's a symptom, not a diagnosis. You need the real error messages to know whether the problem is a module, an override, the database or the server.

- Source canonique : [https://allaux.fr/en/prestashop/erreur-500](https://allaux.fr/en/prestashop/erreur-500)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Set _PS_MODE_DEV_ to true in config/defines.inc.php: the blank page gives way to the real error, with the offending file and line. Also read var/logs/ (1.7, 8, 9) and the host PHP error log. If the error showed up after an update, empty var/cache and rename the override/ folder to rule out a stale override.

## The situations I handle

- Completely blank screen when loading the front end or back office
- 500 error appearing right after a module or PrestaShop update
- 500 error on certain pages only (product page, cart, checkout)
- "The file config/settings.inc.php is missing" message after a hosting transfer
- 500 error triggered after a manual edit to an override file
- Site works locally but errors once deployed on the production server

## How I go about it

1. **Enabling debug mode** — I set _PS_MODE_DEV_ to true in config/defines.inc.php to reveal the real PHP or Smarty error message instead of the generic blank page.
2. **Reading the logs** — I check the server's PHP logs (often in error_log or the Apache/Nginx logs) and, on PrestaShop 1.7/8, the var/logs/ folder, which holds the Symfony errors.
3. **Isolating the culprit** — I disable modules one by one via the ps_module table or FTP, and check the override/ folder for a file conflicting with the core.
4. **Checking the server** — I check the PHP version, active extensions, memory_limit and write permissions on var/cache, var/logs and config, all common causes after a hosting change.
5. **Fixing and clearing the cache** — Once the cause is identified, I fix the file or reconfigure the server, then clear var/cache/prod (or cache/smarty on 1.6) before switching debug mode back to false.

## PrestaShop blank page: where it appears tells you where it comes from

Before even reading the logs, note where the blank page or 500 error occurs. It halves the search area.

Front office and back office both blank: the failure happens before PrestaShop tells them apart. Look at the configuration: PHP version changed by the host, an incomplete app/config/parameters.php (1.7, 8, 9) or config/settings.inc.php (1.6), an invalid .htaccess, missing write permissions.

Back office only: often a cache left over from a previous version in var/cache/, or a module hooked into the admin.

Front office only, or a single page: a module attached to a display hook, a theme file, or data specific to that page.

Only at checkout: the payment or carrier module, which is only called at that step.

If the page stays blank while _PS_MODE_DEV_ is on, the error happens before PrestaShop has loaded: read the server’s PHP error log, not var/logs.

## The most common error messages, and what they point to

Cannot declare class … or Cannot redeclare class …: a duplicated override, or one left behind after a module was uninstalled. Deleting the class index — var/cache/prod/class_index.php on 1.7 and later, cache/class_index.php on 1.6 — makes PrestaShop rebuild it.

Allowed memory size of … bytes exhausted: PHP’s memory limit has been reached, typically during an import, thumbnail regeneration or indexing.

Call to undefined function each() or create_function(): a module written for an old PHP version. Both functions were removed in PHP 8; see moving PrestaShop to PHP 8.

SQLSTATE[42S02]: Base table or view not found: a table is missing, after a migration, an interrupted SQL import or a badly uninstalled module.

Link to database cannot be established: wrong database credentials in the configuration file, or the MySQL server is down. See database connection error.

Permission denied on var/cache or var/logs: write permissions lost, common after an FTP transfer or a change of host.

## The most common causes

On PrestaShop, a 500 error is rarely random. The cases I run into most often:

A badly written or duplicated override file between override/ and a module, causing a class to be redeclared.

A PHP version incompatibility after a hosting upgrade (a module using a function removed in PHP 8, for instance).

Missing write permissions on var/cache, var/logs or config after an FTP file transfer.

A corrupted .htaccess file or an invalid rewrite rule, breaking routing before PrestaShop even runs.

A missing or corrupted database table following a migration or an interrupted SQL import.

On 1.6, the blank page often hides a Smarty error in the compiled cache (cache/smarty/compile) that wasn't cleared after a theme update.

## Your orders aren't lost

> A 500 error blocks the display, it doesn't wipe the database. Orders already recorded stay intact; the real risk is losing sales during the downtime, not the order history.

## config/defines.inc.php

```
define('_PS_MODE_DEV_', true);
```

## Related pages

- **Enabling PrestaShop debug mode** — The exact steps for each version, and how to switch it off afterwards. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop))
- **Reading PrestaShop error logs** — Where the logs live and how to spot the line that matters. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop))
- **Product page will not save** — When the error only appears when saving a product in the back office. ([/prestashop/problemes/fiche-produit-enregistrement-echoue](/prestashop/problemes/fiche-produit-enregistrement-echoue))
- **Module refuses to install** — Installation error, disappearing module: the causes in the files and in the database. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation))
- **Payment method gone after an update** — When the failure is confined to checkout. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj))
- **Recurring errors: repair or rebuild?** — On an old version, when every fix calls for another. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## FAQ

### Am I at risk of losing my orders or customers?

No. The 500 error stops pages from displaying but the database stays intact: existing orders, customer accounts and the catalogue are untouched. It is the PHP execution layer that stops, not the storage.

### What access do I need to give you?

FTP or SSH access, database access (phpMyAdmin or direct credentials) and, if possible, access to the host's client area to check the PHP configuration.

### How long does the diagnosis take?

In most cases, enabling debug mode and reading the logs is enough to identify the cause in the first working session. It is the kind of block that gets sorted the same day once server access is available; the fix itself depends on what's broken.

### Can the error come back after it's fixed?

If it comes from an unstable third-party module, yes, at the next automatic update. I can lock updates on sensitive modules to stop that happening again.

### Do I need to restore a full backup?

Rarely. Restoring a backup loses orders and changes made since that date. I generally fix the file or configuration at fault directly instead.

### Why does my PrestaShop shop show a blank page with no message at all?

Because PrestaShop hides errors in production: as long as _PS_MODE_DEV_ is false, the details are not displayed. Set it to true for one test. If the page is still blank, the error happens before PrestaShop loads — PHP version, .htaccess, configuration file — and the server’s error log is where you will find it.