How to enable debug mode on PrestaShop
Debug mode replaces PrestaShop's blank page or generic message with the exact technical detail of the error: file, line, class at fault. It's the first thing to enable when facing a problem that doesn't explain itself.
Enabling then disabling debug mode
-
Connect via FTP, SFTP or SSH
The file to edit isn't reachable from the back office or the admin: you need access to the server's files.
-
Open config/defines.inc.php
This file sits at the root of the config/ folder in the PrestaShop installation, regardless of version 1.6, 1.7, 8 or 9.
-
Edit the _PS_MODE_DEV_ constant
Find the line define('_PS_MODE_DEV_', false); and replace false with true, then save the file.
-
Reload the page in question
On PrestaShop 1.7 and later, a Symfony debug bar appears at the bottom of the page with the SQL queries executed, the load time, and the full error stack if an exception was thrown.
-
Read the message and trace it back to the cause
The message shows the file, the line, and often the class or module at fault. That's the text to search for or pass along for a precise diagnosis.
-
Set the constant back to false
Once the cause is identified and fixed, set _PS_MODE_DEV_ back to false immediately. Leaving it on exposes technical details, and sometimes data, to any visitor.
define('_PS_MODE_DEV_', true);What debug mode actually changes
Without debug mode, PrestaShop intercepts PHP and Smarty errors and shows a generic page or a blank screen instead, so nothing sensitive is exposed to a visitor. That's a useful safeguard in production, but it also prevents seeing what actually happened.
With debug mode enabled, the behaviour differs by version. On PrestaShop 1.6, standard PHP errors and Smarty compilation errors display directly on the page. On PrestaShop 1.7, 8 and 9, which run on the Symfony framework, dev mode also enables the Symfony debug bar (Symfony profiler) at the bottom of every page: it lists the SQL queries executed, their execution time, memory consumed, and, in the event of an exception, the full call stack with the exact file and line.
Debug mode also affects caching behaviour: in development, PrestaShop recompiles Smarty templates and reloads the configuration on every request rather than serving a compiled version. That's slower, which is another reason never to leave it on permanently.
Common mistakes
- Forgetting to set _PS_MODE_DEV_ back to false after diagnosing: the site then exposes technical information, and sometimes configuration data, to every visitor.
- Trying to edit the file through the back office's built-in code editor when the back office itself is unreachable: in that case, only direct file access works.
- Confusing PrestaShop's debug mode with the server's PHP debug mode (display_errors): both are useful but show different things and are set in different places.
- Enabling debug mode on a store whose SSL certificate is still showing warnings: the revealed technical page could then be visible in plain text on an unsecured network.
Frequently asked questions
Can debug mode break anything on the store?
I don't have FTP access, what should I do?
Debug mode is enabled but the screen is still blank, why?
Should debug mode be enabled site-wide or just on one page?
The error message shown contains sensitive information, is that a problem?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.