MODE_DEV

Niveau intermédiaire

Activer le mode debug PrestaShop 8 et comprendre ce qu'il affiche

PrestaShop masque ses erreurs et affiche une page blanche. Activer le mode développeur, y compris sans back-office, et où lire les journaux.

Une boutique qui ne s'affiche plus coûte de l'argent à la minute. Avant toute chose, il faut voir l'erreur, et PrestaShop la cache par défaut. C'est un bon réglage en production, et le premier à changer en dépannage.

Par le back-office, si vous y avez encore accès

Paramètres avancés puis Performances, section Mode debug, activez Mode debug. La boutique affiche alors les erreurs complètes.

Deux réglages voisins comptent autant : désactivez le cache Smarty et forcez la recompilation des templates. Sans cela, vous corrigerez un fichier sans voir le moindre changement, et vous conclurez à tort que la correction n'a rien donné.

Sans back-office, ce qui est le cas fréquent

Le mode debug se pose dans un fichier. Ouvrez config/defines.inc.php en FTP :

define('_PS_MODE_DEV_', true);

La constante est à false en production. Passez-la à true, rechargez la boutique, l'erreur apparaît.

C'est la manœuvre à retenir : elle marche quand le back-office lui-même renvoie une page blanche, ce qui est la situation la plus courante après l'installation d'un module.

Ce que le laboratoire a montré, et qui surprend

En provoquant la panne en conteneur, la boutique n'a pas répondu deux fois pareil selon la page demandée : tantôt une page vide, tantôt une redirection, tantôt l'écran d'erreur détaillé. C'est déroutant, et c'est normal : PrestaShop tente de se rabattre sur un comportement de secours qui dépend du contrôleur atteint.

Le serveur, lui, a dit la même chose à chaque fois :

PHP Fatal error: Uncaught Error: Class "ClasseDisparueAvecLeModule"
not found in /var/www/html/override/classes/Product.php

Ne vous fiez donc pas à ce que montre le navigateur pour juger de la gravité. Une page qui se recharge sans erreur visible peut cacher exactement la même panne qu'une page blanche. Le journal du serveur est la seule source qui ne varie pas.

Jamais laissé en place. _PS_MODE_DEV_ à true expose les chemins, les requêtes SQL et la structure de la boutique. Sur un site marchand, c'est aussi une infraction aux règles de sécurité des paiements. Activez, diagnostiquez, désactivez.

Où sont les journaux

Depuis PrestaShop 1.7, la boutique repose sur Symfony et journalise dans var/logs/ :

• var/logs/prod.log en fonctionnement normal ;
• var/logs/dev.log quand le mode debug est actif.

Le back-office propose en plus Paramètres avancés puis Journaux, qui liste les événements applicatifs : erreurs de paiement, échecs de commande, problèmes de transporteur. C'est un autre journal, complémentaire, et souvent plus parlant pour une panne fonctionnelle.

Le cache, qui trompe tout le monde

PrestaShop garde trois caches distincts, et c'est ce qui rend son dépannage déroutant :

Le troisième est le piège. PrestaShop y mémorise quelle classe utiliser pour chaque objet, surcharges comprises. Un module qui installe une surcharge modifie cet index. S'il est désinstallé sans nettoyage, l'index pointe vers un fichier disparu, et la boutique tombe en page blanche.

Vider le cache :

php bin/console cache:clear --env=prod

Ou, si la ligne de commande n'est pas disponible, supprimez le contenu de var/cache/ en FTP. PrestaShop le reconstruit tout seul à la visite suivante.

Lire une erreur PrestaShop

Le chemin du fichier fautif dit presque tout :

• modules/nomdumodule/ : le module est le coupable, et son nom est écrit.
• override/ : une surcharge, souvent laissée par un module mal désinstallé. C'est la cause la plus fréquente des pannes après désinstallation.
• classes/ ou controllers/ : le cœur, donc presque toujours une incompatibilité de version PHP, pas un bug de PrestaShop.
• themes/ : le thème, typiquement après une mise à jour.

Le dossier override/ mérite une attention particulière : on peut vider son contenu sans rien casser de vital, PrestaShop retombe alors sur son comportement standard. C'est le geste de dépannage le plus rentable sur une boutique en panne après manipulation de modules.

Refermer

Repassez _PS_MODE_DEV_ à false, réactivez les caches, videz var/cache/.

Une boutique arrêtée se compte en commandes perdues. Si l'erreur désigne un module payant ou une surcharge que vous n'avez pas posée, c'est exactement le genre d'intervention que je traite en urgence.