Guía para decidir mejor
Cómo activar y leer el registro de errores de WordPress
Reproduce el fallo, identifica la línea útil y evita exponer datos en debug.log.
Para activar y leer el registro de errores de WordPress, empieza por precisar qué falla y a qué hora. Un archivo lleno de avisos antiguos no demuestra la causa del incidente actual. El objetivo es reproducir una petición, relacionarla con una línea fechada del log y desactivar el diagnóstico temporal sin exponer rutas o datos personales.
Antes de activar la depuración
Haz una copia de wp-config.php y, si vas a probar un cambio, una copia recuperable de archivos y base de datos. Anota si el problema afecta a portada, administración, una tarea programada o solo al checkout. En una tienda no desactives plugins de pago para «generar» el error mientras haya ventas. Revisa primero el registro PHP del panel: puede contener la traza sin cambiar WordPress. Si hay staging que reproduce el fallo, úsalo para pruebas más invasivas.
Configura un registro temporal sin mostrar errores al visitante
En wp-config.php, antes de la línea que carga wp-settings.php, establece WP_DEBUG en true, WP_DEBUG_LOG en true y WP_DEBUG_DISPLAY en false. Si ya están definidos, modifica sus valores existentes en lugar de duplicar constantes. La guía oficial de depuración explica su función; WordPress suele escribir en wp-content/debug.log, aunque también admite una ruta explícita. Ese archivo puede ser descargable desde la web según la configuración: limita el acceso, usa una ruta fuera del directorio público cuando el entorno lo permita y elimina o rota los datos al terminar. No copies el log completo en un ticket abierto.
Lee la línea útil, no solo la última
- Reproduce una vez la URL o acción afectada y apunta la hora con zona horaria.
- Busca entradas de ese intervalo. Separa Fatal error de Warning o avisos deprecados; los últimos pueden ser importantes, pero no siempre causan la caída.
- Identifica archivo, línea y primera excepción de la cadena. Una traza que termina en WordPress core puede haber empezado en un plugin, tema o código propio.
- Contrasta con logs web/PHP si el archivo queda vacío: quizá la petición no llegó a WordPress, el proceso no pudo escribir o el fallo ocurre antes de su carga.
Ejemplo de método, no de un incidente de IDEIHOSTING: si guardar una entrada provoca un error a las 10:15 y la traza nombra una función de un plugin actualizado ese día, prueba esa versión en staging y verifica si se repite. No elimines el plugin ni aumentes recursos sin aislar la causa.
Cierra el diagnóstico
Devuelve la configuración de depuración a su estado acordado, protege o retira el log temporal y comprueba la misma operación, una página pública y el panel. Si se trataba de un error 500 o del mensaje de error crítico, sigue esas guías para decidir la corrección. Para pedir asistencia, envía hora, ruta y extracto saneado por un canal seguro, nunca credenciales ni datos de clientes.
Cuando el log de WordPress no muestra el origen, revisa también los registros de acceso y error del servidor en la misma ventana temporal.