Diagnostiquer une migration WordPress : SQL, médias et URL

Votre site WordPress s’ouvre sur localhost, mais une image conserve une adresse inaccessible depuis un autre ordinateur. Avant de le déplacer, distinguez trois éléments : la base de données, les fichiers et les URL qui indiquent où se trouve le contenu. Copier le SQL ne copie pas les médias ; transférer les fichiers ne reconstruit pas à lui seul les lignes du CMS.

Ce diagnostic utilise un exemple original sous licence MIT qui teste deux installations synthétiques de WordPress core dans un environnement jetable. Il vérifie SQL, PNG généré, URL sérialisées et restauration. Ce n’est ni une procédure du panneau Sites ni une migration réalisée pour un client.

Inventorier les fichiers et les données

Relevez la base, wp-content/uploads, les thèmes, plugins et paramètres avant de modifier la destination. La documentation officielle française de migration aide à distinguer ces éléments. L’exemple ne teste que core et des médias fictifs, pas vos thèmes, blocs, plugins ou boutique.

Déterminer si l’URL change vraiment

Déplacer une installation n’exige pas toujours un remplacement d’URL. Si l’URL publique reste exactement identique, n’ajoutez pas ce changement uniquement parce que le serveur change. Si le protocole, le nom d’hôte, le port ou le préfixe de chemin change, identifiez les références concernées et testez sur une copie.

La ressource remplace http://source.invalid:8080 par http://destination.invalid:8081. Ce sont des adresses fictives dans un même Pod, pas des domaines publics. WP-CLI search-replace utilise --dry-run avant l’application et --skip-columns=guid : les GUID sont conservés. N’adoptez pas une substitution SQL générale et ne réécrivez pas les GUID pour réparer les images.

La documentation officielle de search-replace décrit le traitement des données sérialisées. Remplacer du texte sans respecter cette structure peut invalider des données. L’exemple vérifie une option imbriquée avec URL et Unicode, ainsi que le lien du contenu, après remplacement.

Résultats de l’essai terminé

La preuve historique comporte onze contrôles et provient de treize essais conservés ; cela ne signifie pas treize réussites. L’exécution finale a réussi avec WordPress 7.1.3, PHP 8.3.35 et WP-CLI 2.12.0, dans des images fixées par digest. Le README et REHEARSAL-EVIDENCE.json distinguent le code exécuté des mises à jour documentaires ultérieures.

La destination possède sa base et son utilisateur. SQL et uploads sont exportés, leurs empreintes vérifiées puis tous deux restaurés. Le dry-run conserve les valeurs initiales ; après application, IDs, types, slugs, GUID et une projection logique définie sont comparés, ainsi que l’option sérialisée et l’empreinte du PNG. Cela ne certifie pas toutes les données possibles de toute installation WordPress.

Les contrôles négatifs rejettent SQL invalide, média absent, URL non remplacée et fichier corrompu. L’importateur détecte aussi les erreurs SQL lorsque WP-CLI annonce une réussite ; ce message ne remplace pas la vérification des données. Après réparation du média, HTTP vérifie article, page, PNG, 404, accès administrateur et déconnexion. Aucun rendu Chrome ni écran mobile n’a été testé.

Le retour arrière restaure SQL et uploads d’origine dans la destination fictive et supprime un fichier de test supplémentaire. Il vérifie aussi que la source reste inchangée. Ce n’est ni un rollback DNS, ni une récupération universelle, ni une garantie de perte nulle.

Lire le harness avant de l’exécuter

Cette ressource est avancée : l’essai WordPress nécessite Kubernetes. Vous pouvez examiner le code et lancer les contrôles de préparation depuis la révision fixée :

git clone https://github.com/ocentelles/hostbrid-example-wordpress-migration.git
cd hostbrid-example-wordpress-migration
git checkout 17d66e5808498adc62a4cf8061cf8c49d4648792
python3 test-preparation.py
/bin/sh -n rehearse.sh

Les quatre tests Python vérifient le contrat de préparation et rejettent des changements de réseau, volume ou token. Le contrôle shell ne vérifie que la syntaxe. Aucun n’exécute WordPress ou ne garantit une migration réussie. prepare.py génère des manifestes, sans appliquer automatiquement de ressources. L’exécution demande un namespace adapté et des ressources nouvelles qui vous appartiennent, des images compatibles et une revue de l’environnement.

L’essai utilise uniquement loopback et configure une NetworkPolicy de refus, mais l’application effective par le CNI n’a pas été mesurée. Ne réutilisez pas ce harness sur une base réelle et ne traitez pas son exception TLS locale comme une procédure pour une base distante.

Avant d’envisager Sites

Confirmez PHP, l’accès à la base et aux fichiers, la capacité disponible et le périmètre précis de migration avant de souscrire ou de créer un site. Ce diagnostic ne démontre pas une restauration du panneau, le TLS distant, DNS ou HTTPS publics, courrier, WooCommerce, multisite ou continuité des écritures. Gardez une copie récupérable et vérifiez votre installation séparément ; changer d’hébergement ne transforme pas le résultat fictif en livraison éprouvée.