NouveauBlack Friday : 50 % de réduction sur votre premier paiement
Dépannage WordPress

L'écran blanc WordPress de la mort

Une page complètement vierge sans erreur et sans HTML. PHP a arrêté la demande en milieu de ligne et le message est allé dans un journal que vous n'avez pas encore lu.

(a blank white page, no text at all)

Réponse rapide

L'écran est vide parce que display_errors est désactivé, pas parce qu'il n'y a rien à dire. Activer WP_DEBUG_LOG, recharger la page une fois et lire wp-content/debug.log - la dernière entrée nomme le fichier et la ligne qui s'est arrêté.

Diagnostic

Les causes les plus probables d’abord.

Parcourez la liste dans l’ordre. Vérifiez chaque cause avant de modifier quoi que ce soit : les correctifs diffèrent et une supposition coûte plus cher qu’une commande.

CauseComment vérifierCorrectif
Une erreur PHP fatale dans un plugin ou un thèmeL'entrée de journal commence par "erreur fatale PHP" et nomme un fichier sous wp-content. Ce chemin est la réponse.Désactiver le plugin nommé ou changer de thème. Si le fichier appartient à un thème, passer à un thème par défaut restaure le site pendant que vous le regardez.
La limite de mémoire a été atteinteLe journal dit "La taille de la mémoire autorisée ... épuisée". Une page blanche et un tueur hors-mémoire semblent identiques du navigateur.Levez la limite assez pour charger la page, puis trouvez ce qui a besoin de la mémoire. La limite est un symptôme, pas la cause.
Seulement wp-admin est blancL'extrémité avant rend et le tableau de bord ne fait pas, ou l'inverse. Cette asymétrie pointe au code admin-only.Le fatal est dans un chemin uniquement admin. Renommer le répertoire des plugins sur SFTP pour revenir dans, puis réactiver un à la fois.
OPcache dessert un fichier compilé en impasseLe site était bien, un fichier a été édité, et maintenant il est vide - et l'erreur nomme une ligne qui n'existe plus dans le fichier.Flush OPcache. Modifier PHP en place sans brush laisse la version compilée et la source en désaccord.
Erreur de syntaxe dans un fichier que vous venez de modifierphp -l sur le fichier que vous avez touché derniers rapports l'erreur sans avoir besoin de WordPress du tout.Correction de la syntaxe ou restauration de la copie précédente. Une bractée errante en wp-config .php ou functions.php descend chaque page à la fois.
Guide

Corriger l’erreur, étape par étape.

Les commandes supposent un accès à WP-CLI et au terminal. Si vous n’en disposez pas, chaque étape explique comment procéder depuis le tableau de bord ou via SFTP.

  1. Remettre le message en marche

    Loger plutôt que d'afficher : vous voulez le détail sans publier une trace de pile pour les visiteurs.

    wp config set WP_DEBUG true --raw
    wp config set WP_DEBUG_LOG true --raw
    wp config set WP_DEBUG_DISPLAY false --raw
  2. Rechargez la page vierge une fois, puis lisez le journal

    La dernière entrée est à vous. Tout au-dessus peut être un vieux bruit.

    tail -n 30 wp-content/debug.log
  3. Si elle a nommé un plugin, retirez ce plugin de la requête

    Désactivation par nom suffit ; vous n'avez pas besoin de supprimer quoi que ce soit.

    wp plugin deactivate the-named-plugin
  4. Si vous ne pouvez pas atteindre wp-admin du tout, désactiver les plugins du système de fichiers

    Renaming du répertoire fait WordPress ne trouvent pas de plugins, ce qui est suffisant pour récupérer le tableau de bord.

    mv wp-content/plugins wp-content/plugins.off
  5. Retirez-vous lorsque vous avez fini.

    Un journal de débogage laissé sur grandit sans limite et enregistre les chemins que vous ne souhaitez pas publier.

    wp config set WP_DEBUG false --raw
Sur MagicWP

Ce que la plateforme prend en charge.

L'écran blanc est un accident de configuration plutôt qu'une fonctionnalité WordPress : PHP est dit de ne pas afficher d'erreurs et rien n'est dit pour les enregistrer. Ici, le journal est allumé et enregistrable à partir de la première requête, donc une erreur fatale est une ligne que vous pouvez lire plutôt qu'une page vide. Cloner le site avant une mise à jour signifie que le plugin fatal le fait sur une copie que personne ne visite.

Questions fréquentes

Questions fréquentes.

Pourquoi la page est-elle vide au lieu de montrer l'erreur?
Parce que display_errors est désactivé, ce qui est correct pour un site de production. Le message existe toujours - il va dans un journal. Activer WP_DEBUG_LOG le pointe à wp-content/debug.log sans montrer quoi que ce soit aux visiteurs.
L'avant est bien, mais wp-admin est blanc. Pourquoi seulement là ?
Le fatal est en code qui ne fonctionne que dans le tableau de bord. Beaucoup de plugins enregistrer des écrans d'administration seulement, donc un bug dans l'un de ceux ne touche jamais un visiteur et enlève chaque éditeur.
J'ai corrigé le fichier mais la page est toujours vide.
Vérifiez si OPcache détient toujours l'ancienne copie compilée. Si l'erreur nomme un numéro de ligne qui ne correspond plus au fichier que vous regardez, c'est ce que vous voyez.
Puis-je trouver le coupable sans accès en ligne de commande ?
Oui, sur SFTP. Renommer wp-content/plugins pour les désactiver tous à la fois, confirmer le retour du site, puis le renommer en arrière et désactiver les plugins individuellement à partir du tableau de bord.
Erreurs associées

Si le problème vient d’ailleurs.

Ces erreurs peuvent se présenter de façon similaire dans le navigateur.