Why Debug Mode Matters

By default, PrestaShop hides most errors to avoid scaring customers or exposing sensitive details. That’s good for shoppers, but frustrating when you’re troubleshooting.

• See the actual error message instead of a blank page.
• Identify whether the issue comes from a module, theme, or PrestaShop itself.
• Collect the information needed for developers, agencies, or the community.

Enable Debug Mode via Back Office

1. Log in to your PrestaShop Back Office.
2. Go to Advanced Parameters → Performance.
3. Find the Debug Mode section.
4. Set Debug Mode = YES and save.
5. Reload the failing page — the detailed error should now appear.

Enable Debug Mode via File Editing

If the error blocks Back Office access, enable debug mode manually:

1. Open your shop’s files via your hosting File Manager or FTP/SFTP.
2. Edit config/defines.inc.php.
3. Find this line and switch false to true:

define('_PS_MODE_DEV_', true);

Save the file and reload the failing page to display the error details.

Reproduce the Problem (with examples)

Once debug mode is enabled, repeat the steps that caused the issue so PrestaShop shows the error during the failing process.

• Open a category page that shows “No products found.”
• Click Checkout and observe if a blank page appears.
• Try to install or enable a module and note any errors.
• Save a product with combinations and watch for a red warning banner.
• Re-run a CSV import that previously stopped without an explanation.

Begin Debugging (with examples)

• Search engines: paste the exact error (include “PrestaShop”).
• PrestaShop Forum: community Q&A and fixes.
• GitHub Issues: check if it’s a known bug or regression.
• Module/Theme docs: review vendor documentation if implicated.

Examples of typical errors:

• “Class not found: ModuleFrontController” → missing/outdated file.
• “Unknown column in ps_product” → database schema issue from a failed upgrade.
• “Failed opening required Smarty template” → missing/renamed theme file.
• “500 Internal Server Error” (with stack trace) → coding error in a module/override.

Tip: When sharing errors publicly, redact sensitive paths, usernames, or database details.

Reviewing Error Logs

Debug mode won’t catch everything—server-level issues often appear only in logs.

• cPanel: Metrics → Errors (last 300). Also check error_log in your shop root.
• Plesk: Domain → Logs tab. Filter for PHP/Apache errors.
• File system: error_log, php_error.log, or /var/log/ on Linux servers.
• Custom host paths: e.g., /logs/yourdomain/ or provider dashboards.

Common entries:

• PHP Fatal error: Allowed memory size exhausted → increase PHP memory limit.
• Permission denied → ownership/CHMOD issue.
• File not found → missing module/theme asset or bad path.

Use Browser Developer Tools (Chrome, Edge, Firefox, Safari)

1. Open DevTools — Chrome/Edge: F12 or Ctrl+Shift+I (Cmd+Opt+I on Mac); Firefox: F12; Safari: enable “Developer Menu,” then Cmd+Opt+C.
2. Console tab: look for red errors (JS, CORS, mixed content). Examples:
   • “Uncaught ReferenceError: $ is not defined” → missing jQuery or script order conflict.
   • “Mixed Content: requested an insecure resource” → HTTP assets on an HTTPS page.
3. Network tab: reload and check failed requests.
   • 404 → missing theme/module asset.
   • 500 → server error (correlate with logs).
   • Very slow requests → potential checkout/cart latency.
4. Reproduce while watching: add to cart, change language/currency, step through checkout. Note any failing request or script.

Turn Debug Mode Off

Never leave debug mode on in production—it exposes internal details.

• Back Office: set Debug Mode = NO.
• File method: revert to define('_PS_MODE_DEV_', false);

Quick-Copy Snippet

define('_PS_MODE_DEV_', true);