Astuce debug Prestashop en production

Bien souvent je suis amené à faire du débugage de Prestashop sur des boutiques qui sont en production, du coup il faut pouvoir intervenir dessus tout en étant le plus transparent possible. Pour y arriver il est possible de mettre en place une astuce toute simple.

Quand on fait une intervention sur un shop online

Lorsqu’il faut intervenir sur une boutique pour corriger un problème rapidement, il faut éviter de perturber la boutique et le faire à l’arrache (même si le client est pressé). Quand on se met en mode « debug » sous Prestashop, les traitements ont un comportement différent et certains processus peuvent s’arrêter ou afficher des « warning » à l’internaute, qui risque de quitter le shop. Parfois on pense que ça va prendre 5 minutes et 2 heures plus tard le problème n’est toujours pas réglé… et les erreurs pullulent pour les visiteurs… (ce qui n’est pas un bon plan).

Le mode débug uniquement pour le développeur

Le principe est donc tout simple, il suffirait de pouvoir activer la gestion des erreurs uniquement pour le développeur et pour tous les autres on charge le shop dans sa version classique (sans le débugage). Cela permettra au développeur de corriger l’erreur sans être chronométré + augmentation du stress, parce que les internautes voient des erreurs sur le shop.

Appliquons la modification

La procédure est toute simple, pour commencer il faut activer le mode « développement » de Prestashop en modifiant cette ligne du fichier « config/defines.inc.php » :

define('_PS_MODE_DEV_', false);

En

define('_PS_MODE_DEV_', true);

Ensuite nous allons modifier le fichier « config/defines.inc.php » en remplaçant la ligne 32 :

if (_PS_MODE_DEV_)

Par le code suivant :

if (_PS_MODE_DEV_ && in_array($_SERVER['REMOTE_ADDR'],array('::1','localhost','127.0.0.1','82.4.22.111 ')))

La méthode est toute simple, il suffit d’ajouter les adresses IP pour lequelles vous désirez que le mode développement soit activé, par exemple ici j’ai mis les adresses IP en localhost, mais si vous travaillez sur un shop online, il faudra ajouter aussi votre véritable IP (cela est très pratique surtout si vous avez en plus une IP fixe).

Cela permet d’éviter les désagréments

Il y’a aussi le cas où l’on oublie d’enlever le débug suite à une intervention ou lorsqu’on active cette option temporairement pour vérifier ou tester un processus et qu’ensuite on la laisse activée. Mettre en place une option de ce genre améliore le confort du développeur / marchant et aussi des clients actifs sur le shop en assurant que la boutique reste toujours en mode « production ».

Une idée à intégrer dans Prestashop

Ce qui serait bien c’est que Prestashop lie le mode débug directement aux adresses IP qui sont mentionnées dans la partie maintenance du site (ça semblerait assez logique & plus dynamique). D’ailleurs je me suis toujours demandé pourquoi cette option (activation du débug) n’était pas directement modifiable via le back-office de manière à ce que Prestashop « re-génère »  automatiquement ce fichier de configuration (sans devoir activer cela manuellement dans le fichier).

Bilan

Voilà une petite astuce simple à mettre en place, mais qui améliore le confort du quotidien, rien ne vous empêche  de désactiver le mode développement quand vous ne l’utilisez pas, mais au moins vous êtes sûr que vos clients ne seront jamais impactés par le changement. Il m’arrive parfois de voir des boutiques en production qui tourne avec l’option développement à « true », cela augmente considérablement les risques d’erreurs et de blocages, donc je vous laisse suivre les instructions ci-dessus 😉 !

14 commentaires sur “Astuce debug Prestashop en production”

  1. Hello Webbax,

    Je me souviens en avoir parlé il y a un an, quasiment, lors de ma rencontre avec l’équipe sur place…

    … et je me souviens surtout avoir bossé sur un prémisse de cette fonctionnalité, que cela soit en module ou en natif.

    Autant la régénération du fichier est simple (preuve en est avec le module pour développeur que je mets à disposition), autant fixé des IP (aussi bien pour le mode debug que le profiling, ceci dit) est plus délicat à mettre en oeuvre, dans un premier temps.

    En effet, si on regarde bien… le mode DEV permet de traiter quelques données/erreurs liées au chargement des configurations. Les IP étant placées dans une configuration…

    … ou alors, il faut réaliser une modification comme pour les slaves MySQL, permettant l’édition d’un fichier.

    D’ailleurs, ça me semble le plus cohérent/adéquat pour la structure actuelle, finalement… 😉

    Répondre

    1. Hello,

      Clairement ça me semblerait bien que ça soit intégré, parce que bon on peut activer l’option pour le « Smarty Debug » depuis le back-office, dans la gestion des paramètres avancés il serait bien de pouvoir basculer en mode développement (pour certaines IP typiquement).

      Parfois ça peut aussi simplifier la vie pour juste déjà « voir l’erreur », parce que parfois il faut demander les accès FTP au clients… avant même d’identifier l’erreur en question (c’est toujours plus délicat).

      Je trouve qu’il y a des options intéressantes dans ces fichiers de configuration, il manque une option pour les manager depuis le back-office, ça viendra peut-être avec le temps.

      Bon après c’est toujours pour plus de confort, la modification d’un fichier en soi n’est pas dramatique 😀 !

      Répondre

  2. Bonjour,

    Merci pour cette astuce.
    Ok pour le mode débug mais comment activer cela avec le mode profiling? (que je puisse rester en mode profiling depuis mon IP) mais que la boutique reste active?

    Merci!

    Répondre

    1. Bonjour,

      Pour cela pas le choix, il faut ajouter une condition dans le fichier config si l’ip = xxx alors on passe le profiling à « true ».

      Si ce type de paramétrage dépasse vos compétences, je vous invite à faire appel à un professionnel de Prestashop pour mettre en place ce type de debugage.

      Merci pour votre visite !

      Répondre

  4. Bonsoir, je viens d’avoir une erreur alors que tout fonctionnait sans soucis. Je n’arrive pas à savoir d’ou viens le soucis. Le site fonctionne sans erreur en mode débug, mais si je le coupe plus rien, j’ai que des pages blanche même vers le back office. Pourrais-tu m’aider stp? Je te remercie par avance. Car le site était pret pour un lancement en production mais du coup sa retarde tout la 🙂

    Répondre

    1. Hello,

      Sincèrement difficile de répondre à cette question (surtout si en mode dev. il n’y a pas d’erreur), peut-être que ça vaut la peine de te faire aider par un freelance pour le debugage, essaie de regarder sur codeur.com. Tu peux aussi tester en désactivant des modules et les overrides Prestashop pour voir si la cause vient de là.

      A bientôt !

      Répondre

  5. Bonjour,

    voici le code qu’il faut ajouter pour être sûr de na pas avoir de debug côté client : 

    if (_PS_MODE_DEV_ && in_array($_SERVER['REMOTE_ADDR'],array('::1','localhost','127.0.0.1','VOTRE_IP')))
{
	define('_PS_MODE_DEV_', true);
	define('_PS_DEBUG_PROFILING_', true);
}
if (_PS_MODE_DEV_ && !in_array($_SERVER['REMOTE_ADDR'],array('::1','localhost','127.0.0.1','VOTRE_IP')))
{
	define('_PS_MODE_DEV_', false);
	define('_PS_DEBUG_PROFILING_', false);
}

    L’ajout de la variable en condition inverse permet de définir la variable à false si l’ip présenté n’est pas dans l’array.
    Je pense que c’est mieux de faire les deux.
    En tout cas ça fonctionne très bien.
    Car la variable restée à true sans le passement à false de mon côté.
    SI votre site passe en tout blanc, sans rien cela peut-être dû aux permissions des groupes clients ( permissions des modules pour chaque groupe client à réactiver) cela peut arriver suite à une surcharge du serveur ou du disque voir une erreur de base de données.

    Répondre

    1. Bonjour,

      Merci pour cette précieuse contribution, qui sera certainement très utile pour les lecteurs de ce billet.

      A bientôt !

      Répondre

  6. Bonjour,

    J’ai essayé d’intégrer le code d’Adrien mais mes 2 pages (BO et FO) étaient blanches. J’ai donc remis le code d’origine mais les 2 pages restent blanche (alors qu’avant je pouvais accéder en mode DEBUG en FO et BO et sans mode début uniquement au FO)
    Pouvez vous me dire si vous voyez une erreur dans le codage ?

    /* Debug only */
    if (!defined(‘_PS_MODE_DEV_’)) {
    define(‘_PS_MODE_DEV_’, false);
    }
    /* Compatibility warning */
    define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, false);
    if (_PS_MODE_DEV_)
    }
    @ini_set(‘display_errors’, ‘on’);
    @error_reporting(E_ALL | E_STRICT);
    define(‘_PS_DEBUG_SQL_’, true);
    } else {
    @ini_set(‘display_errors’, ‘off’);
    define(‘_PS_DEBUG_SQL_’, false);
    }

    Répondre

    1. Bonjour,

      Après la ligne « if (_PS_MODE_DEV_) » l’accolade devrait être dans l’autre sens à mon avis. Ce que je ferai c’est que je reprendrai le code du fichier original dans une archive zip original de Prestashop pour revenir à l’état initial.

      A bientôt !

      Répondre

  7. Bonjour Webbax,
    J’ai la version 1.6.1.6 de Prestashop d’installée et malheureusement votre astuce ne fonctionne pas (plus) (ou alors, je n’ai pas compris comment faire).
    Voici ce que j’ai entre les lignes 27 et 30 de defines.inc.php dans le dossier Config de Prestashop :
    27 /* Debug only */
    28 if (!defined(‘_PS_MODE_DEV_’)) {
    29 define(‘_PS_MODE_DEV_’, false);
    30 }

    puis entre les lignes 31 et 40, ceci :
    31 /* Compatibility warning */
    32 define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, false);
    33 if (_PS_MODE_DEV_ === true) {
    34 @ini_set(‘display_errors’, ‘on’);
    35 @error_reporting(E_ALL | E_STRICT);
    36 define(‘_PS_DEBUG_SQL_’, true);
    37 } else {
    38 @ini_set(‘display_errors’, ‘off’);
    39 define(‘_PS_DEBUG_SQL_’, false);
    40 }

    Vous pouvez voir qu’en ligne 32 j’ai :
    define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, false);
    et non
    if (_PS_MODE_DEV_)
    D’ailleurs, j’ai cherché if (_PS_MODE_DEV_) dans le fichier, je ne l’ai trouvé nulle part.
    Qu’à cela ne tienne, en ligne 29 à la place de :
    define(‘_PS_MODE_DEV_’, false);
    j’ai mis :
    define(‘_PS_MODE_DEV_’, true);
    Et en dessous, après l’accolade fermante de la ligne 30, j’ai mis, à partir de la ligne 31 :
    if (_PS_MODE_DEV_ && in_array($_SERVER[‘REMOTE_ADDR’],array(‘::1′,’localhost’,’127.0.0.1′,’xx.x.xx.xxx ‘)))
    avec, à la place de xx.x.xx.xxx mon adresse IP.
    Comme ça ne fonctionnait pas, j’ai remplacé votre code par celui d’Adrien :
    if (_PS_MODE_DEV_ && in_array($_SERVER[‘REMOTE_ADDR’],array(‘::1′,’localhost’,’127.0.0.1′,’VOTRE_IP’)))
    {
    define(‘_PS_MODE_DEV_’, true);
    define(‘_PS_DEBUG_PROFILING_’, true);
    }
    if (_PS_MODE_DEV_ && !in_array($_SERVER[‘REMOTE_ADDR’],array(‘::1′,’localhost’,’127.0.0.1′,’VOTRE_IP’)))
    {
    define(‘_PS_MODE_DEV_’, false);
    define(‘_PS_DEBUG_PROFILING_’, false);
    }

    En remplaçant, bien sûr « VOTRE_IP » par mon adresse IP.
    Cependant, ça ne fonctionne pas plus.

    Auriez-vous SVP une « astuce 2018 », en remplacement de celle d’il y a 4 ans, adaptée à la version 1.6.1.6 (qui m’intéresse) et (éventuellement une autre) adaptée à la version 1.7.x (qui pourrait intéresser les personnes tournant sous cette version de Prestashop) ?
    Un grand merci par avance.
    Bonne journée 😉

    Répondre

    1. Hello,

      Peut-être que le plus simple dans Prestashop 1.7 c’est de passer via les paramètres avancés de la boutique (en back-office) et d’activer le debug. Cela évite de devoir modifier directement le fichier de configuration natif.

      A bientôt !

      Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *