Comment n’afficher et n’enregistrer que les Erreurs Critiques (Fatal Errors) dans les logs PHP ou WordPress ? (niveau expert)
La simple activation des logs d’erreur PHP et/ou WordPress a pour comportement par défaut d’enregistrer les Erreurs, mais également les Warning, les Notices, ainsi que d’autres messages vous alertant des fonctions dépréciées et de certains problèmes de syntaxe du code PHP.
Ces derniers sont des messages d’avertissement concernant des problèmes mineurs liés à votre code source qui n’interrompent pas l’exécution de vos scripts PHP, mais qui peuvent être très nombreux.
Tous ces messages peuvent générer un grand nombre de lignes dans les fichiers logs, ce qui aurait pour effet de créer des Fichiers très volumineux pouvant parfois atteindre plusieurs Mo ou Go, avec pour effet de consommer une quantité conséquente de l’espace disque disponible sur votre compte d’hébergement, en particulier si vous oubliez de désactiver l’enregistrement des logs après avoir effectué vos interventions de dépannage.
Pour n’afficher ou n’enregistrer que les erreurs fatales dans vos logs PHP, il est nécessaire de modifier le « Reporting Level » (error_reporting) dans votre configuration de PHP.
Dans la majorité des cas, par exemple sous WordPress, modifier le Reporting Level (error_reporting) via votre compte cPanel (équivalent php.ini / .user.ini) ne sera pas suffisant, car la plupart des CMS PHP peuvent écraser le niveau d’affichage des erreurs, pour de multiples raisons plus ou moins justifiées, via la fonction error_reporting() de PHP.
En plus de modifier la valeur de error_reporting dans cPanel > Select PHP Version > Options, il est aussi souvent nécessaire d’effectuer des vérifications et/ou des configurations complémentaires au niveau du CMS PHP.
Pour en savoir plus, lisez ce qui suit ↓
Étape 1 sur 2 : définir le Reporting Level via le paramètre “error_reporting” des Options PHP de cPanel
Cette étape est très simple, rendez-vous dans cPanel > Select PHP Version > Options, comme illustré ci-dessous.
Ensuite, sous l’option error_reporting, choisissez le niveau de report d’erreurs suivant :
E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_WARNING
Par exemple, la constante PHP E_PARSE est une erreur de compilation fatale. Le moteur PHP ne démarre pas l’exécution du script lorsqu’elle se produit. Donc, tout comme E_ERROR, nous conservons sons affichage/enregistrement dans les logs.
Grâce à cette configuration paramétrée au cœur de votre compte cPanel (équivalent php.ini / .user.ini), le comportement par défaut pour l’affichage et/ou l’enregistrement des logs sera de n’afficher que les Erreurs Critiques pouvant interrompre l’exécution de vos scripts PHP.
Étape 2 sur 2 : définir le Reporting Level via le code source de votre site WordPress
Puisque WordPress est le CMS le plus populaire du marché et celui le plus utilisé par nos utilisateurs, nous allons voir en détail ici comment se comporte le Mode Debug de WordPress.
WordPress lui-même a pour comportement d’Écraser le Reporting Level PHP via la Fonction error_reporting de PHP, rendant ainsi la modification faite via cPanel > PHP > Options (équivalent php.ini / .user.ini), inopérante !
Lorsque WP_DEBUG est défini sur true, WordPress définit la valeur de error_reporting sur E_ALL. Ce qui signifie : toutes les erreurs, les avertissements, les notifications et les dépréciations, ce qui est ce que nous voulons éviter.
Cela peut être vérifié en lançant l’instruction echo error_reporting() depuis l’un des fichiers PHP de votre site WordPress, qui devrait renvoyer la valeur de 4983, qui est le niveau de rapport d’erreur par défaut défini par WordPress dans le cœur du CMS.
D’ailleurs, il est facilement possible de vérifier la non-cohérence de la valeur de “error_reporting” pour WordPress vs PHP en créant un fichier phpinfo() à la racine de votre site Web.
Traduction : Pour faire le suivi, je suis reconnaissant envers le support de cPanel (et un peu gêné de ne pas y avoir pensé moi-même). Il a été déterminé que WordPress et plusieurs plugins WP dans la plupart des cas réinitialisaient la valeur de ‘error_reporting’. Étant donné que presque tous les comptes sur le serveur utilisent WordPress, cela m’avait semblé systématique… mais le problème ne venait pas de la configuration de PHP via cPanel.
Donc, si vous êtes utilisateur de WordPress, soyez conscient qu’il y aura dans tous les cas un travail de configuration plus ou moins complexe à réaliser dans votre code source WordPress.
Pour faire court, il s’agit de modifier le niveau de rapport d’erreur via le fonction PHP , error_reporting(), exactement comme WordPress le fait lui-même dans ses fichiers PHP.
Pour modifier le Reporting Level via PHP et n’afficher/n’enregistrer que les erreurs critiques, voici la fonction à exécuter :
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_WARNING);Vous pourriez croire qu’ajouter un appel à error_reporting() dans votre fichier wp-config.php ou le fichier functions.php de votre child-theme pourrait être suffisant. Et cela peut fonctionner dans quelques rares cas, mais la plupart du temps, votre thème et vos plugins s’exécutant après wp-config.php vont aussi prendre des libertés avec votre configuration du Reporting Level PHP.
Par conséquent, votre paramétrage sera remplacé plus tard au cours du chargement des scripts internes à WordPress.
Workaround pour forcer la valeur de “error_reporting” dans WordPress :
Vous l’aurez compris, de nombreux fichiers PHP issus de WordPress, du thème et des plugins peuvent à tout moment modifier la valeur du paramètre “error_reporting”, ce qui peut engendrer l’enregistrement de certains avertissements mineurs, à tout moment, dans vos fichiers logs.
Cependant, même s’il est impossible de garantir une élimination complète de ces avertissements mineurs dans les logs PHP de WordPress, il est possible de les réduire considérablement en rappelant régulièrement à WordPress le niveau de rapport d’erreur désiré, via les Hooks de WordPress.
Pour cela, nous vous suggerons d’utiliser un mu-plugin qui sera exécuté très tôt lors de la construction des fonctions de WordPress.
Concrètement, pour mettre en place ce mu-plugin, rendez-vous dans votre Gestionnaire de fichiers de cPanel ➚
Ensuite, naviguez dans votre site WordPress jusqu’au répertoire “wp-content”. Par exemple, /home/user/public_html/wp-content/.
Si aucun répertoire /mu-plugins/ n’est présent à cet emplacement, veuillez le créer, comme illustré ci-dessous :
Ci-dessous, vous trouverez le contenu du mu-plugin en 1 fichier fatal-errors-only.php ↓ (ce fichier PHP peut aussi être téléchargé en 1 clic depuis sa fiche GitHub ➚).
Il vous sera ensuite nécessaire de créer le fichier fatal-errors-only.php dans le répertoire /mu-plugins/ du site WordPress concerné, comme illustré ci-dessous.
Cependant, même si nous avons conçu ce plugin au mieux pour modifier la valeur de error_reporting à plusieurs niveaux (hooks), tôt dans l’exécution de WordPress, il se peut qu’un autre plugin se charge plus tard dans la hiérarchie des hooks PHP, ce qui risque de modifier à nouveau la valeur de votre “error_reporting ». Donc, certains avertissements mineurs pourraient encore être enregistrés ensuite, aux stades suivants. Dans ce cas, il vous est possible de prolonger la modification du paramètre “error_reporting” en vous reportant aux Hooks WordPress suivants.
Pour conclure, vous avez compris que lorsqu’on utilise un CMS comme WordPress, qui peut écraser à plusieurs niveaux les paramètres du rapport d’erreurs de PHP, il est nécessaire de trouver une solution détournée afin de réduire au maximum le nombre d’avertissements mineurs dans les logs PHP & WordPress. Dès que la logique est comprise, en vous basant sur le mu-plugin partagé ci-dessus, vous devriez être en mesure de pouvoir affiner au maximum le nombre d’entrées non désirées dans vos logs.
Pour toute question ou remarque à ce sujet, n’hésitez pas à prendre contact avec le support de votre Hébergeur Web EasyHoster !
