blueprint

WordPress Playground Blueprints

Overview

A Blueprint is a JSON file that declaratively configures a WordPress Playground instance — installing plugins/themes, setting options, running PHP/SQL, manipulating files, and more.

Core principle: Blueprints are trusted JSON-only declarations. No arbitrary JavaScript. They work on web, Node.js, and CLI.

Quick Start Template

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [{ "step": 

Top-Level Properties

All optional. Only documented keys are allowed — the schema rejects unknown properties.

preferredVersions Values

• php: Major.minor only (e.g. "8.3", "7.4"), or "latest". Patch versions like "7.4.1" are invalid. Check the schema for currently supported versions.
• wp: Recent major versions (e.g. "6.7", "6.8"), "latest", "nightly", "beta", or a URL to a custom zip. Check the schema for the full list.

Shorthands vs Steps

Shorthands (login, plugins, siteOptions, constants) are expanded and prepended to steps in an unspecified order. Use explicit steps when execution order matters.

Resource References

Resources tell Playground where to find files. Used by installPlugin, installTheme, writeFile, writeFiles, importWxr, etc.

git:directory — Installing from GitHub

• When using a branch or tag name for ref, you must set refType ("branch" | "tag" | "commit" | "refname"). Without it, only "HEAD" resolves reliably.
• path selects a subdirectory (defaults to repo root).

literal:directory — Inline File Trees

• files uses nested objects for subdirectories — keys are filenames or directory names, values are plain strings (file content) or objects (subdirectories). Never use resource references as values.
• Do NOT use path separators in keys (e.g. "includes/helper.php" is wrong — use a nested "includes": { "helper.php": "..." } object).

Steps Reference

Every step requires "step": "<name>". Any step can optionally include "progress": { "weight": 1, "caption": "Installing..." } for UI feedback.

Plugin & Theme Installation

• Use pluginData / themeData — NOT the deprecated pluginZipFile / themeZipFile.
• pluginData / themeData accept any FileReference or DirectoryReference — a zip URL, a wordpress.org/plugins slug, a git:directory, or a literal:directory (no zip wrapper needed).
• options.activate controls activation. No need for a separate activatePlugin/activateTheme step when using installPlugin/installTheme.
• ifAlreadyInstalled: "overwrite" | "skip" | "error"

Activation (standalone)

Only needed for plugins/themes already on disk (e.g. after writeFile/writeFiles):

File Operations

data accepts a plain string (as shown above) or a resource reference (e.g. { "resource": "url", "url": "https://..." }).

writeFiles requires a DirectoryReference (literal:directory or git:directory) as filesTree — not a plain object.

Other file operations: mkdir, cp, mv, rm, rmdir, unzip.

Running Code

runPHP:

GOTCHA: You must require '/wordpress/wp-load.php'; to use any WordPress functions.

wp-cli:

The step name is wp-cli (with hyphen), NOT cli or wpcli.

runSql:

Site Configuration

Other Steps

Common Patterns

Inline mu-plugin (quick custom code)

Inline plugin with multiple files

Then activate it with a separate step:

Plugin from a GitHub branch

Common Mistakes

Full Reference

This skill covers the most common steps and patterns. For the complete API, see:

• Blueprint docs: https://wordpress.github.io/wordpress-playground/blueprints
• JSON schema: https://playground.wordpress.net/blueprint-schema.json

Additional steps not covered above: runPHPWithOptions (run PHP with custom ini settings), runWpInstallationWizard, and resource types vfs and bundled (for advanced embedding scenarios).

Blueprint Bundles

Bundles are self-contained packages that include a blueprint.json along with all the resources it references (plugins, themes, WXR files, etc.). Instead of hosting assets externally, bundle them alongside the blueprint.

Bundle Structure

Plugins and themes must be zipped before bundling — installPlugin expects a zip, not a raw directory. To create the zip from a plugin directory:

Referencing Bundled Resources

Use the bundled resource type to reference files within the bundle:

Creating a Bundle Step by Step

1. Create the bundle directory and add blueprint.json at its root.
2. Write your plugin/theme source files in a subdirectory (e.g. my-plugin/my-plugin.php).
3. Zip the plugin directory: zip -r my-plugin.zip my-plugin/
4. Reference it in blueprint.json using { "resource": "bundled", "path": "/my-plugin.zip" }.

Full example — a bundle that installs a custom plugin:

Distribution Formats

GOTCHA: Local directory bundles always need --blueprint-may-read-adjacent-files for the CLI to read bundled resources. Without it, any "resource": "bundled" reference will fail with a "File not found" error. ZIP bundles don't need this flag — all files are self-contained inside the archive.

Testing Blueprints

Inline Blueprints (quick test, no bundles)

Minify the blueprint JSON (no extra whitespace), prepend https://playground.wordpress.net/#, and open the URL in a browser:

Very large blueprints may exceed browser URL length limits; use the CLI instead.

Local CLI Testing

Interactive server (keeps running, opens in browser):

Headless validation (runs blueprint and exits):

Testing with the wordpress-playground-server Skill

Use the wordpress-playground-server skill to start a local Playground instance with --blueprint /path/to/blueprint.json, then verify the expected state with Playwright MCP. For directory bundles, pass --blueprint-may-read-adjacent-files as an extra argument.