{"id":627,"date":"2023-06-21T18:34:01","date_gmt":"2023-06-21T15:34:01","guid":{"rendered":"https:\/\/presta.site\/blog\/?p=627"},"modified":"2026-07-26T09:33:43","modified_gmt":"2026-07-26T06:33:43","slug":"white-screen-of-death-in-prestashop-a-step-by-step-guide","status":"publish","type":"post","link":"https:\/\/presta.site\/blog\/en\/white-screen-of-death-in-prestashop-a-step-by-step-guide\/","title":{"rendered":"PrestaShop White Screen of Death: Step-by-Step Fix Guide"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">A <strong>PrestaShop white screen of death<\/strong> is a blank page with no message &#8211; front office, Back Office, or both. It usually means PHP stopped before the shop could render HTML. This guide shows how to turn on debug mode (even when the admin is down), read the real error, and work through the fixes that clear most WSoD cases.<\/p>\n\n\n<!--more-->\n\n\n<p class=\"wp-block-paragraph\">From PrestaShop 1.7 onward (including 8 and 9), debug toggles live under <strong>Advanced Parameters \u2192 Performance<\/strong> when the Back Office still loads. If admin is blank too, you flip <code class=\"codecolorer text default\"><span class=\"text\">_PS_MODE_DEV_<\/span><\/code> in <code class=\"codecolorer text default\"><span class=\"text\">config\/defines.inc.php<\/span><\/code> over SFTP or SSH. Official screen notes are in the <a href=\"https:\/\/docs.prestashop-project.org\/v.9-documentation\/user-guide\/configuring-shop\/advanced-parameters\/performance\" target=\"_blank\" rel=\"noopener noreferrer\">PrestaShop 9 Performance documentation<\/a>. Take a <a href=\"https:\/\/presta.site\/blog\/en\/how-to-create-a-backup-in-prestashop\/\">full PrestaShop backup<\/a> before you delete modules or restore files.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What a PrestaShop white screen of death usually means<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The blank page is a symptom, not a single bug. A PrestaShop white screen of death means PHP hit a fatal error, ran out of memory, or failed before Smarty could print anything. Production mode hides that detail on purpose &#8211; so shoppers never see a stack trace. Your job is to make the error visible, then fix the cause.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Note where it fails:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Front only &#8211; often a theme override, module hook, or cache artifact on the storefront<\/li>\n<li>Back Office only &#8211; often an admin module, tab, or override under <code class=\"codecolorer text default\"><span class=\"text\">override\/<\/span><\/code><\/li>\n<li>Both &#8211; wrong DB credentials, broken <code class=\"codecolorer text default\"><span class=\"text\">defines.inc.php<\/span><\/code>, PHP version crash, or a fatal that runs on every request<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Step 1: Enable debug mode<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Debug mode prints the exception (or points you at the log) instead of a white page. Prefer the Back Office when it still opens.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"484\" src=\"https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_1-1024x484.png\" alt=\"PrestaShop Performance page with Debug Mode enabled for white screen of death troubleshooting\" class=\"wp-image-630\" srcset=\"https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_1-1024x484.png 1024w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_1-300x142.png 300w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_1-768x363.png 768w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_1-1536x726.png 1536w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_1.png 1611w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Log into the Back Office.<\/li>\n<li>Go to <strong>Advanced Parameters \u2192 Performance<\/strong>.<\/li>\n<li>In the <strong>Debug mode<\/strong> block, set <strong>Debug mode<\/strong> to <strong>Yes<\/strong>.<\/li>\n<li>Click <strong>Save<\/strong>.<\/li>\n<li>Reload the blank URL in a private window.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">If the Back Office is also a PrestaShop white screen of death, edit the file on disk. Download a copy of <code class=\"codecolorer text default\"><span class=\"text\">config\/defines.inc.php<\/span><\/code> first (even if you already took a full shop backup) so you can put the original back in one click if the edit goes wrong:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <code class=\"codecolorer text default\"><span class=\"text\">config\/defines.inc.php<\/span><\/code> via SFTP, SSH, or the host file manager and save a local copy.<\/li>\n<li>Find <code class=\"codecolorer text default\"><span class=\"text\">define('_PS_MODE_DEV_', false);<\/span><\/code> (wording may vary slightly by version).<\/li>\n<li>Change it to <code class=\"codecolorer text default\"><span class=\"text\">define('_PS_MODE_DEV_', true);<\/span><\/code> and save.<\/li>\n<li>Reload the failing page.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Turn debug off again when you are done. Leaving it on in production exposes paths and stack traces to anyone who hits an error.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 2: Identify the error<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">With debug on, the PrestaShop white screen of death usually becomes a readable exception. Note the class name, module name, file path under <code class=\"codecolorer text default\"><span class=\"text\">modules\/<\/span><\/code>, <code class=\"codecolorer text default\"><span class=\"text\">themes\/<\/span><\/code>, or <code class=\"codecolorer text default\"><span class=\"text\">override\/<\/span><\/code>, and the line number. That string is usually enough to pick the right fix below.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"469\" src=\"https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_2-1024x469.png\" alt=\"Example PHP error shown after enabling PrestaShop debug mode on a white screen\" class=\"wp-image-633\" srcset=\"https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_2-1024x469.png 1024w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_2-300x137.png 300w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_2-768x352.png 768w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_2.png 1264w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">If the page stays blank even with <code class=\"codecolorer text default\"><span class=\"text\">_PS_MODE_DEV_<\/span><\/code> true, check the host PHP error log (cPanel, Plesk, or <code class=\"codecolorer text default\"><span class=\"text\">var\/logs\/<\/span><\/code> on some setups). A parse error in a config file can die before PrestaShop\u2019s debug layer runs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Common sources:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Recent customizations<\/strong> &#8211; theme edits, overrides, or copied snippets<\/li>\n<li><strong>Modules<\/strong> &#8211; especially a module installed or updated just before the crash<\/li>\n<li><strong>Hosting changes<\/strong> &#8211; PHP version bump, missing extension, lower memory limit<\/li>\n<li><strong>Database credentials<\/strong> &#8211; wrong values in <code class=\"codecolorer text default\"><span class=\"text\">app\/config\/parameters.php<\/span><\/code> after a migrate<\/li>\n<li><strong>File permissions<\/strong> &#8211; PHP cannot read a required file or write cache<\/li>\n<li><strong>Memory limit<\/strong> &#8211; fatals that mention memory exhausted<\/li>\n<li><strong>Stale cache<\/strong> &#8211; broken compiled templates after an update<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Step 3: Fix the error<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"450\" src=\"https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_3-1024x450.png\" alt=\"PrestaShop Performance options used to isolate modules and overrides after a white screen of death\" class=\"wp-image-636\" srcset=\"https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_3-1024x450.png 1024w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_3-300x132.png 300w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_3-768x338.png 768w, https:\/\/presta.site\/blog\/wp-content\/uploads\/2023\/05\/Screenshot_3.png 1155w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Match the debug output to one path. Change one thing at a time, then reload.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Customizations and overrides<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Undo the last theme or override change if you know it. On Performance, try <strong>Disable all overrides<\/strong> \u2192 <strong>Yes<\/strong>, save, and retest. If the shop returns, the bug is in <code class=\"codecolorer text default\"><span class=\"text\">override\/<\/span><\/code> or a module override &#8211; fix or remove that file rather than leaving overrides disabled forever.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Module bugs<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">On Performance, set <strong>Disable non PrestaShop modules<\/strong> \u2192 <strong>Yes<\/strong> and retest. If that clears the PrestaShop white screen of death, rename the suspect module folder under <code class=\"codecolorer text default\"><span class=\"text\">modules\/<\/span><\/code> (or uninstall from BO once admin works) one at a time until you find the culprit. Prefer renaming over deleting so you can restore files after you identify it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hosting and PHP<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Compare <strong>Advanced Parameters \u2192 Information<\/strong> with what the host says they run. After a PHP upgrade, missing extensions or stricter error handling often surface as a blank page. Ask the host which PHP version and <code class=\"codecolorer text default\"><span class=\"text\">memory_limit<\/span><\/code> the vhost actually uses.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Database connection<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If debug mentions database access or the shop died right after a server move, verify host, name, user, and password in <code class=\"codecolorer text default\"><span class=\"text\">app\/config\/parameters.php<\/span><\/code>. Full steps are in our guide to <a href=\"https:\/\/presta.site\/blog\/en\/how-to-change-database-connection-settings-in-prestashop\/\">changing PrestaShop database connection settings<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions and memory<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When the error names a file PHP cannot open, fix ownership\/permissions for that path (typical web-user ownership; avoid <code class=\"codecolorer text default\"><span class=\"text\">777<\/span><\/code> as a permanent fix). For memory exhausted errors, raise <code class=\"codecolorer text default\"><span class=\"text\">memory_limit<\/span><\/code> in the vhost <code class=\"codecolorer text default\"><span class=\"text\">php.ini<\/span><\/code> or ask the host &#8211; then clear cache and retest.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cache<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">From Performance, click <strong>Clear cache<\/strong>. If BO is down, delete the contents of <code class=\"codecolorer text default\"><span class=\"text\">var\/cache\/prod\/<\/span><\/code> (and <code class=\"codecolorer text default\"><span class=\"text\">var\/cache\/dev\/<\/span><\/code> if present) via file manager or SSH, keeping the folders themselves. Huge cache trees are often easier to empty from SSH than from FTP.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 4: When you still need help<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If debug is on, modules\/overrides are isolated, credentials match, and you still have a PrestaShop white screen of death, gather: exact error text, PrestaShop version, PHP version, and what changed last (module, deploy, host upgrade). Post that on the PrestaShop forums, or send it to your host or a developer who can read server logs you cannot see from the shop alone.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 5: Restore from backup<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Restoring files or a DB dump is a last resort &#8211; you lose changes made after that backup. Use it when a bad deploy cannot be rolled back quickly and you already have a recent copy. How to take and keep those copies is covered in the <a href=\"https:\/\/presta.site\/blog\/en\/how-to-create-a-backup-in-prestashop\/\">PrestaShop backup guide<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Quick checklist<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Enable debug (BO Performance, or <code class=\"codecolorer text default\"><span class=\"text\">_PS_MODE_DEV_<\/span><\/code> in <code class=\"codecolorer text default\"><span class=\"text\">defines.inc.php<\/span><\/code>).<\/li>\n<li>Read the on-screen error or the PHP log.<\/li>\n<li>Isolate overrides and non-native modules from Performance.<\/li>\n<li>Fix DB credentials, permissions, memory, or cache as the message indicates.<\/li>\n<li>Turn debug off; restore from backup only if nothing else recovers the shop.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Most PrestaShop white screen of death cases clear once the real PHP message is visible. Start with debug mode, change one variable at a time, and keep a backup path ready before you delete anything you cannot put back.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Fix a PrestaShop white screen of death step by step: enable debug mode, read the PHP error, isolate modules, and recover the shop.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-627","post","type-post","status-publish","format-standard","hentry","category-development"],"_links":{"self":[{"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/posts\/627","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/comments?post=627"}],"version-history":[{"count":12,"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/posts\/627\/revisions"}],"predecessor-version":[{"id":2022,"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/posts\/627\/revisions\/2022"}],"wp:attachment":[{"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/media?parent=627"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/categories?post=627"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/presta.site\/blog\/wp-json\/wp\/v2\/tags?post=627"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}