Lire et comprendre les journaux d’erreurs de WordPress, partie 1

Alors que nous continuons à regarder ce que signifie être un développeur WordPress indépendant, les outils nécessaires et les différentes stratégies qui peuvent améliorer nos compétences, j’ai parlé des différentes constantes, plugins et outils pour nous aider.

Si vous venez de tomber sur cet article, je vous recommande de consulter mon guide des outils de débogage WordPress natifs ainsi que le reste des articles de la série jusqu’à présent.

Après tout, je trouve important que nous travaillions tous sur la même base – ou quelque chose de étroitement lié – lorsque nous parcourons ces informations.

En fin de compte, utiliser un outil comme Xdebug est indispensable, mais il faut travailler jusqu’à cela (pour les curieux, j’ai écrit un petit guide à ce sujet il y a un peu plus d’un an).

Pour l’instant cependant, commençons par les bases. Dans le post précédent, je suis parti avec la déclaration suivante:

Dans le prochain article, nous commencerons à examiner ce qui est nécessaire pour examiner le journal des erreurs généré par WordPress et comment comprendre les informations que nous voyons.

Et c’est ce que je veux examiner aujourd’hui parce que, si rien d’autre, cela vous donnera quelque chose de pratique sur lequel travailler.

Comprendre les journaux d’erreurs de WordPress, partie 1

Avant d’aller trop loin dans cela, je veux répondre à une question qui a été soulevée par un membre du site.

A savoir, on m’a demandé :

Quand allons-nous nous pencher sur les principes orientés objet ?

Bien que j’en ai parlé un peu dans une série précédente, c’est quelque chose que je travaille à couvrir plus en profondeur plus tard dans cette série.

Cela dit, cependant, commençons à regarder les journaux d’erreurs.

Configuration de vos constantes

Si vous n’avez pas configuré les constantes dans votre fichier wp-config.php, je vous recommande de le faire maintenant car cela vous donnera le plus haut niveau de granualité lors de l’examen des problèmes qui pourraient survenir.

Si vous n’avez pas rattrapé votre retard, assurez-vous de lire cet article (et si c’est le cas, assurez -vous que les constantes suivantes sont définies dans votre fichier de configuration) :

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );

Une fois ceux-ci en place, vous avez tout ce dont vous avez besoin non seulement pour voir les informations à l’écran, mais également dans le journal de débogage que WordPress générera.

Où est le journal ?

Selon la nature de votre environnement, cela peut varier ; cependant, dans la plupart des cas, vous trouverez debug.log dans le répertoire wp-content situé au- dessus des répertoires plugins, themes et uploads.

Comme vous pouvez le voir dans l’aperçu de la capture d’écran ci-dessus, mon fichier de débogage contient beaucoup de contenu. Nous examinerons cela plus en profondeur dans la section suivante, ainsi que la façon de le comprendre. En attendant, cependant, vérifiez si ce fichier existe même. Si c’est le cas, n’hésitez pas à aller de l’avant et à parcourir le contenu du fichier. Vous ne comprenez peut-être pas grand-chose à ce qui se passe, mais le contenu du fichier signifie que quelque chose dans un thème ou un plug-in déclenche divers avertissements, avis et erreurs PHP que WordPress détecte et transfère dans le fichier journal.

Qu’est-ce que le fichier journal signifie même ?

Cela ne signifie pas nécessairement que quelque chose est cassé, mais cela indique que quelque chose ne fonctionne pas comme il se doit, n’est pas correctement détecté et géré au niveau programmatique, ou fait simplement quelque chose qu’il ne devrait pas faire.

Il n’a pas à ressembler à ça (mais c’est possible !).

En tant que développeurs, nous devons nous efforcer de nous assurer que notre code ne génère rien qui serait écrit dans le journal des erreurs.

C’est une chose de le faire en développement car nous sommes en mesure d’avoir un aperçu de ce que nous faisons et de la performance de WordPress. C’est une autre chose, cependant, pour quelque chose que nous publions au niveau de la production pour générer de telles choses.

Lecture du journal des erreurs

Évidemment, il y a plus à lire le journal des erreurs plutôt que de simplement l’ouvrir. Pour beaucoup, l’impression initiale est qu’il peut s’agir d’un tas de jargon. Je comprends ça aussi. Mais quand vous comprenez ce qu’il vous montre, c’est beaucoup plus facile à comprendre.

Prenons donc un exemple très simple. Ce n’est pas non plus un exemple artificiel. En fait, celui-ci provient d’un plugin sur lequel je travaillais. Le journal des erreurs contient les informations suivantes :

[05-Jul-2018 19:43:53 UTC] PHP Fatal error:  Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Notez que, dans l’essentiel ci-dessus, il y a trois lignes. Le meilleur plan d’action lors de la lecture des journaux d’erreurs est de commencer par le bas et de remonter. En effet, lors de l’exécution, les choses fonctionnent sur une pile.

Une courte digression sur les piles

Je n’entrerai pas dans la définition informatique du terme, mais le code est exécuté et fonctionne de telle manière que les fonctions se produisent et littéralement, dans la mémoire d’un ordinateur, s’empilent les unes sur les autres.

Ainsi, la chose la plus récente à exécuter sera toujours en haut là où la racine de l’endroit où elle commence est en bas. Puisque nous écrivons du code sur une application préexistante, c’est-à-dire WordPress ; alors notre code est susceptible d’être toujours au sommet.

Comprendre les journaux d’erreurs WordPress : ce n’est pas ce genre de pile

L’idée est que le code commencera à s’exécuter dans WordPress et progressera jusqu’au travail que nous faisons. Lorsqu’il y a un avis, un avertissement ou une erreur, cela se trouve généralement dans notre code (bien que WordPress ne soit pas exempté, c’est généralement le cas).

Ainsi, lorsque vous lisez le journal des erreurs, vous lisez essentiellement ce que l’on appelle une trace de pile. Wikipédia, tel que lié, a une définition assez détaillée sur le sujet, mais peut-être que la partie la plus pertinente de cet article est la suivante :

Les programmeurs utilisent couramment le traçage de pile pendant le [débogage] interactif et post-mortem (https://en.wikipedia.org/wiki/Debugging). Les utilisateurs finaux peuvent voir une trace de pile affichée dans le cadre d’un message d’erreur, que l’utilisateur peut ensuite signaler à un programmeur.

Cela correspond à ce que j’ai décrit ci-dessus, n’est-ce pas ? Mais assez parlé de ce qu’est une trace de pile (cela deviendra plus clair au fur et à mesure que nous approfondirons le débogage), revenons à la lecture du fichier journal tel qu’il se présente actuellement.

Retour à la lecture du journal

Inclure des fichiers

Tout d’abord, regardons l’essentiel dans l’essentiel ci-dessus. Il contient les éléments suivants :

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Cela me dit qu’à la ligne 25 de mon fichier, easy-email-export.php, il n’a pas réussi à ouvrir un fichier à inclure. Cela signifie que j’ai une instruction include_once dans le code qui fait référence à ./src/Admin/EmailExportSubmenu.php qu’il ne trouve pas.

Donc, le meilleur plan d’action serait de trouver la ligne 25 et de déterminer pourquoi il ne localise pas le fichier. Peut-être que cela vide le chemin complet de l’endroit où il regarde. Nous y reviendrons momentanément lorsque nous parlerons de l’écriture dans le journal des erreurs.

Donner un sens aux erreurs

Sur la ligne suivante (c’est-à-dire la ligne au-dessus de celle que nous venons de regarder) contient ce qui suit :

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Cette ligne particulière ne diffère que légèrement, mais elle donne un aperçu supplémentaire et cela est contenu dans la clause qui lit "Aucun fichier ou répertoire de ce type". C’est perspicace car cela nous dit littéralement que le fichier n’existe pas.

Au moins, il n’existe pas là où il regarde. Donc les deux possibilités sont :

1. nous n’avons pas créé le fichier auquel nous nous référons,
2. nous référençons l’emplacement du fichier au mauvais endroit

Ainsi, la première chose que nous devons vérifier est si le fichier existe à l’emplacement que nous essayons d’inclure. Si ce n’est pas le cas, nous devrions créer le fichier.

Si le fichier existe, nous savons que le plugin cherche à le charger à partir du mauvais chemin. Nous devrons donc peut-être regarder notre autoloader, notre chemin d’inclusion ou la manière dont les fichiers sont récupérés. Parce que, si le fichier existe, il y a de fortes chances qu’il essaie d’être chargé à partir d’un endroit où il ne réside pas.

Une erreur non détectée

Dans la dernière ligne du code, vous verrez quelque chose comme ceci :

[05-Jul-2018 19:43:53 UTC] PHP Fatal error: Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37

C’est un bon exemple, d’abord, parce qu’il déclare explicitement qu’il s’agit d’une erreur non interceptée. Cela signifie que quelle que soit la fonctionnalité, quelque chose génère une erreur et elle n’est pas détectée.

• cela pourrait être une exception,
• cela pourrait être un problème en essayant d’appeler une fonction qui n’existe pas,
• cela pourrait fonctionner sur une variable qui n’est pas définie,
• etc.

En fin de compte, il y a une pléthore de problèmes qui pourraient être présents. La bonne nouvelle, dans cet exemple, c’est que c’est pratiquement la même chose que ci-dessus: un fichier est introuvable.

Sauf que, plutôt que de lancer un avertissement, PHP nous indique explicitement qu’il s’agit d’une erreur fatale et que le programme ne peut pas continuer son exécution tant que cette ligne de code n’est pas résolue. Avant de rejeter cela comme quelque chose qui est identique à la section précédente (parce que, d’une certaine manière, c’est le cas), nous devons reconnaître que cela est explicitement indiqué comme une erreur fatale alors que, dans l’exemple précédent, il a été traité comme un Attention.

Il y a différentes façons de conceptualiser cela, mais la façon dont j’y pense généralement est la suivante :

• Un avis m’indique que quelque chose ne va pas dans le code, mais ce n’est pas assez grave pour justifier l’arrêt de l’exécution.
• Un avertissement est légèrement plus sérieux car cela signifie que quelque chose risque de ne pas fonctionner.
• Une erreur indique directement "cela ne fonctionne pas et le programme ne peut pas continuer".

Maintenant, nous savons que le problème est époustouflant, pour ainsi dire, et nous savons quel est le problème. En termes simples, un fichier nécessaire au programme pour terminer son exécution n’est pas trouvé et le programme cesse donc de fonctionner.

C’est certainement une erreur fatale.

Quelle est la solution ?

Ce que je propose comme solution à mon problème ne sera pas normatif quant à ce qui fonctionnera pour vous. Pour moi, il s’agissait d’une ligne dans ma configuration Composer telle que le chargeur automatique Composer ne pouvait pas localiser le fichier au bon emplacement (mais cela a plus à voir avec l’organisation des fichiers, l’espacement des noms, etc.).

Pour vous, cela peut être quelque chose de différent.

• peut-être cherche-t-il un fichier dans le mauvais répertoire,
• peut-être que le fichier porte un nom différent de celui spécifié dans le code,
• ou peut-être que c’est autre chose.

Quoi qu’il en soit, le fait est qu’il s’agit de parcourir le fichier journal de bas en haut pour diagnostiquer le problème et tracer ce que font PHP, WordPress et votre travail, puis le diagnostiquer à partir de là.

Écriture dans le journal des erreurs

Dans le prochain article, nous allons prendre un moment pour voir comment nous pouvons écrire dans le journal des erreurs. Parfois, lire le fichier est bien et simplement aller et venir entre ce que nous voyons et résoudre les problèmes est agréable.

Mais qu’en est-il du cas où nous voulons vider quelque chose pour avoir un aperçu de ce que voit WordPress ou PHP? C’est aussi utile.

Donc, dans la prochaine partie de cette série sur la compréhension des journaux d’erreurs WordPress, nous ferons exactement cela.

Qu’y a-t-il après ça ?

Ensuite, nous verrons comment utiliser certains des plugins décrits précédemment pour tester le code et également profiler notre code pour nous assurer que nous avons fait tout notre possible pour nous assurer que nous produisons un niveau de qualité.

Cela ne signifie pas que nous en avons complètement terminé avec le processus de débogage, mais nous sommes certainement un peu plus près, et nous sommes positionnés pour écrire du code avec un degré de qualité qui ne se traduit pas par un fichier représentant divers problèmes nuancés nous étions trop négligents pour réparer (et encore moins comprendre).