# The Power of WordPress Playground > [!question] Lingering Questions > - Do Playground blueprint URLs cache the linked GitHub source, or genuinely fetch the latest commit on every load? (Open question from the interview, not resolved in transcript.) > - How reliably does the "recoupling" pattern hold across different hosting/CI setups, versus just Richmond's own workflow? > [!tip] Article Ideas > - A vendor-neutral write-up of the blueprint-driven dev-loop pattern (Playground + linked GitHub repo) as a reusable WordPress development workflow. > [!link] Cross Reference > - [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] — Playground as a demo/training/dev-loop tool relevant to community-facing WordPress content > - [[Zet · Playground demos improve client feedback on themes]] — same underlying tool, applied to client-facing theme feedback rather than dev-loop version control ## Bib - "The Power of WordPress Playground" — https://www.youtube.com/watch?v=ZxiXsfLtb0o - Source: [[3. Resources/Readwise/Articles/The Power of WordPress Playground]] ## Author's thesis Blueprints are the mechanism that turns WordPress Playground from a novelty demo into a repeatable, shareable tool — for client training on the block editor, live prototypes, and a version-controlled bridge for block theme development that GitHub-based workflows lost when the site editor decoupled themes from files. ## Key arguments (≤3) 1. Playground runs a complete WordPress instance client-side via WebAssembly, needing no server or hosting account — the entire stack lives in the browser. 2. Blueprints (JSON configs declaring theme, content, and plugins) are the repeatability layer: without them, Playground is a one-off demo; with them, it's a shareable, reloadable environment. 3. A blueprint linked to a GitHub repo reloads the latest version of that theme/plugin on every load, recoupling block theme development with version control after the site editor decoupled themes from files. ## Claim atoms ### Playground runs a full WordPress instance in-browser via WebAssembly > [!quote] ID:transcript_playground_definition > "Playground is basically an instance of WordPress that lives in your browser with a bundle of plugins that you can add to it." ~00:00:47, Richmond's opening definition — establishes the core mechanic (WebAssembly, no server) that every later use case depends on. ### Blueprints are JSON configs that assemble theme, content, and plugins > [!quote] ID:transcript_blueprint_definition > "A blueprint is basically a JSON object effectively that pulls in various different methods." ~00:02:30 — the mechanism that turns Playground from a novelty into a repeatable tool (training sandboxes, live demos, dev prototypes). ### Blueprint-linked repos always load the latest GitHub version > [!quote] ID:transcript_blueprint_github_sync > "Every time that blueprint is loaded, it loads the latest version of that plugin." ~00:04:50 — answers Richmond's earlier claim that block themes "decoupled" from version control under the site editor; this is the recoupling mechanism. ## Permanent candidates - **Blueprint-driven sandboxes recouple block theme dev with version control** — a browser-based WordPress sandbox that reloads its linked theme/plugin straight from GitHub on every session turns "try it in Playground" into an actual step in a version-controlled dev loop, not just a demo. Promoted below. ## Processing checklist - [ ] Try building a blueprint for a real client site's theme/content to test the training-sandbox pattern - [ ] Confirm whether Playground blueprint URLs cache the GitHub source or truly fetch latest on every load - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] ## Links - [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] — blueprint-driven Playground workflows as demo/training/dev-loop content relevant to community-facing WordPress talks