Comme tout le monde (j’espère ;-)), j’ai mis à jour ce site vers la dernière version 4.3 de WordPress sortie il y a 2 jours. Mal inspiré j’étais, car je suis tombé sur un bug plutôt chiant que je viens de résoudre.
Je vais donc partager mon expérience avec vous, car peut être, rencontrez-vous le même souci. Toujours dans le cadre des optimisations de la table wp-options, dont je vous parlais la dernière fois, j’ai remarqué que depuis la mise à jour, la table wp-options avait tendance à grossir, grossir, grossir, jusqu’à en faire saturer MySQL.
Après analyse plus approfondie de la table wp-options, j’ai remarqué que cette fois, c’était le champ « cron » qui se remplissait à une vitesse folle. J’avais plus de 2 millions de caractères dedans…
Surement la faute à un plugin… J’ai donc commencé soft en cherchant les plugins qui utilisaient wp-cron pour voir lequel déconnait. J’ai aussi installé un plugin pour déporter le cron de WordPress vers la vraie crontab du serveur… Et j’ai changé quelques paramètres par-ci par-là pour voir si ça résolvait le problème. Que des fausses pistes !
J’ai donc désactivé TOUS les plugins, pensant les réactiver un par un afin de trouver le plugin fautif. Et là, je n’en ai pas cru mes yeux puisque même sans aucun plugin, le champ cron continuait à grossir au-delà du raisonnable… Ma table wp-options dépassant largement les 12 MB à ce moment-là. (Et plus, j’avais une tentative de bruteforce sur MySQL en même temps, je ne vous raconte pas le bonheur…)
C’est donc WordPress lui-même qui remplissait ce champ sans jamais le nettoyer… Rah le vilain bug. Après avoir fouillé sur le Trac de WordPress, j’ai vu que je n’étais pas seul et qu’il s’agissait d’un souci avec le job cron wp_batch_split_terms qui est mal appelé dans le fichier wp-includes/taxonomy.php
Il faut donc remplacer la ligne 4448 de ce fichier :
wp_schedule_single_event( ‘wp_batch_split_terms’, time() + MINUTE_IN_SECONDS );
par :
wp_schedule_single_event( time() + MINUTE_IN_SECONDS, ‘wp_batch_split_terms’ );
puis j’ai vidé le contenu du champs cron dans wp-options (via phpmyadmin) pour que tout rentre dans l’ordre. En gros comme les paramètres sont inversés dans l’appel, les timestamps ne correspondent pas, et le champ cron n’est jamais nettoyé.
C’était du sport, mais c’est résolu et comme vous pouvez le voir ici, le correctif sera bien présent dans la prochaine mise à jour de WordPress !
Si vous rencontrez le même problème, j’espère que ce modeste post vous aura été bénéfique.