Base URL patterns

There are two primary URL patterns for payment links.

New purchase (unified checkout):

https://wordpress.com/checkout/unified/{product_slugs}

The unified checkout flow handles account creation and site creation automatically. If the user is logged out, they’ll be prompted to log in or create an account. If no site exists, one is created as part of the purchase flow.

Renewal:

https://wordpress.com/checkout/renew/{subscription_id}

Existing Site:

https://wordpress.com/checkout/{site_domain}/{product_slugs}

Product slug format

The {product_slugs} portion of the URL accepts one or more Store product slugs. Multiple products are separated by commas.

https://wordpress.com/checkout/unified/personal
https://wordpress.com/checkout/unified/premium,domain_reg:example.com

Some products require additional metadata, appended with a colon separator:

{product_slug}:{meta}

For example, domain registrations require the domain name as meta:

dotlive_domain:example.live
domain_reg:example.com

Products that support a quantity use the :-q-{quantity} suffix:

ak_personal_yearly:-q-20
wp_google_workspace_business_starter_yearly:example.com:-q-12

These can be combined. A product with both meta and quantity looks like:

{product_slug}:{meta}:-q-{quantity}

Renewal URLs

To renew an existing subscription, use the subscription ID (the Store subscription ID, not the purchase ID visible in the UI):

https://wordpress.com/checkout/renew/1234

No site slug or product details are needed. The system resolves everything from the subscription ID.

WordPress.com plans

Each plan has a product_slug (the internal Store identifier) and a path_slug (the URL-friendly alias used in checkout URLs). Either can be used in the checkout URL, but path_slug values are preferred for readability.

Current plans

Domain products

Domain product slugs follow the pattern dot{tld}_domain where {tld} is the TLD with dots removed. For example:

There are also generic domain operations:

Email products

Example:

https://wordpress.com/checkout/unified/wp_google_workspace_business_starter_yearly:example.com:-q-5

Jetpack products

Jetpack products use their own slug namespace. Common products include:

Jetpack plans

Jetpack standalone products

Jetpack AI

Jetpack AI uses the quantity suffix to set the tier:

Jetpack Stats

Jetpack Stats uses quantity to set the page views tier:

Akismet products

Akismet products also support the :-q- quantity suffix for volume pricing.

Example URLs

Buy the Personal plan (yearly):

https://wordpress.com/checkout/unified/personal

Buy Premium with a .com domain:

https://wordpress.com/checkout/unified/premium,dotcom_domain:myblog.com

Buy Business with a domain registration and Google Workspace (5 seats):

https://wordpress.com/checkout/unified/business,domain_reg:mybusiness.com,wp_google_workspace_business_starter_yearly:mybusiness.com:-q-5

Renew subscription #98765:

https://wordpress.com/checkout/renew/98765

Buy Jetpack AI (yearly, 500 tier) for an existing site:

https://wordpress.com/checkout/mysite.wordpress.com/jetpack_ai_yearly:-q-500

Notes for API and agent implementors

1. Use path_slug values for plans. They’re shorter and more readable. Both personal and personal-bundle resolve to the same product, but personal is preferred in URLs.
2. Unified checkout creates accounts and sites. The /checkout/unified/ path handles logged-out users. If the user has no site, one is created during checkout.
3. Site-specific checkout works. For purchases tied to an existing site, use the pattern: https://wordpress.com/checkout/{site_slug}/{product_slugs}. The site slug is either example.wordpress.com or a custom domain.
4. Comma-separate multiple products. Each product in the URL is separated by a comma, not a slash or ampersand.
5. Domain meta is required. Domain products (registrations, mappings, transfers) must include the domain name after a colon. Without it, checkout will fail.
6. Quantity is optional. The :-q-{n} suffix only applies to products that support volume pricing or tiered quantities (Jetpack AI, Jetpack Stats, Google Workspace, Akismet).
7. Renewal URLs are self-contained. Pass only the subscription ID. The system resolves the product, site, and billing details.
8. Post-checkout behavior. After a successful purchase on unified checkout, logged-in users are redirected to their newly created or existing site. Logged-out users who log in during checkout are returned to checkout with their cart preserved.

Source references

Product slug constants are defined in the @automattic/calypso-products package in wp-calypso:

• packages/calypso-products/src/constants/wpcom.ts (WordPress.com plans)
• packages/calypso-products/src/constants/jetpack.ts (Jetpack products)
• packages/calypso-products/src/constants/akismet.ts (Akismet products)
• packages/calypso-products/src/constants/google.ts (Google Workspace)

Checkout URL documentation: client/my-sites/checkout/README.md

They standardize how an AI agent is instructed to perform common WordPress workflows, so you don’t have to re-explain context every time (e.g., how to approach UI design, static analysis, caching, and database optimization, etc.).

They aim to make agents:

• Safer, because they bake in best practices and guardrails
• More consistent and accounts for repeatable workflows
• Faster to onboard, as agents get immediate context

How they’re installed

Agent Skills are pulled into your agent’s environment in one of two ways:

1. Project-local install: Skills live inside your project directory, so everyone on the project can use the same behaviors.
2. Global install: Skills live in the user’s coding agent configuration directory, so they apply across all projects.

In both cases, the coding agent reads the skills from disk and incorporates them into its operating instructions.

Because skills are content files, the safest update model is:

• Treat skills as versioned assets
• Periodically pull updates
• Review diffs before rolling them out broadly (especially for team-wide/shared setups)

What WordPress Agent Skills are available?

The list of available Agent Skills may change, so be sure to visit the public repo for the most up-to-date information.

There are skills for many WordPress fundamentals, including:

• Block development
• Plugin development
• REST API
• WordPress Playground
• Performance
• Interactivity API
• Design

Installation options

There are a few ways to integrate agent-skills, depending on your environment and how you prefer to manage dependencies.

Option 1: skills.sh

If you want a quick install without cloning and building the repo manually, use skills.sh, an installation helper that makes it easy to add agent skill files into your local environment.

Prerequisite: Node.js (so you can run npx commands)

1. Choose the skills you want to install. You can also run npx skills add https://github.com/WordPress/agent-skills --list to view the names of all available skills.
2. Install skills. For example, the following would install wordpress-router, wp-project-triage, wp-block-development, wp-block-themes, and wp-plugin-development for Claude Code:

npx skills add https://github.com/WordPress/agent-skills \
  --agent claude-code \
  --skill wordpress-router \
  --skill wp-project-triage \
  --skill wp-block-development \
  --skill wp-block-themes \
  --skill wp-plugin-development

To target a different agent, swap --agent claude-code for your agent (for example, --agent cursor). You can also install to multiple agents by passing multiple --agent arguments.

During installation, you’ll be asked whether to install the skills globally or per project. Install skills globally by default by using the --global argument

To remove a skill, run npx skills remove wp-block-themes, swapping wp-block-themes for the skill you wish to remove.

To check for updates, run npx skills check and then npx skills update to update.

When removing skills or running updates, use the same scope as when you installed them. Global installs (--global) affects your machine-wide skills, while project installs affect the skills checked stored alongside that codebase.

Option 2:

If you need full control, or you’re contributing to the skills themselves, clone the skills repo and follow the manual build/install steps.

Choosing skills: “all” vs “relevant” skills

You may not need all of the available Agent Skills for your project. Instead, you can add skills based on what you’re working on. For example:

• Blocks / Gutenberg development: wp-block-development and wp-interactivity-api
• Block themes/site editing: wp-block-themes and wpds
• Plugin development: wp-plugin-development and wp-abilities-api

Install all skills when you’re:

• Doing broad refactors across multiple areas (blocks + themes + plugins), or
• Building platform tooling where you want maximum coverage.

This feature is available on sites with the Business plan or higher and is configured from the new Multi-site dashboard under the Settings tab:

Under the Cron tab, you can add a command to run and see the list of scheduled jobs:

What are Server Cron Jobs?

A server cron job is a scheduled task that runs automatically at defined intervals.

You can use server cron jobs for recurring maintenance or automation tasks. For example:

• Clearing cache: wp cache flush
• Removing spam comments: wp comment delete $(wp comment list --status=spam --format=ids)

These commands run in the server environment and are not affected by how much traffic your site receives.

Scheduling Server Cron Jobs

You can schedule server cron jobs to run:

• Hourly
• Daily
• Twice daily
• Weekly

To prevent system overload, the exact execution time is randomized within the selected interval. For example, if you choose once per hour, the job may run at any point during that hour.

Command format and supported syntax

Server Cron Jobs run the command you enter in a shell environment on your site’s server.

• WP-CLI commands are supported (for example, commands starting with wp).
• Shell features such as output redirection (>, >>) and combining output/error (2>&1) are also supported.
• If you use shell features like pipes (|) or command substitution ($(...)), confirm the command works when run manually first.
  

Examples:

Run a WP-CLI command:

wp cache flush

Run a command that uses shell output redirection:

echo "Cron ran at $(date)" > /srv/htdocs/wp-content/cron-test.txt

Write both output and errors to a log file:

wp cache flush >> /srv/htdocs/wp-content/cron-debug.log 2>&1

Note: Traditional cron schedule expressions (for example, */5 * * * *) are not currently supported in the scheduling UI.

Viewing command output and debugging

There is currently no built-in execution log available in the dashboard.

If you need to confirm that a command is running or view its output, you can use shell output redirection to write results to a file on your site.

Basic test

The following command creates a file in wp-content each time the cron job runs:

echo "Cron ran at $(date)" > /srv/htdocs/wp-content/cron-test.txt

If successful, cron-test.tx will appear in your wp-content directory.

You can access this file using SFTP.

Capturing output and errors

To record both standard output and errors to a log file, you can use:

command >> /srv/htdocs/wp-content/cron-debug.log 2>&1

Replace command with your actual command. For example:

mysqldump database >> /srv/htdocs/wp-content/cron-debug.log 2>&1

This appends all output to cron-debug.log, which you can download via SFTP for troubleshooting.

Relationship between WP-Cron and Server Cron Jobs

WP-Cron continues to handle WordPress-level scheduled tasks such as publishing posts and running plugin background processes.

Server Cron Jobs operate separately and run directly on the server. They are suitable for tasks that require consistent execution regardless of site traffic.

On WordPress.com, WP‑Cron is the scheduling system that runs these tasks. Server-side cron is not available, so you cannot configure a traditional system crontab or replace WP‑Cron with one.

How WP‑Cron runs

WP‑Cron is request-triggered. Scheduled events run when WordPress receives a request and detects an event is due. On low-traffic sites, scheduled events can run later than their scheduled time because there are fewer requests to trigger WP‑Cron.

Managing WP‑Cron events

If you need more visibility or control over scheduled events from within WordPress, you can use a plugin such as WP Crontrol.

Tools like this can help you view, run, and create your own WP‑Cron events in the WordPress admin. They still operate within WP‑Cron and do not provide server-side cron access.

Triggering WP‑Cron more consistently

If you need WP‑Cron to run more consistently, you can use an external monitoring service such as Jetpack or Uptime Robot that periodically requests your site. This increases the frequency of requests that trigger WP‑Cron and improves reliability.

This guide focuses on the WordPress.com-specific pieces: how to authenticate and which MCP endpoint to call. For general guidance on building an MCP client, see the official MCP client documentation.

Overview

WordPress.com exposes an MCP server over HTTPS and protects it with OAuth 2.1 using:

• Dynamic Client Registration: This allows you to register clients programmatically.
• Authorization Code flow with PKCE: Proof Key for Code Exchange (PKCE) is recommended for public clients like desktop and CLI applications.

The flow looks like this:

1. Register your client with WordPress.com to obtain a client_id
2. Send the user through the OAuth authorization step (with PKCE)
3. Exchange the authorization code for an access_token
4. Call the WordPress.com MCP endpoint with Authorization: Bearer …

WordPress.com endpoints

All endpoints below are hosted on:

• Base URL: https://public-api.wordpress.com

OAuth 2.1

• Register client: POST /oauth2-1/register
• Authorize: GET /oauth2-1/authorize
• Token: POST /oauth2-1/token

MCP

• WordPress.com MCP server: POST /wpcom/v2/mcp/v1

Step 1: Register your OAuth client

WordPress.com supports dynamic client registration, which means your MCP client can register itself without a separate manual setup step.

Request

• POST https://public-api.wordpress.com/oauth2-1/register  
• Content-Type: application/json

Example:

curl -X POST "https://public-api.wordpress.com/oauth2-1/register" \
  -H "Content-Type: application/json" \
  --data '{
    "client_name": "My MCP Client",
    "redirect_uris": ["http://localhost:8080/callback"],
    "grant_types": ["authorization_code", "refresh_token"]
  }'

What you get back

The response includes a client_id and other metadata. WordPress.com is designed to support public clients, and registration responses typically indicate:

• token_endpoint_auth_method: "none"

That is, token requests do not require a client secret. PKCE provides the security for the authorization code exchange.

At a minimum, store the client_id you receive during registration and ensure you consistently use one of the exact redirect_uri values you registered. You can optionally keep the rest of the registration response (for example, timestamps or the registration client URI) if it helps with troubleshooting or inspecting client configuration later.

Step 2: Send the user through authorization

To authenticate a user, your client will:

1. Generate a PKCE code_verifier
2. Derive a code_challenge using the S256 method
3. Open (or redirect) the user to WordPress.com’s authorization page

Authorize request

• GET https://public-api.wordpress.com/oauth2-1/authorize

Example:

https://public-api.wordpress.com/oauth2-1/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=http://localhost:8080/callback&
  code_challenge=YOUR_CODE_CHALLENGE&
  code_challenge_method=S256&
  scope=auth

After the user approves access, WordPress.com redirects the browser back to your redirect_uri with a code query parameter. Your redirect_uri must exactly match one of the URIs you registered.

Step 3: Exchange the authorization code for tokens

Once your client receives the authorization code, exchange it for an access token at the token endpoint.

Token request

• POST https://public-api.wordpress.com/oauth2-1/token  
• Content-Type: application/x-www-form-urlencoded

Example: 

curl -X POST "https://public-api.wordpress.com/oauth2-1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=http://localhost:8080/callback&code_verifier=YOUR_CODE_VERIFIER&client_id=YOUR_CLIENT_ID"

Result

The token endpoint returns an OAuth response containing an access_token and may also include fields like expires_in and a refresh_token.

Use the access_token to authenticate calls to the WordPress.com MCP endpoint via Authorization: Bearer YOUR_ACCESS_TOKEN.

Step 4: Call the WordPress.com MCP server

WordPress.com’s MCP server is accessed over HTTP by POSTing MCP requests to the MCP endpoint, authenticated with your OAuth access token.

MCP request

• POST https://public-api.wordpress.com/wpcom/v2/mcp/v1  

Headers:

• Authorization: Bearer YOUR_ACCESS_TOKEN
• Content-Type: application/json

Example:

{
  "method": "tools/call",
  "params": {
    "name": "wpcom-mcp-posts-search",
    "arguments": {
      "wpcom_site": "yoursite.wordpress.com",
      "search": "recent updates"
    }
  }
}

In this example, your client is asking WordPress.com’s MCP server to run the tool named wpcom-mcp-posts-search with the given arguments.

Implementation notes

• PKCE is required for public clients. Don’t embed secrets in distributed apps.
• All MCP calls must include Authorization: Bearer … with a valid WordPress.com access token.
• Redirect URIs must match registration. If you use http://localhost during development, register that exact callback URL.

Enabling Xdebug

1. Select the site you want to debug.
2. Navigate to the Settings tab.
3. Click “Edit site.”
4. Check the “Enable Xdebug” checkbox.
5. Click Save.

The site will restart automatically with Xdebug enabled.

Important limitations

• Only one site at a time: Xdebug can only be enabled for a single site at once. To enable it for a different site, you must first disable it on the current site.
• Performance impact: Xdebug may slow down site performance. Disable it when not actively debugging.

Using Xdebug with your IDE

Once Xdebug is enabled for a site, you can connect your IDE (code editor) to debug WordPress plugins, themes, and core code.

Visual Studio Code setup

1. Install the PHP Debug extension.
2. Create a .vscode/launch.json file in your project with the following configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/wordpress": "${workspaceFolder}"
      }
    }
  ]
}

3. Set breakpoints in your code.
4. Start the debugging session in Visual Studio Code (Run → Start Debugging).
5. Navigate to your site in the browser to trigger the breakpoints.

PhpStorm Setup

1. Go to Settings → PHP → Debug.
2. Verify that the Xdebug port is set to 9003.
3. To stop breaking at the first line:
   • Disable “Force break at first line when no path mapping specified”
   • Disable “Force break at first line when a script is outside the project”
4. Navigate to Settings -> PHP → Servers and configure mapping for your site’s server:
   • Host: localhost:8884
   • Port: 80
   • File directory: /Users/USERNAME/Studio/SITEDIR
   • Absolute path on the server: /wordpress
5. Enable “Start listening for PHP Debug Connections” from the toolbar.
6. Set breakpoints in your code.
7. Navigate to your site in the browser to trigger the breakpoints.

Learn more

For additional information about Xdebug integration, see the WordPress Playground Xdebug documentation.

You can embed Open in WordPress Studio buttons and links anywhere you share your work: GitHub repositories, plugin or theme listings, documentation, YouTube descriptions, and more. It’s a quick way to help users start working in Studio with your recommended setup.

Here’s an example that creates a new site in Studio with a Blueprint built for WordPress plugin and theme development.

Generate your own

Use this tool to build your own Open in WordPress Studio button or link. Paste any publicly accessible Blueprint URL, Base64 encoded JSON, or raw JSON, and an embed code will be generated. If you haven’t created a Blueprint before, see the Blueprint guide for how to create one.

How to access Beta features

You can enable Beta features from the Studio → Beta Features menu. Once enabled, any available features appear directly in the app and behave like any other part of your workflow.

Announcements and feedback

All Beta features are announced in the Beta Features category of Studio GitHub Discussions. Each announcement includes a short description of the feature, how it works, and testing information.

Feedback should be posted directly in the corresponding discussion thread. Keeping everything in one place makes it easier to track questions, improvements, and follow-up actions.

Trying out Beta features is a great way to support Studio’s ongoing improvement. Your feedback helps shape what ships, what changes, and what gets prioritized next.

Query arguments

You can crop, resize, and filter images served by the Site Accelerator CDN using the following GET query parameters.

GET?w=

Set the width of an image in pixels:

?w=300

GET?h=

Set the height of an image in pixels:

?h=200

GET?crop=x,y,w,h

Crop an image by percentages x-offset, y-offset, width, height (x,y,w,h). Percentages are used so that you don’t need to recalculate the cropping when transforming the image in other ways such as resizing it.

For example, the following image takes a 60% by 60% rectangle from the source image starting at 12% offset from the left and 25% offset from the top.

?crop=12,25,60,60

The next image takes a 788 by 788 square starting at 160 by 160.

?crop=160px,160px,788px,788px

You can also mix the parameters types, for example a 1400 pixels by 60% rectangle from the image starting at 160 pixels by 25%.

?crop=160px,25,1400px,60

GET?resize=

Resize and crop an image to the exact width,height pixel dimensions. Set the first number as close to the target size as possible and then crop the rest. Which direction it’s resized and cropped depends on the aspect ratios of the original image and the target size.

?resize=400,220

?resize=200,400

This is useful for taking an image of any size and making it fit into a certain location while losing as little of the image as possible.

GET?fit=

Fit an image to a containing box of width, height dimensions. Image aspect ratio is maintained.

?fit=300,300

?fit=300,300

For example, fit=100,100 on a landscape image with dimensions 400×300 will result in an image that is 100×75, while fit=100,100 on a portrait image with dimensions 300×400 will result in an image that is 75×100.

GET?lb=

Add black letterboxing effect to images, by scaling them to width, height while maintaining the aspect ratio and filling the rest with black.

Original Image

?lb=310,250

GET?ulb=

Remove black letterboxing effect from images with ulb. This function takes only one argument, true.

Original Image

?ulb=true

GET?filter=

The filter parameter is used to apply one of multiple filters. Valid values are: negate, grayscale, sepia, edgedetect, emboss, blurgaussian, blurselective, meanremoval.

Original Image

?filter=negate

?filter=grayscale

?filter=sepia

?filter=edgedetect

?filter=emboss

?filter=blurgaussian

?filter=blurselective

?filter=meanremoval

GET?brightness=

Adjust the brightness of an image. Valid values are -255 through 255 where -255 is black and 255 is white. Higher is brighter. The default is zero.

?brightness=-40

?brightness=0

?brightness=80

GET?contrast=

Adjust the contrast contrast of an image. Valid values are -100 through 100. The default is zero.

?contrast=-50

?contrast=0

?contrast=50

GET?colorize=

Add color hues to an image with colorize by passing a comma separated list of red, green, and blue (RGB). For example, values such as 255,0,0 (red), 0,255,0 (green), 0,0,255 (blue).

?colorize=100,0,0

?colorize=0,100,0

?colorize=0,0,100

GET?smooth=

The smooth parameter can be used to smooth out the image.

Original image

?smooth=1

According to the PHP manual, the function applies a 9-cell convolution matrix where the center pixel is weighted by the value of the first argument, and all surrounding pixels have a weight of 1. The result is normalized by dividing by the total weight. In simpler terms, a value of 0 results in maximum smoothing, while higher values reduce the smoothing effect. Values around 2048 or more have little to no visible impact.

GET?zoom=

Use zoom to size images for high pixel ratio devices and browsers when zoomed. Not available to use with crop. Zoom is intended for use by scripts such as devicepx.js which automatically set the zoom level. Valid zoom levels are 1, 1.5, 2-10.

Original image

?zoom=2

GET?quality=

Use this parameter to manage the quality output of the images. Valid settings are between the values 10 and 100. The degree of compression depends on the image, its lossy or lossless nature, and the requesting web browser’s capabilities.

For lossless images, providing the quality input less than 100 will result in a lossy image provided the requested browser supports this image type. Below is an example that shows conversion of a non-transparent PNG (lossless) image to a JPEG (or lossy WebP if browser supports it) when quality is specified.

If the quality is not specified, photon will try to preserve the original quality.

Original image

?quality=50

Original png image

?quality=60

GET?allow_lossy=

Use this parameter to control whether the Image CDN may serve a lossy-compressed version of an image. When allow_lossy=1 is specified, the CDN will attempt to deliver a lossy format (for example, JPEG or WebP) if the requesting browser supports it.

Below is an example that demonstrates how a non-transparent PNG (lossless) image can be converted to a JPEG (or lossy WebP if browser supports it) when allow_lossy=1 is included in the request.

Original png image

?allow_lossy=1

GET?strip=

Use the strip functionality to control how metadata is preserved. Color profiles are always applied and removed, but other metadata may be kept. All data is stripped by default, with any existing orientation data being first applied to the image. There are 2 valid settings for this parameter:

• all: strips all extraneous data (this is the default).
• none: preserves Exif, IPTC and XMP.

Original image

?strip=none

• Streamline repeatable setups: Create Blueprints for common site types (like blog, portfolio, or store) to start new Studio projects more efficiently. 
• Keep teams aligned: Add a blueprint.json file to your project’s GitHub repository, whether you’re building a plugin, theme, or full site. It scaffolds the same environment every time, so teammates can start building a plugin, theme, or full site in minutes, while version control keeps changes reviewable and consistent.
• Simplify demos and testing: Launch Studio with the exact theme, plugins, and sample content you need. Reproduce bugs or confirm fixes with a reliable, repeatable setup.

This guide will teach you the basics of creating a custom Blueprint and provide additional resources where you can learn more.

What are Blueprints?

A Blueprint is a JSON file that defines a WordPress site’s setup. Within a Blueprint, you can configure settings such as your preferred WordPress and PHP versions. You can also specify a list of steps to run when the site is created, like installing and activating plugins and themes, setting site options, importing demo content, and running PHP or SQL queries.

Blueprints are written using a public JSON schema, standardizing their use across Playground, WordPress Studio, and beyond.

This minimal example configures the preferred WordPress and PHP versions, installs and activates the WooCommerce plugin and the Pendant theme, and sets the admin color scheme to “Modern.”

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "login": true,
  "preferredVersions": {
    "php": "8.3",
    "wp": "latest"
  },
  "steps": [
    {
      "step": "installPlugin",
      "pluginData": {
        "resource": "wordpress.org/plugins",
        "slug": "woocommerce"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "installTheme",
      "themeData": {
        "resource": "wordpress.org/themes",
        "slug": "pendant"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "updateUserMeta",
      "meta": {
        "admin_color": "modern"
      },
      "userId": 1
    }
  ]
}

Key things to know:

• preferredVersions lets you predefine the PHP and WordPress versions.
• steps is where the magic happens. You can log in, install or activate plugins and themes, import WXR content, set options, run PHP, and more. For instance, the example demonstrates installing WooCommerce, setting the site’s language to Spanish, and adjusting the admin color scheme. Check out the Step Library for each available action with examples.

WordPress Playground offers an interactive Blueprint builder, allowing you to test various Blueprint setups. It’s a great way to validate your custom Blueprints before running them in Studio.

Preview and download this Blueprint using the button above. Once downloaded, you can use it to create a new site in Studio. For detailed instructions, refer to the site creation flow in Studio.

Blueprint limitations in Studio

The following table highlights how Blueprints function differently in Studio compared to playground.wordpress.net, as of version 1.6.0:

Additional resources

Blueprints can be simple like the example above or as sophisticated as your workflow requires. The Playground documentation provides a clear overview of Blueprint JSON format, a quick start tutorial, and detailed references. If you want to create your own Blueprints or explore examples from the WordPress community, see the resources below:

• Blueprints overview and quick start tutorial
• Data format and schema
• Steps reference and visual Step Library
• Example Blueprints and the community gallery

Leveraging AI tools like the Studio Assistant is a great way to get help building custom Blueprints. Simply ask it to write a Blueprint for you:

There are also several community projects that provide a user interface for creating Blueprints, which are worth checking out:

• WordPress Playground Step Library
• Pootle Playground
• Block Based Visual Blueprint Builder