Guillaume PETIT est un développeur et utilisateur de PrestaShop de longue date. Profondément impliqué dans la communauté PrestaShop et expert dans son domaine, il nous dresse aujourd'hui un tableau précis de ce qui se cache derrière la fameuse page blanche qui nous a tous déjà stoppé dans notre élan.
Guillaume PETIT, [email protected] http://blog.dev-net.fr La page blanche est bien connue des acteurs du web. Les projets comme PrestaShop ne dérogent pas à la règle, au même titre que d'autres solutions e-commerce, web, framework, CMS e-commerce, etc.
C'est un phénomène récurrent, qui ne signifie pas que rien ne fonctionne, mais plutôt qu'une sécurité savamment contrôlée a été prévue par ceux qui vous entourent dans votre projet web.
Il n’y a donc pas d’inquiétude à avoir, la page blanche est notre amie. Plus précisément, c’est le signe que votre hébergeur web fait bien son travail, que vous soyez votre propre hébergeur ou que vous ayez délesté l'hébergement de votre site au profit d'une gestion plus universelle que sont les solutions d'hébergements mutualisés telles que celles proposées par OVH, 1&1, ikoula, lws, etc.
Pourquoi cette page blanche ?
La page blanche permet de ne pas afficher les éventuelles erreurs qui se cachent derrière. En n'affichant pas les erreurs, elle n'informe pas.
C'est dans ce silence que votre site web "se protège" au quotidien des attaques sur Internet, qui consistent communément à provoquer des erreurs sur votre site afin de tirer des informations, une fragilité, ou des failles de sécurité du site ou même de vos services d'hébergement liés de très près au serveur.
Si ceci est valable dans l’absolu quel que soit le contenu web que vous publiez, le maître d’œuvre principal de ce silence web sur votre site e-commerce est bien PrestaShop, l'outil qui gère le fonctionnement et paramétrage de votre contenu web.
Derrière cette page blanche se cachent donc des erreurs, qui sont volontairement cachées. Mais alors comment aller plus loin ? Même pour les plus doués, il est impossible de comprendre l’origine du blocage sans afficher les erreurs.
Quelles sont les solutions ?
Assez simplement, il faut afficher ces erreurs afin de les résoudre.
Dans la majorité des cas, celles-ci sont simples mais leur compréhension et leur résolution est indispensable à celui qui souhaite assurer soi-même l'installation principale de PrestaShop, les mises à jour, les configurations, les modifications du thème, les fonctionnalités l'installation de modules ou toute opération d’administration de son propre site de vente en ligne.
Préconisation de versions de test et de production
Lorsque vous installez la solution, les mises à jour, des modules tiers, ou que vous personnalisez votre propre thème, vous devez respecter au moins les bonnes pratiques PrestaShop suivantes :
- vous devez avoir à disposition une version de test de votre PrestaShop accessible et fonctionnelle, soit en local sur votre PC (plus rapide et pratique), soit sur un hébergement privé (distinct de celui de votre site en production).
- vous disposez de votre boutique PrestaShop en production, c'est-à-dire celle qui est consultable par le public sur le web, et qui se doit d'être accessible 24h/24h.
La version test vous permettra de tout savoir, et de tout vérifier. Cette version identique à celle en ligne et publique pourra être configurée en environnement de "DEV" (Développement).
La version production ne doit jamais être un environnement de développement, ou alors pour quelques instants de maintenance uniquement si des incompatibilités existaient entre votre hébergement de test et celui en ligne public.
Les incompatibilités sont souvent dues aux différences entre les utilisations sur Windows qui utilisent des outils comme WAMP (Windows Apache MySql PHP) plus adaptées au poste de travail et les solutions Linux comme LAMP (Linux Apache MySql PHP) plus adaptées aux serveurs directement en frontal sur Internet et qui écoutent le web.
Mais elles peuvent également résulter des différentes versions des services web et des environnements de développement. Il faut s'assurer de respecter les prérequis recommandés par PrestaShop.
Il ne faudra d’ailleurs pas négliger les prérequis facultatifs, qui sont souvent la source des problèmes car le noyau et certains modules tiers utilisent des librairies, des ressources, des configurations nécessaires pour améliorer la qualité du projet web.
Aussi, un serveur web ayant une ressource CPU (processeur) limitée, traitera plus lentement les scripts de la solution PrestaShop, et dépassera les limites accordées par les temps ou les mises en mémoire des processus internes PHP ou SQL, et donc provoquera des erreurs associées.
Il est donc important de retenir que pour traiter les messages d'erreurs au quotidien, après des installations de modules ou changement de votre thème, etc...
Il est grandement préférable de travailler sur une version test de développement qui révélera tout ce qui ne va pas, afin de vous assurer que la version de production sera pleinement fonctionnelle, et n'indiquera aucune erreur en frontal sur le web.
Passer d'une page blanche à la page de consultation des erreurs
Cette manipulation se fait différemment selon votre version de votre e-commerce PrestaShop, suite à des évolutions dans la façon de configurer le bas niveau entre PrestaShop 1.4 et 1.5.
Si votre PrestaShop est en erreur, il se peut que vous ne puissiez plus accéder au back-office pour l'administration de votre boutique, et de cette impossibilité, vous ne pouvez manipuler la configuration.
C'est pourquoi certaines configurations "critiques" ou "de secours", sont rendues accessibles en dehors du fonctionnement interfacé (visuel) de PrestaShop.
Le choix de ne pas utiliser ce genre de configurations enregistrées dans la base de données est tout aussi logique.
En effet, si l'erreur elle-même correspond à un problème d'accès à votre base de données, la récupération de ladite configuration ne pourra pas se faire (c'est le serpent qui se mord la queue).
Il faut donc rendre cette configuration critique disponible au technicien / commerçant, et dissociée de tout support de traitement, soit en texte plein depuis un fichier de configuration accessible depuis le FTP de votre hébergement.
Les modifications ci-dessous sont à éviter sur votre boutique en production.
Si vous travaillez sur votre boutique de test, vous pouvez laisser l'affichage des erreurs en permanence (attention à ne pas transmettre par FTP, vers votre boutique en production, les fichiers cités ci-dessous).
-
Vous possédez PrestaShop 1.5 Editez votre fichier ./config/defines.inc.php, et modifiez la variable telle qu'elle est présentée ci-dessous :
/* Debug only */ define('_PS_MODE_DEV_', true); -
Vous possédez PrestaShop 1.4 Editez votre fichier ./config/config.inc.php, et modifiez les variables telles qu'elles sont présentées ci-dessous :
/* Debug only */ @ini_set('display_errors', 'on'); define('_PS_DEBUG_SQL_', true);$start_time = microtime(true);/* Compatibility warning */ define('_PS_DISPLAY_COMPATIBILITY_WARNING_', true);Editez également votre fichier ./config/defines.inc.php, et modifiez la variable telle qu'elle est présentée ci-dessous :define('_PS_MODE_DEV_', true);
Maintenant que vous avez l'information sur vos éventuels problèmes, il vous faut passer à l'étape de débogage, qui consiste à cerner le problème et à le résoudre.
Liste des messages d'erreurs récurrents
1. Les erreurs HTTP
Afin de résoudre une erreur 500, qui à la base n'est pas spécialement explicite, voici quelques orientations envisageables :
- Vérifiez que les ressources des fichiers demandés, déclarés ou utilisés par un script ou par une référence quelconque sont bien présentes aux emplacements prévus et attendus :
- dans le cas d'un script PHP, il arrive souvent qu'une inclusion d'un script tiers ne puisse aboutir, car le développeur n'a pas prévu d'utiliser les chemins relatifs conventionnels de PrestaShop afin de s'adapter à tous les cas d'accès aux fichiers des hébergements.
- dans le cas d'une inclusion ou d'une déclaration incorrecte de votre fichier .htaccess. Pour vérifier si c'est bien ce fichier qui pose problème, vous pouvez le renommer en .htaccess_back, puis actualiser votre page web.
- Vérifiez les permissions de vos fichiers scripts PHP.
En effet, avec le principe modulaire de PrestaShop, et les possibilités d'envoyer et manipuler les fichiers depuis le FTP, vous pouvez sans le savoir mettre vos ressources PHP avec un degré de permissions trop élevé ou trop faible.
Chez certains hébergeurs, les permissions les plus fortes telles que 777 (tous les droits à tout le monde), peuvent provoquer une erreur 500, car le script ayant ces droits de lecture et d’écriture ne correspond pas à la configuration maximale autorisée.
C'est souvent le cas sur des serveurs utilisant des configurations "maisons" pour plus de sécurité. Les scripts peuvent posséder les bonnes permissions automatiquement dès lors qu'ils sont initialement traités par un autre script PHP.
Les permissions des fichiers traités prennent alors ceux de l'utilisateur / groupe en cours d'exécution et pré-chargés par l'hébergeur dans la configuration du service web.
Pour une installation de module ou thème PrestaShop sans heurt, la méthode d'envoi et d'installation depuis le back-office de PrestaShop est idéale.
2. Les erreurs liées aux codes PHP, à la base de données SQL, ou au moteur de template Smarty
Ce type d’erreurs, très largement répandues, peut être également un simple avertissement "warning" (suivant le degré de débogage prévu par votre hébergement).
En voici parmi les plus récurrentes :
-
Parse error:
syntax error, unexpected […]: ce sont généralement des erreurs de syntaxe dans votre code en cours de traitement. Il vous faudra isoler exactement le traitement qui a pu provoquer cette erreur. Dans la plupart des cas, l'erreur provient d'un code tiers n'appartenant pas à la solution PrestaShop, tel que celui d'un module tiers. A la fin de l'erreur, il est spécifié le chemin d'accès du script dans lequel la syntaxe est en erreur.
-
Notice:
Undefined property […] ou Undefined index [...]: simple avertissement indiquant que le script PHP ou smarty utilise une méthode, une variable, ou une ressource non connue au préalable, et /ou qu'elle n'existe pas, car elle n'a jamais était passée en mémoire. Encore une fois, il suffit de lire le chemin d'accès complet dans le message pour connaître le fichier script qui est en cause. Normalement, ces warnings n'empêchent pas votre site de fonctionner, mais ils peuvent être la cause d'un autre problème engendrant une erreur 500 par exemple.
-
Fatal error:
Smarty error […]: Ceci est renvoyé par le moteur de Smarty qui génère le rendu de votre template "thème". Si le thème ou le module est sous licence propriétaire, il est préférable de contacter directement l'éditeur à qui vous avez acheté ou acquis cette contribution. L’aide d’un développeur tiers ne vous aidera que très peu dans ce cas.
-
Fatal error:
Maximum execution time of XX seconds exceeded […]: cas typique d'un bridage (bienveillant à la base) sur la durée que votre hébergeur accorde à l’exécution d'un script PHP. Le script PHP n'est pas forcément la source du problème, sauf s'il est "mal pensé" et que son algorithme est trop lourd. On retrouve souvent ce genre d'erreur chez les petits hébergeurs, ou dans des scripts de traitements d'images "à la volée", par exemple. Le script fonctionne normalement, jusqu'au jour où trop de ressources sont sollicitées. On peut aussi retrouver des sollicitations de scripts externes qui eux-mêmes peuvent ralentir le script principal. C'est souvent le cas dans les modules tiers qui utilisent de plus en plus les services web externes pour récupérer des ressources. Le script peut aussi solliciter de façon trop conséquente les ressources de la base de données, même locale.
Pour résoudre ce problème, vous devez augmenter ce temps d’exécution grâce à ces trois méthodes, au choix :
-
1re méthode : efficace et rapide, mais doit plutôt être intégrée à un module pour éviter la modification dans le coeur de PrestaShop. Ouvrez votre fichier ./config/config.inc.php et ajoutez juste après
:
ini_set('max_execution_time','180'); // 5 minutes -
2e méthode : si vous n'avez pas l'autorisation de modifier la valeur depuis un script PHP, alors ouvrez votre fichier .htaccess à la racine de votre PrestaShop et ajoutez la directive suivante :
PHP_value max_execution_time 128 -
3e méthode : si vous n'avez pas l'autorisation de modifier la valeur par les deux méthodes précédentes, il faut alors intervenir à un niveau plus bas : le php.ini . Si vous n'avez pas l'accès à ce fichier, contactez votre hébergeur. Sinon, éditez le fichier php.ini (en local depuis WAMP, il se trouve normalement dans wamp/Apache2/bin/php.ini), et modifiez la configuration comme ceci :
max_execution_time = 180;
-
Fatal error:
Allowed memory size of XX bytes exhausted (tried to allocate YY) […]: Cette erreur existe sur le même principe de précaution que l'erreur précédente. Elle indique simplement que votre hébergeur vous bride dans la mise en mémoire possible pour le script en cours d’exécution. Vous pouvez résoudre le problème en suivant la même méthode précédente, mais en remplaçant "max_execution_time" par "memory_limit", et en changeant la valeur de 128 secondes par une valeur en MegaBytes, telle que 64M, voici un exemple :ini_set(‘memory_limit’,’64M’); // mettre 128 si cela ne suffit pas
Conclusion
Les nombreuses plateformes d’hébergement sont toutes différentes les unes des autres, mais PrestaShop est très flexible et s’adapte très bien à cette diversité.
En revanche, travailler sur la solution (développements spécifiques, ajout et configuration de modules externes, etc.) provoquera inévitablement des erreurs très communes qui vous permettront d’avancer et de pousser votre PrestaShop encore plus loin.
Les erreurs que vous aurez à résoudre sont pour la plupart très largement documentées sur Internet et si une rapide recherche dans la section « Difficultés, pannes ou erreurs rencontrées » du Forum officiel de PrestaShop n’apporte pas de solution à votre situation précise, il vous sera alors aisé de trouver une réponse en posant votre question à l’immense communauté PrestaShop en décrivant l’erreur rencontrée ou en suivant une formation PrestaShop.
