Comment masquer les erreurs et avertissements WordPress en cas d’urgence

Parfois, des erreurs ou des avertissements PHP s’affichent sur votre site WordPress en production et gâchent le design ou déroutent les visiteurs. Vous pouvez masquer temporairement ces messages à l’écran pour que le site public redevienne présentable. Ce n’est qu’une mesure d’urgence. Elle ne répare pas le bogue et ne signifie pas que le problème a disparu.

Important : masquer les avertissements ou les erreurs à l’écran est temporaire uniquement. Empêcher leur affichage ne résout pas la cause sous-jacente. Utilisez-le seulement comme mitigation de court terme sur un site en production, puis inspectez les journaux en toute sécurité, identifiez l’extension, le thème ou le code PHP responsable, travaillez à partir d’une sauvegarde ou d’une copie de préproduction, corrigez ou mettez à jour ce code, et vérifiez le site. Ne considérez pas les erreurs masquées comme sans danger à ignorer. Désactiver WP_DEBUG n’écrit pas non plus les erreurs dans un fichier journal.

Étape temporaire : masquer les messages d’erreur aux visiteurs

WordPress inclut déjà une ligne WP_DEBUG dans wp-config.php. Modifiez cette ligne existante. N’ajoutez pas un second define( 'WP_DEBUG', ... ) : définir deux fois la même constante peut déclencher un avis PHP. Placez ces réglages avant le commentaire /* That's all, stop editing! */, pas après.

1. Repérez `wp-config.php`

Connectez-vous avec un client FTP ou le gestionnaire de fichiers de votre hébergement et ouvrez wp-config.php à la racine de votre installation WordPress.

2. Modifiez la ligne `WP_DEBUG` existante

Trouvez la ligne qui ressemble déjà à define( 'WP_DEBUG', true ); ou define( 'WP_DEBUG', false );. Modifiez-la pour désactiver le débogage :

define( 'WP_DEBUG', false );

Utilisez le booléen false sans guillemets. Un 'false' entre guillemets est une chaîne, et PHP le traiterait comme vrai.

3. Masquez les erreurs PHP encore visibles à l’écran, si besoin

Certains hébergeurs affichent encore des erreurs PHP même lorsque le mode débogage de WordPress est désactivé. Si c’est le cas, ajoutez la ligne suivante près de votre réglage WP_DEBUG uniquement si elle n’y figure pas déjà :

@ini_set( 'display_errors', 0 );

Après une modification soigneuse, cette section devrait ressembler à ceci — et non à deux copies de WP_DEBUG l’une sous l’autre :

define( 'WP_DEBUG', false );
@ini_set( 'display_errors', 0 );

Ce que cela fait :

define( 'WP_DEBUG', false ); — Désactive le mode débogage de WordPress. Les visiteurs ne devraient plus voir les messages de débogage WordPress. Cela n’enregistre pas les erreurs pour vous.
@ini_set( 'display_errors', 0 ); — Indique à PHP de ne pas imprimer les erreurs dans le HTML de la page. C’est un réglage d’affichage, pas une réparation.

Évitez error_reporting(0); comme approche principale. Cela réduit tellement les rapports PHP qu’il devient plus difficile de savoir ce qui s’est cassé.

Ce que vous devez faire ensuite : diagnostiquer et corriger la vraie erreur

Dès que le site public redevient lisible, trouvez la cause. Un bon déroulement :

Faites une sauvegarde avant de modifier des extensions, des thèmes ou du code.
Reproduisez le problème sur une copie de préproduction ou un site local chaque fois que possible, afin que les visiteurs ne voient jamais la sortie de débogage.
Sur cette copie de préproduction, activez la journalisation sans afficher les erreurs à l’écran. Placez ceci avant /* That's all, stop editing! */, et mettez à jour les lignes de débogage existantes au lieu de les dupliquer :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Comment ces lignes fonctionnent ensemble :

WP_DEBUG — doit valoir true pour que les deux autres constantes de débogage aient un effet.
WP_DEBUG_LOG — écrit les messages dans wp-content/debug.log (ou un autre chemin que vous définissez). Il ne fait rien si WP_DEBUG vaut false.
WP_DEBUG_DISPLAY — réglé sur false, plus display_errors réglé sur 0, garde ces messages hors de la page pour que vous puissiez les lire dans le journal.

Ouvrez debug.log via FTP ou le gestionnaire de fichiers de votre hébergeur — pas en le laissant téléchargeable dans un navigateur. Un fichier journal dans wp-content peut exposer des chemins serveur et des noms d’extensions si quelqu’un le récupère en HTTP. Une fois terminé, désactivez à nouveau le débogage et supprimez ou restreignez le fichier journal.

Utilisez le journal pour identifier l’extension, le thème ou le fichier PHP à l’origine de l’avertissement ou de l’erreur. Mettez à jour ou corrigez ce code, puis rechargez les pages concernées pour confirmer que le message a disparu.

WordPress documente cette configuration de débogage dans son manuel développeur.

Pourquoi il ne faut pas s’arrêter au masquage du message

Des erreurs masquées peuvent encore casser des fonctionnalités, ralentir le site ou laisser un problème de sécurité en place. Le nettoyage à l’écran protège seulement les visiteurs pendant que vous travaillez. L’objectif réel est un site stable dont la cause sous-jacente a été résolue.

Conclusion

En urgence, vous pouvez masquer la sortie d’erreurs WordPress et PHP en modifiant la ligne WP_DEBUG existante pour la passer à false et, si besoin, en désactivant display_errors — toujours avant le commentaire « stop editing », et jamais en définissant deux fois la même constante. Diagnostiquez ensuite la cause sur une sauvegarde ou un site de préproduction avec journalisation de débogage, corrigez l’extension, le thème ou le code PHP responsable, et vérifiez. Masquer un avertissement est temporaire ; corriger l’erreur, c’est ce qui dure.