WordPress est un super outil. Il nous permet d’ajouter plein de fonctionnalités à nos sites avec juste quelques clics. Du coup, on peut vite être tenté de rajouter plusieurs extensions comme ça, juste pour tester. Le souci est que par conséquent, la taille totale des fichiers du site peut vite gonfler et sa base de données peut vite être remplie d’entrées non-désirées ou dont on a plus besoin, et cela peut devenir compliqué de faire le ménage.

Donc, pour tester quelque chose, c’est toujours mieux de le faire en local, c’est à dire sur une instance d’un site WordPress disponible sur votre ordinateur.

Installer WordPress en local n’est vraiment pas compliqué avec Local By Flywheel, mais vous pouvez aussi utiliser Mamp, ou tout autre outil.

Aussi, pour ceux qui développent et on besoin de taper dans le code, je pense qu’il n’y a pas vraiment besoin de rappeler qu’il faut commencer par développer le site en local, puis le migrer en pré-production, puis en production après tests.

Mais, je préfère le rappeler quand même ! Car il y a des guerriers parmi les développeurs, qui modifient les fichiers direct via FTP ! On télécharge, on modifie, on réuploade directement en production et on teste sur le site en production ! Même pas peur !

Bref, ce n’est vraiment pas idéal de travailler directement en production et vous aurez donc un jour ou l’autre besoin d’un site local.

Mais comment dupliquer votre site en local simplement ? Inversement, une fois votre site développé en local, comment le remettre en production ?

Dans cet article, je vais vous montrer comment utiliser WPMigrateDB pour migrer votre base de données et dupliquer rapidement votre site WordPress, que ce soit de la production vers le local, ou inversement.

En quoi consiste une migration ?

WordPress a besoin de deux choses pour fonctionner : des fichiers et une base de données. L’idée est donc de migrer les deux séparément.

Attention, il est parfaitement possible de tout migrer d’un coup à l’aide d’une extension comme Duplicator, mais ce n’est pas l’objectif de cet article. J’aimerais simplement vous montrer comment on fait ça « à la main ».

Aussi, ces extensions de duplications ont parfois des pré-requis serveur ou des réglages pas forcément simples à comprendre, et en plus elles laissent souvent des traces derrière elles, que ce soit des fichiers ou des entrées dans la base de données.

On va donc faire ça manuellement, comme les artisans du web que nous sommes.

Récupérer vos fichiers

D’abord, il faut récupérer les fichiers de votre site. Vous avez plein de solutions pour ça, et voici les plus simples :

  • Soit vous utilisez un client FTP comme Filezilla et vous téléchargez manuellement vos fichiers (c’est un peu long).
  • Soit vous faites une sauvegarde complète de votre site via votre extension de sauvegardes (vous en avez une, non ?), et téléchargez la sauvegarde.

C’était facile. Vous avez tous les fichiers de WordPress, et vos fichiers (le dossier wp-content/) dans un beau petit dossier.

Créer un site local

Je travaille avec Local By Flywheel pour mes sites locaux. Je vais donc créer un site tout neuf dans le logiciel. Il suffit de cliquer sur l’icône + en bas à gauche, et de l’appeler comme vous voulez. Le mien sera « Example ».

Voilà, un site tout beau tout neuf

Migrer votre base de données

Sur votre site en production (celui que vous souhaitez rapatrier), installez WP Migrate DB. Je ne vais pas vous expliquer comment installer et activer une extension, cela devrait aller.

Rendez-vous sur la page de réglages de l’extension, dans Outils > Migrate DB.

Les réglages de MigrateDB
Les réglages de MigrateDB

Ce qui est fort avec WPMigrateDB, c’est qu’il permet d’exporter une base de données, tout en remplaçant les URLs et chemins vers les fichiers dans toutes vos tables !

On peut aussi faire directement le remplacement dans la base données utilisée sur le site, mais c’est un peu dangereux (un tout petit peu) donc on va éviter.

On va donc exporter notre base, en changeant toutes les urls de notre site en production vers notre site local, ainsi que tous les chemins vers nos fichiers. Il suffit de remplir les champs Replace.

Pour ne pas se tromper, on va utiliser une astuce : installez et activez WPMigrateDB sur votre site local (le site tout frais, tout neuf), puis naviguez vers la page de réglage de l’extension.

Réglages de MigrateDB sur le site local
Les voilà vos valeurs locales !

Il vous suffit de les copier-coller dans les champs Replace sur la page WPMigrateDB de votre site en production. Puis dans les Advanced Options, il est recommandé de laisser cochée l’option Replace GUID. Aussi vous pouvez choisir de ne pas exporter les spams, les transients ou les révisions, ou encore d’activer le mode compatibilité pour les versions de SQL inférieures à 5.5.

La version PRO permet de migrer également vos fichiers médias, thèmes et extensions, mais ça, c’est déjà fait dans notre cas. Vous pouvez aussi sauvegarder votre profil de migration si vous voulez gagner du temps pour plus tard. Cela sauvegarde vos réglages comme un template réutilisable, simplement.

Cliquez sur le bouton Export, et c’est parti. Votre base de données est exportée, et toutes vos URLs et chemins de fichier remplacés pour refléter les valeurs de votre site local.

Note : Pour les multisites, il faudra ajouter des lignes à remplacer correspondants aux domaines des sites additionnels du multisite ! Par exemple si votre multisite a un site à sous-site.example.com, il faudra ajouter une ligne pour remplacer cette URL par sous-site.example.local par exemple.

Préparer le site local

Maintenant, il faut placer les fichiers de votre site distant dans votre site local.

J’utilise la même version de WordPress en local que sur le site distant, donc je n’ai pas besoin d’écraser les fichiers de WordPress de mon site local. Cela m’évite aussi de toucher au fichier wp-config.php ou .htaccess local qui est déjà configuré par Local By Flywheel.

Je me contente donc de remplacer mon dossier local wp-content/ par celui du site distant. Du coup, quand je vais dans l’administration de mon site local, j’ai toutes les mêmes extensions et thèmes disponibles, ainsi que mes images dans mon dossier.

Liste des extensions
Mes extensions sont bien présentes

Importer la base de donnée

Tous mes fichiers sont prêts. Il ne me reste plus qu’à importer ma base de donnée. Pour ça, je vais utiliser l’outil intégré à Local By Flywheel : Adminer. Si vous utilisez MAMP, vous allez devoir utiliser PHPMyAdmin, mais le principe est le même.

L’idée est simplement d’importer notre base de données distante (avec nos URLs et chemins modifiés) sur notre base de données locale. C’est tout.

Dans Local By Flywheel, naviguez vers l’onglet Databases, Et cliquez sur Open Adminer. Vous devriez arriver sur un onglet web comme ceci :

Tableau de bord d'Adminer
Tableau de bord d’Adminer

Maintenant, il reste à importer votre base de données. Cliquez sur Importer à gauche, sélectionnez le fichier .sql précédemment exporté, et go.

Ça marche ! Ou pas …

Maintenant, retournez sur votre site local et rafraîchissez la page. Si tout s’est bien passé, vous devriez être invité à vous reconnecter avec votre mot de passe du site distant (et oui, le site n’a plus les mêmes utilisateurs !), et vous devriez avoir une copie du conforme du site.

Si votre site n’a pas bougé et que vous êtes toujours sur un site tout frais et vide, c’est probablement parce que les tables de la base de données importées ont un préfixe différent ! Du coup, WordPress cherche dans les mauvaises tables ! Vous devriez pouvoir voir dans Adminer si des tables avec un préfixe différent sont présentes parmi les tables par défaut (ayant pour préfixe wp_).

Il va donc falloir éditer votre fichier wp-config.php pour modifier le préfixe des tables, et ainsi indiquer à WordPress dans quelles tables chercher. Aussi, si votre fichier de configuration du site distant contient des réglages funky, il faudra probablement les ajouter au fichier wp-config.php local. Idem pour des règles .htaccess personnalisées qui seraient en production. Là, je ne peux pas trop vous conseiller, car chaque configuration est différente.

Dans mon cas, un simple changement de préfixe de table a suffit pour que tout fonctionne correctement.

Copie du site local
Mon site local fonctionne correctement

Il faut juste penser à faire le ménage : si vous avez importé des tables avec un autre préfixe, pensez à supprimer les tables non-utilisées.

Troubleshooting

Mon site est relativement simple. Je n’ai pas de configuration particulière côté serveur et rien d’extra ordinaire dans mon wp-config.php ou .htaccess. Ce process est donc ultra simple et rapide pour moi. Et normalement, il devrait l’être pour vous !

Mais dans certains cas, cela peut être plus compliqué et tout peut ne pas tourner comme sur des roulettes :

  • Vous avez peut-être une vieille version de PHP en production. Il faudra donc utiliser la bonne sur votre site local.
  • Vous avez peut-être aussi une vieille version de MySQL en production. Même souci.
  • Si vous utilisez des directives spéciales dans wp-config.php ou votre fichier .htaccess, il faudra probablement en recopier certaines (ou les modifier) dans les fichiers locaux du même nom.
  • Les domaines locaux ne sont peut-être pas mappés ! Vous aurez peut-être besoin de modifier votre fichier hosts pour cela. Local By Flywheel le fait automatiquement, donc c’est cool.

De local vers production

Si vous avez développé votre site en local et que vous n’avez pas encore de site en production, c’est facile. Créez un site distant et répétez la procédure.

Si vous avez déjà un site distant, il faudra être beaucoup plus prudent. Par exemple, si votre site est un e-commerce, vous avez surement eu des commandes entre le moment où vous dupliquez votre site en local pour vos tests et le moment ou vous êtes prêt à migrer vos nouveaux développements. Du coup, ce n’est pas une bonne idée de migrer votre base de données, car vous allez détruire vos nouvelles commandes !

Le plus simple est de migrer les fichiers que vous avez besoin de migrer, mais de faire tout ce qui touche à la base de données « à la main ». Par exemple, si vous avez installé une nouvelle extension, migrez les fichiers de votre extension, activez-la puis repassez sur les pages de réglages en copiant vos réglages locaux manuellement. Si vous aviez créé des produits, recréez-les manuellement, etc…

C’est plus pénible, mais c’est bien plus sûr.

Conclusion

J’espère que cet article vous a été utile et que vous avez bien saisi comment migrer un site WordPress manuellement avec WPMigrateDB.

Au final c’est assez simple :

  • On crée un site local
  • On télécharge nos fichiers distants et on écrase notre dossier wp-content/ local par celui du site en production
  • On exporte notre base de données avec WPMigrateDB, en changeant les URLs et le chemin vers les fichiers (pour ne pas se tromper, on peut voir la page de réglage de WPMigrateDB sur le site local aussi)
  • On importe notre base de donnée modifiée sur notre site local.
  • On vérifie que tout est ok au niveau du wp-config.php et .htaccess

Testez et dites-moi si ça marche pour vous !

2 commentaires sur “Comment migrer un site WordPress avec WPMigrateDB

  • rutler

    Bonjour, merci pour ce auto, il y a une étape que je n’arrive pas à faire, c’est quand il faut copier coller les dossiers du site en ligne vers le site en local.
    je ne vois pas où il faut le mettre ?

    mercii beaucoup pour votre aide
    Nolwenn

    • Vincent

      Bonjour,
      Créez un site local, puis écrasez ses fichiers avec ceux du site distant, simplement.
      Vous pouvez directement ouvrir le dossier du site local dans Local by Flywheel en cliquant sous son titre.
      Si vous utilisez MAMP, c’est par défaut dans MAMP/htdocs il me semble.

Les commentaires sont fermés.

neque. mattis venenatis, velit, sed sem, ipsum id,