A 500 error in PrestaShop means the server was unable to handle the request properly. The message itself doesn’t point to the cause. Before changing any settings, note the URL and the time the problem occurred, secure the current state of the store and check the logs. Only a specific log entry will let you tell a module failure apart from a problem with PHP, the database or the server configuration.
Before you change anything
Establish the scope of the failure. Does no page open at all, only the admin panel, or a specific checkout step? Check one example without logging in and another on a test account. Note the product used, the delivery method and the action that preceded the error. If the problem concerns payments, don’t repeat purchases blindly: first check whether the provider has already taken the money.
Write down recent changes. A module update, a PHP switch, a theme deployment, a product import and a change of hosting settings are all different leads. The time of the report doesn’t have to be the time the failure started. Compare it with the last successful orders and the logs, so you don’t blame the problem on a change made after it had already appeared.
Before intervening, make a backup of the database and files or ask your host to secure the current state. Don’t overwrite the last working backup. The database from the time of the failure may contain orders and payments that aren’t in yesterday’s backup. If disk space is short, creating a large archive on the same server may make things worse. In that case agree another way of making the backup with the administrator.
Where to look for logs
You may need the web server, PHP and application logs. On shared hosting, start with the logs section of the control panel. If you don’t have access to them, give support the exact URL, the time including the time zone and a description of what you did. A request saying “the store doesn’t work” leaves far more room for guesswork.
On a VPS the location depends on the Apache or nginx configuration, PHP-FPM and how the store is run. In a container environment some logs may go to the process output rather than a separate file. In a PrestaShop installation, also check the application log directory, usually within var/logs, depending on the version and configuration. No entry in one place doesn’t mean there was no error.
Look for the event that matches the time of the attempt. Read the first relevant exception and its surroundings, not just the last line. A missing class message may result from an incomplete deployment, and a database connection error from the database being unavailable. Keep the original excerpt for analysis. Before sharing it outside the authorised team, remove passwords, tokens and customer data.
Debug mode: how to use it
If the admin panel works, debug mode can be enabled in the performance settings under advanced parameters. Without access to the panel, the PrestaShop documentation describes changing the _PS_MODE_DEV_ constant in config/defines.inc.php. Change the existing definition instead of adding a second one. The configuration is described in the official debugging guide.
Do this on a secured copy or in an environment with restricted access. A detailed message can reveal paths, queries and configuration details. Debug mode isn’t a fix: it helps you see the cause. Once you have recorded the data you need, turn it off and check how the store behaves in normal mode.
If the error occurs before PHP or the application starts, PrestaShop’s debug mode won’t show anything. In that case you need to go back to the server logs and the hosting configuration. Don’t keep piling up changes just because you still see the same generic message on screen.
How to tell common causes apart
PHP out of memory
A message containing Allowed memory size exhausted indicates that the process exceeded its memory limit. Find out which action caused it. Importing a large file and an infinite loop in a module need different solutions. Raising the limit may be justified, but only after checking usage and the server’s available resources.
Incompatible PHP version or extension
If the failure started after an environment change, compare the PHP version with the requirements of the exact release of the store and its modules. A syntax error, a missing function or an incompatible method declaration are clues for further analysis. Restoring the previous configuration can help isolate the change, but ultimately you need a supported and compatible combination of software.
A module, an override or an incomplete deployment
A path to an extension in the stack trace shows where the error occurred, but not always its source. Check that the files and dependencies are complete and what changed last. When the message concerns an overridden method, look at the overrides. Simply copying a missing file from a random version can introduce another incompatibility.
Cache and permissions
An error writing or creating a file may result from the wrong directory owner after a deployment. Check the PHP process user and the required permissions. Don’t set 777 across the whole store. If stale cache files are the cause, rebuild them according to the procedure for your version, after keeping the logs needed for the diagnosis.
No disk space or an unavailable database
Check disk space and the file count limit. A full disk can prevent writing sessions, cache and logs, so the absence of a new message can itself be a symptom. For database connection errors, verify its availability and connection limits. Don’t run table repairs or change login credentials without confirming the cause.
When the error appeared after an update
Stop further deployments and compare the state before the change with the current one. Check the package version, whether the files are complete and whether the update changed the database. Rolling back only the code may not be enough if the new version transformed the data. The rollback plan has to cover both.
If the logs point to one module, disable it in a controlled way and repeat exactly the same test. In versions that provide the relevant command, you can use the PrestaShop console; check the syntax in the help of the installed release. If the application cannot start, the console may not work either. Then you need to analyse the files, dependencies and module registration.
Renaming a module’s directory isn’t a universal equivalent of disabling it. It can leave references to classes and configuration behind. Don’t delete the module’s tables either: they may store data needed to settle orders. After the fix, check not only the page that returned the error but also a purchase, payment confirmation and handing the order over for fulfilment.
When to stop trying on your own
Hand the diagnosis over to a technical person when the problem concerns order data, a suspected breach, database corruption or an update you can’t safely roll back. Do the same if you have no working backup and each further step changes the production state. More random fixes make it harder to establish the cause later.
Prepare a short report: store and PHP versions, the scope of the failure, when it occurred, recent changes, an example URL and a log excerpt. Add what has already been done, even if it didn’t help. Share access through a secure channel, using a separate account with the scope needed for the work.
Once the cause is removed, write a short note: what stopped working, which message confirmed the diagnosis, what was changed and how the fix was checked. Include whether orders from the time of the failure need handling. Such a record will help with the next report and let you see whether the problem comes back. If the failure revealed missing monitoring of a particular payment or integration, add the appropriate check to the maintenance procedure.
Frequently asked questions
Does a 500 error mean data loss?
No. It tells you a request wasn’t handled successfully, not what state all the data is in. The operation may, however, have partly completed, so before retrying a payment or an import you need to check the result on both sides of the integration.
How do I disable a module without access to the admin panel?
If your version provides a working console command, use it after checking the help. When starting the application ends in an error, what to do depends on the cause. Don’t use a random SQL query found for a different release.
Why does the store work but the admin panel doesn’t?
The admin panel and the customer-facing part run different pieces of code. The failure may concern an admin module, a specific view or permissions. Check the logs for the attempt to open the panel separately.
Can I restore a backup myself?
Yes, if you know the procedure and which data will be replaced. First secure the current state and any orders created after the backup date. The files, the database and any environment changes must match each other.
The most useful first step is to find the specific error in the log and link it to an action in the store. If you need support with the diagnosis, use troubleshooting help and include the information you have prepared.