Afficher les erreurs sur son site afin de le déboguer, ou lorsqu’il est en cours de développement, est une chose essentielle (si ce n’est capitale) à savoir paramétrer sur son WordPress ou son Prestashop. Il s’agit en réalité d’une mesure de sécurité qui permet de masquer le code affiché en cas de mauvais développement ou d’instabilité du système. Une page blanche sur un site n’est pas dramatique en soi, c’est ce que cela cache qui peut l’être.
Une ligne de code mal tapée, une faute de frappe, une mauvaise configuration du système ou pire : une mise à jour ratée, tout cela peut être à l’origine d’une page blanche. Pour éviter que de petits malins récupèrent des informations confidentielles en rapport avec votre serveur et/ou votre site, le mode debug a été créé.
Afficher les erreurs sous Prestashop
Dans le cadre de Prestashop, la modification d’un thème devrait systématiquement se passer en local. Une variable Smarty mal insérée peut ainsi bloquer l’affichage d’une page. Rien de plus simple dans ce cas, il vous suffit d’ouvrir le fichier defines.inc.php qui se trouve dans le dossier /config de votre site, et de repérer la ligne se trouvant en dessous de /* Debug Only */ qui devrait être :
if (!defined('_PS_MODE_DEV_'))
define('_PS_MODE_DEV_', false);
Il s’agit de ce qu’on appelle un booléen, c’est-à-dire que le mode développeur ne prend que deux valeurs : soit c’est vrai, soit c’est faux. Si vous laissez la valeur à « false », une page blanche sera affichée en cas de problème, ceci pour des raisons de sécurité. En passant le booléen à « true », vous pourrez ainsi savoir qui est le fautif, et son emplacement (nom du fichier, ligne coupable). Il est évident que cette ligne doit systématiquement être réglée sur « false » lorsque votre site est en production !
Afficher les erreurs sous WordPress
Dans le cadre de WordPress, c’est à peu près pareil. Nous avons toujours un booléen, qui se trouve dans le fichier wp-config.php à la racine de votre site. Même combat donc, voici la ligne à repérer :
/**
* Pour les développeurs : le mode deboguage de WordPress.
*
* En passant la valeur suivante à "true", vous activez l'affichage des
* notifications d'erreurs pendant votre essais.
* Il est fortemment recommandé que les développeurs d'extensions et
* de thèmes se servent de WP_DEBUG dans leur environnement de
* développement.
*/
define('WP_DEBUG', false);
Pas difficile donc d’afficher les erreurs générées par un plugin, ou un thème… A propos, connaissez-vous les constantes utiles à ajouter à un site WordPress WooCommerce, dans ce même fichier wp-config.php ?
Demander du support
Que faire avec les erreurs affichées ?
Tous les développeurs vous diront que c’est très simple : l’erreur vous précise sa nature, ainsi que son emplacement. Pour exemple, si vous voyez « Parse error », c’est qu’il manque quelque chose, comme ce célèbre point-virgule qui a donné des sueurs à tellement de codeurs 🙂
Si vous devez poster le résultat sur un forum, masquer tout ce qui se trouve avant le démarrage de votre site. Par exemple, si votre site se trouve dans le répertoire /www, évitez de citer ce qui se trouve avant. Fournissez également les caractéristiques de votre hébergement (version de PHP, version exacte du CMS, etc). Au plus vous donnerez d’informations, au plus rapidement vous aurez de l’aide. Ne mettez jamais de message de type « J’ai une page blanche » ou « mon site ne marche pas », cela ne nous aidera pas plus que vous. Détaillez donc au maximum, les développeurs constateront l’effort que vous faites pour donner des pistes à la résolution de votre souci !
Un dernier mot, Jean-Pierre ?
Pensez systématiquement que lorsqu’un plugin ou module est responsable du mauvais fonctionnement d’un site, il suffit parfois de le renommer sur le serveur pour que tout refonctionne à peu près comme avant. J’ai déjà entendu des webdesigners accuser de tous les maux leur hébergeur, alors qu’aucun mode de débug n’avait été réglé sur leur site, et qu’en conséquent ils avaient une totale méconnaissance du système qu’ils sont censés paramétrer… Et c’est de cette manière que je vous présente la loi n°1 du web au sein de la Team :
Le problème est régulièrement entre la chaise et le clavier
(et je vérifie cela tous les jours en ce qui me concerne… 😆 )
Imprimer
Laisser un commentaire