Débugger un WordPress multisites en mode bourrin

closeCet article a été publié il y a 8 ans 1 jour, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Récemment, je suis tombé sur un bug étrange : le site, basé sur WordPress est correctement installé, la connexion à la base de données fonctionne (testée en ligne de commandes, puis avec un script maison), et pourtant, il affiche une erreur de connexion à la base de données. Il aura fallu beaucoup de patience, d’essais, et de bidouille de barbu pour avoir la solution. C’est vicieux.

Posons le décor : il s’agit de créer une version de pré-production d’un site en production. Il a donc simplement été « cloné » (base + fichiers), dans un VirtualHost à part avec une configuration FPM dédiée. Le WordPress est un multisites, et il est configuré de manière habituelle, avec dans le fichier wp-config.php les paramètres suivants :

Dans la base, le siteurl (et le home) est également sur le bon domaine :

Après avoir vu fonctionner l’accès à la base dans le même environnement que le site en question, j’ai cherché dans les erreurs PHP. Rien, nada, que dalle, nib. Même en mode debug.

L’étape suivante, le truc de barbu, capturer une trace de l’exécution des threads FPM (le pool est appelé « preprod ») lors de l’appel au site. C’est assez violent, j’avoue, mais ça fonctionne pas mal :

Je remercie Djerfy qui s’était attelé à résoudre un problème sur lequel nous pauvres petits admins butions, et qui a donc lancé cette routine sur un serveur que nous infogérons. Cette commande va donc vous créer un fichier de trace de chaque process FPM lancé (le pid du process est en suffixe, le filtre « preprod » permettant d’isoler le bon pool). J’ai ensuite filtré le fichier récupéré grâce à grep sur le mot-clé « sql » :

Erf, je n’ai pas les messages en entier, mais ceux-ci ressemblent tout de même à des requêtes SQL. On affine un peu, on ajoute une ou deux options par-ci par-là (on filtre notamment les sendto et les recvfrom qui concernent le SQL), la commande devient maintenant :

Là, on voit quelque chose d’un peu plus parlant :

Donc il en exécute des requêtes, et pourtant il affiche l’erreur de connexion, mais que se passe-t-il ? On découvre dans ce fatras une requête sur une table wp_blogs, par curiosité, je la lance à la main sur la base :

Ah, étrange, mais que pourrait-il donc y avoir dans cette table ?

Oh, le joli champ domain qui ne correspond pas du tout. On a déjà une copie de la base, on va donc se permettre de modifier les domain en direct :

Devinez quoi ? Le site s’affiche instantanément.

Je ne sais pas pourquoi il persiste à afficher l’erreur de connexion à la base de données alors que la connexion fonctionne parfaitement, et qu’il ne trouve simplement pas de site correspondant au domaine à afficher. Mais voilà, si jamais vous devez manipuler un WordPress multisites, vous êtes prévenus.

La commande strace utilisée plus haut va m’être très utile. En effet, je n’ai toujours pas réussi à corriger le tir sur l’article 1 de la série de la sécurisation de serveur, qui fait planter FPM. Souhaitez-moi bonne chance.

PS : l’après-midi après avoir planifié l’article, j’ai trouvé la solution au problème. Compte-rendu de l’enquête très bientôt.

1 Commentaire
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
Djerfy
25/04/2016 21:08

Si tu veux je dois avoir une commande (qui traine quelque part) pour afficher correctement une requête à partir d’un strace, disons que c’est plus lisible. J’te donnerais ça dans la semaine (le temps de chercher)…

Côté WordPress tu peux aussi regarder pour optimiser le fichier wp-config avec l’ajout des paramètres tel que WP_HOME et WP_SITEURL. Ces paramètres vont surcharger ce que tu as justement en base et éviter ces dysfonctionnements entre environnements 🙂