Installer un serveur, configurer une base de données, cloner un dépôt juste pour tester un plugin cinq minutes : cette routine, tout développeur WordPress la connaît par cœur. Et si on pouvait s’en passer complètement, en faisant tourner PHP directement dans l’onglet du navigateur ? C’est exactement la promesse de WordPress Playground, un outil qui change radicalement la façon de prototyper, débugger et démontrer son travail.
Comment fonctionne WordPress Playground sous le capot
Bon, entrons un peu dans la technique. WordPress Playground, ce n’est pas de la magie : c’est une combinaison assez maline de plusieurs technologies web récentes qui permettent de faire tourner un WordPress complet sans serveur. On va décortiquer ça ensemble, sans trop de jargon (ou en expliquant le jargon quand il y en a).
WebAssembly : faire tourner PHP dans le navigateur
Le cœur du système, c’est WebAssembly (WASM). Concrètement, c’est un format binaire qui permet d’exécuter du code compilé directement dans le navigateur, à une vitesse proche du natif. Le projet php-wasm a compilé l’interpréteur PHP lui-même en WASM : donc PHP tourne littéralement dans votre navigateur, sans installation, sans serveur Apache ou Nginx derrière.
Le navigateur devient à la fois le client et le serveur. Chaque requête PHP est traitée par ce runtime PHP embarqué, qui s’exécute dans un sandbox JavaScript (via WebAssembly). C’est assez bluffant quand on y pense : plus besoin de configurer un environnement local, tout se passe dans un onglet.
SQLite en remplacement de MySQL : ce que ça change
WordPress a besoin d’une base de données, et normalement, c’est MySQL (ou MariaDB) qui s’en charge. Problème : on ne peut pas faire tourner un vrai serveur MySQL dans un navigateur. La solution retenue, c’est le plugin sqlite-database-integration, qui remplace les appels MySQL par des équivalents SQLite.
SQLite, c’est une base de données légère, sans serveur, qui stocke tout dans un fichier (ou en mémoire). Dans le contexte de Playground, les données sont conservées en mémoire ou via IndexedDB (le système de stockage local du navigateur). Ça fonctionne bien pour prototyper, mais attention : ce n’est pas une vraie base réseau, et la persistance dépend entièrement du navigateur. Si vous fermez l’onglet sans exporter votre travail, tout peut disparaître.
Les limites actuelles à connaître avant de se lancer
WordPress Playground reste un outil de prototypage, pas un environnement de production. Et il a des limites qu’il faut connaître avant de s’y investir à fond :
- Emails : aucun email n’est réellement envoyé. La fonction
wp_mail()est interceptée, mais rien ne part vers une boîte de réception. - Cron : le système de tâches planifiées de WordPress (WP-Cron) ne fonctionne pas comme sur un vrai serveur, faute de processus persistant en arrière-plan.
- Extensions PHP : certaines sont absentes ou partielles, notamment GD (pour le traitement d’images) qui n’est pas complet, ce qui peut poser problème avec certains plugins.
- Réseau externe : pas d’accès direct aux sockets réseau. Les appels vers des API externes passent obligatoirement par un proxy CORS, sinon ça bloque.
- Performances : elles varient énormément selon le navigateur utilisé (Chrome, Firefox, Safari n’ont pas les mêmes performances WASM).
- Stockage volatile : sans export explicite, vos données peuvent se perdre au rechargement de la page.
Ces limitations ne rendent pas l’outil inutile, loin de là. Mais elles définissent clairement son périmètre : le test rapide, la démo, le prototypage. Pas la mise en production.
Créer son premier blueprint JSON pour préconfigurer un environnement de démo
Une fois qu’on a compris comment Playground fonctionne sous le capot (php-wasm, SQLite, et toutes ces limitations vues plus haut), l’étape logique suivante, c’est d’automatiser la configuration. Plutôt que de cliquer manuellement pour installer un plugin à chaque test, on écrit un blueprint. C’est un simple fichier JSON qui décrit l’état initial souhaité : version de WordPress, plugins préchargés, contenu de démo, etc. Et honnêtement, une fois qu’on a compris la logique, ça change complètement la façon de tester ses développements.
Structure de base d’un fichier blueprint.json
Un blueprint repose sur quelques clés essentielles : landingPage (la page affichée à l’ouverture), preferredVersions (pour fixer les versions de PHP et WordPress) et steps (le tableau d’actions exécutées au démarrage). Voici une structure minimale fonctionnelle :
{
"landingPage": "/wp-admin/",
"preferredVersions": {
"php": "8.2",
"wp": "6.5"
},
"steps": [
{
"step": "login",
"username": "admin",
"password": "password"
}
]
}Ce fichier, une fois chargé, ouvre directement le tableau de bord avec un utilisateur déjà connecté. Simple, mais déjà bien pratique pour éviter l’étape de configuration manuelle à chaque test.
Précharger des plugins et thèmes automatiquement
C’est probablement l’usage le plus courant : installer automatiquement un ou plusieurs plugins dès le lancement. On utilise le step installPlugin, avec deux cas de figure possibles. Soit on pointe vers un plugin du répertoire officiel via son slug, soit on charge un zip local (pratique pour tester une version en cours de développement, avant publication).
{
"steps": [
{
"step": "installPlugin",
"pluginData": {
"resource": "wordpress.org/plugins",
"slug": "query-monitor"
}
},
{
"step": "installPlugin",
"pluginData": {
"resource": "url",
"url": "https://mon-serveur.local/mon-plugin-dev.zip"
}
},
{
"step": "installTheme",
"themeData": {
"resource": "wordpress.org/themes",
"slug": "twentytwentyfour"
}
}
]
}On peut empiler autant de steps que nécessaire dans le tableau : plusieurs plugins, plusieurs thèmes, l’ordre d’exécution suit simplement l’ordre du tableau. Attention néanmoins à la taille des fichiers zip distants, ça peut ralentir le chargement initial si le fichier est lourd.
Exécuter des commandes WP-CLI au démarrage
Playground embarque aussi WP-CLI, ce qui ouvre pas mal de possibilités pour préparer un environnement de démo complet. Le step runWpCliCommand permet d’exécuter n’importe quelle commande CLI, comme on le ferait sur un serveur classique : activation de plugin, création de contenu, réglages divers.
{
"step": "runWpCliCommand",
"command": "wp plugin activate query-monitor"
},
{
"step": "runWpCliCommand",
"command": "wp post generate --count=5 --post_type=post"
}On peut aussi utiliser runPHP pour exécuter du code PHP arbitraire directement, utile pour des manipulations plus fines qu’une simple commande CLI (modifier une option, insérer des données custom en base, etc.). C’est vraiment là que le blueprint devient un outil de démo complet plutôt qu’un simple installeur.
Partager son environnement via une URL ou un fichier
Une fois le blueprint prêt, deux options pour le diffuser. On peut héberger le fichier JSON quelque part (un gist GitHub par exemple) et construire une URL du type https://playground.wordpress.net/?blueprint-url=https://mon-url.com/blueprint.json. Quiconque clique sur ce lien obtient instantanément l’environnement configuré, sans rien installer.
Autre option : joindre directement le fichier blueprint.json dans une issue GitHub ou un ticket de support. C’est devenu une pratique courante dans l’écosystème WordPress pour reproduire un bug : au lieu de décrire dix étapes pour reproduire un problème, on donne juste un lien qui recrée exactement le contexte du bug. Un vrai gain de temps, pour soi comme pour les collègues (ou les mainteneurs de plugins qu’on sollicite).
Cas d’usage concrets pour développeurs de plugins et thèmes
La théorie c’est bien joli, mais concrètement, à quoi ça sert dans le quotidien d’un dev WordPress ? Voici les usages que j’utilise (ou que je vois utilisés) le plus souvent, avec des exemples précis pour chacun.
Tester rapidement un plugin en cours de développement
C’est probablement l’usage le plus immédiat : vous développez un plugin en local, et vous voulez juste vérifier rapidement qu’il fonctionne sans monter tout un environnement. La méthode est simple : on zippe le dossier du plugin, on charge Playground avec un blueprint qui pointe vers ce zip (via installPlugin avec une ressource locale ou une URL), et hop, on a un WordPress fonctionnel en quelques secondes.
Comparé à Local by Flywheel ou LocalWP, la différence de rapidité est flagrante. Ces outils sont excellents, mais ils nécessitent de créer un site, d’attendre le provisioning, parfois de configurer la base de données… Avec Playground, on ouvre un onglet et c’est prêt. Pas de conteneur Docker qui traîne, pas de port à libérer. Pour du test rapide et jetable, c’est imbattable.
Reproduire un bug pour un rapport ou une PR GitHub
Là, Playground change vraiment la donne pour la collaboration. Plutôt que d’expliquer par écrit « installez tel plugin, activez tel thème, faites ceci puis cela pour voir le bug », on génère un lien Playground avec un blueprint qui reproduit exactement les conditions du bug. La personne qui reçoit le lien clique, et elle voit le problème immédiatement, sans rien installer.
D’ailleurs, WordPress core utilise déjà cette pratique dans ses propres tickets Trac et ses PR GitHub : les contributeurs joignent un lien Playground préconfiguré pour illustrer un comportement précis. C’est devenu un standard de facto pour les rapports de bug bien documentés. Franchement, ça change la vie des mainteneurs qui n’ont plus à deviner le contexte exact.
Créer une démo interactive pour la documentation ou le support
Autre cas d’usage que j’apprécie particulièrement : intégrer un iframe Playground directement dans la documentation d’un plugin. Vos utilisateurs peuvent alors tester le plugin en conditions réelles, directement depuis votre site de doc, avant même de l’installer sur leur propre WordPress.
C’est particulièrement utile pour :
- Les plugins avec une interface d’administration complexe (on peut montrer, pas juste décrire)
- Les thèmes, pour laisser visualiser le rendu sans installation
- Le support client, en donnant un environnement de test identique à celui du client qui signale un problème
Techniquement, il suffit d’un <iframe> pointant vers playground.wordpress.net avec les paramètres du blueprint encodés dans l’URL. Simple à mettre en place, et l’effet « wahou » fonctionne bien sur les visiteurs.
Automatiser les tests dans une CI avec Playground
Pour les workflows plus avancés, il existe le package npm @wp-playground/cli, qui permet de lancer une instance Playground directement en ligne de commande, sans passer par le navigateur. Pratique pour scripter des scénarios de test dans une pipeline CI.
Il y a aussi l’action GitHub officielle dédiée à Playground, qui simplifie l’intégration dans un workflow .github/workflows. On peut ainsi vérifier automatiquement, à chaque push, que le plugin s’installe et s’active correctement sur une version fraîche de WordPress.
Je mentionne aussi wp-now, un outil complémentaire qui lance un environnement WordPress local basé sur la même techno que Playground, mais en ligne de commande native (pas dans le navigateur). Combiné avec Playwright pour des tests end-to-end, on obtient une chaîne de test assez robuste : Playground (ou wp-now) démarre l’environnement, Playwright pilote le navigateur pour simuler les interactions utilisateur, et on valide le comportement réel du plugin. Ce n’est pas encore aussi mature que des solutions CI classiques avec MySQL complet, mais pour des tests fonctionnels rapides, ça fait clairement le job.