Votre site n'affiche plus rien. Une page entièrement vide, ou une seule phrase sur fond gris qui dit qu'il y a eu une erreur critique. Le tableau de bord ne répond plus non plus, ou alors il répond et c'est le site public qui est mort.
Ce guide donne la procédure qu'on applique en intervention. Il commence par une distinction que presque aucun autre ne fait, et qui divise le travail par deux : il existe deux pannes différentes derrière ce que tout le monde appelle « écran blanc », et la manière de les reconnaître prend dix secondes.
Ce que vous avez sous les yeux, exactement
Regardez votre écran et répondez à une seule question : est-il complètement vide, ou affiche-t-il une phrase ?
Cette question paraît idiote. Elle sépare pourtant deux familles de causes qui n'ont rien à voir, et c'est la raison pour laquelle tant de gens perdent des heures : ils appliquent à la première panne les remèdes de la seconde.
Écran numéro un : une page absolument vide
Rien. Pas un mot, pas un pixel, un fond blanc. Si vous affichez le code source de la page, avec un clic droit puis « afficher le code source », il est vide lui aussi.
Nous avons provoqué cet écran au laboratoire en plaçant un appel de fonction inexistante dans wp-config.php. Le serveur a répondu avec un code 500 et zéro octet. Pas 2 000 octets, pas 300 : zéro.
Ce que ça signifie : l'erreur s'est produite avant que WordPress ne démarre. WordPress n'a jamais eu la main, donc il n'a rien pu afficher, pas même son propre message d'erreur. Le coupable est dans les tout premiers fichiers chargés, ou dans la configuration du serveur.
Écran numéro deux : la phrase de WordPress
Une phrase, centrée, sur fond gris clair : « Il y a eu une erreur critique sur ce site. »
Ce que ça signifie : c'est exactement l'inverse. WordPress a démarré normalement, puis quelque chose s'est cassé en cours de route. Il a attrapé l'erreur, et il vous a affiché sa page de secours. Le coupable est dans le code exécuté après le démarrage : une extension, le thème, une incompatibilité de version de PHP.
C'est une bonne nouvelle, même si ça n'en a pas l'air : WordPress fonctionne assez pour se plaindre, et il a probablement écrit ce qui s'est passé quelque part.
Le détail que personne ne signale
Sur le même site cassé, le visiteur et vous ne lisez pas la même phrase.
Un visiteur non connecté voit une phrase courte. Vous, en tapant l'adresse de votre tableau de bord, vous en voyez une plus longue : « Veuillez vérifier la boîte de réception de votre e-mail d'administration pour obtenir des instructions. »
Retenez ce détail. S'il vous parle d'un e-mail, c'est que WordPress en a envoyé un, et cet e-mail contient le nom du fichier fautif et le numéro de la ligne. C'est le raccourci le plus rapide qui existe vers la cause.
Le troisième cas, celui qu'on oublie
Il existe une troisième chose que les gens appellent écran blanc, et ce n'en est pas un : une page qui commence à s'afficher puis s'arrête en plein milieu. Le menu est là, le début du contenu aussi, et sous une certaine hauteur, plus rien.
Au laboratoire, en déclenchant l'erreur tard dans le rendu, dans le pied de page, on a obtenu 67 627 octets envoyés puis un arrêt net. Ni page blanche, ni message d'erreur : une page tronquée. Si c'est votre cas, sautez directement à la section sur la lecture des journaux, la cause est identique à celle de l'écran numéro deux mais le symptôme trompe.
En trente secondes
Trois gestes, dans cet ordre, avant de toucher à quoi que ce soit.
1. Notez lequel des trois écrans vous avez. Vide, message, ou page coupée. Cette seule observation élimine la moitié des causes.
2. Ouvrez votre boîte mail et cherchez « WordPress ». Si le message parle d'un e-mail d'administration, WordPress a essayé de vous écrire. L'objet ressemble à « Votre site rencontre un problème technique ». À l'intérieur : le nom de l'extension ou du thème fautif, le fichier, et le numéro de ligne. Cinq secondes de lecture contre trois heures de tâtonnement.
3. Chargez un fichier statique de votre site. Tapez https://votre-domaine.fr/readme.html dans le navigateur. Ce fichier est livré avec WordPress et ne contient aucun code exécutable.
- La page s'affiche : le serveur fonctionne, le problème est bien dans WordPress ou dans PHP.
- Vous obtenez encore une page blanche ou une erreur : ce n'est pas WordPress. C'est le serveur, l'hébergement, ou vos noms de domaine. Inutile de renommer quoi que ce soit dans
wp-content. Si le serveur renvoie un code 500 sur ce fichier statique, la panne est ailleurs et le guide de l'erreur 500 est le bon point de départ.
Ce troisième test est l'équivalent, pour l'écran blanc, du test de fichier statique qu'on utilise sur les erreurs 500. Il tranche en dix secondes ce que des heures de manipulations à l'aveugle laissent dans le flou.
Vérifiez d'abord ce qui n'est pas votre site
Avant d'ouvrir le moindre fichier, deux vérifications qui coûtent une minute et qui, dans un cas sur dix, terminent le dépannage.
Vos autres sites répondent-ils ? Si vous avez plusieurs sites sur le même hébergement, ouvrez-en un autre. S'ils sont tous blancs, votre WordPress n'y est pour rien : c'est l'hébergeur. Allez voir sa page d'état, ou son fil d'incidents. Ce réflexe est le premier chapitre du guide de WPBeginner en anglais, et il n'apparaît dans aucun article français que nous ayons lu.
Avez-vous changé d'hébergeur ou de nom de domaine récemment ? Un fil de forum consacré à un écran blanc s'est conclu, après plusieurs jours, sur une propagation de noms de domaine qui n'était simplement pas terminée. Le site n'avait jamais été cassé.
Le panneau de votre hébergeur s'ouvre-t-il ? S'il est lui aussi en panne, vous avez votre réponse, et il n'y a rien à faire d'autre qu'attendre.
Les causes, par fréquence réelle
Ce tableau croise ce qu'on voit en intervention, ce que remontent les fils de forums, et ce que les guides de neuf pays traitent ou ignorent.
| Cause | Écran | Ce qui la trahit |
|---|---|---|
| Extension incompatible ou cassée | message | apparu juste après une mise à jour ou une activation |
| Thème après mise à jour | message | le tableau de bord répond encore, le site public non |
| Mémoire PHP épuisée | message | Allowed memory size ... exhausted dans le journal |
| Version de PHP changée par l'hébergeur | message | personne n'a rien touché, et pourtant c'est cassé |
Erreur de syntaxe dans functions.php |
vide ou message | vous venez d'éditer un fichier |
Ligne parasite dans wp-config.php |
vide | un outil tiers a modifié le fichier |
Drop-in cassé, db.php ou advanced-cache.php |
vide | un plugin de cache ou de base récemment installé |
| Mise à jour interrompue | message | un fichier .maintenance traîne à la racine |
| Espace disque saturé | vide ou message | l'hébergeur ne peut plus rien écrire |
| Fichiers du cœur corrompus | variable | transfert FTP interrompu, ou compromission |
L'arbre de diagnostic
Suivez-le dans l'ordre. Chaque branche élimine une famille entière.
Le fichier statique répond-il ? Non, allez voir votre hébergeur, ce n'est pas WordPress. Oui, continuez.
Avez-vous reçu un e-mail de WordPress ? Oui, il nomme le fichier fautif, allez directement à la réparation de cette cause. Non, continuez. Ne restez pas bloqué sur cet e-mail, la section suivante explique pourquoi il n'arrive souvent jamais.
L'écran est-il vide ou porte-t-il une phrase ?
Vide, le problème est avant le démarrage de WordPress, allez à la section sur wp-config.php et les drop-ins.
Une phrase, le problème est dans le code chargé après le démarrage, allez à la lecture des journaux.
Le tableau de bord répond-il, lui ? Oui, vous avez de la chance, désactivez les extensions depuis l'interface, une par une, en rechargeant le site entre chaque. Non, il faudra passer par le FTP ou le gestionnaire de fichiers de l'hébergeur.
Pourquoi l'e-mail de récupération n'arrive jamais
C'est le point sur lequel les gens se bloquent le plus longtemps, et une seule vidéo au monde, en espagnol, l'explique franchement. WordPress vous dit d'aller voir votre boîte mail. Vous y allez. Il n'y a rien.
Trois raisons, toutes vérifiées dans les fils de forums.
Votre site n'envoie pas d'e-mails du tout. Beaucoup d'installations n'ont jamais eu de configuration d'envoi qui fonctionne. Vous ne l'avez jamais remarqué parce que vous n'aviez jamais eu besoin qu'un e-mail parte.
L'adresse d'administration n'est pas la vôtre. C'est le cas le plus fréquent et le plus rageant. L'adresse enregistrée dans WordPress est celle de l'agence qui a construit le site il y a six ans, ou d'un ancien salarié. Un fil documente une personne qui recevait les alertes d'un site qu'elle ne pouvait pas administrer, sans même avoir de compte : « It simply tells me there is no account associated with that email. »
Le lien expire au bout d'un jour. Et un nouveau lien n'est envoyé qu'à la prochaine erreur. Si vous découvrez la panne le lundi pour un plantage du samedi, le lien est mort.
Il existe une adresse de secours, que seul un article dans tout le corpus mondial mentionne. Tapez directement :
https://votre-domaine.fr/wp-login.php?action=entered_recovery_mode
Elle n'ouvre le mode de récupération que si une session de récupération est déjà valide. Ça ne marche donc pas toujours, et deux fils de forums documentent le cas où ce mode refuse de démarrer avec le message « Recovery Mode not initialized », sans qu'aucune solution n'ait été trouvée. Essayez-la, mais ne construisez pas votre dépannage dessus.
Faire parler le site
Un site qui n'affiche rien peut quand même écrire ce qui lui arrive. Il y a deux journaux, et ils ne disent pas la même chose.
Le journal de WordPress
Ouvrez wp-config.php par FTP ou par le gestionnaire de fichiers de votre hébergeur. Trouvez la ligne qui dit de ne rien modifier au-delà, et juste avant elle, ajoutez :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Rechargez la page en panne, puis lisez wp-content/debug.log. Cherchez PHP Fatal error. Ignorez les Warning et les Notice, ils sont bruyants et rarement responsables.
Si le fichier reste vide, ou ne se crée pas, ce n'est pas un échec. C'est une information, et elle est précieuse. Elle veut dire l'une de deux choses : soit votre hébergeur bloque l'écriture des journaux, soit la panne se produit avant que WordPress ait pu ouvrir son journal. Dans les deux cas, la réponse est dans l'autre journal.
Un fil de forum d'hébergeur résume ce moment mieux que n'importe quel article : « aucun logs n'est écrit nulle part », « à n'y rien comprendre ». La personne finit par trouver, en supprimant toutes ses extensions par FTP puis en les réinstallant une par une.
Le journal du serveur
Celui-là existe même quand WordPress n'a jamais démarré. Il s'appelle error_log ou error.log, et il se trouve dans le panneau de votre hébergeur, souvent dans une section « journaux » ou « logs ».
C'est là qu'on lit les lignes décisives. Voici deux vraies lignes relevées au laboratoire.
Pour une extension cassée :
PHP Fatal error: Uncaught Error: Class "Fournee_Creneaux" not found
in /wp-content/plugins/reservation-fournee/reservation-fournee.php:11
Pour une mémoire épuisée :
PHP Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 20480 bytes) in /wp-content/plugins/reservation-fournee.php on line 14
Le fichier, la ligne, la nature de l'erreur. Tout est là.
La réparation, cause par cause
Une extension a cassé le site
C'est la cause la plus fréquente, et de loin. Le journal vous donne son nom.
Par FTP ou par le gestionnaire de fichiers, allez dans wp-content/plugins et renommez le dossier de cette extension précise, en ajoutant -off à la fin par exemple. WordPress ne la trouvera plus et la désactivera tout seul.
Un mot sur le conseil que vous allez lire partout, et qui consiste à renommer le dossier plugins entier d'un coup. Il fonctionne, il est brutal, et il est cité dans au moins huit fils de forums différents. Dans chacun de ces fils, quelqu'un le conteste dans la foulée, et plusieurs personnes rapportent l'avoir fait sans le moindre effet. Un développeur résume : activez le débogage, il vous donne le problème exact, plutôt que de tout éteindre à l'aveugle. Renommer le dossier entier est un test d'isolement, pas une réparation, et il vous coûtera de réactiver vos extensions une par une ensuite en perdant certains réglages.
Faites-le seulement si vous n'avez aucun journal exploitable.
Le thème est en cause
Symptôme typique : le tableau de bord répond, le site public non. Renommez le dossier du thème actif dans wp-content/themes. WordPress bascule automatiquement sur un thème par défaut, moche mais fonctionnel, et votre site revient. Vous saurez alors où chercher.
Si vous venez d'éditer functions.php depuis l'éditeur de WordPress, c'est presque certainement là. Un caractère en trop suffit.
La mémoire est épuisée
Voici le point où ce guide contredit tous les autres.
Une mémoire épuisée ne donne pas un écran blanc. Nous l'avons vérifié : limite abaissée à 64 Mo, extension gourmande activée, résultat un code 500 et la page « Il y a eu une erreur critique sur ce site », pas une page vide. Depuis WordPress 5.2, le gestionnaire d'erreur fatale attrape l'épuisement mémoire et affiche sa page.
Si vous avez un écran vide, arrêtez de chercher du côté de la mémoire. Si vous avez le message, et que le journal confirme Allowed memory size ... exhausted, ajoutez dans wp-config.php, avant la ligne de fin :
define( 'WP_MEMORY_LIMIT', '256M' );
Si rien ne change, c'est que votre hébergeur plafonne la mémoire au-dessus de WordPress. Cette valeur ne peut alors être relevée que depuis le panneau de l'hébergeur, ou par son support. Et gardez en tête qu'une consommation anormale est un symptôme, pas une cause : quelque chose consomme trop, et c'est ça qu'il faut trouver. La section « Quand c'est la mémoire PHP qui manque », plus bas, dit où cette limite se règle vraiment et comment identifier ce qui l'épuise.
Le fichier de configuration a été modifié
C'est la cause de l'écran vide à zéro octet, et c'est celle que nous avons reproduite. Une ligne parasite dans wp-config.php, ajoutée par un outil de sauvegarde, par un plugin d'optimisation, ou par un transfert qui s'est mal passé.
Ouvrez wp-config.php et regardez trois choses.
Le tout début du fichier. Il doit commencer par <?php, immédiatement, sans un espace, sans une ligne vide, sans le moindre caractère avant. Un espace avant l'ouverture PHP suffit à casser une installation.
La toute fin du fichier. Elle ne doit rien contenir après la dernière ligne de code. Pas de balise fermante suivie d'espaces, idéalement pas de balise fermante du tout.
Les identifiants de base de données. S'ils ont changé, le symptôme n'est en général pas un écran blanc mais un message explicite, traité dans le guide de l'erreur de connexion à la base de données. Vérifiez quand même qu'ils sont intacts.
Toute ligne qui n'y était pas. Comparez avec wp-config-sample.php, qui est livré avec WordPress et qui se trouve dans le même dossier. Les lignes propres à votre site sont les identifiants de base de données, les clés de sécurité, le préfixe des tables. Tout le reste mérite une question.
Le fil de forum le plus long que nous ayons lu sur ce sujet, vingt-neuf réponses étalées sur cinq ans, s'est conclu exactement là : le fichier contenait du code étranger venu d'un gestionnaire de fichiers web. La personne avait entre-temps désactivé toutes ses extensions, remplacé le dossier wp-admin, changé de thème, supprimé son .htaccess et réinitialisé ses permaliens. Rien de tout cela ne pouvait marcher, parce que rien de tout cela ne touche wp-config.php.
Un drop-in bloque le démarrage
Peu connus, et pourtant responsables d'écrans vides. Ce sont des fichiers qui se placent directement dans wp-content et que WordPress charge très tôt, avant tout le reste :
db.php, installé par certains plugins de base de donnéesadvanced-cache.phpetobject-cache.php, installés par les plugins de cachemaintenance.php
Si l'un d'eux référence un plugin que vous avez supprimé, WordPress plante avant d'avoir démarré, et vous n'avez ni message ni journal WordPress. Un commentaire d'une vidéo espagnole donne le chemin exact du coupable le plus courant : /wp-content/advanced-cache.php, laissé derrière lui par un plugin de cache désinstallé.
Renommez le fichier suspect, rechargez. Si le site revient, vous avez trouvé.
Une mise à jour s'est interrompue
Cherchez à la racine du site un fichier nommé .maintenance. Il commence par un point, donc votre client FTP doit être réglé pour afficher les fichiers cachés. WordPress le crée le temps d'une mise à jour et le supprime ensuite. S'il est resté, c'est que la mise à jour a été coupée en route.
Supprimez-le. Trente secondes, et dans plusieurs fils c'est tout ce qu'il fallait.
L'espace disque est plein
Un serveur qui ne peut plus rien écrire produit des symptômes incohérents, y compris des pages vides. Regardez la consommation dans le panneau de votre hébergeur avant de vous lancer dans autre chose. Sur un hébergement mutualisé d'entrée de gamme, un quota atteint est une cause banale et rarement soupçonnée.
Quand c'est la mémoire PHP qui manque
Le geste d'urgence est plus haut. Restent trois questions : est-ce bien la mémoire, qu'est-ce qui l'a vidée, et pourquoi la valeur écrite dans wp-config.php reste-t-elle si souvent lettre morte.
Reconnaître la panne dans le journal
Le message a toujours la même forme, Allowed memory size of X bytes exhausted (tried to allocate Y bytes), puis le fichier et le numéro de ligne. La version complète relevée au laboratoire est plus haut, dans « Faire parler le site ».
Vous ne la verrez presque jamais à l'écran. En production, l'affichage des erreurs est coupé : PHP se tait, WordPress affiche sa page de secours. Le message part dans wp-content/debug.log si le débogage est activé comme indiqué plus haut, et dans le journal du serveur dans tous les cas.
Les deux nombres ne disent pas la même chose. Le premier est le plafond atteint : 67108864 octets sur notre relevé, soit les 64 Mo auxquels la limite avait été abaissée. Le second, entre parenthèses, est le bloc que PHP n'a pas pu réserver, et c'est lui qui oriente. Vingt kilo-octets, comme ici : le site frôlait le plafond depuis longtemps, la ligne nommée n'a réclamé que la goutte de trop, le gourmand est ailleurs. Plusieurs dizaines de mégaoctets d'un coup, c'est l'inverse : cette opération a demandé un gros bloc, vous tenez le coupable.
Ce qui consomme, en pratique
Le traitement d'une image au téléversement. Le piège le moins intuitif. Un JPEG est compressé sur le disque ; pour fabriquer les miniatures, WordPress le décompresse entièrement en mémoire, où il occupe bien plus que son poids de fichier. Une photo d'appareil récent suffit. Les deux moteurs d'image de WordPress, GD et Imagick, demandent d'ailleurs une hausse de la limite avant de commencer.
Un export ou un import. Sauvegarde qui construit son archive, catalogue produit exporté en CSV : ces traitements empilent en mémoire au lieu d'écrire au fil de l'eau.
Une requête qui ramène tout d'un coup. Un posts_per_page réglé sur -1 charge le catalogue entier en objets PHP. Ça tenait à deux cents produits, ça tombe à trois mille.
Une extension qui garde un jeu de données complet en mémoire. Table de correspondance, dictionnaire de traduction, index de recherche.
Trois endroits règlent la limite, un seul gagne
memory_limit est le réglage de PHP lui-même. WP_MEMORY_LIMIT est la constante que vous écrivez dans wp-config.php. Au-dessus des deux, il y a ce que l'hébergeur autorise, qui n'est pas forcément ce qu'il applique.
Ce que WordPress en fait se lit dans son code, wp-includes/default-constants.php : il compare votre constante à la valeur courante de PHP et, si elle est plus haute, il demande à PHP de relever sa limite. Une demande, pas un ordre. Si l'hébergeur a verrouillé memory_limit dans le pool PHP-FPM, PHP refuse, et votre ligne n'aura rien changé. Voilà pourquoi tant de gens montent la valeur, rechargent, remontent encore, sans jamais voir d'effet.
Le même fichier donne les défauts : WP_MEMORY_LIMIT vaut 40 Mo sur un site simple et 64 Mo sur un multisite, WP_MAX_MEMORY_LIMIT vaut 256 Mo. Cette seconde constante, souvent confondue avec la première, ne s'applique pas partout : seulement aux écrans d'administration, aux tâches planifiées et au traitement d'une image. Sur vos pages publiques, WP_MEMORY_LIMIT gouverne seule.
Ce qu'il ne faut surtout pas faire : poser php_value memory_limit dans un .htaccess. En PHP-FPM, mode par défaut chez les mutualisés français, Apache refuse alors le site entier avec une erreur 500.
Si votre tableau de bord répond encore, vérifiez ce qui s'applique vraiment : Outils, Santé du site, onglet Informations, section Serveur. La ligne « Limite de mémoire PHP » donne la valeur réelle, doublée d'une ligne « (uniquement pour les écrans d'administration) » quand les deux diffèrent. Les constantes, plus bas, disent celle qui a été retenue.
Monter la limite répare, et n'explique rien
Devant un site tombé un mardi matin, augmenter la limite est le bon geste : le site revient tout de suite. Sachez seulement que vous venez d'agrandir le récipient sans regarder ce qu'on y verse.
Le signal à surveiller, c'est la répétition. Une limite qu'il faut relever une fois, puis encore pour tenir le mois suivant, ne décrit pas un site qui manque de mémoire mais quelque chose qui en consomme toujours plus. À ce moment-là, cherchez le responsable plutôt que le chiffre à écrire. Deux ou trois lignes de journal comparées désignent souvent le même fichier.
Quand ce n'est pas la mémoire
Si le site répond péniblement mais finit toujours par répondre, sans jamais tomber, la mémoire n'est pas le sujet. Vous avez un site lent, et le raisonnement n'est pas le même.
Si la page meurt en plein calcul parce qu'elle a dépassé le temps accordé, le symptôme change du tout au tout. PHP est tué par max_execution_time et le serveur renvoie un 500 au corps vide, mesuré au laboratoire à 30,03 secondes sur une limite réglée à 30. Pas de page « erreur critique », pas de ligne Allowed memory size dans le journal, une réponse creuse. C'est le domaine du guide de l'erreur 500.
Écran blanc uniquement sur le tableau de bord
Votre site public fonctionne, mais /wp-admin est blanc.
C'est souvent une extension qui ne se charge que dans l'administration. Renommez le dossier plugins pour vérifier, puis remettez-le en place et procédez extension par extension.
Deuxième piste, plus discrète : un plugin de cache qui masque le problème côté public. Le site public sert une version enregistrée d'avant la panne, donc il a l'air d'aller bien, alors que rien ne fonctionne plus vraiment. Un fil de forum allemand documente précisément ce cas, avec un modérateur expérimenté qui part sur une mauvaise piste pendant plusieurs messages parce qu'il n'avait pas relié ce détail à la cause réelle.
Si votre site public fonctionne mais que le tableau de bord est mort, videz le cache avant toute autre conclusion : vous découvrirez peut-être que le site public est cassé lui aussi.
Si rien n'a marché
Trois choses à faire avant d'aller plus loin.
Remplacez les fichiers du cœur. Téléchargez WordPress depuis fr.wordpress.org, décompressez, et téléversez par FTP en écrasant wp-admin et wp-includes. Ne touchez ni à wp-content, ni à wp-config.php. Une vidéo allemande est la seule du corpus à écrire cet avertissement noir sur blanc, et c'est pourtant la manipulation qui fait perdre le plus de données quand elle est mal faite.
Regardez si votre hébergeur a changé la version de PHP. Beaucoup le font sans prévenir, ou avec un e-mail que personne ne lit. Une extension qui n'a pas été mise à jour depuis longtemps casse net au passage à une version majeure. Le panneau de l'hébergeur permet en général de revenir en arrière temporairement, le temps de mettre à jour proprement.
Restaurez une sauvegarde, mais sachez ce que vous faites. Restaurer ramène le site, et ne dit rien de la cause. La panne reviendra à la prochaine mise à jour. Notez au moins la date à laquelle le site fonctionnait, et ce qui a changé entre les deux.
Un point à connaître : chez certains hébergeurs mutualisés, les sauvegardes automatiques ne remontent qu'à deux semaines pour les fichiers. Vérifiez la profondeur réelle avant de compter dessus.
Si vous préférez ne pas y toucher, ou si vous avez déjà passé une heure dessus, c'est exactement le genre de panne qu'on traite en intervention. Le faire réparer un site WordPress qui n'affiche plus rien coûte 149 € HT, remis en ligne ou remboursé.
Comment éviter que ça recommence
Les mises à jour d'extensions sont la première cause d'écran blanc. Trois habitudes suffisent à écarter l'essentiel du risque.
Mettez à jour une extension à la fois, en rechargeant le site entre chaque. Quand ça casse, vous savez immédiatement laquelle.
Vérifiez que l'adresse d'administration est bien la vôtre. Réglages, Général, « Adresse e-mail d'administration ». C'est cette adresse qui recevra le message contenant le nom du fichier fautif. Si c'est celle de votre ancien prestataire, vous ne recevrez jamais rien.
Sachez où sont vos journaux avant d'en avoir besoin. Trouvez la section « logs » du panneau de votre hébergeur un jour où tout va bien. Le jour de la panne, vous ne chercherez pas.
Questions fréquentes
Pourquoi mon site affiche une page blanche ?
Parce qu'un programme s'est arrêté sans rien écrire. Deux situations très différentes se cachent derrière ce même symptôme. Si la page est entièrement vide, l'erreur s'est produite avant que WordPress ne démarre, dans wp-config.php ou dans un fichier chargé très tôt. Si la page affiche « Il y a eu une erreur critique sur ce site », WordPress a démarré puis a rencontré une erreur fatale dans une extension, un thème, ou du code personnalisé. Le premier réflexe est de regarder laquelle des deux vous avez, parce que les remèdes n'ont rien à voir.
Pourquoi WordPress ne marche pas après une mise à jour ?
Parce qu'une extension ou un thème n'est plus compatible avec ce qui vient de changer. C'est la cause la plus fréquente de l'écran blanc, et elle est facile à confirmer : si la panne date de la mise à jour, le coupable est presque toujours ce qui a été mis à jour. Le journal du serveur nomme le fichier exact. À défaut, renommez le dossier de la dernière extension mise à jour et rechargez la page.
Comment débloquer un site WordPress ?
Dans l'ordre : chargez un fichier statique du site, readme.html par exemple, pour savoir si le serveur répond. Cherchez un e-mail de WordPress qui nommerait le fichier fautif. Activez le débogage dans wp-config.php et lisez wp-content/debug.log. Si ce fichier reste vide, lisez le journal d'erreur du serveur depuis le panneau de votre hébergeur. Puis désactivez la cause identifiée en renommant son dossier par FTP. Désactiver toutes les extensions à l'aveugle avant d'avoir lu un journal fait perdre du temps et ne règle rien dans les cas où l'erreur se produit avant le démarrage.
Un écran blanc, est-ce que mon site est piraté ?
C'est possible mais ce n'est pas le cas le plus probable. Un écran blanc vient bien plus souvent d'une mise à jour ratée ou d'une incompatibilité que d'une attaque. Un indice sérieux de compromission serait plutôt un fichier wp-config.php contenant du code que vous ne reconnaissez pas, des fichiers PHP inconnus à la racine, ou des comptes administrateurs que vous n'avez pas créés. Si vous en trouvez, ne vous contentez pas de nettoyer ce qui se voit.
Comment savoir quelle extension a cassé mon site ?
Par le journal, pas par élimination. Le journal d'erreur du serveur écrit le chemin complet du fichier responsable et le numéro de la ligne, par exemple /wp-content/plugins/nom-de-l-extension/fichier.php:11. C'est immédiat. La méthode par élimination, qui consiste à désactiver toutes les extensions puis à les réactiver une par une, ne sert que lorsque aucun journal n'est accessible, et elle vous fera perdre vos réglages sur certaines extensions.
Le site fonctionne mais le tableau de bord est blanc, pourquoi ?
Deux explications. Soit une extension ne se charge que dans l'administration, et c'est elle qui plante. Soit un plugin de cache sert aux visiteurs une version enregistrée avant la panne, ce qui donne l'illusion que le site public va bien. Videz le cache pour lever le doute : vous découvrirez peut-être que le site public est cassé lui aussi et que la panne est plus large que vous ne le pensiez.