🚀 WP-CLI Sync Script pour rapatrier vos projets WordPress en local sous Windows en 6 caractères dans Git Bash
- Authors
-
-
- Rédigé par
- Name
- Website
- gaelgerard.com
- Phone
- 02 85 52 38 66
-
Un script d’automatisation ultra-rapide pour synchroniser la base de données d’un site WordPress distant (Production) vers un environnement de développement local en une seule commande.
Dans mon quotidien de développeur WordPress je suis souvent amené à récupérer les données du site en ligne (Production) pour travailler sur le site sur mon ordinateur (Local) afin de travailler plus vite et sans risquer de compromettre l’affichage pour les internautes.
Voir l’article sur les intérêts de créer son site internet en local
Sur un projet simple, type landing page, le processus est rapide, je rapatrie les fichiers du site en ligne (html, css, images…) pour les modifier sur mon ordi et au fur à mesure que mes tests sont satisfaisant, je les envoie en ligne via mon logiciel ftp ou un script de déploiement. Dans ce cas là, pas de surprise, le contenu est directement intégré dans les fichiers et donc strictement identique sur les 2 environnements.
En revanche, pour un projet plus complexe, bâti sur un CMS comme WordPress, les contenus ne sont plus gérés dans les fichiers directement mais en base de données et modifié directement sur l’interface d’administration du CMS. De fait, sauf à reproduire les modifications de contenu sur les interfaces des 2 environnements (ce qui prend du temps), le contenu peut rapidement différer entre les 2 qui dans de nombreux cas peut altérer la mise en page voire la fonctionnalité qui marche bien en local mais casse tout en production.
Pour remédier à ce problème et m’assurer que je travail toujours sur une copie conforme du site en production sur mon environnement de développement local, j’ai crée ce script basé sur l’interface de ligne de commande WordPress (WP-cli) conçu pour tourner dans mon environnement Windows (Git Bash), et optimisé pour la gestion des constructeurs de pages (Elementor, Divi, Gutenberg).
✨ Fonctionnalités
- ⏱️ Gain de temps maximal : Plus besoin de rapatrier la base de données manuellement. Tout se fait via un flux direct par ligne de commande (Pipe compatible Windows) en 6 petits caractères.
- 🔒 Sécurité (Git-Safe) : Les identifiants de connexion et chemins SSH distants restent locaux et sont masqués du suivi de version.
- 🪵 Compatible Bedrock : Détection automatique des configurations d’URLs ( WP_HOME) directement depuis le fichier
.envsi disponible. - 🎨 Mode Optionnel Constructeurs (Escaped URLs) : Une option intelligente pour nettoyer les URLs échappées (
\/) stockées dans les données JSON sérialisées de vos thèmes et extensions lourdes (type Elementor ou le thème FSE de WordPress Twenty-twenty Five).
🛠️ Prérequis
Avant d’utiliser le script, assurez-vous d’avoir :
- WP-CLI installé en local et configuré dans votre PATH Windows.
- WP-CLI et un accès SSH fonctionnels sur le serveur distant.
- Git Bash (MINGW64) comme terminal (intégré ou non dans VS Code).
📦 1. Configuration du Projet
Fichier wp-cli.local.yml (À ajouter au .gitignore)
À la racine de votre projet WordPress sur le disque dur de votre machine, créez un fichier wp-cli.local.yml pour y placer vos accès SSH de production. Traditionnellement le fichier wp-cli.yml est utilisé par l’interface de ligne de commande pour identifier la racine du projet WordPress. Ici on va lui indiquer l’emplacement du projet WordPress sur le serveur de production et c’est pourquoi il ne doit jamais être poussé sur GitHub :
# Les guillemets protègent le caractère réservé '@' en YAML
"@prod":
ssh: gaelgerard@mon-serveur.com:22/home4/gaelgerard/sites/mon-site-distant.comN’oubliez pas de sécuriser votre dépôt en ajoutant le nouveau fichier dans votre fichier .gitignore :
wp-cli.local.ymlLe workflow sépare la structure de l’application (versionnée) de vos accès machines (ignorés par Git).
Fichier wp-cli.yml (spécificité Bedrock)
Dans le cas d’un projet Bedrock, il existe déjà un fichier wp-cli.yml à la racine du projet qui a une architecture différente d’un projet WordPress classique. Ce fichier est inclue dans le dépôt Git et ne contient aucune données sensible contrairement au fichier local vue précédemment qui contient le chemin complet sur le serveur, ce qui est potentiellement exploitable par un acteur malveillant.
Cependant lorsque je crée le fichier wp-cli.local.yml, celui ci est pris en priorité par WordPress et le contenu du wp-cli.yml de Bedrock est ignoré, ce qui fait que WP-cli ne reconnait pas l’installation WordPress.
De fait, pour conserver la possibilité d’intervenir en ligne de commande sur votre WordPress local, il convient d’ajouter à votre fichier wp-cli.local.yml les 3 lignes du wp-cli.yml de Bedrock.
path: web/wp
server:
docroot: web
# Les coordonnées de mon WordPress sur le serveur de gaelgerard
"@prod":
ssh: gaelgerard@mon-serveur.com:22/home4/gaelgerard/sites/mon-site-distant.com/web/wp⚙️ 2. Installation Globale
Maintenant que l’environnement local est configuré avec l’emplacement de l’installation WordPress sur le serveur de production déclarée à la racine du projet, place à la magie du WP-cli !
Pour rendre la commande accessible depuis n’importe quel projet sur votre machine, ajoutez la fonction dans votre configuration Git Bash.
- Ouvrez Git Bash et accédez à votre dossier utilisateur :
cd ~ - Créez ou éditez votre fichier
.bashrc:code .bashrc - Copiez-y le script suivant :
# Fonction de synchronisation WordPress (Prod vers Local)
syncwp() {
# Détection du mode constructeur (URLs échappées)
local MODE_ESCAPED=false
if [[ "$1" == "--escaped" || "$1" == "-e" ]]; then
MODE_ESCAPED=true
echo "🎨 Mode lourd activé (Search & Replace échappé)."
fi
echo "🔍 Récupération des configurations avant écrasement..."
# 1. On récupère l'URL de prod depuis le serveur distant (avant import)
PROD_HOME=$(wp @prod option get home)
# 2. On récupère l'URL locale
if [ -f .env ]; then
# Environnement moderne (ex: Bedrock) avec fichier .env
LOCAL_HOME=$(grep '^WP_HOME=' .env | cut -d '=' -f2 | tr -d '"' | tr -d "'" | xargs)
else
# Environnement classique (pas de .env)
# On peut rapatrier l'URL directement via WP-CLI
LOCAL_HOME=$(wp option get home --skip-plugins --skip-themes 2>/dev/null)
fi
echo "📥 Export et import de la base distante..."
wp @prod db export - | wp db import -
if [ $? -eq 0 ]; then
# --- PASSAGE 1 : URLs STANDARDS ---
echo "⚡ Search and replace (Pages & Médias) : $PROD_HOME ➡️ $LOCAL_HOME..."
NB_STANDARDS=$(wp search-replace "$PROD_HOME" "$LOCAL_HOME" --format=count)
echo "✅ Synchronisation terminée : $NB_STANDARDS urls standards."
# --- PASSAGE 2 : URLs ÉCHAPPÉES (Optionnel) ---
if [ "$MODE_ESCAPED" = true ]; then
echo "🛠️ Génération des versions échappées (\/)..."
# 4. Génération AUTOMATIQUE des versions échappées (\/) pour les thèmes/constructeurs
PROD_HOME_ESCAPED="${PROD_HOME//\//\\\/}"
LOCAL_HOME_ESCAPED="${LOCAL_HOME//\//\\\/}"
NB_ESCAPED=$(wp search-replace "$PROD_HOME_ESCAPED" "$LOCAL_HOME_ESCAPED" --format=count)
echo "✅ Synchronisation terminée : $NB_ESCAPED versions échappées (JSON / Constructeurs)..."
fi
# 3. Nettoyage du cache WordPress
echo "🚀 Flush du cache local..."
wp cache flush
echo "✅ Synchronisation terminée avec succès !"
else
echo "❌ Échec de la récupération de la base de données."
fi
}Forcez le rechargement de votre terminal pour activer la commande :
source ~/.bashrc🚀 Utilisation
Ouvrez votre terminal Git Bash, placez-vous à la racine de votre projet Bedrock local, puis lancez la commande adaptée :
Mode Standard (Recommandé pour thèmes légers type Sage)
Exécute un doublon de Search and Replace classique (Core + Front) sur l’ensemble des tables :
syncwpMode Avancé (Recommandé pour Elementor, Divi, etc.)
Ajoute deux passes de nettoyage supplémentaires pour modifier les structures d’URLs échappées de type https:\/\/site-prod.fr en https:\/\/site-local.test :
syncwp -e
