Douze projets gérés simultanément avec la même base de composants Elementor : c’est le contexte qui a poussé une agence multi-projets à automatiser la publication de ses Kits, plutôt que de répéter, site par site, l’export-import manuel depuis l’écran Elementor > Outils > Import/Export Kit. Cette architecture ne traite pas de Bitbucket Pipelines, qui suivrait une configuration différente bien que le principe général reste transposable : elle décrit précisément la mise en place retenue avec GitLab CI.
L’idée de départ est simple : un Kit Elementor s’exporte au format JSON, un format parfaitement adapté au versionnement dans un dépôt Git. Reste à automatiser son import sur chaque site cible au moment du déploiement, via WP-CLI, plutôt que de télécharger et réimporter manuellement le fichier depuis l’administration WordPress à chaque mise à jour.
Arborescence du dépôt de Kits
kits-elementor/
├── .gitlab-ci.yml
├── kits/
│ ├── kit-corporate-v3.json
│ └── kit-vitrine-v2.json
├── scripts/
│ └── import-kit.sh
└── sites/
├── site-client-a.env
├── site-client-b.env
└── site-client-c.env
Chaque fichier .env dans le dossier sites/ référence le nom du Kit à appliquer et les identifiants de connexion SSH du site correspondant, ce qui permet au même pipeline de servir l’ensemble des douze projets sans dupliquer la configuration.
Le script d’import via WP-CLI
#!/bin/bash
set -e
KIT_FICHIER="kits/${KIT_NOM}.json"
ssh "${SITE_SSH}" "wp elementor library import ${KIT_FICHIER} --path=${SITE_CHEMIN}"
ssh "${SITE_SSH}" "wp elementor flush-css --path=${SITE_CHEMIN}"
La commande wp elementor library import, fournie par l’intégration WP-CLI d’Elementor, accepte un fichier JSON de Kit et l’applique directement sur l’installation ciblée, sans passer par l’interface d’administration. La commande wp elementor flush-css régénère ensuite les fichiers CSS pour que les nouveaux styles globaux du Kit soient effectivement pris en compte par le rendu des pages existantes.
Le fichier de configuration GitLab CI
stages:
- preprod
- prod
deploy_kit_preprod:
stage: preprod
script:
- source sites/${SITE_CIBLE}.env
- bash scripts/import-kit.sh
environment: preprod
only:
- merge_requests
deploy_kit_prod:
stage: prod
script:
- source sites/${SITE_CIBLE}.env
- bash scripts/import-kit.sh
environment: production
when: manual
only:
- main
Valider en préproduction avant chaque publication
Chaque modification de Kit déclenche d’abord un déploiement automatique sur un environnement de préproduction dédié, via une requête de fusion GitLab. L’équipe vérifie visuellement l’impact du Kit modifié sur un échantillon de pages représentatives avant d’autoriser manuellement le déploiement en production, ce déclenchement manuel étant configuré via l’instruction when: manual du pipeline.
Gérer le cas des Kits divergents entre projets
Certains projets nécessitent des variantes légères du Kit de base (une palette de couleurs différente, par exemple). Plutôt que de dupliquer entièrement le fichier JSON, l’agence a choisi de conserver un Kit de base commun et d’appliquer, juste après son import, un second script qui ne modifie que les variables de couleurs globales via wp elementor combiné à des appels directs à l’API de configuration du Kit, ce qui limite la duplication de code entre les projets.
Le principe qu’on retient de cette architecture : un Kit versionné dans Git devient un artefact de déploiement comme un autre, avec son historique de modifications, ses validations en préproduction, et une traçabilité complète de qui a changé quoi, un confort qu’un export-import manuel ne procure jamais.
En résumé
Versionner les Kits Elementor en JSON dans un dépôt Git et automatiser leur import via WP-CLI et GitLab CI transforme une tâche répétitive et sujette à l’erreur humaine en un processus reproductible, validé en préproduction avant chaque publication. Cette architecture demande un investissement initial modeste, largement rentabilisé dès que plusieurs sites partagent la même base de composants.
