Debug PrestaShop : mode développeur et profiling

Credit : Logo officiel

Debug PrestaShop : mode développeur et profiling

Dylan D. — Agent Support Technique Serveur PrestaShop 1852 mots 10 min de lecture

Debug PrestaShop : mode developpeur et profiling

Lundi matin, ticket P1 : un client e-commerce sur PrestaShop 8.1 voit son site retourner une erreur 500 generique sur la page de checkout depuis qu'il a installe un module de transporteur. Aucun message dans Apache, juste "Internal Server Error" pour les clients qui essaient de finaliser leur commande. Avec un PrestaShop standard, impossible de savoir ce qui se passe -- les erreurs sont masquees pour la securite. Activation du mode dev en deux lignes, je rafraichis la page : Fatal error: Class "Carrier\Module\Helper" not found in /modules/transporteur_xyz/.... Module mal package qui appelle une classe inexistante. Probleme identifie en 30 secondes, module desactive, ventes reprises.

Le mode developpeur PrestaShop, c'est ton outil le plus precieux quand ta boutique deconne. Mais entre les versions 1.6, 1.7 et 8.x, les fichiers de config et les noms de variables ont change. Et la doc officielle est... disons disparate. Je te donne ma methode complete pour PrestaShop 8.x, avec rappels sur les anciennes versions.

Identifier ta version PrestaShop

Avant tout, faut savoir quelle version tu utilises parce que les fichiers de config et methodes ont change. Sur PrestaShop 8.x :

grep "VERSION" /home/htdocs/web/src/Core/Version.php

Sur PrestaShop 1.7.7+ :

grep "VERSION" /home/htdocs/web/app/AppKernel.php

Sur PrestaShop 1.6 et 1.7 (avant 1.7.7) :

grep "_PS_VERSION_" /home/htdocs/web/config/settings.inc.php

Sur les serveurs IONOS, on voit encore beaucoup de PrestaShop 1.7 en production, certains meme en 1.6 (et la c'est urgence migration). Pour ce guide je me concentre sur PrestaShop 8.x qui est la version actuelle, avec rappels pour 1.7.

Activer le mode developpeur

PrestaShop 8.x

Deux methodes, choisis selon ta preference. La premiere via le fichier de config historique :

nano /home/htdocs/web/config/defines.inc.php

Cherche la ligne :

define('_PS_MODE_DEV_', false);

Et passe-la a true :

define('_PS_MODE_DEV_', true);

Methode plus moderne Symfony via le fichier .env a la racine :

APP_ENV=dev
APP_DEBUG=1

Les deux methodes coexistent dans PrestaShop 8.x. La methode .env controle le bootstrap Symfony (back-office moderne), la methode defines.inc.php controle le legacy front-office. Pour un debug complet, active les deux.

Une fois active, PrestaShop affiche les erreurs PHP directement au lieu d'une page 500 generique. Tu vois les fatal errors avec stack trace complete, les warnings, et les erreurs Symfony.

PrestaShop 1.6 / 1.7

Uniquement via defines.inc.php :

define('_PS_MODE_DEV_', true);

Le .env n'existe pas en 1.6.

Configuration complete pour le debug

Voila la config que je colle dans defines.inc.php quand je dois investiguer :

define('_PS_MODE_DEV_', true);
define('_PS_DEBUG_PROFILING_', true);
define('_PS_DEBUG_SQL_', true);
define('_PS_DISPLAY_COMPATIBILITY_WARNING_', true);

Chaque constante a son role :

Debug Smarty et templates

Smarty c'est le moteur de templates de PrestaShop (en plus de Twig pour le BO). Quand tu modifies un fichier .tpl et que rien ne change, c'est que Smarty utilise sa version compilee en cache.

Va dans Back-office > Parametres avances > Performances et configure :

  1. Cache des templates : passe sur "Forcer la compilation a chaque appel"
  2. Cache : desactiver
  3. Cache CCC (Combine Compress Cache) : tout desactiver pendant le debug

Ou directement en SQL :

UPDATE ps_configuration SET value = '1' WHERE name = 'PS_SMARTY_FORCE_COMPILE';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SMARTY_CACHE';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_CSS_THEME_CACHE';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_JS_THEME_CACHE';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_HTML_THEME_COMPRESSION';

Inspecter les variables Smarty

Dans n'importe quel fichier .tpl, ajoute :

{debug}

Ca ouvre une popup JavaScript avec toutes les variables disponibles dans ce template, leur type, et leur valeur. Moche mais redoutablement efficace pour comprendre ce qui est dispo dans un template.

Alternative plus discrete pour inspecter une variable specifique :

<pre>{$nom_variable|var_export:true}</pre>

Le profiling integre

Le profiling integre de PrestaShop est meconnu mais super puissant. Active dans defines.inc.php :

define('_PS_DEBUG_PROFILING_', true);

Chaque page front-office affiche en bas un panneau detaille :

Une anecdote concrete : un client dont la fiche produit mettait 8 secondes a charger. Le profiling a montre qu'un module de cross-selling faisait 340 requetes SQL par page parce qu'il chargeait les produits associes en boucle sans cache. Module vire, page descendue a 1.2 secondes.

Les seuils de criticite que je regarde :

Activer les logs detailles

PrestaShop 8.x utilise Monolog. Pour avoir des logs verbeux, edite app/config/config_dev.yml ou cree-le :

monolog:
    handlers:
        main:
            type: rotating_file
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug
            max_files: 10

Les logs apparaissent dans var/logs/dev.log. Pour suivre en temps reel :

tail -f /home/htdocs/web/var/logs/dev.log

En complement, les logs PHP du serveur :

tail -f /home/htdocs/logs/php-errors.log

Sur les hebergements IONOS, les logs PHP sont generalement dans ~/logs/ ou via le panneau client.

Vider le cache PrestaShop proprement

Quand tu modifies du code et que rien ne change, c'est presque toujours le cache. PrestaShop 8.x a plusieurs niveaux de cache :

cd /home/htdocs/web

# Cache Symfony (BO moderne)
rm -rf var/cache/prod/*
rm -rf var/cache/dev/*

# Cache Smarty (front-office)
rm -rf var/cache/dev/smarty/cache/*
rm -rf var/cache/dev/smarty/compile/*
rm -rf var/cache/prod/smarty/cache/*
rm -rf var/cache/prod/smarty/compile/*

Via la console Symfony :

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

Pour PrestaShop 1.6 :

rm -rf cache/smarty/compile/*
rm -rf cache/smarty/cache/*
rm -rf cache/class_index.php

Le class_index.php est la map des classes overridees. Si tu modifies un override, faut le supprimer pour que PrestaShop le regenere.

Debugger les overrides

Les overrides PrestaShop sont une source classique de bugs. Pour lister tous les overrides actifs :

find /home/htdocs/web/override -name "*.php" -type f

Si un override casse ton site (typiquement apres une mise a jour), regenere le class_index :

rm /home/htdocs/web/var/cache/prod/class_index.php
rm /home/htdocs/web/var/cache/dev/class_index.php

Ou desactive temporairement un override en le renommant :

mv override/classes/Cart.php override/classes/Cart.php.disabled

Activer le profiler Symfony pour le BO

Le BO de PrestaShop 8.x repose sur Symfony. Pour activer le profiler Symfony (la fameuse barre en bas de page de Symfony) :

composer require --dev symfony/profiler-pack

Puis dans app/config/packages/dev/web_profiler.yaml :

web_profiler:
    toolbar: true
    intercept_redirects: false

framework:
    profiler: { only_exceptions: false }

La barre Symfony donne acces a un debug avance : routes Symfony, twig templates, services, requetes Doctrine. Indispensable quand tu touches au BO moderne (catalogue Symfony, dashboard).

Logs des modules tiers

Chaque module PrestaShop peut avoir ses propres logs. Cherche-les dans var/logs/ :

find /home/htdocs/web/var/logs -name "*.log" -mtime -7

Les modules de paiement (Stripe, PayPal) ont generalement un sous-dossier dans leur module avec leurs logs. Chez certains, c'est modules/stripe_official/log/ :

tail -f /home/htdocs/web/modules/stripe_official/log/error.log

Quand un paiement echoue, tu trouves la la reponse complete de l'API Stripe avec le code d'erreur exact.

Debugger une requete SQL specifique

Si tu suspectes une requete SQL precise, log-la depuis ton code PHP :

Db::getInstance()->execute($sql);
file_put_contents('/tmp/debug_sql.log', date('Y-m-d H:i:s') . " - " . $sql . "\n", FILE_APPEND);

Ou active le general_log MySQL temporairement :

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/tmp/mysql_general.log';
-- Reproduis le probleme
SET GLOBAL general_log = 'OFF';

Attention : le general_log explose vite en taille, ne le laisse jamais active longtemps.

Erreurs courantes et leur fix

Page blanche meme avec mode dev

L'erreur survient avant le bootstrap de PrestaShop. Active le debug PHP global dans un .user.ini a la racine :

display_errors = On
error_reporting = E_ALL
log_errors = On
error_log = /home/htdocs/logs/php-errors.log
memory_limit = 512M

"Class not found" apres mise a jour

Le class_index.php est obsolete. Supprime-le :

rm var/cache/*/class_index.php
php bin/console cache:clear

Erreur 500 sur le BO uniquement

Verifie les permissions sur var/ et app/config/ :

chmod -R 755 var/
chmod -R 755 app/config/

Verifie aussi parameters.php qui contient les credentials BDD :

cat app/config/parameters.php

Hook custom qui ne s'execute pas

Verifie que le hook est bien enregistre :

SELECT * FROM ps_hook_module hm 
JOIN ps_hook h ON h.id_hook = hm.id_hook 
JOIN ps_module m ON m.id_module = hm.id_module 
WHERE m.name = 'monmodule';

Modules incompatibles avec ta version

Apres une mise a jour majeure (1.7 vers 8.x par exemple), beaucoup de modules deviennent incompatibles. Liste les modules avec des warnings :

php bin/console prestashop:module list --status=disabled

Ou en SQL :

SELECT name, version, active FROM ps_module WHERE active = 0;

Un module qui s'active pas malgre tes efforts a probablement une exception lors de son install. Cherche dans var/logs/prod.log :

grep -i "module_name" /home/htdocs/web/var/logs/prod.log

Profiling vide en bas de page

Le profiling apparait que sur le front-office, pas sur le BO. Et seulement si _PS_DEBUG_PROFILING_ est a true. Verifie aussi que tu n'as pas un addon de cache (Cloudflare, Varnish) qui sert une version cachee.

Remettre en production proprement

Une fois le bug identifie et corrige, oublie pas de remettre tout en mode prod :

define('_PS_MODE_DEV_', false);
define('_PS_DEBUG_PROFILING_', false);
define('_PS_DEBUG_SQL_', false);

Et remet le .env :

APP_ENV=prod
APP_DEBUG=0

Vide les caches une derniere fois :

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

Laisser le mode dev en prod expose des chemins de fichiers, des credentials, et ralentit le site (compilation Smarty a chaque page). C'est clairement a pas faire.

Pour aller plus loin

Le debug, une discipline pas une option

Le mode dev PrestaShop c'est pas un truc qu'on active a l'arrache et qu'on oublie. C'est un outil chirurgical : tu actives, tu investigues, tu corriges, tu desactives. Garde toujours en tete que sur PrestaShop, plus encore que sur WordPress, le mode dev expose enormement d'infos sensibles : structure de la BDD, requetes SQL completes parfois avec data, chemins de fichiers, versions des modules.

La regle d'or : jamais de mode dev en production publique. Active-le sur un environnement de staging (sous-domaine prive avec .htpasswd), reproduis le bug la-bas, fix, et deploie. Tu evites les fuites de donnees et tu gardes ton site rapide pour tes vrais clients. Et le jour ou un module pete ton checkout un lundi matin, tu sauras quoi faire en deux minutes au lieu de paniquer pendant deux heures.

# Articles similaires

Sur les memes sujets et plus loin