L'écran blanc de la mort WordPress : un guide de récupération
Publié: 2023-01-10WordPress, comme MacOS et même Windows maintenant, a un tristement célèbre « écran blanc de la mort » ou « WSOD » pour faire court. Le WSOD apparaît lorsque quelque chose tourne mal. Vous faites face à un écran blanc vide ou presque vide pour des raisons inconnues. Maintenant quoi?
Qu'est-ce que l'écran blanc de la mort WordPress (WSOD) ?
Il est peu probable que vous rencontriez «l'écran blanc de la mort» (WSOD) sur un site WordPress dans des conditions normales. Il s'agit simplement d'un écran blanc vierge qui apparaît à la place de l'interface publique frontale ou dorsale d'un site WordPress. Cela signifie que WordPress a planté et ne se chargera pas correctement.
L'écran blanc de la mort est probablement le résultat de quelque chose VOUS avez fait à votre site WordPress.
Pourquoi? Qu'est-ce qui a mal tourné ?
Depuis la sortie de WordPress 5.2 en mai 2019, WordPress dispose d'un mode de récupération pour vous protéger du WSOD. Sans le mode de récupération, les problèmes de compatibilité généreraient de nombreux WSOD et des utilisateurs WordPress frustrés. Si votre serveur utilise une version de PHP ou MySQL qui n'est pas prise en charge par un plugin, un thème ou une extension que vous installez, au lieu de casser votre site, vous obtiendrez le mode de récupération. Aujourd'hui, une erreur PHP Out-of-Memory (OOM) est probablement le scénario restant le plus courant qui contournera la protection WSOD, vous laissant avec un écran totalement vide.
J'ai vérifié auprès du contributeur principal de WordPress, Marius Jensen, pour savoir ce qui pourrait causer un véritable WSOD de nos jours. Marius est l'auteur du plugin Site Health (maintenant Health Check and Troubleshooting) dont le concept et les fonctionnalités ont finalement été intégrés au cœur de WordPress. (C'est ainsi que nous avons obtenu le mode de récupération et d'autres protections.) Marius a confirmé que le seul moyen de faire planter WordPress avec un écran totalement vide est d'interrompre le flux d'exécution de PHP afin que le gestionnaire d'erreurs fatales ne puisse pas fonctionner comme il se doit. Briser la connexion entre PHP et votre serveur HTTP y parviendra. Vous n'obtiendrez aucun commentaire de dépannage à l'écran. Ce serait frustrant, mais si vous travaillez simplement dans WordPress, installez et configurez des plugins, il est peu probable que cela se produise.
L'écran blanc de la mort signifie-t-il que WordPress a été piraté ?
Non, un WSOD ne signifie pas que les méchants vous ont eu. Cependant, dans de rares cas, cela pourrait être un effet secondaire d'une faille de sécurité. Si vous pensez que des pirates ont compromis votre site, rendez-vous sur le guide de Kathy Zant, Comment nettoyer un site WordPress piraté.
Une erreur de codage PHP, un conflit entre deux ou plusieurs plugins ou un problème dans votre environnement de serveur sont les causes les plus probables d'un WSOD. Heureusement, ce ne sont pas des catastrophes ! Votre site et son contenu n'ont pas été perdus. Si vous le souhaitez, vous pouvez réparer vous-même un WSOD.
Dans cet article, nous allons parcourir la liste des diagnostics et des remèdes possibles pour le WSOD. Vous apprendrez comment redonner vie à votre site WordPress. Vous apprendrez également comment WordPress fonctionne à un niveau plus profond.
Afficher l'aperçu
L'écran blanc de la mort de WordPress : est-ce que j'ai fait ça ?
Oui. L'écran blanc de la mort est probablement le résultat de quelque chose VOUS avez fait à votre site WordPress.
La cause d'un WSOD se trouve généralement dans un plugin WordPress que vous venez d'installer et d'activer. Ou, cela pourrait être le résultat d'une mise à jour récente. Un plugin nouvellement ajouté ou mis à jour peut être en conflit avec un autre plugin. Dans ce scénario, un plugin essaie de faire la même chose qu'un autre, ou ils agissent à des fins contradictoires.
Si un plugin, un thème ou des extraits de code PHP défectueux provoquent une erreur fatale, vous pouvez obtenir un WSOD. Ils peuvent contenir une erreur de syntaxe, un bogue ou un code incompatible avec la version de PHP que vous utilisez. Si vous ou votre hébergeur venez de mettre à jour votre version de PHP, ce qui est une bonne chose ! - les plugins incompatibles commenceront à lancer des erreurs et pourraient faire tomber votre site avec un WSOD. Si vous utilisez WordPress 5.2 ou supérieur comme vous le devriez, des problèmes d'incompatibilité activeront le mode de récupération, ce qui est beaucoup plus utile qu'un véritable WSOD.
Généralement, le coupable est tout ce qui vient d'être modifié avec un plugin, un thème ou un code personnalisé.
Étant donné que le WSOD est souvent une réponse à tout ce qui a été modifié en dernier (ou très récemment) qui affecte la fonctionnalité de votre site. Passez en revue toutes les modifications récentes. Concentrez-vous sur les changements qui semblent les plus susceptibles de causer un problème. Si vous venez d'installer un nouveau plugin ou de modifier un code de thème, ce sont les premiers endroits à regarder pour voir ce qui a pu mal tourner.
Quand WordPress est seulement presque mort
Tous les WSOD ne sont pas égaux, et certains ne sont même pas de vrais WSOD.
Vous pouvez obtenir une sorte de message d'erreur au lieu d'un écran complètement blanc. Il peut s'agir d'un message d'erreur du serveur concernant une erreur HTTP 500 ou une connexion à la base de données perdue. Il peut s'agir d'un message d'erreur critique de WordPress. Ou, votre site peut se charger normalement pour les visiteurs, mais lorsque vous essayez de vous connecter, vous obtenez l'écran blanc de la mort. L'inverse peut être vrai dans d'autres cas : vous pouvez vous connecter au tableau de bord WordPress, mais l'interface publique de votre site donne à tout le monde un écran vide.
Si votre expérience WSOD correspond à l'une de ces descriptions, bonne nouvelle ! Votre site est seulement presque mort. Il ne sera pas difficile de le faire revivre.
Si vous vous retrouvez face à un écran blanc complètement vide lorsque vous visitez votre site WordPress ou essayez de vous connecter, c'est le vrai WSOD. Vous devrez creuser un peu plus pour déterminer ce qui en est la cause.
Mode de récupération WordPress et écran blanc de la mort
Heureusement pour toute personne confrontée à un WSOD, le mode de récupération a été introduit dans WordPress 5.2 pour s'en débarrasser. Le mode de récupération détecte de nombreuses erreurs fatales et vous aide à les corriger. Si vous n'utilisez pas la version majeure la plus récente du noyau WordPress, commencez par là. Mettez-vous à jour !
Grâce au mode de récupération de WordPress, il est rare de voir un écran blanc complètement vide lorsque quelque chose ne va pas. Vous verrez plus souvent une fenêtre blanche sur un écran gris avec le message suivant à partir de WordPress 6.1 :
Les anciennes versions de WordPress afficheront des messages rédigés de la même manière, comme « Le site rencontre des difficultés techniques ».
Si vous naviguez vers une URL backend /wp-admin , il y aura également un avis vous invitant à vérifier votre compte de messagerie administrateur pour plus d'informations :
Dans d'autres cas, vous pouvez voir un écran blanc avec du texte en gras décrivant une "Erreur de serveur interne" avec une sorte d'explication et de conseils pour réparer votre site.
Bienvenue dans Recovery
C'est le mode de récupération. WordPress essaie de vous aider à le remettre sur pied.
La première chose à faire est de vérifier l'adresse e-mail associée à votre compte administrateur WordPress. WordPress essaie d'identifier les erreurs PHP fatales dans tout le code qu'il exécute.
Si possible, WordPress « mettra en pause » un plugin ou un autre code qui ne fonctionne pas correctement. WordPress empêchera le mauvais code de s'exécuter. Ensuite, il signalera les détails aux administrateurs par e-mail.
Dans l'e-mail du mode de récupération, vous trouverez des instructions et un lien temporaire pour vous connecter à WordPress en mode de récupération. (Ce lien est valide pendant 24 heures. Après cela, un nouveau sera envoyé si le site rencontre toujours une erreur critique.)
CONSEIL DE PRO : Si vous ne recevez pas l'e-mail du mode de récupération, vous pourrez peut-être vous connecter à WordPress en mode de récupération de toute façon en ajoutant l'adresse suivante à l'URL de votre site de base lorsque vous êtes connecté en tant qu'administrateur : /wp-login.php?action=entered_recovery_mode .
Voici votre chance d'enquêter davantage. Si le mode de récupération a identifié un plugin spécifique comme cause de votre WSOD, désactivez-le. Cela ramènera votre site pour tout le monde. Ensuite, vous pouvez enquêter sur tous les problèmes connus pour ce plugin. Vérifiez s'il existe une mise à jour pour cela. Contactez les personnes chargées de son entretien.
Tous les écrans blancs de la mort ne sont pas identiques dans WordPress
Dans quelques cas exceptionnels, quelque chose s'est mal passé ailleurs dans WordPress ou dans votre environnement de serveur. Un processus de mise à jour ou d'installation peut être bloqué, laissant votre site bloqué en mode maintenance. Vous, votre fournisseur d'hébergement ou un plugin que vous avez installé avez peut-être modifié des fichiers php.ini ou .htaccess avec des résultats inattendus. Votre environnement existant peut ne pas prendre en charge les exigences d'un plug-in nouvellement installé.
Le mode de récupération de WordPress n'est pas en mesure de faire face à ces situations, mais il produira des messages d'erreur visibles sur un écran autrement blanc. Le front-end de votre site peut être inaccessible, mais l'écran de connexion administrateur et l'interface back-end peuvent fonctionner normalement.
Ce ne sont pas de vraies situations WSOD, mais elles sont tout aussi ennuyeuses. Habituellement, l'une des conditions suivantes les provoque:
1. Vous êtes bloqué en mode maintenance
Lors de la mise à jour du noyau, des plugins ou des thèmes de WordPress, WordPress passe en « mode maintenance ». La navigation vers n'importe quelle partie du site affichera un écran gris avec une fenêtre de message blanche indiquant :
Parfois, cela ne s'éclaircit pas en une minute, mais l'hébergement WordPress géré par la qualité le remarquera et le corrigera avec un processus automatisé. Si vous avez attendu quelques minutes sans changement, vous pouvez sortir du mode maintenance en supprimant le fichier .maintenance dans votre dossier racine web/application où WordPress est installé. (Pour le voir, vous devrez peut-être activer l'affichage des fichiers "invisibles" précédés d'un point dans le nom du fichier.)
Lorsqu'il n'y a pas de fichier .maintenance présent, votre site se chargera comme prévu.
2. Vous avez atteint une limite de téléchargement de fichier ou de taille de message
Votre site peut expirer sur un écran blanc lors d'un processus de téléchargement, de post-publication ou de soumission de formulaire, car vous envoyez trop de données.
Solution : Augmentez la limite de contenu de votre publication dans wp-config.php :
ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000); Solution : augmentez la limite de téléchargement de fichiers et de publication dans php.ini :
upload_max_filesize = 256M post_max_size = 256M
Prolonger le temps (en secondes) avant l'expiration d'une publication ou de la soumission d'un formulaire peut également aider. Il vous est également possible d'augmenter le temps dont dispose PHP pour exécuter les scripts et analyser l'entrée. De plus, nous pouvons augmenter le nombre de variables autorisées dans une soumission de formulaire. Enfin, nous pouvons spécifier le délai après lequel PHP traitera les données soumises comme des ordures :
max_execution_time = 300 max_input_time = 300 max_input_vars = 1000 session.gc_maxlifetime = 1000
Ou dans .htaccess , httpd.conf ou virtualhost :
php_value upload_max_filesize 256M php_value post_max_size 256M php_value max_execution_time 300 php_value max_input_time 300 php_value max_input_vars 1000 php_value session.gc_maxlifetime 1000
Ou dans un extrait de code personnalisé pour WordPress ou un fichier de thème functions.php :
@ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000' );Les valeurs de mémoire et de temps dans ces paramètres ne sont que des recommandations. Pour vous assurer qu'ils fonctionnent et pour vérifier leurs valeurs actuelles, utilisez l'outil Santé du site dans votre interface d'administration WordPress.
Parallèlement au mode de récupération, WordPress 5.2 a introduit l'outil Santé du site. Il est très utile pour diagnostiquer les problèmes et obtenir des informations techniques sur les paramètres de votre site et l'environnement du serveur. Trouvez-le dans votre menu Admin sous Outils > Santé du site. Vous pouvez également bénéficier des fonctionnalités étendues du plugin Health Check and Troubleshooting pour WordPress.
3. PHP n'a plus de mémoire
PHP est le langage de script côté serveur sur lequel WordPress est basé. Un WSOD apparaît s'il n'y a pas assez de mémoire pour PHP pour exécuter WordPress et vos plugins actifs. Vous pouvez voir cela indiqué dans un message d'erreur ou un journal.
En fonction de votre plan d'hébergement, vous pourrez peut-être augmenter la limite de mémoire PHP pour toutes les applications sur votre serveur ou une instance spécifique de WordPress. Demandez de l'aide à l'équipe d'assistance technique de votre hébergeur si vous ne savez pas quoi faire.
wp-config.php
Normalement, l'ajout du paramètre suivant à votre fichier wp-config.php dans votre dossier WordPress définira la limite de mémoire frontale pour WordPress à 256 Mo dans cet exemple :
définir('WP_MEMORY_LIMIT', '256M'); 128 à 256 Mo devraient être plus que suffisants. Vous pouvez également définir la mémoire maximale ou principale allouée à PHP (256 Mo également dans l'exemple suivant) en ajoutant également la ligne suivante à wp-config.php :
définir('WP_MAX_MEMORY_LIMIT', '256M');Le deuxième nombre est la limite de mémoire maximale définissant la mémoire totale dont PHP dispose pour lui-même. Le premier nombre est la mémoire pour WordPress s'exécutant dans cette plus grande limite PHP. La limite de mémoire PHP maximale doit être égale ou supérieure à la limite de mémoire de l'application WordPress.
php.ini
Une autre façon de définir la limite de mémoire maximale PHP consiste à définir un paramètre dans un fichier php.ini situé dans votre dossier WordPress :
limite_mémoire = 256M
Assurez-vous qu'il n'y a pas de point-virgule au début de la ligne ! Et notez que php.ini n'aura d'impact que sur l'instance de WordPress (ou de toute autre application PHP) exécutée dans ou sous le dossier dans lequel se trouve le fichier php.ini . Si vous avez accès à votre serveur ou à votre racine Web, un fichier php.ini qui s'y trouve régira les paramètres environnementaux de toutes les applications PHP, à moins qu'elles n'aient leur propre fichier php.ini qui spécifie des conditions différentes.
.htaccess
Une troisième façon de définir la limite de mémoire PHP consiste à utiliser le fichier .htaccess dans votre dossier WordPress si vous utilisez Apache ou Litespeed comme serveur HTTP. Comme dans les exemples ci-dessus, .htaccess doit avoir une ligne non commentée comme celle-ci pour définir une limite PHP maximale de 256 Mo :
php_value memory_limit 256M
Des erreurs dans la syntaxe des paramètres d'application et de serveur dans wp-config.php , php.ini et .htaccess peuvent également provoquer un WSOD. Vous devrez peut-être les corriger manuellement ou les remplacer par leurs valeurs par défaut d'origine s'ils cassent votre site. Si vous utilisez un serveur Web Apache ou Litespeed, le fichier .htaccess qui régit leur fonctionnement peut être modifié par de nombreux plugins WordPress. Les erreurs introduites dans l'un de ces fichiers peuvent faire apparaître un WSOD et faire tomber votre site.
4. Votre serveur HTTP plante
HTTP (ou sa forme cryptée et sécurisée HTTPS) est le protocole de transfert hypertexte qui fait d'un serveur Web un serveur Web. C'est ainsi que les serveurs servent des pages Web (documents HTTP) aux clients (comme les navigateurs) sur demande.
Les serveurs HTTP couramment utilisés pour les sites WordPress sont Apache, Litespeed et NGINX. Leurs écrans d'erreur sont légèrement différents et peuvent varier dans la manière dont les navigateurs les affichent, mais ils signalent tous les mêmes codes d'erreur HTTP.
Une erreur HTTP 500, également connue sous le nom d'erreur interne du serveur, indique qu'il existe un problème inattendu avec votre serveur HTTP qui l'empêche de répondre aux requêtes HTTP. D'autres codes d'erreur de serveur 5xx, en particulier 502 (Bad Gateway), 503 (Service Unavailable) et 504 (Gateway Timeout), indiquent que votre serveur est surchargé ou inaccessible. L'erreur interne 500 est un fourre-tout pour les pannes sur le serveur qui l'empêchent de renvoyer la page/le document demandé.
Votre navigateur peut fournir sa propre version unique des écrans d'erreur HTTP et il peut afficher ses propres codes d'erreur spéciaux. Google Chrome (et d'autres navigateurs basés sur Chromium) répertorie et explique tous ses propres codes d'erreur en interne si vous accédez à chrome://network-errors/ dans votre barre d'adresse lorsque vous utilisez Chrome.
Problèmes côté serveur
Les logiciels de serveur HTTP couramment utilisés pour les sites WordPress incluent Apache, Litespeed et NGINX. De nombreux hébergeurs WordPress les utilisent avec la mise en cache pour optimiser les performances.
Si une actualisation matérielle de votre navigateur ou la suppression des cookies et du cache de votre navigateur n'éliminent pas l'écran d'erreur 500, vous pourriez récupérer de mauvais fichiers de cache côté serveur. La mise en cache côté serveur peut causer beaucoup de confusion lorsqu'elle ne fonctionne pas bien, vous devriez donc également essayer de l'effacer. Votre panneau de contrôle d'hébergement ou votre interface d'administration WordPress peut avoir des contrôles de suppression du cache.
Les causes courantes d'une erreur HTTP 500 peuvent inclure les conditions côté serveur suivantes :
- La limite de mémoire PHP a été dépassée.
- Autres erreurs PHP lorsque PHP n'est pas configuré pour afficher les erreurs.
- Autorisation insuffisante pour accéder aux fichiers et dossiers du serveur.
- Erreurs de syntaxe dans le fichier de configuration .htaccess.
Nous avons déjà abordé les limites de mémoire PHP et comment les augmenter. Nous approfondirons le débogage PHP dans la section suivante ci-dessous.
Des autorisations incorrectes ne devraient pas se produire sur l'hébergement WordPress moderne et géré, mais elles sont courantes sur l'hébergement mutualisé traditionnel. Les fichiers doivent être définis sur 664 ou 644, les dossiers doivent être définis sur 775 ou 755 et wp-config.php doit être défini sur 660, 600 ou 644. En savoir plus sur la modification des autorisations de fichiers sur WordPress.org.
Si vous avez apporté des modifications à votre fichier .htaccess ou si vous utilisez un plugin (souvent ou en cache) qui le modifie, vous devrez peut-être le vérifier pour détecter les erreurs, le restaurer ou recréer un nouveau fichier .htaccess fonctionnel. En savoir plus sur .htaccess sur WordPress.org.
Problèmes côté client
Les erreurs HTTP 500 peuvent également être causées côté client (dans votre navigateur) par d'autres conditions :
- Paramètres de navigateur incorrects.
- Un cache corrompu.
- Fichiers JavaScript corrompus qui s'exécutent dans votre navigateur.
- Problèmes de connectivité Internet.
Essayez de charger votre site dans un autre navigateur pour éliminer votre navigateur actuel comme étant le problème. Si vous avez un problème de navigateur, essayez de le réinitialiser à ses paramètres par défaut. Désactivez les extensions de navigateur ou les plugins que vous avez installés pour voir s'ils interagissent mal avec votre site.
Si votre problème est lié à de mauvais fichiers de cache, la zone d'administration WordPress non mise en cache peut toujours vous être accessible. Si vous pouvez toujours vous connecter à l'interface d'administration de WordPress, vous pourrez peut-être y utiliser des commutateurs d'effacement de cache ou essayer les étapes de dépannage supplémentaires décrites ci-dessous.
Il est également possible qu'une erreur HTTP 500 soit causée par un problème avec la base de données, un problème avec un plugin ou un thème dans un site WordPress, ou un problème avec WordPress lui-même.
Pour résoudre une erreur HTTP 500, vous devez activer la journalisation des erreurs pour votre serveur HTTP et PHP. Vérifiez ensuite quelles erreurs apparaissent dans les deux. Vous pouvez également vérifier et éventuellement augmenter la limite de mémoire PHP, désactiver les plug-ins et passer à un thème par défaut pour voir si l'une de ces actions rétablit votre site.
Nous aborderons ces étapes plus en détail ci-dessous. Si les suivre ne supprime pas l'erreur 500, contactez l'équipe d'assistance de votre hébergeur pour obtenir de l'aide.
Quand WordPress est vraiment mort
Si vous obtenez un écran complètement blanc sur chaque page avant et arrière de votre site WordPress sans aucun retour d'erreur visible, c'est l'expérience WSOD complète. Vous pouvez obtenir des messages d'erreur et des informations de diagnostic si vous savez comment accéder à vos journaux d'erreurs PHP et aux journaux de serveur HTTP. Activer le débogage PHP pour WordPress est une autre option. Votre hébergeur peut avoir des outils pour vous rendre le débogage plus accessible. Mais si ce n'est pas le cas, vous pouvez simplement parcourir cette liste de remèdes pour le WSOD commun jusqu'à ce que vous trouviez votre solution.
Une liste de contrôle principale pour le dépannage et la réparation de l'écran blanc de la mort de WordPress
Pour réparer l'écran blanc de la mort de WordPress, suivre les étapes suivantes vous mènera à une solution. Ils sont organisés dans l'ordre des causes WSOD les plus courantes telles que je les ai expérimentées, mais vous pouvez les essayer dans n'importe quel ordre.
Il est plus logique de hiérarchiser les solutions qui semblent les plus pertinentes pour votre situation particulière.
L'étape de journalisation des erreurs et de débogage (#2) est la plus technique, mais elle est approfondie et vous dira toujours ce qui provoque l'arrêt de WordPress.
J'ai fourni des liens vers quelques plugins gratuits qui peuvent être des outils de diagnostic et de réparation utiles. Vous pouvez également trouver iThemes Security particulièrement utile pour sa fonction d'analyse et de réparation de base de données, ainsi que pour sa détection des modifications de fichiers. Il dispose même d'outils de serveur pour un examen plus approfondi des paramètres et des capacités de votre serveur.
En dernier recours, une bonne sauvegarde récente remettra votre site en ligne dans son dernier bon état connu. Backup Buddy est le meilleur plugin pour ce rôle.
Videz le cache et les cookies de votre navigateur
Les pages mises en cache de votre site dans votre navigateur et sur votre serveur peuvent vous montrer quelque chose de différent de ce qui se passe réellement. Assurons-nous que vous voyez ce que WordPress montre aux nouveaux visiteurs de votre site.
Tout d'abord, effacez le cache et les cookies de votre navigateur. Cela mettra fin à votre session utilisateur si vous êtes connecté à WordPress ou à tout autre site, vous le regardez donc comme n'importe quel autre visiteur.
Ensuite, utilisez votre panneau d'hébergement et votre administrateur WordPress (s'il est disponible) pour effacer toute mise en cache côté serveur créée par votre hôte et les plug-ins de cache WordPress. Essayez de désactiver toute la mise en cache de votre site et de votre serveur. Effectuez une actualisation matérielle de votre navigateur. Si cela résout le problème, le problème peut être que vous avez activé des paramètres de cache qui ne fonctionnent pas sur votre système. Grâce à un processus d'élimination, vous pouvez identifier ceux qui fonctionnent et ceux qui ne fonctionnent pas.
2. Recherchez les erreurs PHP
Le code PHP dans le noyau, les thèmes ou les plugins de WordPress peut générer une erreur fatale qui fera que WordPress abandonnera le fantôme avec un écran blanc de la mort.
Pour obtenir plus d'informations sur les erreurs PHP fatales et leurs causes, vous pouvez activer le rapport d'erreur PHP et l'envoyer à l'écran, à un fichier journal ou aux deux. Les erreurs fatales indiqueront probablement la source du WSOD.
En tant qu'application Web basée sur PHP, WordPress possède son propre système de rapport de diagnostic pour le débogage qui vous aide à tirer parti des fonctions de journalisation des erreurs de PHP. Pour l'activer et le contrôler, assurez-vous qu'il y a une ligne dans wp-config.php qui dit :
définir('WP_DEBUG', vrai);Vous devrez peut-être l'ajouter ou modifier la valeur de false à true. Cela indique à WordPress d'activer le débogage PHP.
Vous pouvez également prendre un raccourci en installant et en activant le plugin WP Debugging. Il activera le débogage PHP pour WordPress sans que vous ayez à modifier directement wp-config.php vous-même.
Les paramètres supplémentaires wp-config.php affichés ci-dessous imprimeront la sortie de débogage à l'écran au format HTML et un fichier nommé "error_log" par défaut :
définir( 'WP_DEBUG_DISPLAY', vrai ); définir( 'WP_DEBUG_LOG', vrai );
Il peut également être utile de forcer WordPress à utiliser les versions non optimisées de ses dépendances CSS et JavaScript au cas où elles causeraient un problème :
définir( 'SCRIPT_DEBUG', vrai );
Le plugin Debug Bar est un outil supplémentaire et complémentaire utile. Il vous montrera les données de débogage dans une interface agréable.
Pour que cela se produise, dans php.ini , il doit y avoir une ligne qui donne à la constante error_reporting une valeur autre que NONE , comme error_reporting = E_ALL . Il ne doit pas y avoir de point-virgule en tête de cette ligne ; cela en fait un commentaire plutôt qu'un paramètre actif. Notez que vous obtiendrez toutes les erreurs, avertissements et avis PHP si vous utilisez E_ALL . Utilisez une valeur différente comme E_ERROR pour consigner uniquement les erreurs d'exécution fatales qui font planter WordPress.
3. Vérifiez les conflits de thème et de plugin
Le débogage des erreurs PHP tel que décrit à l'étape précédente devrait vous indiquer un thème ou un fichier de plug-in clair comme source de votre WSOD. Vous pouvez également vous rapprocher d'une approche moins technique du processus d'élimination.
Thèmes de dépannage
L'écran blanc de la mort est souvent causé par des conflits entre les thèmes WordPress et/ou les plugins. Pour identifier la ou les sources de conflit, vous pouvez essayer de désactiver tous vos plugins et de passer aux packages de thèmes par défaut actuels et non modifiés avec le noyau WordPress, comme Twenty Twenty-Three.
Commencez par le thème — c'est le plus simple à tester. Si le passage de votre thème actif à un thème par défaut connu et non modifié ramène votre site en ligne, vous savez que votre problème réside dans le thème que vous utilisiez.
Jetez un œil au fichier functions.php de votre thème s'il en a un. Si vous l'avez récemment changé, c'est une source probable de votre malheur. Le fichier functions.php est l'endroit où le code fonctionnel personnalisé est ajouté pour être utilisé avec un thème lorsqu'il est activé. Un mauvais code et des erreurs de syntaxe ici vous donneront un WSOD.
Dépannage des plugins
Vous pouvez désactiver les plugins sans accès à l'administrateur WordPress via la ligne de commande/SSH ou SFTP simplement en déplaçant temporairement les dossiers des plugins hors du dossier /wp-content/plugins/ . Ma pratique consiste à créer un sous-dossier de plug-in appelé "A" afin qu'il apparaisse en premier dans le répertoire /plugins trié par ordre alphabétique. Ensuite, je déplace tous les autres dossiers de plugins dans "A".
Une fois que vous avez fait cela, rechargez votre site. WordPress se comportera comme si les plugins avaient tous disparu. Ils sont toujours installés mais désactivés. Si l'écran blanc de la mort disparaît, vous pouvez essayer de réactiver vos plugins et votre thème un par un, en actualisant votre page d'accueil à chaque fois pour voir lequel provoque le blocage de votre site.
Meks Quick Plugin Disabler est un outil pratique qui désactive rapidement tous les plugins actifs, puis les réactive depuis l'intérieur de l'administrateur WordPress à votre demande.
4. Réparer les fichiers de base corrompus
Votre WSOD peut être la conséquence de fichiers WordPress corrompus. Bien que cela soit peu probable, il est simple de réinstaller rapidement la dernière version de WordPress en un clic dans la zone WordPress Dashboard Updates. Cela n'endommagera aucun de vos plugins, thèmes ou contenus existants, c'est donc un bon moyen facile de confirmer que vos fichiers principaux sont corrects.
Si aucune des étapes ci-dessus ne vous aide, le WSOD peut être causé par un problème avec votre environnement de serveur qui est hors de votre portée. Dans ce cas, vous devrez peut-être contacter votre fournisseur d'hébergement pour obtenir de l'aide. En dernier recours, vous pouvez également ramener votre site à un état de "dernier bon connu" en restaurant une sauvegarde.
Comment prévenir un WSOD — Conseils pour les propriétaires et constructeurs de sites WordPress
WordPress fonctionnait très bien - et tout à coup, vous avez eu l'écran blanc de la mort !
C'est probablement parce que VOUS avez changé quelque chose d'essentiel au fonctionnement de WordPress.
Si vous utilisez un compte d'hébergement WordPress géré solide avec Liquid Web ou Nexcess qui est correctement configuré avec suffisamment de ressources pour ce que vous faites avec, 99 % des façons dont vous pouvez casser WordPress avec un WSOD peuvent être évitées.
Le problème est que les propriétaires de sites n'évitent pas ces pratiques !
Ce qu'il ne faut pas faire
- Codage de cow-boy. Ajouter ou modifier du code fonctionnel sur un site en direct via SFTP, la ligne de commande ou des éditeurs de code et des insertions de scripts dans l'administrateur WordPress. Une petite erreur fera tomber le site. La modification des fichiers de configuration tels que
.htaccessetwp-config.phppeut également faire tomber un site. Travaillez plutôt sur un site de test local ou en direct (mais pas public). - Installation de thèmes, plugins et extensions douteux. L'installation d'un logiciel de mauvaise qualité ou même annulé sur un site en direct est une invitation aux ennuis. Le simple fait d'ajouter trop de choses à la fois peut rendre difficile la détermination de ce qu'est finalement un changement avec rupture. Semblable au codage de cow-boy, l'installation de nouveaux produits de code dans un site en direct est risquée. Testez d'abord bien sur un local privé ou un site de staging.
- Mise en cache compliquée. Il existe plusieurs types de mise en cache côté serveur que votre hôte peut proposer et qui peuvent ne pas fonctionner correctement avec tous les plug-ins de mise en cache et d'optimisation des performances. Lorsque vous implémentez de nouvelles méthodes ou de nouveaux paramètres de mise en cache, testez soigneusement sur des environnements locaux et intermédiaires avant d'implémenter des modifications sur un site en production.
- Tout mettre à jour à la fois. Vous pouvez mettre à jour par lots de nombreux thèmes et plugins en même temps. Normalement, cela fonctionne, mais si votre serveur expire, vous risquez de rester bloqué en mode maintenance. De plus, le code récemment mis à jour peut introduire de nouveaux bogues, conflits ou problèmes de compatibilité. Si cela se produit et que votre site tombe en panne, il sera plus difficile d'identifier la source du problème. Il peut s'agir de n'importe quel nombre d'éléments si vous mettez à jour plusieurs thèmes, plugins et extensions en même temps. Le code mis à jour peut être testé localement et sur des sites de développement en direct avant de le déployer sur votre site public principal.
Conseils pour une vie sans WSOD
Le WSOD peut arriver à n'importe quel site WordPress, mais il ne faut pas s'alarmer. Suivre les conseils de ce guide peut vous aider à identifier le problème et à le résoudre rapidement avant que les visiteurs de votre site ne le remarquent.
Les problèmes avec un site WordPress soulignent l'importance d'un entretien et d'un entretien appropriés. Mieux que de réagir aux WSOD, vous pouvez apprendre à travailler sur WordPress d'une manière qui n'exposera jamais vos visiteurs à des messages d'erreur et à des écrans vides.
Apportez vos modifications avec soin et délibérément. Traitez vos WSOD potentiels dans un environnement de test ou de mise en scène local. Ce sont des outils et des fonctionnalités standard pour la plupart des hébergeurs WordPress gérés aujourd'hui. Si vous suivez ces meilleures pratiques de base, vous n'aurez pas à vous soucier de l'écran blanc de la mort de WordPress.
Le meilleur plugin de sécurité WordPress pour sécuriser et protéger WordPress
WordPress alimente actuellement plus de 40 % de tous les sites Web, il est donc devenu une cible facile pour les pirates ayant des intentions malveillantes. Le plugin iThemes Security Pro élimine les conjectures de la sécurité de WordPress pour faciliter la sécurisation et la protection de votre site Web WordPress. C'est comme avoir un expert en sécurité à plein temps dans le personnel qui surveille et protège constamment votre site WordPress pour vous.
Dan Knauss est le généraliste du contenu technique de StellarWP. Il est écrivain, enseignant et pigiste travaillant en open source depuis la fin des années 1990 et avec WordPress depuis 2004.