Wp Playground
Spin up disposable WordPress instances in the browser or via CLI to test plugins and themes without a local LAMP stack.
Overview
wp-playground is an agent skill most often used in Validate (also Build integrations, Ship testing) that spins up disposable WordPress instances via Playground CLI or browser to test plugins, themes, blueprints, and Xdeb
Install
npx skills add https://github.com/wordpress/agent-skills --skill wp-playgroundWhat is this skill?
- Disposable WordPress via browser or `npx @wp-playground/cli` with auto-mount for plugin/theme roots
- Run and iterate Playground Blueprints (JSON) and build reproducible snapshots for sharing or CI
- Switch WordPress and PHP versions quickly to reproduce compatibility issues
- Optional Xdebug in an isolated Playground for plugin/theme debugging
- Explicit guardrails: ephemeral SQLite-backed instances—never production data
- Targets WordPress 6.9+ with PHP 7.2.24+ compatibility
- Playground CLI requires Node.js 20.18+
- Default local server port 9400 (configurable when conflicts occur)
Adoption & trust: 1.4k installs on skills.sh; 1.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to exercise WordPress plugin or theme behavior across WP/PHP versions but do not want to maintain local LAMP, Docker, or staging databases.
Who is it for?
WordPress plugin/theme authors and indie builders validating compatibility, blueprints, and debug sessions in minutes.
Skip if: Teams that need persistent MySQL-backed staging, production migrations, or hosting that must mirror live traffic and backups.
When should I use this skill?
Spin up disposable WordPress, run blueprints, build snapshots, switch WP/PHP versions, or debug with Xdebug in Playground.
What do I get? / Deliverables
You get a mounted, version-pinned Playground instance with optional blueprint or snapshot workflow and a clear ephemeral-data boundary before you commit to real hosting or CI pipelines.
- Running Playground instance with mounted codebase
- Executed blueprint or snapshot artifact when requested
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the primary job is fast disposable prototypes before committing to full build or production deploy. Prototype subphase matches throwaway WP runs, version matrix repro, and blueprint iteration—not shipping a durable environment.
Where it fits
Auto-mount a plugin repo and click through admin flows before writing deployment docs.
Iterate on a Playground blueprint JSON that installs your theme and demo content for contributors.
Pin WP 6.8 vs 6.9 and PHP 8.2 vs 8.3 to confirm a regression fix before release.
How it compares
Use instead of full Docker WordPress stacks when you only need short-lived WASM/SQLite sandboxes for reproduction and demos.
Common Questions / FAQ
Who is wp-playground for?
Solo and indie WordPress developers who test plugins, themes, or blueprints in disposable environments without provisioning servers.
When should I use wp-playground?
During Validate when prototyping a plugin or theme; during Build when wiring Playground into local dev; during Ship when reproducing version-specific bugs or building CI snapshots—always on non-production code paths.
Is wp-playground safe to install?
Review the Security Audits panel on this Prism page before installing; the skill itself stresses never pointing Playground at production data and mounting only secret-free project trees.
SKILL.md
READMESKILL.md - Wp Playground
# WordPress Playground ## When to use - Spin up a disposable WordPress to test a plugin/theme without full stack setup. - Run or iterate on Playground Blueprints (JSON) locally. - Build a reproducible snapshot of a site for sharing or CI. - Switch WP/PHP versions quickly to reproduce issues. - Debug plugin/theme code with Xdebug in an isolated Playground. ## Inputs required - Host machine readiness: Node.js ≥ 20.18, `npm`/`npx` available. - Project path to mount (`--auto-mount` or explicit mount mapping). - Desired WP version/PHP version (optional; defaults to latest WP, PHP 8.3). - Blueprint location/URL if running a blueprint. - Port preference if 9400 conflicts. - Whether Xdebug is needed. ## Procedure ### 0) Guardrails - Playground instances are ephemeral and SQLite-backed; **never** point at production data. - Confirm Node ≥ 20.18 (`node -v`) before running CLI. - If mounting local code, ensure it is clean of secrets; Playground copies files into an in-memory FS. ### 1) Quick local spin-up (auto-mount) ```bash cd <plugin-or-theme-root> npx @wp-playground/cli@latest server --auto-mount ``` - Opens on http://localhost:9400 by default. Auto-detects plugin/theme and installs it. - Add `--wp=<version>` / `--php=<version>` as needed. - For classic full installs already present, add `--skip-wordpress-setup` and mount the whole tree. ### 2) Manual mounts or multiple mounts - Use `--mount=/host/path:/vfs/path` (repeatable) when auto-mount is insufficient (multi-plugin, mu-plugins, custom content). - Mount before install with `--mount-before-install` for bootstrapping installer flows. - Reference: `references/cli-commands.md` ### 3) Run a Blueprint (no server needed) ```bash npx @wp-playground/cli@latest run-blueprint --blueprint=<file-or-url> ``` - Use for scripted setup/CI validation. Supports remote URLs and local files. - Allow bundled assets in local blueprints with `--blueprint-may-read-adjacent-files` when required. - See `references/blueprints.md` for structure and common flags. ### 4) Build a snapshot for sharing ```bash npx @wp-playground/cli@latest build-snapshot --blueprint=<file> --outfile=./site.zip ``` - Produces a ZIP you can load in Playground or attach to bug reports. ### 5) Debugging with Xdebug - Start with `--xdebug` (or `--enable-xdebug` depending on CLI release) to expose an IDE key, then connect VS Code/PhpStorm to the host/port shown in CLI output. - Combine with `--auto-mount` for plugin/theme debugging. - Checklist: `references/debugging.md` ### 6) Version switching - Use `--wp=` to pin WP (e.g., 6.9.0) and `--php=` to test compatibility. - If feature depends on Gutenberg trunk, prefer the latest WP release plus plugin if available; Playground images track stable WP plus bundled Gutenberg. ### 7) Browser-only workflows (no CLI) - Launch quick previews with URL fragments or query params: - Fragment: `https://playground.wordpress.net/#<base64-or-json-blueprint>` - Query: `https://playground.wordpress.net/?blueprint-url=<public-url-or-zip>` - Use the live Blueprint Editor (playground.wordpress.net) to author blueprints with schema help; paste JSON and copy a shareable link. ## Verification - Verify mounted code is active (plugin listed/active; theme selected). - For blueprints/snapshots, re-run with `--verbosity=debug` to confirm steps executed. - Run targeted smoke (e.g., `wp plugin list` inside Playground shell via browser terminal if exposed) or UI click-path. ## Failure modes / debugging - **CLI exits complaining about Node**: upgrade to ≥ 20.18. - **Mount