Chaque fois que je travaille sur un projet, j’ai souvent WordPress en mode débogage et j’aime écrire des messages dans le journal des erreurs que je peux facilement visualiser, suivre et suivre chaque fois que je travaille sur un projet.
Lorsque je fais cela, il y a deux façons (et cela dépend simplement du projet):
- Je vais utiliser une bibliothèque telle que Monolog ,
- Je vais utiliser ma propre fonction de journal simple.
Dans cet article, je vais couvrir ce dernier. Autrement dit, je vais partager comment j’écris des messages dans le journal de débogage de WordPress, puis certaines des choses auxquelles vous devrez peut-être faire attention chaque fois que vous faites la même chose.
Le journal de débogage de WordPress
Tout d’abord, il est important de noter que la fonction que je vais partager se situe généralement dans le contexte d’une classe de base.
Disons que j’ai un AbstractSubscriber que tous mes abonnés implémentent (comme un ScriptAssetSubscriber pour l’enregistrement et la mise en file d’attente du fichier JavaScript).
Le AbstractSubscriber inclura cette fonction afin qu’elle puisse être appelée par n’importe quelle classe enfant. La fonction est assez simple :
<?php
/**
* Prints a message to the debug file that can easily be called by any subclass.
*
* @param mixed $message an object, array, string, number, or other data to write to the debug log
* @param bool $shouldNotDie whether or not the The function should exit after writing to the log
*
*/
protected function log($message, $shouldNotDie = true)
{
error_log(print_r($message, true));
if ($shouldNotDie) {
exit;
}
}Mais il y a plusieurs choses à propos de cette fonction qui peuvent violer un principe ou déclencher des erreurs dans les outils de qualité du code.
Arguments booléens facultatifs
Chaque fois qu’une fonction accepte un argument booléen facultatif, cela peut indiquer qu’une fonction a plus d’une responsabilité (violant ainsi le principe de responsabilité unique ).
La raison pour laquelle cela violerait ledit principe est que cela donne à un module plus d’une raison de changer.
Je suis à l’aise de permettre que cela soit écrit de cette façon parce que je l’utilise pour le débogage, pas pour les environnements de production, et parce qu’il y a des moments où je peux vouloir arrêter l’exécution, et il y a des moments où je ne le fais pas.
Et bien sûr, je pourrais écrire deux fonctions distinctes, mais si c’est la seule fonction qui fait ça, ça me va.
Déclarations de sortie interdites
D’autres outils de qualité de code n’aiment pas l’ instruction exit (et, de même, ils n’aiment pas l’ instruction die ). Et c’est compréhensible: ils arrêtent généralement le programme lorsque nous devrions lancer une exception, retourner une valeur ou faire quelque chose pour gérer la situation avec élégance.
Encore une fois, cependant, parce que dans cette fonction, il y a des moments où je veux arrêter l’exécution, je suis d’accord pour gérer les conséquences d’avoir la ligne de code dans la fonction.
Alternativement, je pourrais utiliser wp_die(), et la plupart des outils de qualité de code ne l’attraperaient probablement pas, mais cela masque le problème principal. Si quoi que ce soit, il est peut-être préférable de simplement supprimer l’avertissement en utilisant la directive que votre renifleur de choix peut autoriser.
Quoi qu’il en soit, enregistrez le message
En fin de compte, le but de la fonction ci-dessus est de fournir un moyen simple d’écrire dans le journal de débogage de WordPress et éventuellement d’arrêter l’exécution du programme en le faisant.
Ce n’est clairement pas sans problèmes, et il existe des bibliothèques de meilleure qualité qui sont disponibles, mais parfois vous n’avez pas besoin d’un marteau pour une punaise problématique.