Pourquoi versionner ses templates Elementor Pro avec Git ?
Elementor stocke ses données en JSON dans la table wp_postmeta de la base de données. Sans versionning, il n’y a pas d’historique Git natif — et l’historique de révisions Elementor est limité à quelques semaines. Pour les projets clients importants, un versionning Git propre des templates est une nécessité.
Les deux approches de versionning
Approche 1 : Export JSON + Git
La méthode la plus simple. Après chaque session de travail significative, exportez vos templates Elementor (Templates → Mes Templates → Exporter) en JSON et commitez ces fichiers dans votre dépôt Git. L’inconvénient : c’est un processus manuel, donc facilement oublié.
Approche 2 : Versionner la base de données
Plus robuste. Utilisez WP-CLI (wp db export) dans un hook Git pre-commit pour exporter automatiquement la base de données avant chaque commit. Cette approche nécessite une configuration technique mais garantit que rien n’est oublié.
Structure Git recommandée pour un projet Elementor
projet-client/
├── templates/
│ ├── header-main.json
│ ├── footer-main.json
│ ├── single-post.json
│ └── page-home.json
├── database/
│ └── backup-YYYY-MM-DD.sql
└── wp-content/
└── themes/hello-elementor-child/Alternative : le système de révisions natif Elementor
Si Git vous semble trop complexe, Elementor Pro propose un historique de révisions natif accessible via l’icône horloge dans l’éditeur. Il conserve les 20 dernières révisions d’une page, avec la date, l’heure et l’auteur. Pour la majorité des projets solo ou petites équipes, c’est suffisant.
Utiliser WP Staging pour la gestion staging/production
Pour les équipes qui n’utilisent pas Git, WP Staging (plugin WordPress) offre une alternative efficace. Il crée un environnement de staging complet (clone du site en quelques clics), vous permettant de travailler sur les templates Elementor en staging et de pousser les modifications vers la production en un clic. La synchronisation copie les tables de base de données (y compris les données Elementor) et les fichiers media depuis staging vers production — sans écraser les contenus ajoutés en production entre-temps.
localStorage et les révisions automatiques d’Elementor
Elementor Pro sauvegarde automatiquement les modifications dans le localStorage du navigateur toutes les 30 secondes (autosave). Si votre navigateur se ferme brutalement ou que vous perdez la connexion, Elementor propose de restaurer la session depuis ce localStorage au prochain chargement de l’éditeur. Cette fonctionnalité est limitée à la session en cours et ne remplace pas les révisions serveur — elle est un filet de sécurité complémentaire, pas une solution de versionning.
Déploiement staging vers production : les bonnes pratiques
Que vous utilisiez Git ou WP Staging, quelques règles s’appliquent systématiquement pour un déploiement sans surprises : (1) Exportez toujours une sauvegarde de la production avant tout déploiement. (2) Vérifiez que les URLs dans la base de données sont correctement remplacées (staging.monsite.fr → monsite.fr) avec WP-CLI : wp search-replace 'staging.monsite.fr' 'monsite.fr' --all-tables. (3) Testez le site sur mobile et desktop immédiatement après le déploiement. (4) Purgez le cache WP Rocket ou Cloudflare après chaque déploiement.
→ Retour au guide complet Elementor Pro
FAQ — Git, Staging et Versionning Elementor Pro
Peut-on versionner les templates Elementor Pro directement avec Git comme du code source ?
Pas directement, car Elementor stocke les données de design en JSON dans la base de données MySQL (table wp_postmeta), pas dans des fichiers. La solution la plus propre est d’exporter régulièrement les templates en JSON (Templates → Exporter) et de commiter ces fichiers dans votre dépôt Git. C’est un processus manuel mais il permet d’avoir un historique clair des modifications de design.
WP Staging ou Duplicator : quel outil choisir pour le staging Elementor ?
WP Staging est le plus adapté pour les projets Elementor actifs : il crée un clone complet du site (base de données + fichiers) en quelques minutes, avec une URL de staging sécurisée. La fonctionnalité de push vers production (payante) copie uniquement les tables et fichiers modifiés. Duplicator est excellent pour la migration initiale mais moins prätique pour les cycles staging/production répétés.
Comment Elementor Pro gère-t-il l’historique de révisions ?
Elementor Pro maintient un historique de révisions par page, accessible via l’icône horloge dans l’éditeur (bas gauche de l’interface). Par défaut, les 20 dernières révisions sont conservées. Chaque révision est horodatée et associée à l’auteur. Vous pouvez visualiser chaque révision et revenir à n’importe quelle version antérieure en un clic. La durée de conservation dépend du paramètre WordPress wp_post_revisions.
Comment éviter les conflits lors du déploiement staging vers production ?
La règle d’or : ne jamais modifier le contenu en production pendant qu’une séance de design est en cours en staging. Communiquez clairement avec votre client : « pendant cette période, n’ajoutez pas de nouveaux articles ou pages en production ». Si vous devez déployer malgré des modifications en production, faites une sauvegarde manuelle des tables de contenu (wp_posts, wp_postmeta) avant le déploiement et comparez avec un outil diff SQL.
Le localStorage d’Elementor peut-il remplacer les révisions serveur ?
Non. L’autosave localStorage d’Elementor est un filet de sécurité pour la session en cours — il est effacé quand la page est sauvegardée normalement ou quand le cache navigateur est vidé. Les révisions serveur (historique Elementor ou révisions WordPress) sont persistantes et fiables. Pour les projets critiques, combinez les deux : autosave localStorage pour la protection court terme et révisions serveur pour l’historique long terme.