wp-env start : cette seule commande suffit à faire tourner une instance WordPress complète, isolée dans des conteneurs Docker, sans toucher au serveur de recette partagé habituellement utilisé par toute l’équipe pour valider les livrables. C’est exactement ce dont a besoin une équipe qui teste un Kit Elementor V4 avant de le livrer à un client : un environnement jetable, reproductible, qui n’entre en conflit avec aucun autre test en cours.
Ce tutoriel décrit la mise en place concrète de cet environnement pour prévisualiser un Kit avant livraison. La comparaison avec DDEV, une alternative fréquemment citée pour ce même usage, ne fait pas partie de ce périmètre.
Pourquoi éviter le serveur de recette partagé pour ce test
Le serveur de recette partagé, utilisé par plusieurs projets en parallèle, pose un problème spécifique pour la validation d’un Kit : importer un Kit complet écrase les réglages de style globaux existants, ce qui peut perturber d’autres tests en cours menés par des collègues sur le même environnement. Un environnement jetable, propre à ce seul test, élimine totalement ce risque de conflit.
Installer et configurer wp-env pour ce test
- Installer wp-env globalement via npm, si ce n’est pas déjà fait sur la machine du testeur :
npm -g install @wordpress/env. - Créer un fichier de configuration
.wp-env.jsonà la racine d’un dossier dédié, en spécifiant la version de WordPress souhaitée et les extensions à charger automatiquement, dont Elementor et Elementor Pro. - Lancer l’environnement avec
wp-env start, qui télécharge et démarre les conteneurs nécessaires. - Se connecter à l’instance locale via l’adresse fournie par wp-env dans la sortie de la commande précédente.
- Importer le Kit à valider depuis l’interface d’Elementor, exactement comme cela se ferait sur le site final du client.
Un exemple minimal de fichier de configuration pour ce cas d’usage :
{
"core": "WordPress/WordPress#6.9",
"plugins": [
"https://example.com/elementor.zip",
"https://example.com/elementor-pro.zip"
]
}Faire tester plusieurs personnes sans conflit
Chaque membre de l’équipe qui souhaite valider le Kit peut monter sa propre instance wp-env en local, à partir du même fichier de configuration versionné dans le dépôt du projet. Cette approche évite tout conflit entre testeurs : chacun travaille sur sa propre copie isolée, sans risquer d’écraser les modifications d’un collègue en cours de test.
Ce qu’il faut vérifier spécifiquement pour un Kit V4
Au-delà de l’installation des extensions, un Kit récent construit avec l’éditeur atomique embarque son propre lot de classes globales et de composants réutilisables. Il vaut la peine, une fois l’environnement démarré, de vérifier que la version de WordPress et d’Elementor déclarée dans le fichier de configuration correspond bien à celle utilisée sur le site final du client : un décalage de version peut faire apparaître des différences subtiles dans le rendu des composants, invisibles au premier coup d’œil mais gênantes une fois le Kit livré.
Il est également utile de conserver, à côté du fichier .wp-env.json, une courte note listant les extensions tierces attendues sur le site final mais absentes de l’environnement de test : cela évite de valider un Kit dans des conditions trop éloignées de la réalité du projet, notamment quand certains widgets dépendent d’une extension complémentaire non incluse dans ce test isolé.
Nettoyer proprement une fois le test terminé
Une fois la validation du Kit terminée, la commande wp-env destroy supprime intégralement les conteneurs et les données associées à cet environnement de test, sans laisser de trace résiduelle sur la machine du testeur. Cette propreté de nettoyage est précisément ce qui manque à un serveur de recette partagé, où les Kits testés précédemment s’accumulent souvent sans jamais être retirés.
- Pas de risque de pollution du serveur de recette partagé par un Kit en cours de validation.
- Un environnement reproductible à l’identique par n’importe quel membre de l’équipe, à partir du même fichier de configuration.
- Une suppression complète et rapide une fois le test terminé, sans tâche de nettoyage manuelle à effectuer.
Sur ce type de test, mieux vaut versionner le fichier
.wp-env.jsondirectement dans le dépôt du Kit lui-même : cela garantit que chaque testeur, aujourd’hui comme dans plusieurs mois, reproduise exactement les mêmes conditions de validation.
En résumé
wp-env apporte une réponse simple à un problème récurrent d’organisation d’équipe : tester un Kit Elementor sans perturber les autres projets en cours sur le serveur de recette partagé. La légèreté de mise en place, quelques commandes suffisent, en fait une option particulièrement adaptée à une validation ponctuelle avant livraison client.
