Los registros permiten relacionar una petición fallida con el código PHP, pero los errores visibles pueden revelar rutas del servidor, fragmentos de base de datos, secretos y datos personales. En producción deben escribirse en una ubicación protegida mientras se mantiene desactivada su visualización en el navegador.
Activa el registro durante una ventana de incidencia definida, reproduce el fallo una vez y retira después los archivos que ya no sean necesarios.
Revisa primero los registros del alojamiento
cPanel, Plesk y muchos alojamientos gestionados ya ofrecen registros de PHP-FPM y del servidor web. Anota su zona horaria, conservación y el dominio y controlador PHP que cubren.
Si el registro existente contiene el error fatal, utilízalo. Duplicar registros consume disco y recopila más información sensible.
No descargues el registro completo de la cuenta cuando basta con unos minutos alrededor de la incidencia.
Haz copia de la configuración
Copia wp-config.php a una ubicación protegida y confirma cuál es la raíz activa de WordPress. En multisitio o configuraciones desplazadas, otro archivo puede definir las constantes de depuración.
Busca definiciones existentes de WP_DEBUG. Declarar dos veces una constante genera avisos y hace confuso su valor efectivo.
Si la administración falla, no edites desde WordPress; utiliza un gestor de archivos, SFTP o SSH autorizado.
Configura el registro de WordPress
Coloca estas definiciones antes de la línea final «stop editing»:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_LOG escribe normalmente en wp-content/debug.log. Recoge los mensajes de WordPress y PHP que alcanzan esta configuración, no todos los fallos de PHP-FPM o del servidor web.
No actives display_errors en una web pública.
Elige una ubicación protegida
Cuando sea compatible, establece en WP_DEBUG_LOG una ruta absoluta fuera del directorio público:
define( 'WP_DEBUG_LOG', '/protected/path/wordpress-debug.log' );El usuario PHP necesita escribir en el archivo, pero ningún visitante debe poder descargarlo. Utiliza una ruta facilitada por el hosting en vez de inventar permisos.
Nunca hagas escribible para cualquiera todo el directorio.
Configura el registro de PHP
Algunos errores suceden antes de que cargue WordPress. Desde cPanel, Plesk o la configuración PHP activa, habilita log_errors y selecciona un error_log protegido.
Confirma que PHP web y CLI utilizan los archivos de configuración previstos. Recarga PHP solo mediante controles compatibles.
No guardes credenciales en comentarios de php.ini ni en páginas públicas de diagnóstico.
Reproduce con una hora exacta
Anota hora, URL o acción, estado del usuario y una referencia que no contenga datos privados. Reproduce una vez y consulta únicamente las nuevas líneas.
Extrae:
clase del error
mensaje
archivo y línea
pila de llamadas
referencia de la peticiónOculta cookies, valores de consulta, nombres de cuenta del servidor y datos personales antes de compartir.
Anonimiza sin destruir la prueba
Conserva la clase del error, la ruta relativa del componente, línea, hora y un identificador generado. Sustituye de forma consistente correos, IP, tokens y valores para poder reconocer referencias repetidas.
No confíes en una expresión regular genérica: puede dejar secretos dentro de arrays. Revisa manualmente el fragmento antes de enviarlo y confirma si el receptor necesita toda la traza o solo el error principal.
Controla el crecimiento
Un aviso dentro de un bucle puede llenar el disco rápidamente. Vigila el tamaño y detén el registro si crece de forma anormal.
Utiliza la rotación del alojamiento y una conservación limitada. No ejecutes una limpieza genérica que pueda eliminar registros de auditoría u otras aplicaciones.
La falta de disco crea nuevos fallos, así que el propio registro no debe convertirse en la incidencia.
Desactiva y verifica
Después de reparar, pon WP_DEBUG a false o restaura la configuración anterior, elimina diagnósticos temporales y confirma que los visitantes siguen sin ver errores.
Conserva solo el extracto anonimizado necesario para documentar la incidencia y elimina los archivos según la política establecida.
El mantenimiento recurrente debería centralizar errores fatales protegidos y alertar ante firmas nuevas. Un registro seguro proporciona pruebas suficientes para reparar sin convertir información interna en contenido público.