Utilisation

Une fois le plugin configuré et activé, il n'y a plus rien à appeler depuis votre code. Le plugin installe automatiquement les handlers PHP globaux et remonte les problèmes à votre place.

Ce qui est capturé automatiquement

Lorsque le plugin est activé avec une clé de projet valide (une URL de serveur vide valant le service hébergé), il enregistre trois handlers PHP globaux (via l'ErrorHandler du cœur) :

• Exceptions non interceptées: tout Throwable qui atteint le gestionnaire d'exceptions de PHP est remonté.
• Erreurs PHP: une erreur levée pendant la requête est encapsulée en exception puis remontée lorsque sa sévérité est E_USER_ERROR ou E_RECOVERABLE_ERROR. Le handler respecte la suppression par @ et votre niveau error_reporting, et laisse ensuite le gestionnaire natif de PHP s'exécuter : le comportement existant reste donc inchangé.
• Arrêts fatals: à l'arrêt du script, le plugin inspecte la dernière erreur et la remonte si elle était fatale (E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR). C'est ainsi qu'une erreur fatale mettant fin à la requête parvient tout de même à votre tableau de bord.

Chaque rapport contient la classe, le message, le fichier et la ligne de l'exception, ainsi que la trace de pile complète par défaut (trace_limit vaut 0) ; une valeur positive de trace_limit tronque la trace à ce nombre de frames. La release configurée est jointe à chaque événement.

Pourquoi les avertissements et les notices ne sont pas remontés

Toute sévérité était auparavant transmise, en un appel HTTP synchrone chacune. Sur WordPress, l'avertissement de n'importe quel thème ou extension atterrit dans ce handler : un seul avertissement dans une boucle sur cinq cents lignes, c'était donc cinq cents appels bloquants dans un chargement de page, ce qui est une panne du point de vue du visiteur, et le quota mensuel d'un forfait gratuit brûlé en une journée.

Deux garde-fous s'ajoutent à ce plancher : la même erreur sur le même fichier:ligne n'est remontée qu'une fois par requête, et vingt erreurs au plus sont remontées dans une requête, parce qu'un plancher ne voit pas une boucle. Les arrêts fatals ne sont pas concernés : ils sont attrapés par la fonction d'arrêt, pas par ce handler.

La remontée est conçue pour ne jamais casser votre site : si le serveur est lent ou injoignable, la page continue de s'afficher.

Vérifier le bon fonctionnement

Après avoir enregistré vos réglages, provoquez une erreur inoffensive et confirmez qu'elle apparaît dans votre tableau de bord Quiet Guard pour le projet. Un moyen rapide consiste à ajouter temporairement un extrait à un thème ou à un petit plugin « must-use » :

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

Chargez une fois n'importe quelle page du site, puis consultez les Issues du projet dans le tableau de bord, une RuntimeException portant le message « Quiet Guard test exception » devrait apparaître. Retirez l'extrait ensuite.

Si rien n'arrive, vérifiez à nouveau que :

• Enabled vaut 1 et que Project key est renseignée ;
• la Server URL est facultative : vide, elle vaut le service hébergé ; renseignée, c'est l'adresse de votre serveur (un /api ou /api/v1 final est accepté, tout autre chemin ne l'est pas) ;
• le serveur est joignable en HTTPS depuis l'hôte WordPress ;
• le dossier du plugin a été construit avec composer install, de sorte que son dossier vendor/ existe (voir Installation).

Puis lisez le log. Le plugin écrit ses propres diagnostics avec error_log(), c'est-à-dire dans wp-content/debug.log partout où WP_DEBUG_LOG est actif : une clé fausse, une adresse fausse ou une charge refusée par le serveur produisent chacune une ligne commençant par [Quiet Guard], nommant le statut et l'adresse. Ce client ne passait jusqu'ici aucun logger : un plugin qui n'avait jamais fonctionné n'avait donc aucun moyen de vous le dire, ni exception, ni notice d'administration, ni ligne de log.

Nettoyage des données sensibles

Avant qu'un rapport ne quitte le site, ses données de contexte passent par le nettoyeur du cœur, qui masque les valeurs par clé. Toute clé dont le nom contient l'un des termes suivants (correspondance par sous-chaîne sur le nom de clé, insensible à la casse, un tiret y valant un souligné à partir de la version 0.3.1, appliquée récursivement aux tableaux imbriqués) voit sa valeur remplacée par [scrubbed] ; une clé configurée password masque donc aussi user_password :

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

Cela évite d'envoyer les identifiants évidents vers votre serveur. La liste de nettoyage est définie dans l'adaptateur WordPress et n'est pas modifiable depuis l'écran de réglages dans cette version.

Une seconde passe s'y ajoute, venue du cœur et sans réglage propre : les valeurs ayant la forme d'une adresse e-mail, d'un IBAN, d'un numéro de carte, d'un numéro de sécurité sociale ou d'un téléphone français sont masquées où qu'elles se trouvent, y compris dans le texte d'un message d'erreur, et le masque nomme ce qu'il a caché ([redacted:email]).

Point d'ingestion

Pour référence, les rapports sont livrés via une requête HTTPS POST vers :

{Server URL}/api/v1/ingest

authentifiée par la clé de projet en jeton Bearer. C'est la même API d'ingestion neutre vis-à-vis de la plateforme que celle utilisée par les clients Laravel et Symfony : un site WordPress apparaît donc à leurs côtés dans le même tableau de bord.

Étape suivante

Consultez la Mise à jour pour savoir comment actualiser le plugin.