Activar modo debug WordPress

Introducción al modo debug WordPress

Ver la famosa «pantalla blanca de la muerte» no es una experiencia agradable. Ahí te quedas, mirando el monitor sin saber qué pasó. Para el usuario medio es un momento de pánico, pero para quien administra sistemas, ese es el momento de actuar. El modo debug WordPress es tu primera herramienta de defensa. Lo que hace es simple: saca a la luz los avisos, advertencias y errores que el CMS suele ocultar para que el visitante no vea «fealdades». Activarlo es la diferencia entre tener un problema abstracto y tener una dirección concreta hacia la solución.

WordPress, por defecto, es muy educado y esconde estos errores para mantener el diseño limpio. Y por seguridad, claro está. Pero cuando estás arreglando algo o en medio de una crisis técnica, necesitas levantar el velo. Vamos a ver cómo se enciende esta luz y qué hacer con lo que te muestra.

¿Por qué es crucial activar la depuración?

Nadie busca tecnicismos por aburrimiento; suele ser porque algo se rompió y hay urgencia. Sin el modo debug, vas a ciegas. Es como intentar arreglar un motor sin abrir el capó: puedes cambiar piezas al azar, pero si no sabes qué falla, perderás el tiempo. La depuración te dice exactamente qué archivo de PHP está dando problemas, qué función generó el aviso o si hay un conflicto de versiones entre plugins.

Y no es solo de arreglar roturas. Los errores ignorados se acumulan. Ensucian la base de datos o comen recursos del servidor. Habilitar este modo no solo ayuda a poner parches; optimiza el rendimiento a largo plazo.

Paso a paso: Editar el archivo wp-config.php

La forma seria, la robusta, de habilitar esto es tocando el archivo wp-config.php. No hay otra. Este archivo vive en la raíz de tu instalación. Olvida el panel de administración: si el error es tan grave que no te deja entrar al backend, tampoco podrás activar ningún plugin desde ahí. Tienes que ir a la raíz.

Ubicación y acceso al archivo

Necesitas entrar a tu servidor. Usa un cliente FTP (FileZilla es el clásico) o el administrador de archivos de tu hosting (cPanel, Plesk). Busca wp-config.php en la carpeta pública (public_html o www). Y hazme caso: antes de tocar nada, haz una copia de seguridad de ese archivo.

Constantes principales de depuración

Dentro del wp-config.php, busca la línea que pone «That’s all, stop editing!» (o su traducción). El código va justo antes de eso. Estas son las constantes que te interesan:

• WP_DEBUG: El interruptor principal. Viene en false. Cámbialo a true para que empiece la fiesta.
• WP_DEBUG_LOG: Si pones esto en true, WordPress guardará todos los errores en un archivo de texto, debug.log, dentro de /wp-content/. Vital para cuando no quieres que los usuarios vean los errores en pantalla.
• WP_DEBUG_DISPLAY: Esto controla si se muestran los errores en el navegador. En un sitio en vivo, esto mejor en false. Deja que el WP_DEBUG_LOG haga el trabajo sucio.

Código de implementación recomendado

Toma este bloque. Es el estándar. Cópialo y pégalo asegurándote de que no se cuelen espacios raros:

define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
@ini_set( ‘display_errors’, 0 );

Esta configuración es la ideal para producción. Captura lo que pasa para que tú lo revises después, pero mantiene la fachada limpia para el visitante. No es buena idea enseñar los fallos técnicos del servidor al mundo.

Revisando el archivo debug.log

Una vez activado el registro, provoca el error o navega por la zona fallida. Luego vuelve al servidor y ve a /wp-content/. Allí te esperará el archivo debug.log.

Interpretar los errores comunes

Al abrirlo puede dar vértigo. Tanta información. Pero filtra. Fíjate en las líneas que empiezan con «Fatal error», «Warning» o «Notice». Te resumo los clásicos:

• Fatal error: Allowed memory size exhausted… – Te has quedado sin memoria RAM. Suele arreglarse subiendo el límite de memoria PHP en el servidor o desactivando los plugins más pesados.
• Fatal error: Call to undefined function… – Algo (un plugin o tema) está llamando a una función que no existe. Normalmente es un problema de compatibilidad de versiones.
• Warning: Cannot modify header information… – El error favorito de los espacios en blanco. Significa que hay espacios antes de la etiqueta <?php en algún archivo.

Depuración en entornos de desarrollo vs. producción

No es lo mismo trabajar en tu ordenador (staging/local) que en un sitio real donde la gente entra. Ojo con eso.

Desarrollo o Staging

Si estás construyendo o probando, pon WP_DEBUG y WP_DEBUG_DISPLAY ambos en true. Quieres ver el error ahí mismo, en tu cara, para corregirlo ya. Aquí la prioridad es la velocidad.

Sitio en vivo (Producción)

Aquí no se juega. Nada de errores visibles. Un mensaje de error puede enseñar la ruta de tus archivos, detalles de la base de datos… un manjar para quien busque hacer daño. Usa la combinación de Log activado y Display desactivado. Revisa el log cuando notes cosas raras.

Plugins como alternativa temporal

Mi recomendación siempre es editar el wp-config.php. Es lo más seguro. Ahora bien, hay plugins como «Query Monitor» o «Debug Bar» que facilitan la vida mostrando datos en la barra de administración.

Son buenos para ver consultas a la base de datos, ganchos (hooks) y tiempos de carga. Pero tienen un talón de Aquiles: si el error es un «Fatal Error» que detiene PHP, el plugin no carga. Y si no carga, no ves nada. Para los errores que rompen el sitio del todo, el método del archivo de configuración no falla.

Soluciones avanzadas con WP_DEBUG

Si quieres control total, hay más constantes que puedes añadir al archivo wp-config.php.

SCRIPT_DEBUG

WordPress, por defecto, usa versiones «minificadas» (comprimidas) de CSS y JS. Bien para la velocidad, mal para encontrar errores. Si añades define( 'SCRIPT_DEBUG', true );, forces al CMS a usar las versiones de desarrollo. Así ves en qué línea exacta de un JavaScript o CSS está el fallo en la consola del navegador.

SAVEQUERIES

¿Tu base de datos va lenta? Esto ayuda. Define define( 'SAVEQUERIES', true );. Guardará cada consulta a la base de datos en un array para que la analices. Ojo, que esto consume recursos, úsalo con cuidado y solo por un rato. Para ver los resultados, tendrás que poner un poquito de código en tu footer.php para imprimir el array $wpdb->queries.

Conclusión

Saber activar el modo debug WordPress no es opcional si te tomas en serio el mantenimiento web. Es una habilidad básica. Ya sea editando el wp-config.php o revisando el debug.log, esto te saca de las suposiciones y te lleva a los hechos. Identificar un «Warning» de memoria o un «Fatal Error» te da el poder para arreglar conflictos, actualizar temas o ajustar el servidor.

La seguridad y la velocidad dependen de un código limpio. Cuando arregles el problema, recuerda devolver la configuración a su estado original. Si te atascas con un error complejo, en RedServicio (redservicio.net) estamos para ayudarte a recuperar la estabilidad de tu web.