How do I enable debug mode in PrestaShop?

Question published 2707 views

PrestaShop debug mode shows PHP errors and detailed exception output, which is useful while diagnosing a problem but unsafe to leave enabled on a live shop. It can expose paths, configuration details, SQL errors, and customer-facing stack traces.

Advanced Parameters > Performance showing the Debug mode toggle
Advanced Parameters > Performance, the Debug mode toggle and Disable all overrides.

From the back office, the normal path is Advanced Parameters > Performance > Debug mode. On the filesystem, the same setting is controlled by _PS_MODE_DEV_ in config/defines.inc.php:

// config/defines.inc.php
define('_PS_MODE_DEV_', true);

// switch back after debugging
define('_PS_MODE_DEV_', false);

If you must debug production briefly, enable it for the shortest possible time, reproduce the issue, save the error details, and turn it off again. A safer developer-only pattern is to gate debug mode behind a private condition, for example a temporary cookie check:

define('_PS_MODE_DEV_', isset($_COOKIE['debug']) && $_COOKIE['debug'] === 'secret');

After changing debug mode, clear PrestaShop cache if the behavior does not change immediately. Also check server logs, because fatal errors may be logged there even when the browser only shows a generic 500 page.

If you use MPR Performance Revolution, there is a safer production pattern than editing the core define directly: Employee Debug Mode writes a small bootstrap file and sets a short-lived MPRPSDEV cookie for logged-in back-office employees, so regular visitors stay in production mode. The cookie is HTTP-only, secure when HTTPS is in use, same-site Lax, and expires after four hours of inactivity. That is still debugging on a live shop, so use it narrowly, but it is less risky than showing stack traces to every visitor.

Never leave _PS_MODE_DEV_ enabled after the incident is reproduced. Capture the exception message, stack trace and the request URL, then disable debug mode and work from logs. If the error appears only during checkout or payment callbacks, prefer server logs and module logs over exposing debug output on public payment return URLs.

Was this answer helpful?

Still have questions?

Can't find what you're looking for? Send us your question and we'll get back to you.

Loading...
Back to top