Écran blanc WordPress : retrouver l’erreur sans l’afficher au public

Une page blanche donne peu d’indices, mais elle ne signifie pas que tout le site a disparu. Le navigateur peut recevoir une réponse vide, un document incomplet ou du contenu qu’un style masque. Avant de remplacer un thème ou de désactiver des extensions, il faut savoir ce que le serveur renvoie et où le chargement s’arrête.

Distinguer une réponse vide d’un affichage masqué

Relevez l’adresse, l’heure et le contexte du problème : page publique, administration, visite connectée ou première ouverture. Comparez une page touchée et une page encore fonctionnelle. La documentation des erreurs WordPress présente plusieurs origines possibles ; l’apparence blanche ne suffit pas à choisir une réparation.

Dans les outils du navigateur, regardez le statut HTTP et le contenu de la réponse. Une erreur 500 indique un échec côté serveur sans en désigner la cause ; une réponse 200 ne prouve pas que le contenu attendu est présent. Le guide de l’erreur 500 WordPress aide à poursuivre la piste serveur si ce statut est confirmé.

Si le document contient déjà les textes mais qu’ils restent invisibles, examinez les styles et les erreurs JavaScript. Un essai sans JavaScript dans une session de test peut montrer une différence utile, sans modifier le site. Vérifiez aussi le cache : une page normale encore stockée ne garantit pas que l’origine fonctionne, et une ancienne réponse vide peut survivre à la correction.

Retrouver une erreur exploitable dans les journaux

Faites correspondre une demande précise avec l’heure des journaux PHP et du serveur. Relevez le type d’erreur, le fichier, la ligne et les appels utiles. Un ancien avertissement trouvé dans un journal volumineux ne prouve pas qu’il explique la panne actuelle. Le chemin d’une extension dans une trace indique aussi un lieu d’exécution, pas automatiquement toute la cause.

Le débogage WordPress permet de conserver des erreurs pour les analyser. Gardez le journal dans un emplacement protégé ou avec un accès web bloqué, et l’affichage public désactivé. Si l’exécution s’arrête avant que WordPress puisse initialiser ce dispositif, consultez les journaux PHP de l’hébergement plutôt que de supposer que l’absence de debug.log exclut une erreur.

Les réglages PHP display_errors et log_errors ont des rôles différents : afficher une erreur aux visiteurs ne remplace pas sa journalisation. Évitez de rendre publics chemins, requêtes ou informations de session. Si une erreur de syntaxe désigne un fichier récemment modifié, le diagnostic de syntaxe PHP permet de traiter cette cause précise.

Utiliser le mode de récupération quand il est disponible

Lorsqu’il détecte certaines erreurs fatales, WordPress peut envoyer à l’adresse d’administration un lien vers le mode de récupération. Utilisez ce lien personnel pour vous connecter par l’accès autorisé et lire le composant signalé. Ne le publiez pas dans un ticket ou une capture : il sert à une session de dépannage.

Dans ce mode, une extension ou un thème défaillant peut être mis en pause pour votre session. Retrouver l’administration ne signifie donc pas que les visiteurs ont retrouvé le site. Si le courriel n’arrive pas ou si l’arrêt intervient trop tôt, ce mécanisme peut ne pas être utilisable ; reprenez l’analyse avec les journaux et l’accès de maintenance prévu par l’hébergeur.

Isoler le composant concerné avec un retour possible

Avant une modification de fichiers, de configuration ou de données, vérifiez une sauvegarde récente et restaurable. Les sauvegardes WordPress doivent couvrir les éléments nécessaires à la reprise, dont les fichiers et la base. Contrôlez ce qui peut réellement être restauré ; un dossier nommé sauvegarde ne suffit pas à garantir un retour.

Reliez ensuite la trace au dernier changement connu : version d’une extension, thème enfant, extrait de code ou environnement PHP. Sur une copie de test isolée, retirez une seule cause supposée et rejouez la même demande. Désactiver toutes les extensions ou remplacer tous les fichiers en production peut casser d’autres fonctions et rend l’attribution beaucoup plus difficile.

Si les accès et l’environnement le permettent, une désactivation ciblée avec WP-CLI fait partie des moyens de diagnostic. Elle doit viser le bon site et le bon composant, avec une procédure de retour. Un cache de l’hébergeur ou un élément chargé en amont peut rester actif malgré la désactivation d’une extension ordinaire ; vérifiez le périmètre réel avant d’élargir le test.

Si la panne suit une mise à jour, revenez à une version compatible et connue seulement après avoir vérifié ses dépendances. Une évolution de données peut demander un plan différent du simple remplacement des fichiers. Le guide des échecs de mise à jour WordPress détaille cette distinction ; ne remplacez pas toute la base actuelle par une ancienne copie pour retrouver une page visible.

Vérifier la mémoire et le contexte PHP réellement utilisés

Un message Allowed memory size oriente vers une allocation qui dépasse la limite mémoire PHP. Recherchez l’opération qui consomme cette mémoire : traitement de média, requête, import ou répétition anormale. Augmenter la limite sans comprendre ce travail peut seulement repousser l’erreur. Cette limite ne décrit pas, à elle seule, la mémoire disponible sur le serveur.

Comparez aussi la version et la configuration du PHP qui sert la page avec celles utilisées par les outils en ligne de commande. Un test qui réussit en terminal peut ne pas reproduire le même environnement. Pour un arrêt de processus ou une saturation, les journaux de l’hébergeur complètent ceux de WordPress ; ne changez pas simultanément version PHP, thème et extensions pour chercher un effet.

Contrôler le contenu après la correction

Rejouez la demande initiale et vérifiez le statut, la réponse et le contenu attendu. Testez une visite sans la session de récupération, puis l’administration habituelle. Une page peut répondre 200 tout en perdant son menu, ses images ou son formulaire. Contrôlez les fonctions réellement touchées sur ordinateur, tablette et mobile, ainsi que le clavier et le contenu essentiel sans JavaScript lorsque le parcours le permet.

Purger le seul cache concerné peut être nécessaire pour voir le résultat actuel ; conservez d’abord les observations qui expliquaient la panne. Vérifiez que les nouvelles demandes ne produisent plus la même erreur, sans effacer les anciens journaux pour obtenir un écran propre. Retirez les dispositifs temporaires de diagnostic et rétablissez le niveau de journalisation prévu.

Gardez une trace courte de la cause étayée, du changement, des tests et du retour arrière disponible. Si le site reste inaccessible ou si la correction exige de manipuler des données dont la reprise est incertaine, une intervention sur un site WordPress en panne permet de cadrer la suite avec les accès et protections existants. Un écran redevenu lisible ne prouve pas encore que tous les parcours sont rétablis.