Importer une base de données dans Local depuis le shell

LocalWP, souvent appelé simplement Local, propose une interface pratique pour créer des sites WordPress en local. Pour les petites opérations, son accès à la base de données via Adminer suffit largement.

Mais dès qu’il faut importer une grosse base de données WordPress, l’interface graphique peut vite devenir pénible. Timeout, limite de taille, page qui mouline, import incomplet : le grand classique du “ça aurait dû prendre deux minutes”.

La solution la plus fiable consiste à passer par le shell intégré à Local. Vous pouvez importer le fichier SQL avec WP-CLI ou avec la commande MySQL classique. C’est plus rapide, plus robuste, et beaucoup moins capricieux qu’un import via navigateur.

Pourquoi importer la base depuis le shell ?

Adminer reste très utile pour consulter rapidement une table, lancer une petite requête ou importer un dump léger. Cependant, un gros fichier SQL peut dépasser les limites PHP ou le temps d’exécution autorisé.

Avec le shell, vous évitez ces limites côté navigateur. Le dump est envoyé directement au client MySQL ou à WP-CLI. Le processus devient plus stable, notamment pour les bases de plusieurs centaines de mégaoctets.

Autre avantage : vous pouvez enchaîner l’import, le remplacement d’URL, la vérification des tables et la régénération des permaliens sans quitter le terminal.

Ouvrir le shell du site dans LocalWP

Commencez par démarrer le site dans Local.

1. ouvrez Local ;
2. sélectionnez le site concerné ;
3. faites un clic droit sur le nom du site ;
4. cliquez sur Open Site Shell.

Local ouvre alors un terminal déjà configuré pour ce site. Vous êtes généralement placé dans le dossier WordPress, souvent autour de app/public.

Pour vérifier où vous êtes :

pwd

Pour lister les fichiers présents :

ls -lah

Préparer le fichier SQL à importer

Placez votre dump SQL dans le dossier du projet Local. Vous pouvez le mettre dans app ou directement dans app/public.

Par exemple, sur macOS, un projet Local peut ressembler à ceci :

/Users/matt/Local Sites/mon-site/app/publicCode language: PHP (php)

Si vous placez le fichier dans app, et que le shell s’ouvre dans app/public, vous devrez remonter d’un niveau avec ../.

Exemple :

ls -lah ../backup.sql

Si le fichier est directement dans app/public, la commande sera simplement :

ls -lah backup.sqlCode language: CSS (css)

Méthode recommandée : importer avec WP-CLI

Pour un site WordPress, la méthode la plus propre consiste à utiliser WP-CLI :

wp db import backup.sqlCode language: JavaScript (javascript)

WP-CLI lit les identifiants de base de données depuis wp-config.php. Vous n’avez donc pas besoin d’indiquer manuellement le nom de la base, l’utilisateur ou le mot de passe.

Si votre fichier SQL est dans le dossier parent app, utilisez :

wp db import ../backup.sqlCode language: JavaScript (javascript)

Après l’import, vérifiez que WordPress répond bien :

wp option get siteurl
wp option get homeCode language: JavaScript (javascript)

Si les URLs pointent encore vers le site de production, c’est normal après un import brut. Il faut ensuite remplacer les URLs.

Remplacer l’URL de production par l’URL locale

Après l’import, votre base contient souvent l’ancienne URL du site. Par exemple :

https://www.example.comCode language: JavaScript (javascript)

Il faut la remplacer par l’URL locale créée par LocalWP :

https://example.localCode language: JavaScript (javascript)

Commencez toujours par un test à blanc :

wp search-replace 'https://www.example.com' 'https://example.local' --dry-runCode language: JavaScript (javascript)

Si le résultat semble cohérent, lancez le remplacement réel :

wp search-replace 'https://www.example.com' 'https://example.local'Code language: JavaScript (javascript)

WP-CLI gère correctement les données sérialisées, contrairement à un remplacement SQL brut. C’est essentiel sur WordPress, car les options, widgets, réglages de thème et métadonnées peuvent contenir des chaînes sérialisées.

Si votre site utilise aussi l’URL sans www, traitez les deux variantes :

wp search-replace 'https://example.com' 'https://example.local' --dry-run
wp search-replace 'https://example.com' 'https://example.local'Code language: JavaScript (javascript)

Méthode alternative : importer avec MySQL

Dans Local, la base s’appelle généralement local. L’utilisateur MySQL est souvent root, avec le mot de passe root.

Vous pouvez donc importer un fichier SQL comme ceci :

mysql -u root -proot local < backup.sqlCode language: CSS (css)

Si le fichier se trouve dans le dossier parent :

mysql -u root -proot local < ../backup.sql

Vous verrez probablement cet avertissement :

mysql: [Warning] Using a password on the command line interface can be insecure.Code language: CSS (css)

En local, sur une machine de développement, ce n’est généralement pas dramatique. Cependant, sur un serveur distant, évitez de mettre le mot de passe directement dans la commande. Utilisez plutôt une invite interactive ou un fichier de configuration protégé.

Pour saisir le mot de passe sans l’écrire dans l’historique du shell :

mysql -u root -p local < backup.sqlCode language: CSS (css)

MySQL vous demandera alors le mot de passe.

Importer un fichier .sql.gz sans le décompresser

Les exports WordPress volumineux sont souvent compressés en .sql.gz. Bonne nouvelle : vous n’avez pas besoin de les décompresser avant l’import.

Avec WP-CLI, vous pouvez utiliser gunzip et envoyer le flux SQL vers l’entrée standard :

gunzip -c backup.sql.gz | wp db import -Code language: JavaScript (javascript)

Avec MySQL direct :

gunzip -c backup.sql.gz | mysql -u root -proot local

Sur certains systèmes, zcat fait le même travail :

zcat backup.sql.gz | wp db import -Code language: JavaScript (javascript)

Cette méthode évite de créer un énorme fichier SQL temporaire sur le disque. Sur une base lourde, c’est plus propre et souvent plus rapide.

Réinitialiser la base locale avant import

Si vous importez une copie complète de production dans un site Local déjà existant, vous pouvez d’abord vider la base locale.

Attention : cette commande supprime les tables de la base locale. Utilisez-la seulement sur un environnement de développement.

wp db reset

WP-CLI demandera une confirmation. Pour automatiser dans un script local, vous pouvez ajouter --yes :

wp db reset --yes

Ensuite, importez le dump :

wp db import backup.sqlCode language: JavaScript (javascript)

Cette approche évite les conflits avec d’anciennes tables, anciens préfixes ou restes de tests précédents.

Importer une base avec un préfixe différent

Un dump de production peut utiliser un préfixe différent de celui du site Local. Par exemple :

wp_6tt9k634w0_posts
wp_6tt9k634w0_options
wp_6tt9k634w0_postmeta

Si wp-config.php attend wp_, WordPress ne trouvera pas les bonnes tables. Vérifiez le préfixe avec :

wp db prefix

Puis inspectez les tables importées :

wp db tables

Si le préfixe diffère, adaptez $table_prefix dans wp-config.php ou recréez l’environnement local avec le bon préfixe. Sur un site de test, modifier $table_prefix est souvent le plus simple.

Corriger les erreurs fréquentes pendant l’import

ERROR 2006 : MySQL server has gone away

Cette erreur indique souvent que le dump contient une requête trop grosse, ou que MySQL coupe la connexion pendant l’import.

Dans Local, commencez par redémarrer le site. Ensuite, vérifiez la taille du dump :

ls -lh backup.sql backup.sql.gzCode language: CSS (css)

Si l’erreur persiste, augmentez les limites MySQL dans la configuration du service local, notamment max_allowed_packet. Selon votre version de Local, l’accès à cette configuration peut varier. Le shell reste toutefois l’approche la plus fiable pour reproduire et diagnostiquer l’erreur.

ERROR 1049 : Unknown database ‘local’

La base local n’existe pas, ou vous n’êtes pas connecté au bon service MySQL. Dans le shell Local, vérifiez les constantes WordPress :

wp config get DB_NAME
wp config get DB_USER
wp config get DB_HOSTCode language: JavaScript (javascript)

Si WordPress répond correctement à ces commandes, utilisez plutôt :

wp db import backup.sqlCode language: JavaScript (javascript)

Cela évite de deviner le nom exact de la base.

ERROR 1045 : Access denied

Les identifiants MySQL sont incorrects. Là encore, utilisez les valeurs du fichier wp-config.php :

wp config get DB_USER
wp config get DB_PASSWORD
wp config get DB_NAMECode language: JavaScript (javascript)

Puis retentez avec WP-CLI, qui lit ces constantes automatiquement :

wp db import backup.sqlCode language: JavaScript (javascript)

ERROR 1062 : Duplicate entry

La base contient déjà des données qui entrent en conflit avec le dump. Sur un site local, le plus simple est souvent de réinitialiser la base avant import :

wp db reset --yes
wp db import backup.sqlCode language: JavaScript (javascript)

Ne faites pas cela sur un site de production. Là, ce serait moins “workflow développeur” que “catastrophe industrielle”.

Vérifier le site après import

Après l’import et le remplacement d’URL, vérifiez les informations principales :

wp option get home
wp option get siteurl
wp db size --tables --human-readable
wp rewrite flushCode language: JavaScript (javascript)

Ensuite, ouvrez le site local dans le navigateur et testez :

• la page d’accueil ;
• quelques articles ;
• l’administration WordPress ;
• les médias ;
• les permaliens ;
• les formulaires ;
• le panier et le checkout si le site utilise WooCommerce.

Si les liens internes pointent encore vers la production, relancez un search-replace avec --dry-run pour repérer les occurrences restantes :

wp search-replace 'https://www.example.com' 'https://example.local' --dry-run --all-tablesCode language: JavaScript (javascript)

Utilisez --all-tables seulement si vous savez pourquoi vous le faites. Sur certains sites, des tables externes ou logs n’ont pas besoin d’être modifiés.

Exporter depuis production puis importer dans Local

Si vous avez accès à WP-CLI sur le serveur de production, vous pouvez exporter la base proprement :

wp db export production.sqlCode language: JavaScript (javascript)

Puis compresser le dump :

gzip production.sqlCode language: CSS (css)

Vous obtenez :

production.sql.gzCode language: CSS (css)

Copiez ce fichier dans votre projet Local, puis importez-le directement :

gunzip -c production.sql.gz | wp db import -Code language: JavaScript (javascript)

Enfin, remplacez les URLs :

wp search-replace 'https://www.example.com' 'https://example.local' --dry-run
wp search-replace 'https://www.example.com' 'https://example.local'Code language: JavaScript (javascript)

Pour une migration complète, il faut aussi copier le dossier wp-content, notamment les thèmes, extensions et médias. La base seule ne suffit pas à recréer un site WordPress complet.

Sécurité : attention aux dumps SQL

Un dump WordPress contient souvent des données sensibles : emails, comptes utilisateurs, commandes WooCommerce, adresses, réglages d’extensions, tokens, clés API, URLs privées et parfois des données de formulaires.

Ne laissez pas un fichier .sql ou .sql.gz dans le répertoire public du site. Même en local, prenez l’habitude de nettoyer après import :

rm backup.sql
rm backup.sql.gzCode language: CSS (css)

Si vous devez conserver un export, placez-le hors du dossier web, ou dans un répertoire privé. Un dump oublié dans app/public, c’est littéralement votre base de données en vitrine. Ambiance brocante, mais avec les mots de passe.

Besoin d’aide pour migrer ou réparer un site WordPress ?

Checklist rapide

• Créer ou démarrer le site dans LocalWP.
• Ouvrir Open Site Shell.
• Placer le fichier SQL dans app ou app/public.
• Importer avec wp db import backup.sql.
• Ou importer avec mysql -u root -proot local < backup.sql.
• Remplacer l’URL de production avec wp search-replace.
• Régénérer les permaliens avec wp rewrite flush.
• Tester le site local dans le navigateur.
• Vérifier les médias, formulaires et parcours WooCommerce.
• Supprimer le dump SQL après import.

FAQ : importer une base dans Local depuis le shell

Pourquoi Adminer échoue sur les grosses bases SQL ?

Adminer passe par le navigateur et PHP. Selon la taille du fichier, il peut rencontrer des limites de temps d’exécution, de mémoire ou d’upload. Le shell évite ces limites et importe directement via MySQL ou WP-CLI.

Quelle commande utiliser dans Local pour importer une base WordPress ?

La méthode recommandée est wp db import backup.sql. Elle utilise les identifiants de wp-config.php. L’alternative MySQL directe est mysql -u root -proot local < backup.sql.

Comment importer un fichier .sql.gz dans Local ?

Utilisez gunzip -c backup.sql.gz | wp db import -. Cette commande décompresse le dump à la volée et l’envoie directement à WP-CLI.

Pourquoi mon site local redirige encore vers la production ?

La base importée contient encore l’ancienne URL dans home, siteurl, les contenus ou les options. Lancez wp search-replace avec l’ancienne URL et l’URL locale.

Faut-il vider la base locale avant import ?

Oui, si vous voulez remplacer totalement le site local par une copie de production. Utilisez wp db reset --yes, puis importez le dump. Ne faites jamais cela sur production.

Pourquoi WordPress affiche une erreur après import ?

Les causes courantes sont une mauvaise URL, un préfixe de table différent, des fichiers wp-content manquants, un plugin absent, une version PHP incompatible ou une base importée partiellement.

Sources

• Documentation WP-CLI : wp db import
• Documentation WP-CLI : wp db
• Documentation WP-CLI : wp search-replace
• Documentation WP-CLI : wp rewrite flush
• SkyMinds : Local, résoudre les problèmes d’importation de la base de données
• SkyMinds : changer le mot de passe d’un utilisateur WordPress depuis SQL
• SkyMinds : migrer WordPress avec WP-CLI vers un nouveau serveur

Report a typo