Corriger les soucis de sérialisation dans WordPress

Cet article a été publié il y a 7 ans 6 mois 3 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Le titre est légèrement trompeur je pense mais comme c’est le cas que j’ai eu, c’est plus simple à expliquer pour moi. Un blog, développé en local sur le laptop du développeur, qu’il faut passer en production sur un vrai domaine. Je ne vais pas faire l’inventaire de tout ce qu’il faut savoir pour faire le boulot correctement, je vais me concentrer uniquement sur la sérialisation car c’est un procédé/format de données que vous rencontrez sur d’autres CMS également.

Sérialisation, première

La sérialisation est un procédé pour transformer un jeu de données, typiquement un tableau, en un autre plus « simple », condensé, généralement une chaîne de caractères. Dit comme ça ça peut paraître étrange puisque WordPress travaille déjà avec une base de données pour stocker entre autres ses paramètres, alors pourquoi s’embêter avec un deuxième format ?

Un thème peut choisir de sérialiser ses paramètres pour éviter de créer trop d’entrées dans la table wp_options. Tous les paramètres sont alors regroupés au sein d’une chaîne de caractères qui sera éclatée et lue pour vous afficher les parties que vous aurez personnalisées.

Il est où le problème alors ?

On l’a vu, en regroupant les paramètres de la sorte les avantages nombreux : compression facile (because chaine de caractères), une seule requête sql pour tout récupérer.

Mais regardez un peu la forme (extrait) :

On voit une constante : une lettre, un :, un nombre, un :, une valeur. Si la première lettre est un s, alors la valeur est une chaîne de caractères (s pour string). Et le nombre au milieu ? C’est la longueur de la valeur. Et là se trouve notre plus gros problème. Certains thèmes et plugins stockent des chemins vers, par exemple, un script ou une feuille de style sous forme d’URL et non pas d’URI, sinon je ne serais pas là à vous parler de ça aujourd’hui.

Pour rappel, voici une URL :

Et voici l’URI qui correspond :

Avantage de la deuxième, quelque soit le domaine, si le site reste le même, le chemin reste bon, et sa longueur ne changera pas. Pour que le blog migré fonctionne correctement, les URLs doivent être réécrites, et presque inévitablement leur taille changera. On doit donc corriger les nombres pour chaque valeur modifiée.

Pourquoi ? Au mieux WordPress va réinitialiser le contenu. Au pire il va vous balancer une erreur de sérialisation, puisque la taille ne correspond plus au contenu.

Autant dire qu’on est pas sorti de l’auberge.

Un script pour les gouverner tous

Je tire un poil le trait, mais franchement ça peut sauver une vie. Si pour rappel on peut facilement changer le domaine en suivant les instructions partagées par l’ami Korben, le contenu des options, comme on l’a vu, c’est plus tendu.

Et puis récemment j’ai découvert ce script, « Database Search and Replace Script in PHP« , ou plutôt on m’a fait découvrir ce script, un grand MERCI à Nehaad qui est tombé dessus le premier 🙂

C’est du WTFPL, et c’est un outil découvert sur le serveur d’un client, en gros, vous mettez le domaine d’origine, le domaine de destination, clic, et paf, ça fait des Chocapic. Vous pouvez même vérifier à blanc ce qu’il va faire avant de le valider, si vous avez un doute. Pour les éléments de connexion à la base de données, si vous avez un trou ça se trouve dans le fichier wp-config.php. Ce client s’en sert pour resynchroniser régulièrement sa version de préproduction avec sa version de production. Simple, efficace, mis en place en très peu de temps.

Pour vous, c’est probablement pratique si vous devez mettre en place une version de test de votre site. Et dieu sait qu’avec un monde en perpétuelle évolution, pouvoir valider des modifications invasives est importante. Et quand je vois le temps que j’ai passé cette semaine à déplomber du WordPress plus ou moins salement fusillé, je vous assure que ce n’est jamais de trop.