Skip to Content
WordPressPartie 2 — Utiliser & administrerImport, export & migration de contenu

Chapitre 2.6 — Import, export & migration de contenu

⏱️ TL;DR — Un site WordPress = des fichiers (wp-content : thèmes, plugins, uploads) + une base de données (contenus, réglages, users). Exporter/importer du contenu (outil natif WXR) ne déplace que le contenu ; migrer un site entier (changer d’hébergeur/domaine) exige de copier fichiers + base et de remplacer les URLs en base. Savoir migrer proprement est une compétence de service directement facturable (Partie 13) — et une source classique de bugs si on la bâcle.

🎯 Objectifs

  • Distinguer export de contenu et migration de site complète.
  • Utiliser l’outil d’import/export natif (WXR).
  • Comprendre les deux « moitiés » d’un site : fichiers + base de données.
  • Connaître le piège n°1 de migration : le remplacement d’URL (et pourquoi sed naïf casse tout).

1. Deux opérations très différentes

  • Export/Import de contenu (WXR) : Outils → Exporter génère un fichier XML (WXR) contenant articles, pages, médias (références), catégories, commentaires. Outils → Importer le réinjecte ailleurs. Ne transporte pas les réglages, les plugins, le thème, ni la config. Idéal pour déplacer du contenu entre deux sites.
  • Migration complète : déplacer tout le site (changer d’hébergeur ou de domaine). Il faut copier les fichiers ET la base, puis corriger les URLs.

2. L’outil natif d’export/import (WXR)

  • Outils → Exporter : tout le contenu, ou seulement articles/pages/un type. Produit un .xml (WXR = WordPress eXtended RSS).
  • Outils → Importer → WordPress : installe l’importateur, téléverse le WXR. Option pour importer les médias (télécharge les fichiers liés) et réassigner les auteurs.

⚠️ Piège — L’import WXR échoue souvent sur les gros fichiers (limites upload_max_filesize / max_execution_time de PHP). Pour un gros site, préférez WP-CLI (wp import, Partie 4) ou une migration base+fichiers. Et pensez à vérifier que les médias ont bien été rapatriés (sinon les images pointent vers l’ancien domaine).

3. Les deux moitiés d’un site

MoitiéContientOù
FichiersWordPress lui-même, wp-content (thèmes, plugins, uploads), wp-config.php.Le système de fichiers de l’hébergeur (FTP/SSH).
Base de donnéesContenus, réglages, utilisateurs, métadonnées, options.Un serveur MySQL/MariaDB.

Migrer un site = déplacer les deux. Oublier l’un donne un site cassé (thème présent mais base vide, ou base présente sans les uploads → images manquantes).

💡 Pour un dev React — Contrairement à une app Next.js souvent stateless (le contenu vit dans une BDD/CMS distant, le déploiement ne bouge que le code), un WordPress classique mélange code et données dans le même hébergement. C’est pourquoi la migration est plus lourde : on déplace un état applicatif complet, pas juste un build. En headless, on retrouve la séparation qui vous est familière (WP = données, Next = front déployé à part).

4. Le piège n°1 : remplacer les URLs

Quand vous changez de domaine (ancien.com → nouveau.com) ou d’environnement (localhost → prod), l’ancienne URL est écrite partout dans la base (contenu, réglages, liens, options). Il faut la remplacer.

Mais on ne fait PAS un simple chercher-remplacer SQL brut, car WordPress stocke certaines données en PHP sérialisé (des chaînes préfixées de leur longueur, ex. s:19:"http://ancien.com/"). Un remplacement naïf change le texte sans mettre à jour la longueur → données corrompues.

La bonne méthode : un outil conscient de la sérialisation :

  • WP-CLI (Partie 4) : wp search-replace 'https://ancien.com' 'https://nouveau.com' --all-tables (gère la sérialisation, --dry-run pour tester).
  • Des plugins de migration (Duplicator, All-in-One WP Migration, WP Migrate) qui automatisent fichiers + base + URLs.
  • L’outil Search-Replace-DB (script) pour un remplacement sûr.

⚠️ Piège — le sed sur le dump SQL. Faire sed 's/ancien.com/nouveau.com/g' sur l’export SQL casse toutes les données sérialisées (widgets, options de thème/plugins). Utilisez toujours un outil qui gère la sérialisation (wp search-replace).

5. Une migration propre, en résumé

  1. Sauvegarder l’ancien (fichiers + base) — jamais de migration sans filet.
  2. Copier wp-content (surtout uploads) vers le nouveau serveur.
  3. Exporter/importer la base MySQL.
  4. Adapter wp-config.php (identifiants de la nouvelle base).
  5. wp search-replace l’ancienne URL → la nouvelle (avec --dry-run d’abord).
  6. Régénérer les permaliens (Réglages → Permaliens → Enregistrer).
  7. Vérifier : pages, images, liens, formulaires, HTTPS, e-mails.

Un plugin de migration fait souvent 2→6 automatiquement — pratique pour un site standard.

✏️ Exercices

  1. Un client veut juste récupérer les articles d’un ancien blog vers un nouveau site (thème et plugins différents). Export complet ou WXR ?
  2. Pourquoi un sed sur le dump SQL pour changer le domaine est-il dangereux ?
  3. Donnez l’ordre des étapes clés d’une migration de domaine complète.

✅ Solution

  1. Export/Import WXR (Outils → Exporter puis Importer) : il ne transporte que le contenu (articles, médias), ce qui est exactement le besoin, sans imposer l’ancien thème/plugins.
  2. Parce que WordPress stocke des données en PHP sérialisé (avec la longueur des chaînes) ; changer le texte sans ajuster la longueur corrompt ces données (widgets, options). Il faut wp search-replace, conscient de la sérialisation.
  3. Sauvegarde → copier les fichiers (wp-content) → importer la base → adapter wp-config.php → wp search-replace des URLs → régénérer les permaliens → vérifier le site.

🧠 Quiz de révision

1. Que contient un export WXR ?

Le contenu (articles, pages, médias référencés, catégories, commentaires) — pas les réglages, plugins, thème ni config.

2. De quoi se compose un site WordPress à migrer ?

Des fichiers (wp-content : thèmes, plugins, uploads + config) et une base de données MySQL.

3. Quel outil remplace les URLs en base sans casser la sérialisation ?

wp search-replace (WP-CLI), ou un plugin de migration ; jamais un sed brut.

4. Pourquoi la sérialisation PHP complique-t-elle le chercher-remplacer ?

Les chaînes sérialisées incluent leur longueur ; changer le texte sans ajuster la longueur corrompt la donnée.

5. Quelle étape ne jamais sauter avant une migration ?

La sauvegarde complète (fichiers + base) de l’ancien site.

Chapitre suivant : Maintenance, sauvegardes & mises à jour.

Commentaires & modérationMaintenance, sauvegardes & mises à jour