Lectura y comprensión de los registros de errores de WordPress, Parte 1

A medida que continuamos analizando lo que significa ser un desarrollador independiente de WordPress, las herramientas necesarias y las diversas estrategias que pueden mejorar nuestro conjunto de habilidades, he estado hablando sobre las diversas constantes, complementos y herramientas para ayudarnos.

Si simplemente se está tropezando con esta publicación, le recomiendo que consulte mi guía de herramientas de depuración nativas de WordPress, así como el resto de las publicaciones de la serie hasta el momento.

Después de todo, me parece importante que todos estemos trabajando sobre la misma base, o algo estrechamente relacionado, cuando analizamos esta información.

En última instancia, usar una herramienta como Xdebug es indispensable, pero tenemos que trabajar en eso (para aquellos que tienen curiosidad, escribí una breve guía sobre esto hace poco más de un año).

Sin embargo, por ahora, comencemos con lo básico. En la publicación anterior, me fui con la siguiente declaración:

En la próxima publicación, comenzaremos a analizar lo que es necesario para examinar el registro de errores que genera WordPress y cómo comprender la información que vemos.

Y eso es lo que quiero ver hoy porque, al menos, les dará algo práctico sobre lo cual trabajar.

Comprender los registros de errores de WordPress, parte 1

Antes de profundizar demasiado en esto, quiero abordar una pregunta que planteó un miembro del sitio.

Es decir, me preguntaron:

¿Cuándo vamos a ver los principios orientados a objetos?

Aunque he cubierto un poco sobre esto en una serie anterior, es algo en lo que estoy trabajando para cubrir más a fondo más adelante en esta serie.

Sin embargo, dicho esto, comencemos a ver los registros de errores.

Configurando sus constantes

Si no ha configurado las constantes en su archivo wp-config.php, le recomiendo que lo haga ahora, ya que esto le brindará el mayor nivel de granularidad al examinar cualquier problema que pueda surgir.

Si no se ha puesto al día, asegúrese de leer esta publicación (y si lo ha hecho, asegúrese de que las siguientes constantes estén definidas en su archivo de configuración):

<?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 );

Una vez que estén en su lugar, tendrá todo lo que necesita no solo para ver la información en la pantalla, sino también en el registro de depuración que generará WordPress.

¿Dónde está el registro?

Dependiendo de la naturaleza de su entorno, esto puede variar; sin embargo, en la mayoría de los casos, encontrará debug.log en el directorio wp-content que se encuentra sobre los directorios de complementos, temas y cargas.

Como puede ver en la vista previa de la captura de pantalla anterior, mi archivo de depuración tiene mucho contenido. Echaremos un vistazo a eso más en profundidad en la siguiente sección, así como también cómo entenderlo. Mientras tanto, sin embargo, verifique si este archivo existe. Si es así, siéntase libre de seguir adelante y leer detenidamente el contenido del archivo. Puede o no entender gran parte de lo que está sucediendo, pero el contenido del archivo significa que algo en un tema o complemento está activando varias advertencias, avisos y errores de PHP que WordPress detecta y descarga en el archivo de registro.

¿Qué significa el archivo de registro?

Esto no significa necesariamente que algo esté roto, pero indica que algo no está funcionando como debería, que no se está capturando y manejando adecuadamente a nivel programático, o simplemente está haciendo algo que no debería estar haciendo.

No tiene que verse así (¡pero puede!).

Como desarrolladores, debemos esforzarnos por asegurarnos de que nuestro código no genere nada que se escriba en el registro de errores.

Una cosa es hacerlo en desarrollo, ya que podemos obtener información sobre qué es lo que estamos haciendo y cómo funciona WordPress. Sin embargo, otra cosa es que algo que lanzamos a nivel de producción genere tales cosas.

Lectura del registro de errores

Obviamente, hay más para leer el registro de errores en lugar de simplemente abrirlo. Para muchos, la impresión inicial es que puede ser un montón de jerga. Yo también entiendo eso. Pero cuando entiendes lo que te está mostrando, es mucho más fácil de entender.

Así que echemos un vistazo a un ejemplo realmente simple. Este tampoco es un ejemplo artificial. De hecho, este es uno que proviene de un complemento en el que estaba trabajando. El registro de errores contiene la siguiente información :

[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

Observe que, en la esencia anterior, hay tres líneas. El mejor curso de acción al leer los registros de errores es comenzar desde abajo y avanzar hacia arriba. Esto se debe a que las cosas, cuando se ejecutan en ejecución, operan en una pila.

Una breve digresión sobre las pilas

No entraré en la definición informática del término, pero el código se ejecuta y funciona de tal manera que las funciones ocurren y, literalmente, en la memoria de una computadora, se apilan una encima de la otra.

Por lo tanto, lo más reciente que se ejecute siempre estará en la parte superior, donde la raíz de donde comienza está en la parte inferior. Ya que estamos escribiendo código en una aplicación preexistente, eso es WordPress; entonces es probable que nuestro código siempre esté en la parte superior.

Comprender los registros de errores de WordPress: no es este tipo de pila

La idea es que el código comience a ejecutarse en WordPress y avance hasta el trabajo que estamos haciendo. Cuando hay un aviso, una advertencia o un error, generalmente será algo en nuestro código (aunque WordPress no está exento, ese es generalmente el caso).

Entonces, cuando lee el registro de errores, está, en esencia, leyendo lo que se llama un seguimiento de la pila. Wikipedia, como está vinculado, tiene una definición bastante detallada sobre el tema, pero quizás la parte más relevante de esta publicación es la siguiente:

Los programadores suelen utilizar el seguimiento de pila durante la [depuración] interactiva y post-mortem (https://en.wikipedia.org/wiki/Debugging). Los usuarios finales pueden ver un seguimiento de la pila que se muestra como parte de un mensaje de error, que luego el usuario puede informar a un programador.

Esto concuerda con lo que he esbozado anteriormente, ¿verdad? Pero basta de hablar sobre qué es un seguimiento de pila (se volverá más claro a medida que profundicemos en la depuración), volvamos a leer el archivo de registro tal como está actualmente.

Volver a Leer el registro

Incluyendo archivos

Primero, veamos el resultado final en la esencia anterior. Contiene lo siguiente:

[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

Esto me dice que en la línea 25 de mi archivo, easy-email-export.php, no pudo abrir un archivo para su inclusión. Esto significa que tengo una instrucción include_once en el código que hace referencia a ./src/Admin/EmailExportSubmenu.php que no puede encontrar.

Entonces, el mejor curso de acción sería encontrar la línea 25 y determinar por qué no está localizando el archivo. Tal vez eso es descargar el camino completo en cuanto a dónde está mirando. Llegaremos a esto momentáneamente cuando hablemos de escribir en el registro de errores.

Dar sentido a los errores

En la siguiente línea (es decir, la línea encima de la que acabamos de ver) contiene lo siguiente:

[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

Esta línea en particular difiere solo un poco, pero brinda información adicional y está contenida en la cláusula que dice "No existe tal archivo o directorio". Esto es revelador porque literalmente nos dice que el archivo no existe.

Al menos, no existe donde está mirando. Entonces las dos posibilidades son:

1. no hemos creado el archivo al que hacemos referencia,
2. estamos haciendo referencia a la ubicación del archivo en el lugar equivocado

Por lo tanto, lo primero que tendríamos que verificar es si el archivo existe en la ubicación que estamos tratando de incluir. Si no es así, entonces debemos crear el archivo.

Si el archivo existe, entonces sabemos que el complemento está buscando cargarlo desde la ruta incorrecta. Por lo tanto, es posible que debamos mirar nuestro cargador automático, nuestra ruta de inclusión o cómo se recuperan los archivos. Porque, lo más probable es que si el archivo existe, entonces está tratando de cargarse desde un lugar en el que no reside.

Un error no detectado

En la línea final del código, verá algo como esto:

[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

Este es un buen ejemplo, en primer lugar, porque declara explícitamente que se trata de un error no detectado. Esto significa que cualquiera que sea la funcionalidad, algo arroja un error y no se detecta.

• esto podría ser una excepción,
• esto podría ser un problema al tratar de llamar a una función que no existe,
• esto podría estar operando en una variable que no está definida,
• y así.

En última instancia, hay una plétora de problemas que podrían estar presentes. La buena noticia, en este ejemplo, es que es prácticamente lo mismo que el anterior: No se encuentra un archivo.

Excepto que, en lugar de lanzar una advertencia, PHP explícitamente nos sigue, esto es un error fatal y el programa no puede continuar la ejecución hasta que se resuelva esta línea de código. Antes de descartar esto como algo que es igual a la sección anterior (porque, por así decirlo, lo es), debemos reconocer que esto se establece explícitamente como un error fatal mientras que, en el ejemplo anterior, se trató como un advertencia.

Hay diferentes formas de conceptualizar esto, pero la forma en que generalmente lo pienso es esta:

• Un aviso me dice que algo no está bien en el código, pero no es lo suficientemente malo como para justificar la detención de la ejecución.
• Una advertencia es un poco más grave porque significa que algo está en peligro de no funcionar.
• Un error directamente dice "esto no funciona y el programa no puede continuar".

Ahora sabemos que el problema es espectacular, por así decirlo, y sabemos cuál es el problema. En pocas palabras, no se encuentra un archivo que se requiere para que el programa complete su ejecución y, por lo tanto, el programa deja de funcionar.

Eso es ciertamente un error fatal.

¿Cual es la solución?

Lo que brindo como solución a mi problema no será prescriptivo en cuanto a lo que funcionará para usted. Para mí, era cuestión de una línea en mi configuración de Composer, de modo que el cargador automático de Composer no pudiera ubicar el archivo en la ubicación adecuada (pero esto tiene más que ver con la organización de archivos, el espacio de nombres, etc.).

Para ti, puede ser algo diferente.

• tal vez esté buscando un archivo en el directorio equivocado,
• tal vez el archivo tenga un nombre diferente al especificado en el código,
• o tal vez es otra cosa.

Cualquiera que sea el caso, el punto es que se trata de abrirse camino a través del archivo de registro de abajo hacia arriba para diagnosticar el problema y rastrear lo que está haciendo PHP, WordPress y su trabajo y luego diagnosticarlo desde allí.

Escribir en el registro de errores

En la próxima publicación, nos tomaremos un momento para ver cómo podemos escribir en el registro de errores. A veces, leer el archivo está bien y simplemente ir y venir entre lo que estamos viendo y resolver los problemas está bien.

Pero, ¿qué pasa en el caso de que queramos volcar algo para obtener información sobre lo que está viendo WordPress o PHP? Eso también es útil.

Entonces, en la siguiente parte de esta serie sobre la comprensión de los registros de errores de WordPress, haremos exactamente eso.

¿Qué hay después de eso?

A continuación, veremos cómo usar algunos de los complementos descritos anteriormente para probar el código y también para perfilar nuestro código para asegurarnos de que hemos hecho todo lo posible para garantizar que estamos produciendo un nivel de calidad.

Esto no significa que hayamos terminado por completo con el proceso de depuración, pero definitivamente estamos un paso más cerca y estamos posicionados para escribir código con un grado de calidad que no resulta en un archivo que representa varios problemas matizados. fuimos demasiado descuidados para arreglar (y mucho menos entender).