PrestaShop 500 Error — Diagnosis & Fix [2026]

A 500 error in PrestaShop ("Internal Server Error", "Oops! An error occurred", "The server returned a 500 Internal Server Error") is the second most common store failure after the white screen. Unlike a white screen, a 500 error almost always leaves a trace in the server logs — which makes diagnosis faster. The most common causes are PHP memory limits, a broken .htaccess, file permissions and an incompatible module. A specialist fix: 200–600 PLN net, diagnostics with a report 500–1,500 PLN net.

Key takeaway: You diagnose a PrestaShop 500 error in this order: 1) server (nginx/apache) and PHP logs — that is where the concrete message is, 2) PHP memory limit (Allowed memory size exhausted), 3) .htaccess — regenerate or temporarily disable for testing, 4) file permissions (directories 755, files 644), 5) debug mode on a copy for the full message, 6) module isolation via ps_module. A 500 error usually affects one page (e.g. only the cart) — that narrows the culprit down to a single module.

How a 500 error differs from a white screen

A white screen is disabled error display — you do not know what happened until you enable debug mode. A 500 error is the server explicitly telling you the request failed. In PrestaShop 1.7/8/9 you will see one of these messages:

• "Oops! An error occurred." — the standard PrestaShop error screen,
• "The server returned a "500 Internal Server Error". Something is broken." — the Symfony error (PrestaShop 1.7+/8/9),
• a blank screen with a 500 code in the browser developer tools.

Regardless of the message, the procedure is the same: logs → causes → fix. If you see a blank screen with no message, follow the PrestaShop white screen procedure.

• ## Step 1: Server and PHP logs

Start with the logs — a 500 error always leaves an entry

• nginx/apache logs — in the hosting panel, the logs/ directory (e.g. error.log),

• PHP logs — error_log in the store directory or ~/logs/php_errorlog,

• PrestaShop logs — var/logs/prod.log and var/logs/dev.log.

• Look for: PHP Fatal error, Allowed memory size, Cannot redeclare, Call to undefined method, SQLSTATE. The last entry before the error is usually the culprit. How to read logs: PrestaShop logs.

• ## Step 2: PHP memory limit

The single most common cause of a 500 error in PrestaShop

• - message: Allowed memory size of 134217728 bytes exhausted (tried to allocate ...),
• - fix: raise memory_limit to 256M–512M (.user.ini, hosting panel or php.ini),
• after the change, clear the cache and test the page that returned the error.

PrestaShop 8/9 with a large catalogue and modules realistically needs 256M+ for the front end and 512M for administrative operations (imports, updates).

• ## Step 3: .htaccess

A broken or incorrectly generated .htaccess returns 500 across the whole store

1. back up .htaccess,
2. temporarily rename it to .htaccess.bak and check the store,
3. if the store recovers — regenerate .htaccess (panel → Advanced Parameters → Performance → generate button) or restore it from a clean installation of the same version,
4. check whether your host requires its own rules (PHP handler, HTTPS redirect) — compare with the hosting documentation.

• ## Step 4: File and directory permissions

After a hosting migration or backup extraction, permissions can block PHP

• Fix via SSH: find . -type d -exec chmod 755 {} \;, find . -type f -exec chmod 644 {} \;, then chmod -R 775 var/.

• ## Step 5: Debug mode and the full message

If the logs are empty or ambiguous, enable debug mode on a store copy: in config/defines.inc.php set define('_PS_MODE_DEV_', true);. Instead of "Oops! An error occurred" you will see the full stack trace: file, line and class. That is the fastest route to the cause — details in PrestaShop debug mode.

Warning: Debug mode on production exposes server paths, SQL queries and configuration to customers. Enable it only on a copy, and disable it immediately after the diagnosis.

• ## Step 6: Module isolation

When the error affects one specific page (cart, product, checkout), the culprit is usually a module hooked to that page

1. check which page returns the 500 — that narrows the module list,
2. disable modules related to that feature (e.g. cart and discount modules for the cart),
3. when the panel works, use the panel; when it does not — UPDATE ps_module SET active = 0 WHERE name = 'module_name';,
4. the last module disabled before the error disappeared is the culprit — update it or report the issue to its author.

• Full isolation procedure: PrestaShop module conflicts.

500 error when logging into the admin panel

A special case: the front end works, but /admin (your custom panel URL) returns 500. The most common causes

• exhausted memory limit — the PrestaShop panel uses more memory than the front end; raise the limit,
• corrupted cache after an update — delete the contents of var/cache,
• an incompatible admin module — disable the last installed module via the database,
• an error in a core class override — check override/ for classes modified by modules.

In PrestaShop 8/9 you can also check the Symfony logs in var/logs/ and use php bin/console commands.

When to call a specialist

Help is worth it when the logs point to the core or the database, the error returns after every fix, or the store has been down for more than an hour. Before that, you can do the following yourself: backup, log reading, raising the memory limit and regenerating .htaccess — that covers most cases. Ongoing technical help packages: PrestaShop technical help.

Frequently asked questions

Where do I find the details of a PrestaShop 500 error?

In the server (nginx/apache) and PHP (error_log) logs and in var/logs/. A 500 error always leaves an entry — look for the last PHP Fatal error before the failure. The full message with file and line is also shown by debug mode on a store copy.

A 500 error on only one store page — what does that mean?

• Good news: an error on a single page (e.g. only the cart) narrows the cause down to a module hooked to that feature. Disable modules related to that page one by one — the last one disabled before the error disappears is the culprit.

Can hosting cause a 500 error?

Yes — the PHP memory limit, disabled extensions (e.g. intl, zip) or overly strict mod_security rules can cause 500s across the store. If the hosting logs show WAF blocks, ask for the rule to be disabled for the admin panel.

500 error after an update — what is the first thing to do?

Check var/logs/ and disable the most recently updated module. If the error appeared after a core update, follow post-update problems — it covers restoring a backup and staging tests.

Sources and tools

• PrestaShop DevDocs — troubleshooting
• PrestaShop — the HTTP 500 error article
• PHP — error handling and logging
• nginx — documentation

👉 Store returning a 500 error? Send the logs or access via a secure channel — contact form or kontakt@informatix.com.pl. See also the full failure overview: PrestaShop help.

📖 See also: PrestaShop white screen, debug mode and module conflicts.