WordPress Search and Replace

WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…

WordPress stocke les URL absolues dans des dizaines de tables de base de données, donc un changement de domaine ou un passage en SSL laisse les anciennes adresses dispersées dans les articles, les options et les paramètres des plugins : une recherche et remplacement est la façon sûre de les nettoyer. Ce guide couvre les deux méthodes prises en charge dans KPanel, explique pourquoi une troisième méthode courante corrompt les données, et comment vérifier le résultat.

Quand vous en avez besoin

Migration de http:// vers https:// après l'activation SSL.
Changement de domaine, par exemple old-brand.co.nz vers new-brand.co.nz.
Après avoir poussé la préproduction vers la production, quand le nom d'hôte de préproduction est toujours ancré dans la base de données.
Retrait d'un ancien serveur d'assets et redirection de chaque URL d'image en une seule opération.
Correction d'une faute de frappe en masse dans de nombreux articles, comme un ancien numéro de téléphone ou un nom de produit discontinué.

Une recherche et remplacement réécrit des lignes dans toutes les tables à la fois et il n'y a pas d'annulation par ligne. Faites une sauvegarde avant de commencer, à chaque fois, même pour une modification qui semble anodine. KPanel en crée une automatiquement quand vous utilisez les outils intégrés décrits ci-dessous, mais si vous exécutez la commande vous-même, vous en êtes responsable. Voir Faire une sauvegarde.

Pourquoi vous ne pouvez pas simplement exécuter un REPLACE SQL

C'est l'erreur la plus dommageable dans le travail avec une base de données WordPress, donc cela vaut la peine de le comprendre avant de choisir une méthode.

WordPress stocke les paramètres des plugins, les options de thème et les données des widgets comme des chaînes PHP sérialisées. Une chaîne sérialisée enregistre la longueur de chaque valeur qu'elle contient, comme ceci :

a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}

Ce s:26 indique que l'URL fait 26 caractères de long. Remplacez http:// par https:// en utilisant un REPLACE() SQL simple et le texte devient 27 caractères tandis que la longueur stockée prétend toujours être 26. PHP refuse alors de désérialiser l'ensemble de l'option, et le paramètre revient silencieusement à vide. Les paramètres du customiseur de thème disparaissent, les sliders perdent leurs diapositives, les licences des plugins se désenregistrent.

La recherche-remplacement WP-CLI que KPanel exécute désérialise chaque valeur, effectue le remplacement à l'intérieur, et ressérialise avec les longueurs corrigées. C'est pourquoi c'est la seule méthode documentée ici.

N'exécutez jamais UPDATE wp_options SET option_value = REPLACE(...) ou l'équivalent dans phpMyAdmin sur une base de données WordPress. Cela semble avoir fonctionné, cela rapporte des lignes affectées, et cela détruit silencieusement chaque paramètre sérialisé qu'il a touché. Il n'y a pas de réparation en dehors de la restauration d'une sauvegarde.

Méthode 1 : La Carte Recherche et Remplacement

C'est le bon choix pour presque tout le monde. Elle est disponible sur tous les plans WordPress.

Connectez-vous à KPanel et cliquez sur Websites dans la barre latérale gauche.
Cliquez sur le site.
Ouvrez l'onglet WordPress, puis la section Quick Actions.
Trouvez la carte Search & Replace et cliquez sur Configure.
Entrez le texte existant dans Find (old value).
Entrez le nouveau texte dans Replace with.
Laissez Dry run (preview only, no changes) coché et cliquez sur Preview.

L'exécution d'essai rapporte combien de remplacements seraient effectués et ventile le compte par table et colonne, vous pouvez donc voir exactement où le changement atterrirait avant de vous y engager.

Quand l'aperçu semble correct :

Décochez Dry run.
Cliquez sur Run.
Confirmez la boîte de dialogue.

Une sauvegarde complète est créée automatiquement avant le début du remplacement, et l'exécution couvre toutes les tables, y compris celles créées par les plugins.

Recherchez la chaîne la plus spécifique possible. Remplacer old-domain.co.nz réécrit également mail.old-domain.co.nz et staging.old-domain.co.nz, ce qui est rarement ce que vous voulez. L'inclusion du schéma, comme dans https://old-domain.co.nz, maintient la correspondance serrée.

Méthode 2 : WP-CLI Depuis la Console

La console vous donne le même moteur avec plus de contrôle sur les drapeaux. C'est l'une des sections qui apparaissent sur les plans gérés ; sur les autres plans, la bande d'onglets montre plutôt un lien +8 on Managed.

Ouvrez le site, puis WordPress, puis Console. L'invite commence déjà par wp, tapez seulement le reste de la commande.

Aperçu d'abord :

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run

Ensuite, exécutez-le pour de vrai :

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables

La console ne crée pas de sauvegarde pour vous. La sauvegarde automatique avant l'exécution ne se produit que quand vous utilisez la carte Search & Replace de la Méthode 1. Si vous exécutez la commande ici, faites vous-même une sauvegarde d'abord à partir de l'onglet Backups du site.

Drapeaux utiles :

Drapeau	Ce qu'il fait
`--all-tables`	Inclut les tables personnalisées créées par les plugins, pas seulement les tables WordPress principales
`--dry-run`	Rapporte ce qui changerait et n'écrit rien
`--precise`	Utilise PHP plutôt que SQL pour le remplacement. Plus lent, mais gère les structures sérialisées complexes
`--skip-columns=guid`	Laisse les GUID des articles inchangés (voir ci-dessous)
`--report-changed-only`	Réduit le résultat aux tables qui ont réellement changé

Une Remarque sur les GUID

Chaque article WordPress a une colonne guid. Bien qu'elle ressemble à une URL, c'est un identifiant, pas un lien, et les lecteurs de flux l'utilisent pour déterminer s'ils ont déjà vu un élément. Le réécrire peut faire réapparaître chaque article de votre flux comme nouveau.

Réécrivez les GUID quand vous changez de domaine définitivement et que vous repartez de zéro. Ignorez-les avec --skip-columns=guid quand vous ne faites que passer de HTTP à HTTPS sur le même domaine.

Changement de Domaine : Utilisez la Carte Change Site URL à la Place

Si le but entier est de déplacer le site vers un nouveau domaine, ne commencez pas par une recherche et remplacement. La carte Change Site URL, dans la même section Quick Actions, met à jour les options siteurl et home et exécute le remplacement dans toutes les tables en une seule opération, dans le bon ordre. Faire l'inverse peut laisser WordPress incapable de charger son propre admin.

Après le Remplacement

Parcourez cette liste avant de considérer que c'est fait.

Videz le cache. Dans la section Quick Actions, exécutez Flush Cache. Si le site utilise le cache de la page complète, purgez-le depuis WordPress, puis Caching.
Videz les règles de réécriture. Exécutez Flush Rewrites dans la même section, ou ouvrez Settings, puis Permalinks dans wp-admin et cliquez sur Save Changes sans rien changer.
Purgez le CDN si le site est dessus, depuis Performance, puis Kapsule CDN. Voir Purger le Cache du CDN.
Chargez le site dans une fenêtre privée afin que votre cache de navigateur ne puisse pas vous induire en erreur.
Vérifiez le cadenas. Un cadenas manquant ou d'avertissement après un passage en SSL signifie que des URL ont été laissées derrière : Corriger les Avertissements de Contenu Mixte.
Cliquez sur les pages délicates. Sliders de la page d'accueil, logo d'en-tête, toute page construite avec un générateur de pages, et la caisse d'une boutique. Celles-ci contiennent les URL qui vivent dans les options sérialisées.
Effacez tout plugin de cache depuis son écran de paramètres propre.

Dépannage

L'exécution d'essai rapporte zéro remplacement. La chaîne n'est pas dans la base de données sous cette forme exacte. Vérifiez la présence d'une barre oblique finale, d'un préfixe www., ou du schéma. Essayez de chercher d'abord juste le nom d'hôte nu pour confirmer qu'il s'y trouve.

Les images sont cassées après un changement de domaine. Les URL des médias vivent dans wp_posts et wp_postmeta et sont détectées par --all-tables, mais un CDN ou un plugin d'optimisation d'images peut mettre en cache ses propres copies réécrites. Purgez le CDN et le cache du plugin, puis rechargez.

Les paramètres ont disparu après le remplacement. C'est le problème de sérialisation, et cela signifie que le changement a été effectué avec du SQL brut plutôt que via les outils ici. Restaurez la sauvegarde créée avant l'exécution : Restaurer à Partir d'une Sauvegarde.

Les URL de préproduction continuent de réapparaître. Quelque chose les repeuple, généralement une poussée programmée ou une option mise en cache. Vérifiez le flux de travail dans Utiliser la Préproduction : Pousser et Tirer et assurez-vous que Rewrite URLs est coché quand vous poussez.

Exécuter une recherche et remplacement dans votre base de données WordPress