blueprint

作者: wordpress

在创建、编辑或审查WordPress Playground蓝图JSON文件时使用。当提及蓝图、Playground配置或请求时触发…

npx skills add https://github.com/wordpress/agent-skills --skill 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": "login" }]
}

Top-Level Properties

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

PropertyTypeNotes
$schemastringAlways "https://playground.wordpress.net/blueprint-schema.json"
landingPagestringRelative path, e.g. /wp-admin/
descriptionstringDeprecated optional top-level description. Prefer meta.description for new Blueprints
metaobject{ title, author, description?, categories? } — title and author required
preferredVersionsobject{ php, wp } — both required when present
featuresobject{ networking?: boolean, intl?: boolean }only these two keys, nothing else. Networking defaults to true
phpExtensionBundlesanyDeprecated/no longer used; the schema leaves the value unconstrained and says to remove it from Blueprints
extraLibrariesarray["wp-cli"] — auto-included when any wp-cli step is present
constantsobjectShorthand for defineWpConfigConsts. Values: string/boolean/number
pluginsarrayShorthand for installPlugin steps. Strings = wp.org slugs
siteOptionsobjectShorthand for setSiteOptions
loginboolean or objecttrue = login as admin. Object = { username?, password? } (both default to "admin"/"password")
stepsarrayMain execution pipeline. Runs after shorthands

preferredVersions Values

  • php: Major.minor only: "7.4", "8.0", "8.1", "8.2", "8.3", "8.4", "8.5", or "latest". Patch versions like "7.4.1" are invalid. Check the schema for currently supported versions.
  • wp: Recent major versions, "latest", "beta", "nightly"/"trunk", or a URL to a custom zip. The schema also accepts false for PHP-only Playground; do not combine wp: false with WordPress-only fields such as plugins, siteOptions, login, or WordPress-only steps.

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.

Resource TypeRequired FieldsExample
wordpress.org/pluginsslug{ "resource": "wordpress.org/plugins", "slug": "woocommerce" }
wordpress.org/themesslug{ "resource": "wordpress.org/themes", "slug": "astra" }
urlurl{ "resource": "url", "url": "https://example.com/plugin.zip" }
git:directoryurl, refSee below
literalname, contents{ "resource": "literal", "name": "file.txt", "contents": "hello" }
literal:directoryname, filesSee below
bundledpathReferences a file within a blueprint bundle (e.g. { "resource": "bundled", "path": "/plugin.zip" })
zipinnerWraps another resource in a ZIP — use when a step expects a zip but your source isn't one (e.g. wrapping a url resource pointing to a raw directory)

git:directory — Installing from GitHub

{
  "resource": "git:directory",
  "url": "https://github.com/WordPress/gutenberg",
  "ref": "trunk",
  "refType": "branch",
  "path": "/"
}
  • 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

{
  "resource": "literal:directory",
  "name": "my-plugin",
  "files": {
    "plugin.php": "<?php /* Plugin Name: My Plugin */ ?>",
    "includes": {
      "helper.php": "<?php // helper code ?>"
    }
  }
}
  • 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

{
  "step": "installPlugin",
  "pluginData": { "resource": "wordpress.org/plugins", "slug": "gutenberg" },
  "options": { "activate": true, "targetFolderName": "gutenberg" },
  "ifAlreadyInstalled": "overwrite"
}
{
  "step": "installTheme",
  "themeData": { "resource": "wordpress.org/themes", "slug": "twentytwentyfour" },
  "options": { "activate": true, "importStarterContent": true },
  "ifAlreadyInstalled": "overwrite"
}
  • Use pluginData / themeDataNOT 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):

{ "step": "activatePlugin", "pluginPath": "my-plugin/my-plugin.php" }
{ "step": "activateTheme", "themeFolderName": "twentytwentyfour" }

File Operations

{ "step": "writeFile", "path": "/wordpress/wp-content/mu-plugins/custom.php", "data": "<?php // code" }

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

{
  "step": "writeFiles",
  "writeToPath": "/wordpress/wp-content/plugins/",
  "filesTree": {
    "resource": "literal:directory",
    "name": "my-plugin",
    "files": {
      "plugin.php": "<?php\n/*\nPlugin Name: My Plugin\n*/",
      "includes": {
        "helpers.php": "<?php // helpers"
      }
    }
  }
}

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:

{ "step": "runPHP", "code": "<?php require '/wordpress/wp-load.php'; update_option('key', 'value');" }

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

wp-cli:

{ "step": "wp-cli", "command": "wp post create --post_type=page --post_title='Hello' --post_status=publish" }

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

runSql:

{ "step": "runSql", "sql": { "resource": "literal", "name": "q.sql", "contents": "UPDATE wp_options SET option_value='val' WHERE option_name='key';" } }

Site Configuration

{ "step": "setSiteOptions", "options": { "blogname": "My Site", "blogdescription": "A tagline" } }
{ "step": "defineWpConfigConsts", "consts": { "WP_DEBUG": true } }
{ "step": "setSiteLanguage", "language": "en_US" }
{ "step": "defineSiteUrl", "siteUrl": "https://example.com" }

Other Steps

StepKey Properties
loginusername?, password? (default "admin" / "password")
enableMultisite(no required props)
importWxrfile (FileReference)
importThemeStarterContentthemeSlug?
importWordPressFileswordPressFilesZip, pathInZip? — imports a full WordPress directory from a zip
requestrequest: { url, method?, headers?, body? }
updateUserMetauserId, meta
runWpInstallationWizardoptions? — runs the WP install wizard with given options
resetData(no props)

Common Patterns

Inline mu-plugin (quick custom code)

{
  "step": "writeFile",
  "path": "/wordpress/wp-content/mu-plugins/custom.php",
  "data": "<?php\n// mu-plugins load automatically — no activation needed, no require wp-load.php\nadd_filter('show_admin_bar', '__return_false');"
}

Inline plugin with multiple files

{
  "step": "writeFiles",
  "writeToPath": "/wordpress/wp-content/plugins/",
  "filesTree": {
    "resource": "literal:directory",
    "name": "my-plugin",
    "files": {
      "my-plugin.php": "<?php\n/*\nPlugin Name: My Plugin\n*/\nrequire __DIR__ . '/includes/main.php';",
      "includes": {
        "main.php": "<?php // main logic"
      }
    }
  }
}

Then activate it with a separate step:

{ "step": "activatePlugin", "pluginPath": "my-plugin/my-plugin.php" }

Plugin from a GitHub branch

{
  "step": "installPlugin",
  "pluginData": {
    "resource": "git:directory",
    "url": "https://github.com/user/repo",
    "ref": "feature-branch",
    "refType": "branch",
    "path": "/"
  }
}

Common Mistakes

MistakeCorrect
pluginZipFile / themeZipFilepluginData / themeData
"step": "cli""step": "wp-cli"
Flat object as writeFiles.filesTreeMust be a literal:directory or git:directory resource
Path separators in files keysUse nested objects for subdirectories
runPHP without wp-load.phpAlways require '/wordpress/wp-load.php'; for WP functions
Invented top-level keysOnly documented keys work — schema rejects unknown properties
Inventing proxy URLs for GitHubUse git:directory resource type
Omitting refType with branch/tag refRequired — only "HEAD" works without it
Resource references in literal:directory files valuesValues must be plain strings (content) or objects (subdirectories) — never resource refs
features.debug or other invented feature keysfeatures only supports networking and intl — use constants: { "WP_DEBUG": true } for debug mode
require wp-load.php in mu-plugin codeOnly needed in runPHP steps — mu-plugins already run within WordPress
Schema URL with .org domainMust be playground.wordpress.net, not playground.wordpress.org

Full Reference

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

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

my-bundle/
├── blueprint.json          ← must be at the root
├── my-plugin.zip           ← zipped plugin directory
├── theme.zip
└── content/
    └── sample-content.wxr

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

cd my-bundle
zip -r my-plugin.zip my-plugin/

Referencing Bundled Resources

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

{
  "step": "installPlugin",
  "pluginData": {
    "resource": "bundled",
    "path": "/my-plugin.zip"
  },
  "options": { "activate": true }
}
{
  "step": "importWxr",
  "file": {
    "resource": "bundled",
    "path": "/content/sample-content.wxr"
  }
}

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:

dashboard-widget-bundle/
├── blueprint.json
├── dashboard-widget.zip        ← zip of dashboard-widget/
└── dashboard-widget/           ← plugin source (kept for editing)
    └── dashboard-widget.php
{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": { "php": "8.3", "wp": "latest" },
  "steps": [
    { "step": "login" },
    {
      "step": "installPlugin",
      "pluginData": { "resource": "bundled", "path": "/dashboard-widget.zip" },
      "options": { "activate": true }
    }
  ]
}

Distribution Formats

FormatHow to use
ZIP file (remote)Website: https://playground.wordpress.net/?blueprint-url=https://example.com/bundle.zip
ZIP file (local)CLI: npx @wp-playground/cli server --blueprint=./bundle.zip
Local directoryCLI: npx @wp-playground/cli server --blueprint=./my-bundle/ --blueprint-may-read-adjacent-files
Git repository directoryPoint blueprint-url at a repo directory containing blueprint.json

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), encode it once with encodeURIComponent(), prepend https://playground.wordpress.net/#, and open the URL in a browser:

https://playground.wordpress.net/#%7B%22%24schema%22%3A%22https%3A%2F%2Fplayground.wordpress.net%2Fblueprint-schema.json%22%2C%22preferredVersions%22%3A%7B%22php%22%3A%228.3%22%2C%22wp%22%3A%22latest%22%7D%2C%22steps%22%3A%5B%7B%22step%22%3A%22login%22%7D%5D%7D

Very large blueprints may exceed browser URL length limits; use the CLI or a hosted Blueprint URL instead. For share-link details, use wp-playground/references/website.md.

Local CLI Testing

Interactive server (keeps running, opens in browser):

# Directory bundle — requires --blueprint-may-read-adjacent-files
npx @wp-playground/cli server --blueprint=./my-bundle/ --blueprint-may-read-adjacent-files

# ZIP bundle — self-contained, no extra flags needed
npx @wp-playground/cli server --blueprint=./bundle.zip

Headless validation (runs blueprint and exits):

npx @wp-playground/cli run-blueprint --blueprint=./my-bundle/ --blueprint-may-read-adjacent-files

Testing with WordPress Playground

Use the wp-playground skill for local or browser testing. For CLI testing, follow wp-playground/references/cli.md with --blueprint=<path-or-url>; for directory bundles, pass --blueprint-may-read-adjacent-files.

来自 wordpress 的更多技能

wordpress-router
wordpress
对WordPress代码库进行分类,并根据插件、主题、区块及核心检出结果路由至正确的工作流程。运行自动化项目分类以识别仓库类型(插件、主题、区块主题、Gutenberg区块、WP核心)及可用工具。输出分类结果及基于用户意图和项目类型的决策树路由至领域特定技能。需要仓库根目录访问权限及bash/Node文件系统操作;部分工作流程需WP-CLI。目标环境为WordPress 6.9+及PHP 7.2.24+;...
official
wp-abilities-api
wordpress
WordPress Abilities API 注册、REST 暴露及客户端消费,适用于 WordPress 6.9+。使用 wp_register_ability() 和 wp_register_ability_category() 在 PHP 中注册能力和类别,包含稳定 ID、标签和元数据。通过设置 meta.show_in_rest: true,将能力暴露给客户端,使用 /wp-json/wp-abilities/v1/ REST 端点。在 JavaScript 中使用 @wordpress/abilities 包消费能力,实现客户端访问和权限检查。需要 WordPress 6.9+...
official
wp-abilities-audit
wordpress
审计WordPress插件的REST接口面,并生成一份标准化的审计文档,提出Abilities API注册建议。生成一份包含YAML……的markdown文档。
official
wp-abilities-verify
wordpress
验证WordPress插件的Abilities API注册:枚举能力,检查回调行为是否与每个注解的声明相符(对抗性…
official
wp-block-development
wordpress
WordPress区块开发(针对Gutenberg):元数据、注册、渲染及构建工作流。涵盖区块创建、block.json配置、静态与动态渲染,以及使用register_block_type_from_metadata()进行服务端PHP注册。强制使用apiVersion: 3以确保与WordPress 6.9+兼容,包括iframe编辑器支持和样式隔离。处理属性序列化、弃用/迁移以避免"无效区块"错误,以及内部区块组合。包括...
official
wp-block-themes
wordpress
WordPress区块主题开发:theme.json、模板、样式块及站点编辑器故障排查。涵盖theme.json编辑(预设、设置、逐块样式)、模板与模板部件、样式块及WordPress 6.9+版本中的样式变体。包含用于检测主题根目录和区块主题结构的分类脚本,以及创建新主题或转换经典主题的引导流程。提供样式层级问题、用户自定义覆盖及站点编辑器调试的工作流程。
official
wp-interactivity-api
wordpress
在构建或调试WordPress Interactivity API功能时使用(data-wp-*指令、@wordpress/interactivity存储/状态/动作、块viewScriptModule…)
official
wp-patterns
wordpress
生成技术上正确、设计上独具特色的WordPress块模式。用于创建块模式、起始页面模式、模板模式、模板……
official