Trouver l'origine d'une erreur WordPress, dans l'ordre qui va vite

Un site WordPress, c’est le cœur, un thème, une pile d’extensions et ce que vous avez ajouté vous-même. Quand ça casse, c’est presque toujours à la couture entre deux de ces morceaux. La bonne nouvelle : WordPress parle beaucoup, si on le laisse parler. La mauvaise : la plupart des gens ne le laissent pas parler et se mettent à deviner.

Voici l’ordre qui trouve la panne le plus vite. Ne sautez pas d’étape.

1. Lire le message d’erreur comme une phrase

Si WordPress affiche une erreur, il vous donne le fichier, la ligne et la fonction.

Fatal error: Allowed memory size exhausted in /wp-content/plugins/quelquepart.php on line 142

Ça veut dire « ce fichier, cette ligne ». Huit fois sur dix, le coupable est nommé directement. Le nom qui suit plugins/ est l’extension à désactiver. Lisez-le comme une phrase, pas comme un mur de texte.

2. Faire écrire les erreurs dans un fichier

Page blanche, rien d’autre ? WordPress se tait, c’est tout. Trois lignes dans wp-config.php :

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

Les erreurs partent maintenant dans /wp-content/debug.log. La troisième ligne compte : avec false, vos visiteurs ne voient rien pendant que vous cherchez. Vous pouvez laisser ça sur un site en production le temps de l’enquête.

Ouvrez le fichier et lisez-le par la fin. Les Warning peuvent être nombreux sans rien casser. Ce que vous cherchez, ce sont les lignes Fatal error.

3. Couper les extensions par moitiés

Pas de nom de fichier dans l’erreur, ou rien dans le log alors que le site est cassé : le coupable se cache dans vos extensions actives.

Les désactiver une par une est la pire méthode. Trente extensions, trente essais. Faites plutôt une recherche par dichotomie :

1. Désactivez la moitié des extensions
2. Si l’erreur disparaît, le coupable est dans la moitié désactivée. Sinon, dans l’autre
3. Coupez encore en deux la moitié suspecte
4. Recommencez jusqu’à n’en avoir plus qu’une

Trente extensions, cinq essais. Si l’admin est inaccessible, renommez le dossier de l’extension dans wp-content/plugins par FTP ou depuis le gestionnaire de fichiers de l’hébergeur (akismet devient akismet-off), ça la désactive tout de suite.

4. Regarder aussi côté navigateur

Le log PHP est calme, mais la page est cassée ou un bouton ne fait rien : c’est du JavaScript, ou une requête qui échoue.

Dans Chrome, F12 (Cmd+Option+I sur Mac), onglets Console et Network ouverts, et refaites la manipulation qui pose problème. Une ligne rouge, c’est presque toujours la réponse. Rouge dans Console : un script qui plante. Rouge dans Network (code 400 ou 500) : une requête au serveur qui a échoué. Un 500 vous renvoie à l’étape 2, le problème est de nouveau côté PHP.

5. Changer de thème dix minutes

Tout est propre jusqu’ici et ça casse encore ? Passez sur Twenty Twenty-Five, dix minutes. Si l’erreur s’en va, la cause est dans le functions.php de votre thème ou dans le code qu’il embarque. Si elle reste, c’est le cœur ou la configuration du serveur, et c’est le moment d’écrire au support de l’hébergeur.

Les erreurs sur lesquelles on a déjà écrit

En anglais, sur meowapps.com :

• Allowed Memory Size Exhausted
• Les erreurs de timeout
• Cookie nonce invalide
• L’API REST qui ne répond plus
• Où sont les logs PHP

Comment écrire au support ensuite

Si vous êtes arrivé jusqu’à « cette extension, cette ligne », il ne reste qu’à le dire à son auteur. On reçoit ces tickets tous les jours pour AI Engine ou Media Cleaner, et la différence est nette. « Ça ne marche pas » demande trois allers-retours de questions avant de pouvoir répondre. « Ligne 142 de foo.php, erreur X quand je fais Y » est en général corrigé dans la semaine, souvent le jour même.

Collez le message d’erreur tel quel. Collez la ligne Fatal du log. Dites en une phrase ce que vous faisiez. C’est tout, et ça change tout 🙂