Theme demos used to come down to two bad options. You shipped a gallery of static screenshots, or you kept a bloated multisite staging install alive and spent your afternoons maintaining it. What the Playground team built on top of WordPress 6.x got rid of both. With Playground Blueprints you hand people a working WordPress install that runs in their browser, and there is no server behind it to babysit.
There is a catch. Point Playground at nothing but your theme slug and you get a “Hello World” site that looks nothing like the design you are selling. The environment has to be configured before the visitor lands on it. I have debugged enough race conditions in these throwaway instances to trust a proper Blueprint over anything else. If staging sites have worn you down, I wrote up my take on WordPress Playground in 2025.
Why Playground Blueprints matter for theme devs
A Blueprint is a JSON recipe. It tells Playground how to build the instance: which plugins to activate, which theme to make active, and which content to import. That last one does most of the work. Skip the Blueprint and what you are handing people is a skeleton of your theme with none of the content that makes it look good.
1. Preparing your demo content
Start with a local source of truth. Build the site on your own machine in the Site Editor, and once the navigation, patterns and style variations are where you want them, run the built-in exporter at Tools → Export to get your WXR file.
Now the part that bites: a Playground instance is temporary and lives inside a browser sandbox. It cannot reach back into localhost on your machine for images, so the assets have to sit somewhere public. I went into this in my guide to WordPress GitHub Repositories, and GitHub is where I park them.
2. Swapping the media URLs
The attachment URLs inside your XML need rewriting before the import. Most servers block cross-origin requests, so CORS will quietly kill your images, but GitHub serves them from raw.githubusercontent.com without complaint. A one-line Bash script does the swap:
# Example of updating attachment URLs in WXR
sed -i 's|https://your-local-site.test/wp-content/uploads/|https://raw.githubusercontent.com/username/repo/main/media/|g' demo-content.xmlStructuring your Playground Blueprints JSON
The blueprint.json file holds a few global settings and a steps array, and Playground runs those steps in order. For a theme demo the first step is almost always a WP-CLI call that wipes the default “Hello World” content.
{
"$schema": "https://playground.wordpress.net/blueprint-schema.json",
"login": true,
"steps": [
{
"step": "wp-cli",
"command": "wp site empty --yes"
},
{
"step": "installTheme",
"themeData": {
"resource": "wordpress.org/themes",
"slug": "twentytwentyfive"
},
"options": { "activate": true }
},
{
"step": "importWxr",
"file": {
"resource": "url",
"url": "https://raw.githubusercontent.com/user/repo/main/playground-content.xml"
}
},
{
"step": "setSiteOptions",
"options": {
"blogname": "Pro Theme Demo",
"show_on_front": "page",
"page_on_front": 80
}
}
]
}page_on_front above is the ID of a page that came in with your XML. Because wp site empty cleared the database first, that ID comes out the same on every run, which is the only reason hardcoding it is safe.
Testing your Blueprint
With the JSON and the XML committed to GitHub, the demo launches from a single URL parameter:
https://playground.wordpress.net/?blueprint-url=https://raw.githubusercontent.com/user/repo/main/blueprint.json
Keep the browser console open on the first run. When the images do not load it is a CORS problem or a typo in the raw GitHub URL almost every time. The official Blueprints documentation covers the rest of the step reference.
If Playground Blueprints are eating your billable hours, hand the work to me. I have been building on WordPress since the 4.x days.
Worth the setup time
A demo people can click through is the baseline now, not a bonus. Playground Blueprints let someone break your theme before they pay for it, which is a far easier sell than a screenshot gallery.
