Cada vez que estoy trabajando en un proyecto, a menudo tengo WordPress configurado en modo de depuración, y me gusta escribir mensajes en el registro de errores que puedo ver, rastrear y seguir fácilmente cuando estoy trabajando en un proyecto.
Cuando hago esto, hay dos formas (y solo depende del proyecto):
- Usaré una biblioteca como Monolog ,
- Usaré mi propia función de registro simple.
En esta publicación, voy a cubrir esto último. Es decir, voy a compartir cómo escribo mensajes en el registro de depuración de WordPress y luego algunas de las cosas a las que debe prestar atención cuando esté haciendo lo mismo.
El registro de depuración de WordPress
En primer lugar, es importante tener en cuenta que la función que voy a compartir suele estar en el contexto de una clase base.
Digamos que tengo un AbstractSubscriber que todos mis suscriptores implementan (como un ScriptAssetSubscriber para registrar y poner en cola el archivo JavaScript).
AbstractSubscriber incluirá esta función para que cualquier clase secundaria pueda llamarla. La función es bastante 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;
}
}Pero hay varias cosas sobre esta función que pueden violar un principio o desencadenar errores en las herramientas de calidad del código.
Argumentos booleanos opcionales
Cada vez que una función acepta un argumento booleano opcional, puede indicar que una función tiene más de una responsabilidad (violando así el principio de responsabilidad única ).
La razón por la que esto violaría dicho principio es que le da a un módulo más de una razón para cambiar.
Me siento cómodo al permitir que esto se escriba de esta manera porque lo uso para la depuración, no para entornos de producción, y porque hay ocasiones en las que es posible que desee detener la ejecución y otras veces no.
Y claro, podría escribir dos funciones separadas, pero si esta es la única función que hace esto, estoy de acuerdo con eso.
Declaraciones de salida prohibida
A otras herramientas de calidad de código no les gusta la declaración de salida (y, de manera similar, no les gusta la declaración de morir ). Y es comprensible: por lo general, detienen el programa por completo cuando deberíamos lanzar una excepción, devolver un valor o, en general, hacer algo para manejar la situación con gracia.
Una vez más, sin embargo, debido a que en esta función hay momentos en los que quiero detener la ejecución, estoy de acuerdo con las consecuencias de tener la línea de código en la función.
Alternativamente, podría usar wp_die(), y la mayoría de las herramientas de calidad de código probablemente no lo detectarían, pero eso enmascara el problema principal. En todo caso, tal vez sea mejor simplemente suprimir la advertencia usando cualquier directiva que su sniffer de elección pueda permitir.
Independientemente, registre el mensaje
En última instancia, el propósito de la función anterior es proporcionar una forma sencilla de escribir en el registro de depuración de WordPress y, opcionalmente, detener la ejecución del programa al hacerlo.
Claramente no está exento de problemas, y hay bibliotecas de mayor calidad disponibles, pero a veces no necesitas un mazo para una chincheta de problemas.