PrestaShop 500 error: show the real error and restore the store
A 500 error on PrestaShop means the server stopped PHP execution before producing the page. The store, the back office or a single page (cart, payment, product sheet) becomes unreachable and, because the message is generic, the real cause has to be found in debug mode or in the logs.
On PrestaShop, this error most often occurs after installing or updating a module, a core update, a PHP version change or a server migration. It can also come from wrong permissions, a corrupted cache or a faulty .htaccess file.
This page explains how to display the exact message, what the most frequent causes are depending on the version (1.6, 1.7, 8), how to fix them and when it is better to bring in a professional to limit lost sales.
Typical symptoms
- White page or "HTTP ERROR 500" across the whole store or only on the back office.
- Message "Oops! Something went wrong. Try to refresh this page" with no further detail, or a Symfony error page on PrestaShop 1.7 and 8.
- The error appears right after installing, updating or configuring a module.
- The error appears after a PHP version change at the host or a server migration.
- Only one specific step fails: cart validation, carrier selection, payment, or one back-office page.
- The var/logs folder (1.7, 8) or app/logs contains new error entries, or the server error_log is growing.
Possible causes
Incompatible or faulty module
A module written for another PrestaShop or PHP version, an override conflicting with another, or a badly uninstalled module leaving orphaned hooks.
Incompatible PHP version
Each PrestaShop version supports a specific range of PHP versions. PrestaShop 1.6 does not work properly beyond PHP 7.1; 1.7 and 8 have their own constraints. Raising PHP without checking causes fatal errors.
Incomplete core update
An interrupted upgrade (1-click upgrade module, autoupgrade) leaves files from old versions, a partial database schema or a stale cache.
File permissions and ownership
After an FTP transfer or a migration, var/cache, img or config folders not writable by PHP block the store.
Corrupted cache
A stale Smarty or Symfony cache after an update or a PHP change returns class-not-found errors.
Insufficient memory or execution time
Catalogue imports, thumbnail generation or heavy modules exceed memory_limit or max_execution_time.
.htaccess or server configuration
Wrong URL rewrites, rules added by a module, or missing Apache modules (mod_rewrite) after a migration.
Checks to perform
- 1
Enable debug mode
In config/defines.inc.php, set _PS_MODE_DEV_ to true (or enable debug mode in Advanced Parameters > Performance if the back office is reachable). The full error, with file and line, replaces the white page. Disable it as soon as the diagnosis is done.
- 2
Read the PrestaShop logs
PrestaShop 1.7 and 8 write to var/logs (dev.log, prod.log); 1.6 to the log folder. Also check Advanced Parameters > Logs in the back office.
- 3
Check the server logs
The error_log file at the root, the Apache or Nginx logs (/var/log/apache2/error.log, /var/log/nginx/error.log) and the php-fpm log contain the "PHP Fatal error" line naming the offending file.
- 4
Clear the cache
Delete the contents of var/cache/prod and var/cache/dev (1.7, 8) or cache/smarty/compile and cache/smarty/cache (1.6). A stale cache is a frequent cause after an update.
- 5
Check the PHP version
Compare the active version (php -v or hosting panel) with the compatibility of your PrestaShop version and your modules. Temporarily revert to the previous version to confirm.
- 6
Check permissions
Over SSH, ls -la on var, img, config, modules and themes: folders must belong to the PHP user and be writable where PrestaShop requires it.
- 7
Isolate the culprit module
Without back-office access, rename the folder of the last installed module in modules/ or disable it in the database (ps_module, active column) after a backup.
Solutions
Disable or fix the faulty module
Disable the module concerned, update it to a compatible version or replace it. Remove the overrides it left in the override folder if they conflict.
Align the PHP version
Pick the PHP version compatible with your PrestaShop and your modules, and plan a PrestaShop upgrade if you must move to a recent PHP version.
Finish the update properly
Restore the pre-upgrade backup and rerun the update on a copy, or manually complete the missing files and database schema.
Restore permissions and .htaccess
Fix owner and rights, then regenerate the .htaccess from Preferences > SEO & URLs or Shop Parameters > Traffic & SEO.
Raise the PHP limits
memory_limit, max_execution_time and upload_max_filesize sized for the store, in php.ini or .user.ini depending on the host.
Restore a backup
If no quick fix works and the store is losing sales, restore the last clean backup then analyse the cause on a copy.
When should you call a professional?
- The error names a core class, an override or a custom module you cannot fix.
- The error affects payment or order validation: every hour means lost sales.
- The store is stuck in the middle of an update and you do not know whether the database is consistent.
- You have no recent backup or test environment to reproduce the error.
- The problem appeared after a server migration and involves the Apache, Nginx or PHP-FPM configuration.
How Agencei can help
- 1
Diagnosis
Controlled activation of debug mode, review of PrestaShop and server logs, identification of the module, override or configuration at fault.
- 2
Getting back online
Disabling or fixing the faulty component, cache clearing, PHP or server adjustment, with a prior backup of the store.
- 3
Lasting fix
Module update or replacement, custom code fix, completion of the core update, .htaccess regeneration.
- 4
Store testing
Full journey: browsing, search, cart, carriers, payment, customer account, back office, order emails.
- 5
Prevention
Setting up a staging environment, automatic backups and a tested update procedure for modules and core.
Frequently asked questions
How do I see the exact error message on PrestaShop?
Enable _PS_MODE_DEV_ in config/defines.inc.php or debug mode in the back office. The full error appears on screen. The logs in var/logs and the server error_log contain the same information without exposing visitors.
Can I leave debug mode enabled?
No. It displays sensitive information (paths, SQL queries) and slows the store down. Disable it as soon as the diagnosis is complete.
Does the 500 error necessarily come from the last installed module?
It is the most likely suspect, but a PHP version change by the host, a stale cache or a permission changed by a backup can happen at the same time. The logs settle it.
Why does PHP 8 break my 1.6 store?
PrestaShop 1.6 uses functions and syntax removed in recent PHP versions. You either stay on a compatible PHP version or migrate to PrestaShop 8, which is usually the better option in the medium term.
How long does it take to fix a PrestaShop 500 error?
When the cause is a module or the cache, often less than an hour. An interrupted update or an override conflict can take several hours.
Related services
PrestaShop Maintenance
Tested updates, backups, monitoring and security for a PrestaShop store that stays open.
See this servicePrestaShop Agency
Custom PrestaShop modules and themes, takeover of 1.6, 1.7 and 8 stores, performance and integrations.
See this serviceBug Fixing
Reproduction, root cause and tested fix on your web, mobile, API and CMS applications.
See this serviceIT Support
Application and server support, incident handling and clear service commitments.
See this serviceTell us about your project
Describe your need in a few lines: we come back to you with a first analysis and the next steps.