WordPress Playground

Quand l'utiliser

Créer un WordPress temporaire pour tester un plugin/thème sans installation complète.
Exécuter ou itérer sur des Blueprints Playground (JSON) localement.
Construire un snapshot reproductible d'un site pour le partager ou en CI.
Basculer rapidement entre versions WP/PHP pour reproduire des problèmes.
Déboguer du code plugin/thème avec Xdebug dans un Playground isolé.

Les instances Playground sont éphémères et basées sur SQLite ; ne pointez jamais vers des données de production.
Confirmez Node ≥ 20.18 (node -v) avant d'exécuter la CLI.
En cas de montage de code local, assurez-vous qu'il est exempt de secrets ; Playground copie les fichiers dans un système de fichiers en mémoire.

cd <plugin-or-theme-root>
npx @wp-playground/cli@latest server --auto-mount

S'ouvre sur http://localhost:9400 par défaut. Détecte automatiquement le plugin/thème et l'installe.
Ajoutez --wp=<version> / --php=<version> selon les besoins.
Pour les installations complètes classiques déjà présentes, ajoutez --skip-wordpress-setup et montez l'arborescence entière.

Utilisez --mount=/host/path:/vfs/path (répétable) quand auto-mount est insuffisant (multi-plugin, mu-plugins, contenu personnalisé).
Montez avant l'installation avec --mount-before-install pour les flux d'amorçage de l'installateur.
Référence : references/cli-commands.md

npx @wp-playground/cli@latest run-blueprint --blueprint=<file-or-url>

À utiliser pour la configuration scriptée/validation en CI. Supporte les URLs distantes et les fichiers locaux.
Autorisez les ressources regroupées dans les blueprints locaux avec --blueprint-may-read-adjacent-files si nécessaire.
Voir references/blueprints.md pour la structure et les drapeaux courants.

npx @wp-playground/cli@latest build-snapshot --blueprint=<file> --outfile=./site.zip

Produit un ZIP que vous pouvez charger dans Playground ou joindre aux rapports de bogue.

Démarrez avec --xdebug (ou --enable-xdebug selon la version de la CLI) pour exposer une clé IDE, puis connectez VS Code/PhpStorm au host/port affiché dans la sortie de la CLI.
Combinez avec --auto-mount pour le débogage plugin/thème.
Checklist : references/debugging.md

Utilisez --wp= pour épingler WP (ex. 6.9.0) et --php= pour tester la compatibilité.
Si la fonctionnalité dépend de la branche Gutenberg trunk, préférez la dernière version WP plus le plugin si disponible ; les images Playground suivent WP stable plus Gutenberg inclus.

Lancez des aperçus rapides avec des fragments URL ou des paramètres de requête :
- Fragment : https://playground.wordpress.net/#<base64-or-json-blueprint>
- Requête : https://playground.wordpress.net/?blueprint-url=<public-url-or-zip>
Utilisez l'éditeur Blueprint en direct (playground.wordpress.net) pour créer des blueprints avec aide au schéma ; collez le JSON et copiez un lien partageable.

Vérifiez que le code monté est actif (plugin listé/actif ; thème sélectionné).
Pour les blueprints/snapshots, relancez avec --verbosity=debug pour confirmer l'exécution des étapes.
Exécutez des tests critiques ciblés (ex. wp plugin list dans le shell Playground via terminal navigateur s'il est exposé) ou un parcours UI.

CLI quitte en se plaignant de Node : passez à ≥ 20.18.
Montage non appliqué : vérifiez le chemin, utilisez un chemin absolu, ajoutez --verbosity=debug.
Blueprint ne peut pas lire les ressources locales : ajoutez --blueprint-may-read-adjacent-files.
Port déjà utilisé : --port=<free-port>.
Interface lente/verrouillée : désactivez --experimental-multi-worker si activé ; ou activez-le pour améliorer le débit sur les exécutions gourmandes en CPU.

Si des extensions PHP ou un accès natif à la BD sont requis, Playground peut être inadéquat ; revenir à la pile WP complète ou wp-env/Docker.
Pour l'intégration basée sur le navigateur ou les spécificités des extensions VS Code, consultez la documentation en amont : https://wordpress.github.io/wordpress-playground/