Pourquoi le search-replace sérialisation-safe
Changer l'URL d'un site WordPress sans corrompre les données sérialisées : le problème des longueurs encodées, et comment l'outil le résout.
Le problème
WordPress stocke beaucoup d'options (réglages de thème, widgets, Elementor…) sous forme de données PHP sérialisées. Or ce format encode la longueur de chaque chaîne. Si vous remplacez une URL par une autre de longueur différente avec un simple « rechercher/remplacer » SQL, la longueur déclarée ne correspond plus — et WordPress n'arrive plus à lire la donnée.
Un exemple concret
Une option siteurl sérialisée. Notez le s:25 : la chaîne fait 25 caractères.
a:1:{s:7:"siteurl";s:25:"https://ancien-domaine.com";}a:1:{s:7:"siteurl";s:25:"https://nouveau-domaine.com";}s:25 n'a pas changé → donnée corrompue, illisible par PHP.a:1:{s:7:"siteurl";s:26:"https://nouveau-domaine.com";}s:26 : la longueur est mise à jour en même temps que la valeur. Donnée valide.Comment l'outil s'y prend
Pour chaque table ayant une clé primaire, et pour chaque valeur texte contenant l'ancien domaine, l'outil :
- Dé-sérialise la valeur (si elle l'est).
- Parcourt récursivement tableaux, objets et chaînes imbriqués.
- Remplace l'ancienne chaîne par la nouvelle.
- Re-sérialise : PHP recalcule alors automatiquement les longueurs.
Résultat : on peut passer de knosa.ancien.com à test.nouveau.org (longueurs différentes) sans jamais casser un widget, un menu ou un réglage Elementor.
Quand est-ce déclenché ?
Automatiquement en fin de migration : le CLI appelle le search-replace après l'import, avec l'ancien et le nouveau domaine déduits de votre config. Côté plugin, vous saisissez simplement les deux domaines dans le formulaire d'import.
Prêt à essayer ? Téléchargez le CLI ou le plugin WordPress.