npx @wp-playground/cli server : cette seule commande suffit à faire tourner une instance WordPress complète, exécutée via WebAssembly directement dans le navigateur ou dans un environnement Node local, sans base de données MySQL classique et sans le moindre serveur à configurer. Pour un développeur d’extension qui veut vérifier rapidement une compatibilité avant de publier une mise à jour, c’est un gain de temps considérable par rapport au montage d’un environnement complet.
Ce que Playground permet réellement
WordPress Playground exécute PHP compilé en WebAssembly et utilise SQLite à la place de MySQL, via la couche de compatibilité fournie par l’extension officielle correspondante. Cette architecture rend le démarrage quasi instantané, mais impose aussi des limites : certaines fonctions PHP liées au système de fichiers natif ou à des extensions PHP compilées ne sont pas disponibles dans cet environnement.
npx @wp-playground/cli server --php=8.2 --wp=6.7 \
--mount=./mon-extension:/wordpress/wp-content/plugins/mon-extension
Cette commande monte le répertoire local de l’extension directement dans l’instance Playground, ce qui permet de tester chaque modification de code sans réimporter quoi que ce soit à chaque cycle.
Ce que wp-env apporte en complément
wp-env, à l’inverse, fait tourner une vraie instance WordPress dans des conteneurs Docker, avec MySQL réel et un système de fichiers persistant classique. Certains tests, en particulier ceux qui portent sur les tâches Cron réelles, les écritures de fichiers volumineux, ou l’intégration avec un vrai serveur de messagerie sortant, nécessitent cet environnement complet que Playground ne peut pas reproduire fidèlement.
Une stratégie de test à deux niveaux
La méthode la plus efficace consiste à traiter Playground comme un premier filtre rapide, exécuté à chaque modification de code, et wp-env comme validation finale avant publication :
- Playground pour vérifier l’absence d’erreur fatale au chargement de l’extension, sur plusieurs versions de PHP et de WordPress successivement ;
- Playground pour tester l’interface d’administration de l’extension sans configuration préalable ;
- wp-env pour valider tout ce qui touche aux tâches planifiées, aux emails ou aux écritures disque réelles ;
- wp-env pour exécuter la suite de tests PHPUnit complète avant publication sur le répertoire officiel.
Automatiser la matrice de compatibilité
Playground se prête particulièrement bien à un test automatisé sur plusieurs combinaisons de versions, exécuté en amont de chaque publication :
for php in 8.1 8.2 8.3; do
npx @wp-playground/cli server --php=$php --wp=6.7 \
--mount=./mon-extension:/wordpress/wp-content/plugins/mon-extension \
--blueprint=./blueprint-test.json
done
Un fichier blueprint.json décrit les étapes à exécuter automatiquement dans l’instance Playground dès son démarrage : activation de l’extension, création d’un contenu de test, vérification de l’absence d’erreur dans les journaux.
Les limites à connaître avant de se fier uniquement à Playground
Une extension qui fonctionne parfaitement sous Playground peut encore échouer en production si elle dépend d’une extension PHP native absente de la compilation WebAssembly, ou si elle suppose l’existence d’un vrai système de fichiers persistant entre deux requêtes. Ce constat ne remet pas en cause l’intérêt de l’outil, mais rappelle qu’il ne remplace pas totalement un test sous wp-env avant publication.
Un principe adopté sur nos projets d’extension : Playground pour aller vite à chaque commit, wp-env pour la validation qui compte vraiment, juste avant la mise en ligne d’une nouvelle version.
En résumé
Playground et wp-env ne sont pas concurrents mais complémentaires : le premier élimine en quelques secondes les incompatibilités les plus grossières sur une large matrice de versions, le second confirme, dans un environnement fidèle à la production, que l’extension se comporte correctement une fois publiée.
