Écran blanc de la mort de WordPress

Ce que signifie cette erreur et comment la reconnaître

• Le site WordPress, le tableau de bord d’administration ou les deux affichent une page blanche complètement vide, sans message d’erreur.
• L’échec peut concerner l’ensemble du site ou uniquement un écran précis du tableau de bord, un template, un shortcode, un bloc ou une URL.
• La page blanche peut apparaître immédiatement après l’installation ou la mise à jour d’un plugin ou d’un thème.
• Le problème peut commencer après la modification de la version PHP du site par l’hébergeur.
• Les requêtes concernées restent blanches tant que le plugin, le thème, le problème de mémoire, le problème de compatibilité ou le fichier endommagé à l’origine de l’échec PHP n’est pas corrigé.

Causes principales, classées par probabilité

1. Une erreur fatale PHP d’un plugin — la cause la plus probable lorsque le problème commence après l’installation ou la mise à jour d’un plugin, ou lorsque seules les pages liées aux plugins échouent.
2. Une erreur du thème actif — un problème dans le thème ou son fichier functions.php peut affecter de nombreuses pages ou l’ensemble du site.
3. Une mémoire PHP épuisée — une requête peut dépasser la memory_limit configurée ; le journal indique souvent Allowed memory size exhausted.
4. Une incompatibilité de version PHP — un plugin ou un thème peut contenir du code qui ne fonctionne pas avec la version PHP actuellement utilisée par l’hébergeur.
5. Des fichiers core WordPress corrompus — une mise à jour interrompue ou incomplète peut endommager les fichiers core, même si cette cause est moins probable lorsque l’échec suit clairement une modification d’un plugin ou d’un thème.

Comment corriger le problème

1. Protéger le site et identifier la requête en échec

Si vos outils d’hébergement proposent des sauvegardes, effectuez-en une avant de modifier les fichiers. Notez si la page blanche concerne le site public, le tableau de bord ou une URL particulière uniquement. Vous aurez besoin d’un accès SFTP ou au gestionnaire de fichiers du panneau d’hébergement, ainsi que de l’autorisation de modifier wp-config.php.

2. Activer la journalisation du débogage sans exposer les erreurs aux visiteurs

Ouvrez wp-config.php et ajoutez ou modifiez ces réglages afin que chaque constante n’apparaisse qu’une seule fois :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Laissez WP_DEBUG_DISPLAY défini sur false sur un site en production. Rechargez l’URL exacte qui affiche l’écran blanc, puis examinez wp-content/debug.log. Recherchez l’erreur fatale, le chemin du fichier et le numéro de ligne. Si le journal WordPress n’est pas créé ou ne contient pas l’événement, demandez à l’hébergeur de vérifier le journal d’erreurs PHP du compte.

3. Désactiver le plugin identifié par le journal

Si l’erreur mentionne un plugin, utilisez SFTP ou le gestionnaire de fichiers de l’hébergement pour ouvrir wp-content/plugins/. Renommez le dossier du plugin concerné en lui ajoutant un suffixe tel que -disabled. Le renommage empêche WordPress de charger le plugin tout en conservant ses fichiers et ses réglages.

Rechargez l’URL en échec. Si elle fonctionne, le plugin est la cause immédiate. Recherchez une mise à jour compatible ou contactez le développeur du plugin si aucune mise à jour adaptée n’existe pour les versions de WordPress et de PHP du site. Ne laissez pas actif un plugin incompatible ou obsolète simplement parce que le renommage de son dossier a rétabli le site.

4. Tester le thème actif

Si le journal pointe vers le thème actif, ou si la désactivation du plugin identifié ne résout pas le problème, renommez le dossier de ce thème dans wp-content/themes/. WordPress devrait utiliser un thème par défaut disponible.

Si le site est rétabli, examinez le fichier et la ligne indiqués dans le journal, en accordant une attention particulière à functions.php. Si aucun thème de secours utilisable n’est installé, rétablissez le nom d’origine du dossier après le test et contactez le fournisseur du thème ou l’hébergeur avant d’effectuer d’autres modifications.

5. Résoudre une erreur d’épuisement de mémoire

Si le journal indique Allowed memory size exhausted, la requête en échec a dépassé la limite de mémoire PHP configurée. Suivez la procédure de l’hébergeur ou de l’administration WordPress du site pour augmenter cette limite en toute sécurité, et cherchez à déterminer si un plugin, un thème ou une requête précise consomme trop de mémoire.

Après avoir effectué une modification de configuration autorisée, rechargez la même URL et vérifiez que la même erreur fatale n’est plus enregistrée. Augmenter la limite peut simplement masquer un composant inefficace ou incompatible ; poursuivez donc l’analyse si l’erreur réapparaît.

6. Vérifier la compatibilité de la version PHP

Si l’écran blanc a commencé après une modification de la version PHP, comparez ce moment avec le plugin ou le thème mentionné dans le journal. Désactiver temporairement cette extension peut aider à confirmer le lien.

Demandez à l’hébergeur si un retour temporaire à une version PHP précédente est possible pendant la mise à jour, le remplacement ou la correction du plugin ou du thème. Considérez ce retour comme une mesure de diagnostic ou temporaire, et non comme une solution permanente de compatibilité.

7. Restaurer les fichiers core uniquement lorsque les éléments l’indiquent

Si aucun changement de plugin, de thème, de PHP ou de mémoire n’explique l’échec et que le journal n’identifie aucune extension, des fichiers core WordPress endommagés sont possibles. Téléversez à nouveau les fichiers core WordPress correspondants depuis une nouvelle archive officielle de WordPress, via SFTP.

Ne remplacez pas wp-content ni wp-config.php. Si vous ne pouvez pas distinguer de manière fiable les fichiers core du contenu et de la configuration du site, arrêtez-vous et demandez l’aide de l’hébergeur ou d’un professionnel WordPress.

8. Vérifier le rétablissement et nettoyer

Rechargez l’URL exacte du site public ou l’écran d’administration qui était vide. Testez les pages associées utilisant le même plugin, thème, shortcode ou bloc. Examinez wp-content/debug.log et vérifiez que la même erreur fatale ne se reproduit pas.

Une fois la cause confirmée, désactivez les modifications temporaires de débogage ou assurez-vous que tout journal conservé est protégé contre l’accès public.

Prévention et vérification du correctif

• Sauvegardez le site avant de mettre à jour WordPress, les plugins, les thèmes ou la version PHP de l’hébergement.
• Mettez à jour les plugins et les thèmes un par un afin de pouvoir identifier la modification associée à un éventuel échec.
• Testez les changements importants concernant WordPress, PHP, les thèmes et les plugins sur une copie de staging avant de les appliquer en production.
• Laissez WP_DEBUG_DISPLAY désactivé sur les sites en production et limitez l’accès à tout journal de débogage.
• Surveillez la mémoire PHP disponible et analysez les composants qui s’approchent régulièrement de la limite configurée.
• Après chaque correction, rechargez l’URL exacte qui échouait et examinez le journal pour vérifier que la même erreur fatale ne réapparaît pas.

Questions fréquentes