Uso

Una vez el plugin configurado y activado, ya no hay nada que llamar desde su código. El plugin instala automáticamente los handlers PHP globales y reporta los problemas por usted.

Qué se captura automáticamente

Cuando el plugin está activado con una clave de proyecto válida (una URL de servidor vacía equivale al servicio alojado), registra tres handlers PHP globales (a través del ErrorHandler del núcleo):

• Excepciones no interceptadas: todo Throwable que llega al gestor de excepciones de PHP se reporta.
• Errores PHP: un error producido durante la petición se encapsula en una excepción y se reporta cuando su severidad es E_USER_ERROR o E_RECOVERABLE_ERROR. El handler respeta la supresión mediante @ y su nivel error_reporting, y deja que el gestor nativo de PHP se ejecute a continuación: el comportamiento existente permanece por tanto sin cambios.
• Errores fatales: al final del script, el plugin inspecciona el último error y lo reporta si era fatal (E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR). Así es como un error fatal que termina la petición llega de todos modos a su panel.

Cada informe contiene la clase, el mensaje, el archivo y la línea de la excepción, así como la traza de pila completa por defecto (trace_limit vale 0); un valor positivo de trace_limit recorta la traza a ese número de frames. La release configurada se adjunta a cada evento.

Por qué no se reportan las advertencias ni los notices

Antes se transmitía toda severidad, con una llamada HTTP síncrona cada una. En WordPress, la advertencia de cualquier tema o extensión llega a este handler: una sola advertencia dentro de un bucle sobre quinientas filas eran por tanto quinientas llamadas bloqueantes en una carga de página, lo que desde el punto de vista del visitante es una caída, y la cuota mensual de un plan gratuito consumida en un día.

A ese umbral se añaden dos protecciones: el mismo error en el mismo archivo:línea se reporta una sola vez por petición, y se reportan veinte errores como máximo en una petición, porque un umbral no ve un bucle. Los apagados fatales no se ven afectados: los captura el hook de apagado, no este handler.

El envío de informes está diseñado para no romper nunca su sitio: si el servidor es lento o inaccesible, la página sigue mostrándose.

Verificar el funcionamiento

Después de guardar sus ajustes, provoque un error inofensivo y confirme que aparece en su panel Quiet Guard para el proyecto. Una forma rápida consiste en añadir temporalmente un fragmento a un tema o a un pequeño plugin "must-use":

add_action('init', function () {
    throw new RuntimeException('Quiet Guard test exception');
});

Cargue una vez cualquier página del sitio y consulte después las Issues del proyecto en el panel, debería aparecer una RuntimeException con el mensaje "Quiet Guard test exception". Retire el fragmento después.

Si no llega nada, verifique de nuevo que:

• Enabled vale 1 y que Project key está definida;
• la Server URL es opcional: vacía, equivale al servicio alojado; rellenada, es la dirección de su servidor (un /api o /api/v1 final se acepta, cualquier otra ruta no);
• el servidor es accesible por HTTPS desde el host WordPress;
• el directorio del plugin se construyó con composer install, de modo que su directorio vendor/ existe (vea la Instalación).

Después lea el log. El plugin escribe sus propios diagnósticos con error_log(), es decir, en wp-content/debug.log allí donde WP_DEBUG_LOG está activo: una clave equivocada, una dirección equivocada o un payload rechazado por el servidor producen cada uno una línea que empieza por [Quiet Guard], nombrando el estado y la dirección. Este cliente no pasaba hasta ahora ningún logger: un plugin que nunca había funcionado no tenía forma alguna de decírselo, ni excepción, ni aviso de administración, ni línea de log.

Limpieza de datos sensibles

Antes de que un informe salga del sitio, sus datos de contexto pasan por el limpiador del núcleo, que enmascara los valores por clave. Toda clave cuyo nombre contenga uno de los términos siguientes (coincidencia por subcadena en el nombre de clave, sin distinción de mayúsculas y minúsculas, contando un guion como un guion bajo a partir de la versión 0.3.1, aplicada recursivamente a los arrays anidados) ve su valor reemplazado por [scrubbed]; una clave configurada password enmascara por tanto también user_password:

password, pwd, passphrase, token, signature, secret, authorization,
cookie, referer, referrer, auth, api_key, nonce, salt, logged_in, db_

Esto evita enviar las credenciales evidentes a su servidor. La lista de limpieza está definida en el adaptador WordPress y no puede modificarse desde la pantalla de ajustes en esta versión.

Una segunda pasada se añade encima, procedente del núcleo y sin ajuste propio: los valores con forma de dirección de correo, IBAN, número de tarjeta, número de seguridad social o teléfono franceses se enmascaran estén donde estén, incluido el texto de un mensaje de error, y la máscara nombra lo que ocultó ([redacted:email]).

Punto de ingesta

Como referencia, los informes se entregan mediante una petición HTTPS POST a:

{Server URL}/api/v1/ingest

autenticada con la clave de proyecto como token Bearer. Es la misma API de ingesta neutra respecto a la plataforma que usan los clientes Laravel y Symfony: un sitio WordPress aparece por tanto junto a ellos en el mismo panel.

Siguiente paso

Consulte la Actualización para saber cómo actualizar el plugin.