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

La dernière fois, nous avons parcouru ce qui suit :

1. configuration des constantes de débogage,
2. localiser un fichier journal des erreurs,
3. comprendre comment lire le fichier journal,
4. compréhension des traces de pile
5. comprendre comment lire la pile

Aussi agréable que cela puisse paraître, il est toujours important de comprendre comment écrire des données dans le journal des erreurs d’un point de vue programmatique. C’est-à-dire; c’est une chose si votre travail génère des erreurs, des avertissements ou des avis.

C’est autre chose si vous voulez comprendre comment écrire manuellement des informations dans le fichier pour la recherche et le débogage.

Dans cet article, nous continuerons à faire exactement cela pour approfondir notre compréhension des journaux d’erreurs WordPress.

Comprendre les journaux d’erreurs de WordPress, partie 2

Quel est l’intérêt d’écrire dans le journal des erreurs, de toute façon ? Je veux dire, cela fait-il même partie du processus de débogage ?

Du post précédent :

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.

Lorsque les programmeurs pensent au débogage, beaucoup d’entre eux pensent à utiliser un véritable débogueur (c’est-à-dire un logiciel), à définir des points d’arrêt et à parcourir le code pour surveiller la valeur des variables pendant l’exécution du programme.

Nous allons arriver à ce point, mais avant cela, examinons comment nous pouvons écrire nous-mêmes dans le journal des erreurs pour nous donner un aperçu de la performance de notre travail.

Après tout, c’est une chose si notre travail génère des avertissements, des erreurs et des avis. C’en est une autre s’il y a des informations que nous voulons voir. Et c’est là que l’écriture dans le journal des erreurs entre en jeu.

Comprendre les fonctions PHP

Pour écrire dans le journal des erreurs, il est important de comprendre deux fonctions PHP :

1. error_log
2. print_r

En ce qui concerne la fonction error_log, notez que son objectif est de :

Envoyer un message d’erreur aux routines de gestion des erreurs définies

Dans la plupart des cas, ceci est configuré pour écrire dans le fichier journal pour nous via la configuration WordPress et PHP par défaut. Mais il y a plus que cela car nous allons souvent vouloir sortir les valeurs de variables, de tableaux, d’objets, etc.

À cette fin, vous devez pouvoir utiliser print_r en conjonction avec error_log. print_r effectue les opérations suivantes :

Imprime des informations lisibles par l’homme sur une variable

Et si vous lisez le manuel, vous remarquerez qu’il faut deux arguments dont le second doit être défini sur vrai si vous voulez que le résultat d’une fonction soit imprimé dans le fichier journal.

Plus précisément, comme l’indique le manuel :

Si vous souhaitez capturer la sortie de print_r(), utilisez le returnparamètre. Lorsque ce paramètre est défini sur TRUE, print_r() renverra les informations plutôt que de les imprimer.

Ainsi, l’idée générale d’écrire la valeur d’un tableau, disons $exampleArray, ressemblerait à ceci :

<?php

error_log(print_r($exampleArray, true));

Mais qu’en est-il dans le contexte de WordPress ?

Écrire des valeurs dans le journal des erreurs dans WordPress

Ainsi, ce qui précède décrit les fonctions intégrées à PHP dont nous avons besoin, mais à quoi cela ressemble-t-il dans le contexte du développement WordPress.

Pour ce faire, disons que nous avons implémenté une version du Registry Pattern. Dans notre implémentation du modèle, nous avons également une méthode appelée start que nous pouvons appeler une fois que tous nos objets ont été ajoutés au registre.

Cela peut ressembler à ceci :

<?php

/**
 * Starts all of the objects stored is the registry by calling
 * the `start` method that's available on each of the objects.
 */
public function start()
{
    foreach ($this->storage as $obj) {
        $obj->start();
    }
}

Maintenant, en ce qui concerne la mise en œuvre, c’est simple. Mais que se passe-t-il si nous voulons voir quels objets sont invoqués via chaque itération de la boucle.

L’idée derrière cela est que nous sommes capables de parcourir les objets stockés et d’appeler une méthode sur chacun d’eux. Ceci est basé sur l’idée que chacun des objets a une méthode disponible sur chacun d’eux (qui peut être appliquée par une interface ).

Tout d’abord, cela soulève une question : pourquoi pouvons-nous vouloir faire cela ? En raison de la nature du système de gestion des événements de WordPress, nous voulons peut-être nous assurer que chaque objet que nous prévoyons de déclencher se déclenche.

Deuxièmement, comment pouvons-nous voir quels objets sont invoqués ? C’est là que l’écriture dans le journal des erreurs entre en jeu. En utilisant les méthodes que nous avons décrites ci-dessus, une façon de procéder serait de procéder comme suit :

<?php

/**
 * Starts all of the objects stored is the registry by calling
 * the `start` method that's available on each of the objects.
 */
public function start()
{
    foreach ($this->storage as $obj) {
        error_log(print_r($obj, true));
        $obj->start();
    }
}

Cela se traduira par la sortie suivante :

Ici, vous pouvez voir l’objet ; c’est l’espace de noms, c’est les valeurs de propriété (y compris si oui ou non les propriétés sont privées, protégées, publiques, etc.).

À partir de là, vous pouvez ensuite effectuer un peu de débogage si la sortie correspond à ce que vous n’attendiez pas ou peut-être pouvez-vous l’utiliser pour vérifier que votre code fait ce que vous attendez.

Ce n’est qu’un exemple, cependant. Vous pouvez cependant vider les valeurs de la variable $storage avant même de parcourir la boucle. Ce choix dépend vraiment de vous et de ce que vous cherchez à réaliser.

Utilisation des plugins installés

À ce stade, nous avons couvert les aspects fondamentaux du code de débogage grâce à l’utilisation de journaux d’erreurs.

Cependant, nous devons maintenant porter notre attention sur les plugins dont il a été question il y a quelques articles. Après cela, nous finirons par nous frayer un chemin jusqu’à Xdebug.

Mais ensuite, nous examinerons les outils à notre disposition depuis WordPress lui-même.