WordPress Playground Blueprint Generator
Builds a WordPress Playground blueprint and boots it in the page, so you can see the site your JSON actually produces.
One per line. A directory slug, or a URL to a zip the browser can fetch.
A directory slug, or a zip URL. Leave empty to keep the default theme.
Where the site lands once it has booted.
A WordPress export file. It is fetched by the browser, so it needs CORS headers.
This is a real WordPress running in your browser, built by this blueprint. Nothing is uploaded, and closing the tab throws it away.
{
"$schema": "https://playground.wordpress.net/blueprint-schema.json",
"landingPage": "/wp-admin/",
"preferredVersions": {
"php": "8.3",
"wp": "latest"
},
"features": {
"networking": false
},
"steps": [
{
"step": "installPlugin",
"pluginData": {
"resource": "wordpress.org/plugins",
"slug": "hello-dolly"
},
"options": {
"activate": true
}
}
],
"login": true
}- Networking is off, so the site cannot reach the plugin directory from inside. Installing by slug still works: Playground fetches those itself before boot.
A blueprint tells WordPress Playground what to build before it hands you a site: which WordPress, which PHP, which plugins and theme, who to log in as. This writes that file, and boots it in the page so you can see whether it actually works.
Playground is WordPress compiled to WebAssembly, running in your browser tab. There is no server, no install, and nothing to clean up — closing the tab throws the site away. That makes it the fastest way to reproduce a bug report, show a client a theme, or check a plugin against PHP 8.3 without touching anything you care about.
The part people get wrong is not the JSON. It is that a blueprint can boot a perfectly healthy site with your plugin silently missing, because the step was spelled wrong or the zip could not be fetched. Every step here comes from the published schema, a bad slug is refused at the field, and the preview is right there to prove it worked.
How to use
- Put in the plugins you want — directory slugs one per line, or a URL to a zip.
- Pick the WordPress and PHP versions, and where the site should open.
- Press Run it here. WordPress boots in the page, built by your blueprint.
- Copy
blueprint.json, or share the URL, which carries the whole blueprint inside it.
Example
A bug report that needs WooCommerce on PHP 8.1:
{
"$schema": "https://playground.wordpress.net/blueprint-schema.json",
"landingPage": "/wp-admin/plugins.php",
"preferredVersions": { "php": "8.1", "wp": "latest" },
"features": { "networking": false },
"steps": [
{
"step": "installPlugin",
"pluginData": { "resource": "wordpress.org/plugins", "slug": "woocommerce" },
"options": { "activate": true }
},
{ "step": "setSiteOptions", "options": { "blogname": "Bug 4821" } }
],
"login": true
}Send the URL to whoever filed the bug and they are looking at the same site you are, in about ten seconds, without installing anything.
Pitfalls
A zip has to be fetchable by the browser. Playground downloads it from the tab, so the host must send CORS headers. GitHub release assets do. A zip on your own server usually does not, and the symptom is a site that boots fine with the plugin missing.
A GitHub page is not a zip. github.com/owner/repo returns HTML. You want the release asset URL,
the one ending in .zip.
Playground already ships Hello Dolly and Akismet. Installing one of those by slug gives you two copies in the plugins list, one of them inactive. Harmless, confusing the first time.
Nothing persists. There is no database to keep and no files to find afterwards. If you need the state again, keep the blueprint, not the site.
Networking is off by default, which means the site cannot reach the plugin directory from inside its own admin. Installing by slug still works, because Playground fetches those before boot. Turn networking on if you want to browse the directory inside the preview.
Versions are a preference, not a guarantee. Playground serves the builds it has; an old PHP or an exotic WordPress may quietly come back as something near it.
It is a browser tab, not a server. Expect a few seconds and several megabytes on first boot, and expect a phone to feel it.
Compatibility
The blueprint is written in your browser and the preview runs on playground.wordpress.net, which is WordPress’s own service. Nothing is sent to this site.
The blueprint travels in the URL fragment, encoded as base64. A fragment is never sent to a server, so a blueprint naming a private zip stays between you and the Playground runtime in your tab. That is also why the URL is long — the whole recipe is in it, with nothing stored anywhere.
Playground needs a current browser with WebAssembly and SharedArrayBuffer: Chrome, Edge, Firefox and Safari 16.4 or newer. The generator itself works anywhere.
Steps written here: installPlugin, installTheme, activatePlugin, activateTheme, login,
setSiteOptions, defineWpConfigConsts and importWxr — all from the published blueprint schema.