PluginBench
Skill
Official
Review
Audit score 70

wp-playground

wordpress/agent-skills

Spin up fast, disposable WordPress instances locally or in-browser for testing, debugging, and CI workflows.

What is wp-playground?

WordPress Playground lets you create isolated, ephemeral WordPress environments using WebAssembly and SQLite. Use it to test plugins/themes, run blueprints, switch WP/PHP versions, and debug with Xdebug—all without a full stack setup.

  • Spin up disposable WordPress instances in seconds with auto-mount of plugins/themes
  • Run or iterate on Playground Blueprints (JSON configuration) locally or via URL
  • Build reproducible snapshots for sharing, CI, or bug reports
  • Switch WordPress and PHP versions instantly to test compatibility
  • Debug plugin/theme code with Xdebug in an isolated environment
  • Mount multiple plugins, themes, or custom code paths for complex testing

How to install wp-playground

npx skills add https://github.com/wordpress/agent-skills --skill wp-playground
Prerequisites
  • Node.js ≥ 20.18
  • npm or npx available
  • Project path to mount (plugin, theme, or WordPress root)
Claude Code
Cursor
Windsurf
Cline

How to use wp-playground

  1. 1.Install @wp-playground/cli via npx (no separate install needed)
  2. 2.Navigate to your plugin/theme directory and run: npx @wp-playground/cli@latest server --auto-mount
  3. 3.Access the instance at http://localhost:9400 (or specified port)
  4. 4.For blueprints, run: npx @wp-playground/cli@latest run-blueprint --blueprint=<file-or-url>
  5. 5.To build a shareable snapshot: npx @wp-playground/cli@latest build-snapshot --blueprint=<file> --outfile=./site.zip
  6. 6.For debugging, add --xdebug flag and connect your IDE to the exposed port

Use cases

Good for
  • Test a plugin or theme without setting up a full WordPress stack
  • Reproduce issues across different WordPress/PHP version combinations
  • Validate a Blueprint-based site setup in CI/CD pipelines
  • Share a reproducible WordPress state with team members via snapshot ZIP
  • Debug plugin code with Xdebug while iterating locally
Who it's for
  • Plugin and theme developers
  • WordPress core contributors
  • QA engineers validating WordPress configurations
  • DevOps/CI engineers automating WordPress testing

wp-playground FAQ

Can I use Playground with production data?

No. Playground instances are ephemeral and SQLite-backed. Never point at production data; they are for testing only.

What if my plugin requires a specific PHP extension or native database?

Playground may be unsuitable for those cases. Fall back to a full WordPress stack, wp-env, or Docker.

How do I test multiple plugins at once?

Use repeatable --mount flags to mount multiple plugin/theme directories, or use --mount-before-install for bootstrapping flows.

Can I share a Playground state with teammates?

Yes. Use build-snapshot to create a ZIP file that can be loaded in Playground or attached to bug reports.

Does Playground work in the browser without CLI?

Yes. Use playground.wordpress.net with URL fragments or query parameters, or the live Blueprint Editor to author and share blueprints.

Full instructions (SKILL.md)

Source of truth, from wordpress/agent-skills.


name: wp-playground description: "Use for WordPress Playground workflows: fast disposable WP instances in the browser or locally via @wp-playground/cli (server, run-blueprint, build-snapshot), auto-mounting plugins/themes, switching WP/PHP versions, blueprints, and debugging (Xdebug)." compatibility: "Targets WordPress 6.9+ (PHP 7.2.24+). Playground CLI requires Node.js 20.18+; runs WP in WebAssembly with SQLite."

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)

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)

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

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 not applied: check path, use absolute path, add --verbosity=debug.
  • Blueprint cannot read local assets: add --blueprint-may-read-adjacent-files.
  • Port already used: --port=<free-port>.
  • Slow/locked UI: disable --experimental-multi-worker if enabled; or enable it to improve throughput on CPU-bound runs.

Escalation

  • If PHP extensions or native DB access are required, Playground may be unsuitable; fall back to full WP stack or wp-env/Docker.
  • For browser-only embedding or VS Code extension specifics, consult the upstream docs: https://wordpress.github.io/wordpress-playground/