Blueprint data format

---

• JSON schema
• Landing page
• Preferred versions
• Features
• Extra libraries
• Steps
• Common property placement mistakes
• Activate a plugin or theme
• Install plugins with the shorthand
• Use one plugin install shape
• Keep preferredVersions limited to versions
• Use explicit steps when order matters

---

A Blueprint JSON file can have many different properties that will be used to define your Playground instance. The most important properties are detailed below.

Here’s an example that uses many of them:

{
    "landingPage": "/wp-admin/",
    "preferredVersions": {
        "php": "8.3",
        "wp": "6.5"
    },
    "features": {
        "networking": true
    },
    "steps": [
        {
            "step": "login",
            "username": "admin",
            "password": "password"
        }
    ]
}

Try it out!

JSON schema

JSON files can be tedious to write and easy to get wrong. To help with that, Playground provides a JSON schema file that you can use to get auto-completion and validation in your editor. Just set the $schema property to the following:

{
    "$schema": "https://playground.wordpress.net/blueprint-schema.json",
}

Landing page

The landingPage property tells Playground which URL to navigate to after the Blueprint has been run. This is a great tool, especially when creating theme or plugin demos. Often, you will want to start Playground in the Site Editor or have a specific post open in the Post Editor. Make sure you use a relative path.

{
    "landingPage": "/wp-admin/site-editor.php",
}

Preferred versions

The preferredVersions property declares your preferred PHP and WordPress versions. It can contain the following properties:

• php (string): Loads the specified PHP version. Accepts 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, latest, or next. Minor versions like 7.4.1 are not supported. Use next to preview the next PHP version from the php-src development branch; it is currently supported by the web runtime only.
• wp (string): Loads the specified WordPress version. Accepts the last seven major WordPress versions. As of April 28, 2026, that’s 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, or 6.9. You can also use the generic values latest, beta, or nightly (alias trunk). beta resolves to the most recent Beta or Release Candidate of an active release cycle; nightly/trunk builds straight from the WordPress development branch.

{
    "preferredVersions": {
        "php": "8.3",
        "wp": "6.7"
    },
}

Features

You can use the features property to turn on or off certain features of the Playground instance. It can contain the following properties:

• networking: Defaults to true. Enables or disables the networking support for Playground. If enabled, wp_safe_remote_get and similar WordPress functions will actually use fetch() to make HTTP requests. If disabled, they will immediately fail instead. You will need this property enabled if you want the user to be able to install plugins or themes.

{
    "features": {
        "networking": false
    },
}

Extra libraries

You can preload extra libraries into the Playground instance. The following libraries are supported:

• wp-cli: Enables WP-CLI support for Playground. If included, WP-CLI will be installed during boot. If not included, you will get an error message when trying to run WP-CLI commands using the JS API. WP-CLI will be installed by default if the blueprint contains any wp-cli steps.

{
    "extraLibraries": [ "wp-cli" ],
}

Steps

Arguably the most powerful property, steps allows you to configure the Playground instance with preinstalled themes, plugins, demo content, and more. The following example logs the user in with a dedicated username and password. It then installs and activates the Gutenberg plugin. Learn more about steps.

{
    "steps": [
        {
            "step": "login",
            "username": "admin",
            "password": "password"
        },
        {
            "step": "installPlugin",
            "pluginData": {
                "resource": "wordpress.org/plugins",
                "slug": "gutenberg"
            }
        },
    ]
}

Common property placement mistakes

Blueprint validation errors often come from putting a valid property in the
wrong object.

Activate a plugin or theme

activate belongs inside options, not inside pluginData, themeData, or
directly on the step.

{
    "step": "installPlugin",
    "pluginData": {
        "resource": "wordpress.org/plugins",
        "slug": "gutenberg"
    },
    "options": {
        "activate": true
    }
}

Install plugins with the shorthand

The plugins shorthand is a top-level Blueprint property. Do not put it inside
preferredVersions.

{
    "preferredVersions": {
        "php": "8.3",
        "wp": "latest"
    },
    "plugins": ["gutenberg"]
}

Use one plugin install shape

For an installPlugin step, use pluginData. Do not mix pluginData with
older examples or custom objects such as pluginZipFile.

{
    "step": "installPlugin",
    "pluginData": {
        "resource": "wordpress.org/plugins",
        "slug": "woocommerce"
    },
    "options": {
        "activate": true
    }
}

The wordpress.org/plugins resource needs a separate slug. Do not write the
slug into the resource value, such as "wordpress.org/plugins/woocommerce".

Keep preferredVersions limited to versions

preferredVersions only accepts php and wp. Use features for networking,
plugins or installPlugin for plugins, and steps for ordered setup tasks.

Use explicit steps when order matters

Shorthands such as plugins, login, siteOptions, and constants are
expanded before the steps array. If one action must happen before another,
write both actions as explicit steps in the order you need.