Une erreur 500 PrestaShop ou une page blanche signifie presque toujours une erreur fatale PHP que la boutique cache aux visiteurs. Pour en trouver la cause, activez le mode debug (dans le back-office ou dans le fichier config/defines.inc.php), lisez les dernières lignes des logs PHP et du dossier var/logs, puis vérifiez dans l'ordre : vider var/cache, désactiver les surcharges et le module suspect, contrôler la version de PHP et la limite de mémoire. Le plus souvent, le message d'erreur désigne le fichier fautif. Voici la checklist complète.
- Que signifie une erreur 500 ou une page blanche sur PrestaShop ?
- Avant de commencer : qu'est-ce qui a changé récemment ?
- Comment activer le mode debug sur PrestaShop ?
- Où trouver les logs d'erreurs de PrestaShop ?
- Les causes les plus fréquentes de l'erreur 500 et comment les corriger
- Quand restaurer la boutique depuis une sauvegarde ?
- Checklist : corriger une erreur 500 PrestaShop en 10 minutes
- Questions fréquentes
Que signifie une erreur 500 ou une page blanche sur PrestaShop ?
Le code 500 (Internal Server Error) est le « quelque chose s'est mal passé » générique du serveur. Sur PrestaShop, c'est le plus souvent une erreur fatale PHP (Fatal error) qui interrompt la génération de la page. En production, l'affichage des erreurs est désactivé : vous obtenez une page vide ou un écran d'erreur générique.
Déclencheurs typiques : nouveau module ou thème (ou sa mise à jour), mise à jour de PrestaShop ou changement de version PHP, modification manuelle de fichiers (surcharge, template, .htaccess), disque plein, limite de mémoire ou de temps atteinte et, plus rarement, fichiers modifiés après un piratage.
Regardez où l'erreur apparaît. Si une seule page plante (fiche produit ou panier, par exemple), le coupable est souvent un module greffé sur cette page. Si la boutique et le back-office sont tous deux en panne, cherchez plus loin : surcharge, configuration PHP ou cache corrompu.
Avant de commencer : qu'est-ce qui a changé récemment ?
Qu'est-ce qui a changé juste avant la panne ? Un nouveau module, une mise à jour, un changement de PHP chez l'hébergeur, un fichier modifié par une agence ? Si vous le savez, annuler ce seul changement suffit souvent.
Avant de supprimer ou de renommer quoi que ce soit : copiez le fichier ou le dossier concerné. Ne désinstallez pas de modules et ne supprimez pas de tables pendant le diagnostic.
Comment activer le mode debug sur PrestaShop ?
Le mode debug remplace la page blanche par l'erreur réelle : message, fichier et numéro de ligne. C'est l'étape la plus importante.
Depuis le back-office
Si le back-office fonctionne, allez dans Paramètres avancés > Performances et, dans la section Mode debug, réglez Mode debug : Oui, puis enregistrez. L'option est la même dans PrestaShop 1.7, 8 et 9 et écrit en réalité le réglage dans config/defines.inc.php.
PrestaShop 9 y ajoute les champs Nom du cookie de débogage et Valeur du cookie de débogage : le mode debug n'est alors actif que dans le navigateur qui possède ce cookie.
Depuis le fichier config/defines.inc.php
Si le back-office est lui aussi en panne, ouvrez config/defines.inc.php en FTP, en SSH ou via le gestionnaire de fichiers de l'hébergeur. En haut du fichier se trouve la ligne define('_PS_MODE_DEV_', false);. Remplacez false par true, enregistrez et rechargez la page. Le fichier et la constante sont les mêmes dans PrestaShop 1.7, 8 et 9.
Aucun effet ? Cherchez un fichier config/defines_custom.inc.php : PrestaShop le charge en premier, donc son _PS_MODE_DEV_ l'emporte.
Attention : le mode debug montre le détail des erreurs à tous les visiteurs et ralentit la boutique. Désactivez-le dès que la cause est trouvée.
Où trouver les logs d'erreurs de PrestaShop ?
Si vous préférez ne pas activer le mode debug sur une boutique en ligne, lisez les logs. Cherchez, à l'heure de la panne, les lignes contenant PHP Fatal error, Uncaught ou CRITICAL.
| Log | Où le trouver | Ce qu'il contient |
|---|---|---|
| Log PrestaShop (1.7) | var/logs/prod.log (dev.log en mode debug) |
erreurs Symfony, surtout du back-office et des pages récentes |
| Log PrestaShop (8 et 9) | var/logs/prod-AAAA-MM-JJ.log, un fichier par jour |
idem |
| Log d'erreurs PHP | le chemin défini dans error_log, souvent visible dans le panneau d'hébergement |
erreurs fatales PHP, dont la limite de mémoire |
| Log du serveur web | par ex. /var/log/apache2/error.log, /var/log/nginx/error.log |
erreurs .htaccess, PHP-FPM, délais dépassés |
| Logs du back-office | Paramètres avancés > Logs | événements enregistrés par la boutique et les modules, si le back-office répond |
Avec un accès SSH, tail -n 50 /var/log/nginx/error.log affiche sans risque la fin d'un log (adaptez le chemin). Sur un hébergement mutualisé, les logs sont généralement dans le panneau de l'hébergeur. Les très anciennes versions 1.7 (avant 1.7.4) plaçaient les logs et le cache dans app/logs et app/cache au lieu de var/.
Un chemin commençant par modules/nom_du_module/, override/ ou themes/nom_du_theme/ dans le message désigne directement le coupable.
Les causes les plus fréquentes de l'erreur 500 et comment les corriger
Un cache corrompu ou obsolète
Après une mise à jour, un déménagement ou une modification de fichiers, le cache peut pointer vers des classes disparues. Si le back-office fonctionne, cliquez sur Vider le cache dans Paramètres avancés > Performances. Sinon, supprimez le contenu des dossiers var/cache/prod et var/cache/dev (en gardant les dossiers eux-mêmes). PrestaShop le reconstruit à la requête suivante. Ne supprimez rien en dehors de var/cache.
Une surcharge incompatible avec la version de PrestaShop
Les surcharges (dossier override/) remplacent des classes du cœur. Après une mise à jour, une ancienne surcharge appelle souvent une méthode disparue ou modifiée.
- Depuis le back-office : Paramètres avancés > Performances > Mode debug > Désactiver toutes les surcharges : Oui.
- PrestaShop 1.7 propose aussi, dans cette section, une option pour désactiver temporairement les modules non PrestaShop. Elle n'existe plus dans PrestaShop 8 et 9.
- Sans back-office : renommez le fichier cité dans l'erreur (par exemple
override/classes/Cart.phpenCart.php.off), puis supprimezclass_index.phpdevar/cache/prod(etvar/cache/dev) pour que PrestaShop reconstruise sa carte des classes.
Un module qui a planté
Si l'erreur désigne un module, désactivez-le dans Modules > Gestionnaire de modules. Si le back-office est inaccessible, renommez le dossier du module, par exemple modules/un_module en modules/un_module_off : PrestaShop l'ignorera. Remettez le nom d'origine une fois le module corrigé.
Ne désinstallez pas le module dans la précipitation : la désinstallation peut effacer ses données et ses réglages. S'il a installé ses propres surcharges, désactivez-les comme indiqué ci-dessus.
La version de PHP ne correspond pas à PrestaShop
Un changement de version PHP par l'hébergeur ou un déménagement de serveur est une cause très fréquente. PrestaShop 1.7 ne prend officiellement en charge PHP que jusqu'à la version 7.4, tandis que PrestaShop 9 exige au minimum PHP 8.1. Comparez les prérequis de votre version (documentation officielle) avec le PHP choisi chez l'hébergeur. Si le back-office répond, Paramètres avancés > Informations affiche la version de PHP et la limite de mémoire.
Si votre version de PrestaShop ne prend pas en charge le PHP actuel, revenez au PHP précédent et planifiez une mise à jour ; notre guide pour mettre à jour PrestaShop étape par étape explique comment le faire sans perdre de données. Un vieux module peut aussi planter sous un PHP récent, même si le cœur est compatible.
Mémoire ou temps d'exécution épuisés
Allowed memory size of ... bytes exhausted signifie que la limite memory_limit est atteinte. On attribue généralement au moins 256M à PrestaShop ; modifiez-la dans le panneau d'hébergement ou la configuration PHP. Si l'erreur n'apparaît que pendant un import, une régénération des miniatures ou un gros export, c'est peut-être max_execution_time qui bloque. Mais si une simple page catégorie consomme des centaines de mégaoctets, augmenter la limite ne fait que masquer un problème de code.
.htaccess, permissions et espace disque
Sous Apache, une directive erronée dans .htaccess renvoie une erreur 500 avant même le démarrage de PHP ; seul le log du serveur web en donne la raison. Régénérez le fichier en enregistrant Paramètres de la boutique > Trafic et SEO > SEO et URL (copiez d'abord l'ancien fichier). Vérifiez aussi que le disque n'est pas plein et que var/ est accessible en écriture.
Des fichiers que personne n'a ajoutés ou du code que personne n'a modifié peuvent signaler un piratage : voir notre article sur la sécurité de PrestaShop.
Quand restaurer la boutique depuis une sauvegarde ?
Restaurer une sauvegarde a du sens lorsque :
- la boutique est tombée après une mise à jour et vous ne pouvez pas déboguer en pleine activité,
- trop de choses ont changé pour identifier le coupable,
- des fichiers ou la base ont été endommagés ou modifiés par un tiers.
Restaurez toujours fichiers et base du même moment ; les mélanger provoque de nouvelles erreurs. Les commandes passées après la sauvegarde devront être ressaisies. Faites une sauvegarde avant chaque mise à jour et vérifiez quelles sauvegardes votre hébergeur conserve et comment les restaurer.
Checklist : corriger une erreur 500 PrestaShop en 10 minutes
- Identifiez ce qui a changé juste avant la panne, et si toute la boutique ou une seule page est touchée.
- Activez le mode debug (back-office ou
_PS_MODE_DEV_dansconfig/defines.inc.php) et rechargez la page. - Lisez les dernières entrées de
var/logs, du log PHP et du log du serveur web. - Videz le cache : bouton du back-office ou contenu de
var/cache/prodetvar/cache/dev. - Désactivez les surcharges ; sans back-office, renommez le fichier et supprimez
class_index.php. - Désactivez le module cité dans l'erreur ; sans back-office, renommez son dossier.
- Contrôlez la version de PHP et
memory_limitdans le panneau d'hébergement. - Vérifiez
.htaccess, l'espace disque libre et les droits d'écriture survar/. - Si rien n'y fait, restaurez fichiers et base depuis la même sauvegarde.
- Désactivez le mode debug et testez un achat complet, du panier au paiement.
Pas à l'aise avec les fichiers du serveur, ou besoin d'un retour en ligne rapide ? Confiez le diagnostic à notre service de développement PrestaShop.
Questions fréquentes
Pourquoi ma boutique PrestaShop affiche-t-elle une page blanche sans message d'erreur ?
Parce que l'affichage des erreurs est désactivé en production. PHP s'arrête sur une erreur fatale et le navigateur reçoit une réponse vide ou un code 500. Activez le mode debug ou lisez le log PHP pour voir l'erreur réelle.
Peut-on laisser le mode debug activé ?
Non. Le mode debug ralentit la boutique et montre aux visiteurs des détails techniques qui facilitent les attaques. Activez-le uniquement pendant le diagnostic et, sous PrestaShop 9, pensez à le limiter avec le cookie de débogage.
Supprimer var/cache est-il sans risque ?
Supprimer le contenu de var/cache/prod et var/cache/dev est sans risque : PrestaShop reconstruit le cache tout seul, le premier chargement est simplement plus lent. Ne supprimez pas les autres dossiers de var/.
L'erreur 500 n'apparaît que dans le back-office. Que faire ?
Consultez var/logs : une grande partie du back-office repose sur Symfony et y enregistre ses erreurs. Les causes fréquentes sont un cache obsolète après une mise à jour, un module qui ajoute son propre onglet au back-office et une limite de mémoire trop basse.
Toujours une erreur 500 ? Contactez-nous en joignant le message d'erreur du log.
Produits de cet article
