Données sérialisées WordPress cassées après un remplacement SQL

Repérez ce qui a changé dans la migration

Les articles s’ouvrent sur le nouveau domaine, mais le pied de page revient à sa valeur par défaut, des widgets disparaissent ou une extension perd sa configuration. Si cela commence juste après un remplacement de texte dans le fichier SQL, cherchez une valeur devenue illisible avant de refaire les réglages. Plusieurs fonctions peuvent lire la même option. Les reconstruire à la main risque de masquer la cause et d’effacer les dernières valeurs encore exploitables.

Relevez la dernière version qui fonctionnait, les deux chaînes remplacées, les tables touchées et l’heure de l’import. Cherchez dans la fiche de migration si le changement a été fait dans un éditeur de texte, par une commande SQL ou par un outil WordPress. Notez un exemple reproductible, comme le lien absent d’un bloc réutilisé sur deux pages. Une capture ancienne et l’adresse d’une page témoin sont plus faciles à comparer qu’une impression générale de présentation différente.

Un lien qui pointe encore vers l’ancien domaine peut simplement avoir été oublié. Un ensemble de réglages qui revient à ses valeurs par défaut après une manipulation de la base mérite une vérification différente. Si le serveur affiche une erreur de connexion à la base sur toutes les pages, commencez par rétablir cet accès. Ce guide suppose que WordPress peut déjà lire sa base et qu’une valeur identifiable est suspecte.

Protégez la base avant de comparer deux états

Exportez la base actuelle avant un nouvel essai et récupérez la copie qui a précédé le remplacement. Étiquetez chaque fichier avec le domaine, l’heure et le fuseau. Si l’hébergeur propose une sauvegarde avec les fichiers du site et la base au même point de restauration, notez ces deux composants. Conservez les exports dans un dossier privé. Ils peuvent contenir des courriels, des jetons ou des données de commande.

Créez une copie distincte avec sa propre base, son adresse et un compte de test. Vérifiez sa connexion à la base dans le panneau d’hébergement et ouvrez son administration avant d’y importer un fichier. Un site de préproduction qui pointe vers la même base que le site public expose les mêmes données. Faites désactiver sur la copie les courriels et tâches qui contactent des services réels, ou utilisez les modes de test prévus.

Gardez une trace de ce que la production a reçu depuis la migration. Une boutique peut avoir de nouvelles commandes, une association de nouvelles adhésions et un site éditorial de nouveaux brouillons. Ce relevé détermine si la correction validée pourra être appliquée à une option, à un groupe de données ou à une nouvelle migration préparée par le mainteneur. Même si l’ancienne base répare le symptôme sur la copie, son âge et sa couverture restent à comparer avant toute restauration réelle.

Lisez une valeur sérialisée sans toucher à la base

WordPress enregistre certains tableaux ou objets PHP sous une forme qui conserve leur structure dans une chaîne. Dans un fragment comme s:5:"salut";, le nombre décrit la longueur en octets de la chaîne qui suit. Si la valeur devient bonjour mais que le nombre reste à cinq, PHP rencontre une longueur incohérente. Une adresse peut poser ce problème dès qu’un domaine, un chemin ou le protocole change de longueur. Une lettre accentuée peut aussi occuper plusieurs octets en UTF-8.

L’exemple ci-dessous tourne dans un fichier PHP local créé pour l’essai. Il utilise un tableau fictif en mémoire et ne se connecte à aucun WordPress. Avec PHP en ligne de commande, enregistrez-le sous essai-serialisation.php puis lancez php essai-serialisation.php. La dernière ligne doit indiquer que l’ancienne longueur est encore présente après le remplacement de texte.

Ce mécanisme explique pourquoi la recherche de l’ancienne adresse peut renvoyer zéro résultat alors que des options ne se chargent plus. La chaîne recherchée a bien été remplacée, mais WordPress peut ne plus pouvoir la relire. Une correction doit remettre une structure lisible et conserver les autres valeurs du tableau. Évitez de recalculer des nombres à la main sur un export entier, surtout s’il contient des tableaux imbriqués ou des valeurs dont le format appartient à une extension.

<?php
$avant = 'https://ancien.exemple.test/document';
$apres = 'https://nouveau-site.exemple.test/document';
$stocke = serialize(['lien' => $avant, 'libelle' => 'Été']);
$texte = str_replace($avant, $apres, $stocke);
echo 'Ancienne longueur : ', strlen($avant), PHP_EOL;
echo 'Nouvelle longueur : ', strlen($apres), PHP_EOL;
echo str_contains($texte, 's:' . strlen($avant) . ':"' . $apres . '"')
    ? "L’ancienne longueur est encore présente.\n"
    : "Vérifiez la chaîne produite.\n";

Confirmez la piste avec une option et un rendu témoin

Commencez par le réglage qui explique le symptôme. Pour un thème, vérifiez que le même thème est actif sur les deux copies et que le modèle attendu est utilisé. Pour une extension, comparez sa version et vérifiez qu’elle est active. Une version différente ou une activation oubliée peut changer les valeurs lues au démarrage, même avec une base intacte. Relisez aussi les journaux à l’heure du test, dans leur espace privé.

Identifiez le nom de l’option par le mainteneur ou la documentation de l’outil concerné. Sur chaque copie, lisez la valeur par WordPress ou avec le mécanisme d’export du composant. Comparez d’abord le type attendu, comme un tableau, puis les clés dont dépend la page. Un retour vide ou false peut aussi signaler une option absente. Pour conclure à une corruption, confirmez que l’entrée existe, que la copie antérieure est lisible et que la version modifiée est devenue incohérente à l’endroit du remplacement.

La recette locale a enregistré un tableau de trois champs dans une option WordPress. Après un remplacement brut en mémoire, la même option simulée n’était plus désérialisable. Une simulation WP-CLI a ensuite trouvé une modification sans toucher à l’option. Après le remplacement par WP-CLI sur la copie, WordPress a relu le tableau, dont le libellé accentué et le booléen, et le lien a pris la nouvelle adresse. Cette preuve porte sur une option témoin et la longueur de sa chaîne, dans un WordPress 7.1.4 sur copie SQLite.

Si la valeur est lisible dans les deux copies, comparez l’adresse obtenue à celle demandée par le navigateur. Une redirection ou une réponse mise en cache peut produire un ancien lien alors que le réglage est correct. Dans ce cas, demandez quel modèle ou composant génère le lien et rechargez une seule page témoin. Pour une adresse d’accueil inattendue, vérifiez aussi les valeurs définies dans la configuration WordPress ou par l’hébergement. Cette comparaison vous évite de transformer la base alors que la cause se trouve dans une autre couche.

Approche 1 — Repartir de la base cohérente d’avant migration

Choisissez ce parcours si plusieurs réglages ont disparu et si la sauvegarde d’avant le remplacement est disponible. Restaurez la copie de départ avec les versions de fichiers qu’elle utilisait au même moment. Vérifiez que les pages et composants témoins fonctionnent avant d’effectuer le changement d’adresse. Si le rendu est déjà mauvais, cherchez d’abord une sauvegarde cohérente ou une différence de version.

Sur un site simple sans nouvelles écritures, repartir d’une base propre puis refaire la migration peut suffire. Si les commandes ou contenus récents doivent être conservés, l’état validé sur la copie sert de référence pour une réparation ciblée ou une reprise avec réconciliation. Décidez après avoir identifié quelles données doivent suivre chaque option.

1. Notez les chaînes exactes à transformer, de préférence des URL complètes. Listez les variantes réellement présentes, comme les anciennes URL HTTP et HTTPS ou un chemin de sous-dossier. Préparez un essai par variante lorsque leur portée diffère.
2. Simulez le remplacement avec un outil qui sait relire et réécrire les données sérialisées. Sélectionnez les tables nécessaires et relisez le rapport. Un nombre de lignes très élevé ou une table inattendue justifie de réduire le périmètre avant tout changement.
3. Appliquez la transformation à la copie et relisez la valeur témoin via WordPress. Vérifiez aussi le rendu, les liens, l’administration et les actions utilisées par le site. Comparez au moins un réglage qui devait rester intact.
4. Pour la production, choisissez avec son mainteneur le point de reprise et la façon de conserver les données arrivées après ce point. Préparez une nouvelle sauvegarde et un test de retour avant toute bascule.

Vérifiez les remplacements avec WP-CLI

Lancez les commandes dans le dossier de la copie. Comparez la sortie de wp option get siteurl à l’adresse prévue pour cette copie et confirmez sa base dans le panneau d’hébergement. Repérez son préfixe avec wp db prefix. Le nom wp_options de l’exemple correspond au préfixe du banc. Utilisez le nom de la table de votre copie et les chaînes que vous avez validées. En multisite, identifiez d’abord le sous-site et ses tables avec le responsable réseau.

La simulation suivante cherche une URL dans la colonne des valeurs d’options. Elle laisse les identifiants de contenu de côté et demande à WP-CLI de traiter les valeurs en PHP. L’option --report-changed-only aide à lire le rapport. Sur un vrai site, les options peuvent aussi contenir des URL de connexion ou des paramètres de services. Si le périmètre voulu correspond à une seule option, préférez sa restauration via l’interface ou l’export de l’outil qui la possède.

Pour le banc, le rapport a trouvé un remplacement et l’option est restée à sa valeur d’origine. Lorsque le rapport correspond à la préparation et que la copie est prête, relancez sur cette copie en retirant seulement --dry-run. Lisez à nouveau le réglage et refaites le parcours témoin. Utilisez une simulation avant chaque autre variante. Un rapport indiquant zéro remplacement sur une base déjà altérée donne une raison de revenir à un état propre, car l’ancienne chaîne a pu disparaître avant ce contrôle.

wp search-replace 'https://ancien.exemple.test' 'https://nouveau-site.exemple.test' wp_options --include-columns=option_value --precise --report-changed-only --dry-run

Approche 2 — Récupérer un réglage isolé

Si une seule fonctionnalité est touchée et que le site a continué à recevoir des données, réinstallez une copie actuelle et une copie du dernier état cohérent. Comparez les réglages de la fonction entre les deux. Cherchez un export propre au thème ou à l’extension, ou recréez le réglage dans son interface sur la copie actuelle. Le composant enregistre alors ses valeurs dans le format qu’il utilise aujourd’hui.

Documentez le périmètre exact de l’import. Une option peut contenir à la fois un réglage visuel et des valeurs indépendantes. Comparez les autres champs avant d’importer une configuration complète ou de demander une restauration ciblée. Pour une fonctionnalité simple, la recréer dans l’interface avec les valeurs relevées peut être plus facile à vérifier. Pour un ensemble imbriqué ou une extension qui migre ses données, demandez au mainteneur sa procédure de transfert plutôt que de recopier la chaîne brute.

Gardez l’export de l’état courant et l’exemple de bon fonctionnement. Si la réparation validée est appliquée au site public, préparez un retour portant sur le seul réglage modifié, quand la fonction le permet. Contrôlez le rendu et une action courante après l’application, puis fermez les accès temporaires de la copie.

Approche 3 — Simuler depuis l’administration

Si vous avez l’administration de la copie et que le terminal est indisponible, Better Search Replace propose une simulation avec sélection de tables et prise en charge des données sérialisées. Installez-le seulement sur la copie autorisée, ou demandez à l’hébergeur s’il propose déjà une fonction de migration équivalente. Préparez la sauvegarde avant de lancer l’outil.

Cette approche valide un remplacement sur des valeurs encore lisibles. Elle ne constitue pas une réparation automatique d’une structure déjà cassée par une modification antérieure. Revenez à la sauvegarde cohérente ou reconstituez le réglage avant de corriger les adresses. La recette de ce guide a exécuté WP-CLI. Le parcours Better Search Replace s’appuie sur les fonctions documentées de l’extension.

1. Indiquez l’ancienne URL complète et la nouvelle. Confirmez leur protocole et leur chemin. Sélectionnez seulement les tables prévues pour le premier essai.
2. Gardez la simulation activée et laissez l’option de remplacement des GUID désactivée lorsqu’elle est proposée. Lisez le rapport de la simulation avant de décider si le périmètre correspond au problème.
3. Si le résultat est cohérent, appliquez sur la copie. Réouvrez l’écran du réglage et la page témoin. Si la copie manque de ressources ou interrompt l’opération, vérifiez ce qui a été écrit avant toute relance.

Validez l’état obtenu et sachez quand passer la main

Comparez l’écran de réglage, le rendu public en session anonyme et une action exécutée avec le rôle habituel. Pour un lien de téléchargement, ouvrez le bon document sur la copie avec un compte fictif. Pour un bloc de contact, utilisez le mode de test ou arrêtez-vous avant l’envoi réel. Vérifiez aussi un autre réglage de la même extension, puis revenez à la page qui présentait le symptôme après une nouvelle session.

Si aucune copie d’avant modification n’existe, conservez la base actuelle et cherchez les exports de configuration, captures ou historiques de l’hébergeur. Un réglage peut être reconstruit depuis ces éléments alors que la valeur brute ne peut plus être lue. Pour plusieurs structures touchées ou des données liées aux commandes, transmettez au mainteneur le nom des tables, les variantes d’URL, les versions du composant et les dates des états disponibles. Fournissez des exemples neutralisés et gardez les exports complets dans le canal privé convenu.

Notez enfin le périmètre réparé, les contrôles passés et la sauvegarde qui permet le retour. Conservez la commande ou la configuration de simulation avec le dossier de migration. Lors du prochain changement d’adresse, vous pourrez rejouer le contrôle sur une copie et comparer le nombre d’occurrences avant de toucher au site.