Depurar WordPress sin sufrir: cómo mejora Acorn la salida de WP_DEBUG

En desarrollo, WP_DEBUG es de esas constantes que deberían estar activadas siempre: te avisa de notices, warnings y errores que, si los dejas pasar, terminan convirtiéndose en bugs difíciles de rastrear en staging o producción. El problema es que la experiencia “de serie” en WordPress es bastante espartana: te imprime mensajes en pantalla y poco más.

Si trabajas con stacks modernos alrededor de WordPress (por ejemplo Bedrock, el boilerplate de Roots gestionado con Composer), la parte buena es que el modo debug ya suele venir activado en entornos de desarrollo. La parte mejor es que, si además usas Acorn, el salto de calidad en el manejo de excepciones es enorme: pasas de texto suelto a páginas de error estructuradas, con stack traces navegables y contexto útil.

Qué hace realmente WP_DEBUG (y por qué su salida se queda corta)

WP_DEBUG es el interruptor principal del modo debug en WordPress. Cuando está activo, WordPress muestra (y/o registra) avisos y errores de PHP que, de otro modo, podrían quedar ocultos. En un proyecto con plugins, mu-plugins y temas de terceros, esto es oro: el ecosistema está lleno de extensiones que emiten notices constantemente.

El punto débil es la presentación: el output por defecto tiende a aparecer incrustado en la página, sin estructura, con poca jerarquía visual y sin herramientas para inspeccionar rápidamente dónde se originó el problema.

Acorn y el “debug moderno” en WordPress

Acorn es el framework de Roots que lleva piezas del ecosistema Laravel a WordPress (contenedor, configuración, helpers, y en versiones recientes también routing). En la práctica, además de mejorar tu arquitectura PHP, también mejora la experiencia de depuración cuando tienes WP_DEBUG activo.

Salida por defecto con Acorn: manejador de excepciones de Symfony

De base, Acorn utiliza el exception handler de Symfony para renderizar errores. La diferencia es inmediata: obtienes una página de excepción más legible, con un formato consistente y un stack trace más fácil de seguir que el texto plano incrustado en el HTML.

Ignition en WordPress con Acorn v3: experiencia tipo Laravel

Si vienes de Laravel, probablemente te suene Ignition: es la página de error por defecto en Laravel desde la v9 y destaca por lo bien que guía durante la depuración. Con Acorn v3 llega un detalle clave: al incorporar soporte de routing al estilo Laravel, también se habilita el uso de Ignition en sitios WordPress que usan Acorn.

Roots recomienda instalar Ignition para tener “la mejor experiencia” de manejo de errores en WordPress cuando estás en un stack con Acorn.

Para empezar a usar Ignition en un proyecto WordPress con Acorn, la instalación se hace vía Composer (en modo desarrollo) desde el mismo directorio donde tengas Acorn:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

Whoops: la opción clásica (sobre todo si sigues en Acorn v2)

Antes de Acorn v3, una recomendación habitual era instalar whoops (la librería de filp) para tener páginas de error más amigables. Si estás en Acorn v2, sigue siendo una mejora posible frente a la página de Symfony, aunque la recomendación general es actualizar a Acorn v3 cuando te encaje.

Si no usas Acorn: plugins que mejoran la depuración en WordPress

Aunque Acorn es una solución muy potente cuando construyes WordPress con una base más moderna (y además te abre la puerta a cosas como los Laravel helpers, es decir, funciones utilitarias muy prácticas del framework), no siempre encaja en todos los proyectos. Si estás en un WordPress más tradicional, hay alternativas en forma de plugins que ayudan mucho en local.

• Query Monitor: prácticamente imprescindible en un entorno local; aporta visibilidad sobre consultas, hooks, HTTP, errores y mucho más. https://querymonitor.com/
• Debug Bar: añade una barra de depuración con información útil durante el desarrollo. https://wordpress.org/plugins/debug-bar/

Resumen práctico

1. Activa WP_DEBUG siempre en desarrollo para detectar avisos y errores cuanto antes.
2. La salida por defecto de WordPress cumple, pero es poco legible cuando el problema escala.
3. Con Acorn, el manejo de excepciones mejora automáticamente (Symfony handler) cuando WP_DEBUG y WP_DEBUG_DISPLAY están habilitados.
4. En Acorn v3, puedes usar Ignition (vía Composer) para una experiencia de depuración tipo Laravel.
5. Si no usas Acorn, Query Monitor y Debug Bar son dos herramientas muy sólidas para mejorar el debugging en local.