The Power of WordPress Playground-2 - CourtneyR.dev's 2nd Brain

The Power of WordPress Playground ![rw-book-cover](https://img.youtube.com/vi/ZxiXsfLtb0o/maxresdefault.jpg) 🔗 **Source:** [The Power of WordPress Playground](https://www.youtube.com/watch?v=ZxiXsfLtb0o#transcript) > [!note]+ Document Notes > --- > tags: [wordpress-playground, webassembly, blueprints, developer-tools, block-editor, client-training] > author: Eric Karkovack > source: The WP Minute > reference: https://www.youtube.com/watch?v=ZxiXsfLtb0o > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > --- > # 🏷️ Title: The Power of WordPress Playground > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ## 📝 Summary > - Eric Karkovack (The WP Minute) interviews developer and WordPress core contributor Elliot Richmond about WordPress Playground — a browser-based, WebAssembly-powered instance of WordPress that needs no server or hosting account. > - Richmond frames two practical use cases beyond the usual "quick demo" framing: client training for long-time users adapting to the block editor, and rapid prototyping paired with version-controlled block themes on GitHub. > - Stakeholders: WordPress agencies and freelancers training clients on the block editor; theme/plugin developers who want a fast local-in-browser dev loop; the Playground core team (Richmond describes his own involvement as informal, talking to the dev team at WordCamp while contributing on the AI Core team). > - Risk/tradeoff: Playground sessions are ephemeral by default — persistence is local-only (browser storage) unless the user explicitly exports, and blueprint-driven content isn't a permanent hosted site. > - Bottom line: blueprints are the mechanism that turns Playground from a novelty demo into a repeatable, shareable tool — for training material, live prototypes, and a version-controlled bridge for block theme development that GitHub-based workflows lost when the site editor decoupled themes from files. > ## 📖 Main Content > Richmond frames WordPress Playground as "an instance of WordPress that lives in your browser," bundled with a chosen theme and plugin set, and built on WebAssembly rather than a server — the entire stack runs client-side. Two features do the real work: **Playground** itself (the runtime) and **Blueprints** (the configuration layer). > A blueprint is described as "basically a JavaScript... JSON object" that declares which theme, content, and plugins should load. Blueprints are hosted (frequently on GitHub) and passed to Playground as a URL parameter; when the URL fires, Playground reads the blueprint, pulls the referenced files, and installs everything in-browser, ready to use. > Richmond's leading use case is **client training**: a client running the same WordPress site for roughly 15 years, migrating multiple users onto the block editor for the first time. Rather than train on the live production site, he pairs the client's actual content with Playground + a blueprint, giving users a safe sandbox that doubles as a durable reference they can revisit to relearn a workflow or try a new plugin or theme without any risk to the live site. > Karkovack raises the natural follow-up: is this permanent, like a locally-installed dev environment (he compares it to a prior WP Minute episode on a local-install tool)? Richmond clarifies that a Playground session is WebAssembly-based and lives for that browser session only — but it isn't fully throwaway. Users can persist changes to a local (browser) database and export their work if they want to keep it. > The second use case is **development workflow**. If a blueprint points at a theme or plugin repo, a developer can make changes, test them live in the Playground browser instance, then push those changes back to GitHub as a pull request. Richmond calls this out as particularly valuable for block themes: the shift to the site editor "decoupled" version control from block theme development in a way classic PHP themes never had to deal with, and blueprints + Playground recouple the two — every time the blueprint loads, it pulls the current GitHub version of the linked plugin or theme. > ## 🗒️ Notes > #### ⏱️ [00:00:47](https://www.youtube.com/watch?v=ZxiXsfLtb0o&t=47) What Playground is > - Playground = a browser-resident WordPress instance with a chosen theme + plugin bundle; Richmond's involvement was informal (WordCamp conversations with the core dev team while on the AI Core team). > - > "Playground is basically an instance of WordPress that lives in your browser with a bundle of uh plugins that you can add to it" > #### ⏱️ [00:01:20](https://www.youtube.com/watch?v=ZxiXsfLtb0o&t=80) Client training use case > - 15-year-old client site moving multiple users onto the block editor for the first time — steep learning curve for non-technical, long-tenured users. > - Playground + blueprint = training sandbox AND a persistent reference point users can return to. > #### ⏱️ [00:02:30](https://www.youtube.com/watch?v=ZxiXsfLtb0o&t=150) Blueprints explained > - Blueprint = JSON object that pinpoints theme, content, and plugins; hosted (often on GitHub), passed as a URL parameter to Playground. > - > "blueprint is basically a JavaScript uh J JSON object effectively that pulls in uh various different methods" > #### ⏱️ [00:03:40](https://www.youtube.com/watch?v=ZxiXsfLtb0o&t=220) Persistence and session model > - WebAssembly-based, session-scoped by default; can persist to a local browser database and export if changes need to survive the session. > - Framed as "a live demo with real content" rather than a hosted, permanent site. > #### ⏱️ [00:04:50](https://www.youtube.com/watch?v=ZxiXsfLtb0o&t=290) Dev workflow and version control for block themes > - Editing a linked theme/plugin in Playground, then shipping changes back to GitHub as a PR — recouples version control with block theme development after the site editor decoupled the two. > - > "every time that blueprint um is loaded, it loads the latest version of that plugin." > ## 📚 References > - WordPress Playground — official project (URL not provided in source transcript) > - The WP Minute / WP Minute Plus — publisher of this interview (see reference URL above for the source video; full-episode link mentioned but not provided in transcript) > - A prior WP Minute episode on a local WordPress install tool, referenced by Karkovack for comparison (title/URL not given in transcript) > ## 🗣️ Paraphrase > Karkovack opens by noting most listeners have heard of Playground without really knowing what it does, and asks Richmond — who's talked with the core Playground team at WordCamp while serving on the AI Core team — to explain it. Richmond describes Playground as a full WordPress instance running in the browser, paired with blueprints, and says it's best understood as a prototyping tool. He's found an additional angle: using it to train a long-time client's staff on the new block editor, since it gives them a safe, revisitable sandbox loaded with their real content. > Karkovack then probes the mechanics: is this like the local-install tools WP Minute has covered before, and how would you actually hand a built Playground instance to someone else? Richmond explains blueprints — JSON configuration hosted online (typically GitHub) and passed as a URL parameter — as the answer. He clarifies the session/persistence model (browser-session-scoped by default, but savable and exportable), and closes by describing how this setup lets developers push live-tested changes on a linked theme or plugin back to GitHub as a pull request, which he frames as solving a version-control gap the block editor's site editor created for themes. > ## 📰 Newsletter > Ever wanted to hand a client a "try it yourself" WordPress site without spinning up hosting, a database, or a support ticket? That's the pitch behind WordPress Playground, and developer Elliot Richmond just gave The WP Minute a great case study: using Playground + Blueprints to train long-time client users on the block editor, safely, with their real content, in a sandbox they can revisit any time. Bonus for theme devs — blueprints can point straight at your GitHub repo, so every Playground load pulls your latest code, turning a WebAssembly demo into a genuine dev-to-PR loop for block themes. Worth a watch if you're rolling out the editor to non-technical teams or maintaining a block theme repo. > ## ✅ Action Items > #### DevRel > - Education: build a Playground + blueprint training-sandbox template agencies can reuse for client block-editor onboarding, mirroring Richmond's 15-year-client scenario. > - Developer experience: document the blueprint JSON schema with a "point at your GitHub repo" quickstart for theme/plugin devs. > #### OSPO > - Not applicable to this source — no licensing, governance, or compliance topics raised in this segment. > #### Community > - Maintainers: a short "Playground for training, not just demos" writeup would help agencies who only know Playground as a quick-preview tool. > #### WordPress > - **Playground:** Primary topic — expand blueprint documentation/examples for training-sandbox and GitHub-linked dev workflows specifically (not just demo/prototyping framing). > - **Training:** Build or adapt a lesson plan using Playground + blueprints for block editor onboarding of long-tenured, non-technical site users. > - **Documentation:** Add a "client training with Playground" recipe alongside existing prototyping docs. > - **Core Program Team:** Not applicable to this source. > - Core, Core Performance, Core AI, Mobile, Community (meetups/WordCamp), Marketing, Support, Design, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins: Not applicable to this source — segment stays scoped to Playground/Blueprints. > #### The WPCC > - Not applicable to this source. > ### FAIR > - Not applicable to this source. > ## 🧪 Hypotheses > - H1: Agencies that adopt Playground + blueprints for client block-editor training see fewer support tickets from users relearning the editor than agencies training on the live site. > - H2: Blueprint-linked GitHub theme/plugin repos reduce the "decoupling" friction site-editor block themes introduced versus classic PHP theme version control. > - H3: Developers who prototype with Playground before building locally ship working block themes/plugins faster than those who skip a browser-based prototyping step. > - H4: Training sandboxes built from real (exported) client content increase user retention of new block-editor workflows compared to generic/demo content. > ### 📊 Methodology > - H1/H4: A/B or before-after comparison of support-ticket volume and task-completion time for two cohorts of client users — one trained via Playground sandbox, one trained on the live site or via static documentation. > - H2: Case-study comparison of PR turnaround time and merge-conflict rate on block theme repos before vs. after adopting blueprint-linked Playground dev loops. > - H3: Time-to-first-working-build comparisons between developers who prototype in Playground first vs. those who go straight to local environment setup. > ### ❓ Questions > - How durable is a blueprint's link to "latest GitHub version" — does it cache, and could that create a mismatch between what a trainee sees and the live repo state? > - What's the practical ceiling on content size/complexity for a Playground-based training sandbox before browser performance or WASM limits become a problem? > - Is there tooling to convert an existing live client site into a ready-made training blueprint with minimal manual configuration? > ### 🔮 Future Research > - Formal usability study on Playground-based onboarding vs. traditional documentation/video training for non-technical WordPress users. > - Investigate whether blueprint-driven workflows meaningfully reduce the theme-development-to-version-control gap Richmond describes, across a sample of real block theme repos. > ### 💡 Implications > - Practice: Playground lowers the cost of building a safe, disposable-but-revisitable training environment — agencies can offer this without provisioning staging sites. > - Security: sandboxed, session-scoped execution limits blast radius for training exercises — no risk to production data, useful default for client-facing demos. > - Education: block-editor onboarding materials could shift from static screenshots/video toward interactive, blueprint-defined sandboxes. > - Funding/business model: this is a low-cost differentiator agencies could bundle into onboarding/training packages without extra hosting spend. > ### 🧠 Learning Styles Assessment > - Reading level estimate: Flesch-Kincaid grade ≈ 8–9 (conversational spoken interview register, short clauses, frequent filler words like "um"/"you know," moderate technical vocabulary — "WebAssembly," "blueprint," "version control"). > #### 👀 Visual learners > - Present: none — this is a transcript-only segment with no diagrams, screenshots, or on-screen visuals captured. > - Improve: add a blueprint JSON example and a before/after diagram of the "decoupled vs. recoupled" version-control flow Richmond describes. > #### 🔊 Aural learners > - Present: the source itself is audio/video — well served natively. > - Improve: a short standalone audio pull-quote on the blueprint/GitHub-sync mechanic for feed distribution. > #### 🗣️ Verbal learners > - Present: Richmond uses plain-language analogies ("live demo with real content," "a big learning curve"). > - Improve: a glossary callout defining "blueprint," "WebAssembly," and "site editor decoupling" for readers new to the terms. > #### 🧩 Kinesthetic learners > - Present: none directly, but the subject matter (Playground) is inherently hands-on. > - Improve: link a ready-to-click Playground blueprint URL so readers can try the training-sandbox pattern immediately. > #### 🧠 Logical learners > - Present: implicit before/after structure (life before blueprints vs. after) around the version-control problem. > - Improve: a simple flow table — Session start → Blueprint resolves theme/content/plugins → User works → Export or discard. > #### 🧑‍🤝‍🧑 Social learners > - Present: the piece is itself a two-person dialogue/interview format. > - Improve: a discussion prompt for readers to share their own client-training pain points. > #### 🧘‍♀️ Solitary learners > - Present: none explicit. > - Improve: a self-check prompt — "could a Playground blueprint replace my current client-training method?" > #### 🌿 Naturalistic learners > - Present: none — not a relevant lens for this technical/dev-tools content. > - Improve: not applicable to this source. > ### 📊 Accessibility Assessment > #### Screen reader semantics > - Present: N/A — this note is a transcript-derived text artifact, not the original video's UI. > - Improve: if republished, use proper heading structure and descriptive link text (already applied in this note). > #### Keyboard navigation > - Present: N/A — no interactive UI in this source. > - Improve: not applicable. > #### Contrast and readability > - Present: N/A — plain transcript text. > - Improve: not applicable. > #### Text resizing and reflow > - Present: N/A. > - Improve: not applicable. > #### Media and captions > - Present: this note itself was produced from a transcript, implying captions/transcript exist for the source video — good baseline accessibility. > - Improve: confirm the published video includes accurate closed captions (not just auto-generated) and a downloadable transcript link, per WCAG 2.2 AA media guidance. > #### Forms and interactions > - Present: N/A — no forms in this source. > - Improve: not applicable. > #### Standards reference > - Primary applicable WCAG 2.2 AA criterion: 1.2.2 Captions (Prerecorded) — satisfied if the published video ships accurate captions; not verifiable from transcript alone. > ### 🌍 DEIB Assessment > #### Cultural breadth > - Present: none — single-region (implicitly US/English-language WordPress community), no multi-region examples. > - Improve: note regional variation in client-training needs (e.g., hosting/latency considerations for browser-based tools in low-bandwidth regions). > #### Inclusive language > - Present: plain, jargon-light language overall; a few undefined technical terms ("WebAssembly," "blueprint"). > - Improve: brief inline definitions on first use for listeners newer to WordPress development. > #### Neurodiversity support > - Present: conversational, informally structured — no chunking or predictable segment markers in the raw transcript. > - Improve: chapter markers / timestamped segment titles (partially provided in this note's Notes section) aid scanability. > #### Representation > - Present: two participants, roles as host and technical contributor; no broader representation signal in this segment. > - Improve: not enough content in this excerpt to assess further; note for future episodes to vary guest backgrounds. > #### Psychological safety > - Present: collegial, low-stakes technical conversation; no contentious or sensitive material. > - Improve: not applicable — no concerns identified. > ### ✅ Logical Validity > #### Strong reasoning > - Causal: Richmond ties the site editor's shift to file-decoupled block themes directly to a version-control gap, then shows how blueprint-linked GitHub sourcing closes that specific gap — a clear, well-scoped causal claim (~00:04:50). > - Analogical: comparing Playground to a previously-covered local-install tool (Karkovack's question) helps listeners map new information onto a known category, then Richmond sharpens the distinction (session-scoped vs. persistent-by-default). > #### Fallacies > - None identified. This is a descriptive technical interview without argumentative claims that would be susceptible to common fallacies (no appeals to authority beyond accurately-described first-hand experience, no false dichotomies, no straw-manning of alternatives). > #### Tone of voice > - Informal, enthusiastic, exploratory — Richmond hedges appropriately ("I would say," "sort of," "basically") when describing mechanics he's relaying secondhand from core team conversations, which reads as honest calibration rather than evasiveness. > ### 🛡️ DARVO Analysis > - Not applicable to this source — this is a collaborative, non-adversarial technical interview with no accusation, conflict, or defensive dynamic present. No denial, attack, or victim/offender reversal patterns occur. > ## 🎯 Conclusion > WordPress Playground's real value in this conversation isn't the "instant demo" pitch most people already know — it's what blueprints unlock: a repeatable, shareable, version-controllable configuration layer on top of a disposable browser sandbox. That combination supports two underused workflows: safe, revisitable client training on real content, and a GitHub-synced dev loop that reconnects block theme development to version control. Next step for readers: try building a blueprint that points at an existing GitHub theme/plugin repo and a client's exported content, and use it as a live training reference instead of a one-off demo. > ## 🔄 Refactor Appendix — The Power of WordPress Playground > ### 📚 Literature Atoms (H3) > #### 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 uh plugins that you can add to it > **Context & use**: > - ~00:00:47, Richmond's opening definition of Playground. > - Establishes the core mechanic (WebAssembly, no server) that every later use case (training, prototyping, dev workflow) depends on. > **Tags**: #xref > **Highlight**: [view highlight](readwise://transcript-only — no Reader doc created in this pass) >  > #### Blueprints are JSON configs that assemble theme, content, and plugins > > [!quote] ID:transcript_blueprint_definition > > blueprint is basically a JavaScript uh J JSON object effectively that pulls in uh various different methods > **Context & use**: > - ~00:02:30, Richmond explaining how a Playground instance is actually configured and shared. > - This is the mechanism that turns Playground from a novelty into a repeatable tool (training sandboxes, live demos, dev prototypes). > **Tags**: #xref > **Highlight**: [view highlight](readwise://transcript-only — no Reader doc created in this pass) >  > #### Blueprint-linked repos always load the latest GitHub version > > [!quote] ID:transcript_blueprint_github_sync > > every time that blueprint um is loaded, it loads the latest version of that plugin. > **Context & use**: > - ~00:04:50, in the discussion of using Playground for real development work on a linked theme/plugin. > - Directly answers Richmond's earlier claim that block themes "decoupled" from version control under the site editor — this is the recoupling mechanism. > **Tags**: #xref > **Highlight**: [view highlight](readwise://transcript-only — no Reader doc created in this pass) >  > ### 🧠 Permanent Candidates (H4) > #### Blueprint-driven sandboxes recouple block theme dev with version control > **Claim** (one sentence, Courtney's voice): A browser-based WordPress sandbox that reloads its linked theme or 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. > **Evidence pointer**: [[#Blueprint-linked repos always load the latest GitHub version]] > **Scope & conditions**: Holds when the blueprint points at a real, actively-maintained GitHub repo for the theme/plugin under test; breaks down if the blueprint caches or if the repo isn't the actual deploy target (staging drift). > **Links**: > - [[WordPress block themes]] — because applies-in block theme development workflows > - [[Client training sandboxes]] — because contrasts on purpose (dev-loop tool vs. training tool, same underlying mechanism) >  > ### ✏️ Fleeting Queue > - [F1] Try building a blueprint for one of my own client sites' theme/content to test the training-sandbox pattern Richmond describes — https://www.youtube.com/watch?v=ZxiXsfLtb0o #xref > - [F2] Look into whether Playground blueprint URLs cache the GitHub source or truly fetch latest on every load — open question from the interview, not resolved in transcript #xref > ### → Things 3 (max 2 actions) > - [ ] Test a blueprint pointed at a live GitHub theme repo to confirm the "loads latest version every time" behavior — WordPress Playground research #things > --- > ## Full Transcript > [00:00] Hi everyone and welcome to the WP [00:02] Minute. I'm Eric Caravac. [00:05] Today's episode features a segment from [00:07] my interview with developer and core [00:09] contributor Elliot Richmond. Elliot [00:12] stopped by to give us an inside look at [00:14] WordPress playground and to show us how [00:16] to harness it for client training, [00:18] prototyping, and more. Now you can catch [00:22] the entire episode over on our WP Minute [00:25] Plus channel. Visit the wpminut.com for [00:28] all the details. [00:31] I know like a lot of us have probably [00:33] heard about about Playground. Um, but I [00:37] suspect a lot of people don't actually [00:39] know what it is. Could you explain a [00:41] little bit about what Playground does [00:42] because I think you've actually made [00:43] some contributions to it, haven't you? [00:46] >> Uh, my only contribution is basically [00:48] just talking to the developer core [00:50] developer um development team at Word [00:52] Camp. Um I was actually contributing on [00:54] the AI core team uh when I was there. Um [00:59] but yeah, Playground is basically an [01:02] instance of WordPress that lives in your [01:03] browser with a bundle of uh plugins that [01:07] you can add to it um and a particular [01:11] theme. But that coupled with blueprints [01:14] is a tool that can be used for [01:17] prototyping, sorry, prototyping a [01:19] website very quickly. Um, and recently [01:23] it just struck me that you can use it [01:25] for training. Um, so I do have a client [01:27] that have they have multiple users that [01:31] use the same website and we are [01:34] basically using the block editor now. [01:36] Um, they've been using a site for maybe [01:39] 15 years. [01:40] >> Okay. [01:41] >> And it's a big leap into uh it's it's a [01:44] big learning curve for them to learn how [01:45] to edit their new site in the block [01:47] editor. So coupling that content in a [01:52] browser with playground and blueprints [01:55] just makes for a brilliant sort of uh [01:57] training session for them as well as a [02:00] um uh a reference point that they can [02:03] come back to and re refresh their memory [02:05] on stuff or try something out or try a [02:08] plug-in um or try a new theme. It's it's [02:12] it's really good for that kind of uh [02:13] process. [02:15] Now, so this lives in your browser and I [02:18] I we had an episode a few months back [02:20] with the uh team behind my [02:22] WordPress.net, which is also a local [02:25] like install. [02:28] But I was wondering how how do you share [02:31] something that you've created in [02:32] Playground? Does it have like a [02:34] permanent URL or does is it something [02:37] that once they they access wherever [02:39] you're storing it, it it automatically [02:41] just downloads to their browser then? [02:45] Well, this is where blueprint comes into [02:47] play. So, it kind of blueprint is [02:49] basically a JavaScript uh J JSON object [02:53] effectively that pulls in uh various [02:55] different methods. So, you can pinpoint [02:57] a theme, you can pinpoint content, you [03:00] can pinpoint uh plugins and then you [03:02] apply that to WordPress uh the [03:05] playground WordPress.net net um as a [03:08] parameter blueprint URL and you host [03:11] that somewhere and then within your [03:12] blueprint as long as you've got hosted [03:14] files whether they're uh for a theme or [03:17] for a plug-in or even for content when [03:20] that URL is fired up it reads that and [03:22] then it reads where your your all your [03:24] GitHub uh or from GitHub or hosted uh [03:28] files and then it just installs [03:30] everything ready to go in the browser [03:32] and it's yeah it's it's a live demo with [03:34] real content but it only lives for that [03:37] session. So it's um it's built with web [03:39] assembly. Uh so it's a it's a one [03:42] session only. It it it does stay [03:45] persistent. You can save stuff to a [03:46] database and you can export stuff um if [03:49] you make changes. And it's particularly [03:51] powerful as well if you have a plugin or [03:54] a theme that you want to um link in and [03:57] you want to make some changes or [03:58] development changes and then test them [04:00] in the browser. you can then deploy them [04:02] back to your um GitHub as a PR and merge [04:06] things in that way or prove that code. [04:09] So, it's really good for um especially [04:11] the block themes and [04:14] the sort of GitHub and version control [04:17] became uh decoupled with the new sort of [04:20] site editor and uh developing block [04:23] themes, but blueprint actually with [04:26] playground makes it really powerful to [04:28] bring that back together. So a a [04:30] developer can version control their [04:32] source code effectively. [04:34] >> Okay. So you can go in and actually like [04:36] I can write a post and it will be there [04:38] the next time because of the blueprint [04:40] essentially. [04:41] >> You you can save it persistent in the [04:43] browser and then when it come in that [04:44] will save it as local uh data but then [04:47] yeah it won't it it's only accessible to [04:49] you really in your browser session. [04:52] >> Gotcha. Gotcha. If the blueprint [04:55] references a GitHub plugin that you've [04:57] developed and you make changes to, every [05:00] time that blueprint um is loaded, it [05:02] loads the latest version of that plugin. [05:04] So for custom developments or plug uh [05:08] themes or plugins that you've developed, [05:09] it's really useful for that as well. And [05:11] it's it stays current with the uh with [05:14] the GitHub your your version control. Hi everyone and welcome to the WP Minute. I'm Eric Caravac. Today's episode features a segment from my interview with developer and core contributor Elliot Richmond. Elliot stopped by to give us an inside look at WordPress playground and to show us how to harness it for client training, prototyping, and more. Now you can catch the entire episode over on our WP Minute Plus channel. Visit the wpminut.com for all the details. I know like a lot of us have probably heard about about Playground. Um, but I suspect a lot of people don't actually know what it is. Could you explain a little bit about what Playground does because I think you've actually made some contributions to it, haven't you? >> Uh, my only contribution is basically just talking to the developer core developer um development team at Word Camp. Um I was actually contributing on the AI core team uh when I was there. Um but yeah, Playground is basically an instance of WordPress that lives in your browser with a bundle of uh plugins that you can add to it um and a particular theme. But that coupled with blueprints is a tool that can be used for prototyping, sorry, prototyping a website very quickly. Um, and recently it just struck me that you can use it for training. Um, so I do have a client that have they have multiple users that use the same website and we are basically using the block editor now. Um, they've been using a site for maybe 15 years. >> Okay. >> And it's a big leap into uh it's it's a big learning curve for them to learn how to edit their new site in the block editor. So coupling that content in a browser with playground and blueprints just makes for a brilliant sort of uh training session for them as well as a um uh a reference point that they can come back to and re refresh their memory on stuff or try something out or try a plug-in um or try a new theme. It's it's it's really good for that kind of uh process. Now, so this lives in your browser and I I we had an episode a few months back with the uh team behind my WordPress.net, which is also a local like install. But I was wondering how how do you share something that you've created in Playground? Does it have like a permanent URL or does is it something that once they they access wherever you're storing it, it it automatically just downloads to their browser then? Well, this is where blueprint comes into play. So, it kind of blueprint is basically a JavaScript uh J JSON object effectively that pulls in uh various different methods. So, you can pinpoint a theme, you can pinpoint content, you can pinpoint uh plugins and then you apply that to WordPress uh the playground WordPress.net net um as a parameter blueprint URL and you host that somewhere and then within your blueprint as long as you've got hosted files whether they're uh for a theme or for a plug-in or even for content when that URL is fired up it reads that and then it reads where your your all your GitHub uh or from GitHub or hosted uh files and then it just installs everything ready to go in the browser and it's yeah it's it's a live demo with real content but it only lives for that session. So it's um it's built with web assembly. Uh so it's a it's a one session only. It it it does stay persistent. You can save stuff to a database and you can export stuff um if you make changes. And it's particularly powerful as well if you have a plugin or a theme that you want to um link in and you want to make some changes or development changes and then test them in the browser. you can then deploy them back to your um GitHub as a PR and merge things in that way or prove that code. So, it's really good for um especially the block themes and the sort of GitHub and version control became uh decoupled with the new sort of site editor and uh developing block themes, but blueprint actually with playground makes it really powerful to bring that back together. So a a developer can version control their source code effectively. >> Okay. So you can go in and actually like I can write a post and it will be there the next time because of the blueprint essentially. >> You you can save it persistent in the browser and then when it come in that will save it as local uh data but then yeah it won't it it's only accessible to you really in your browser session. >> Gotcha. Gotcha. If the blueprint references a GitHub plugin that you've developed and you make changes to, every time that blueprint um is loaded, it loads the latest version of that plugin. So for custom developments or plug uh themes or plugins that you've developed, it's really useful for that as well. And it's it stays current with the uh with the GitHub your your version control., The Power of WordPress Playground, YouTube, 01kxzy2t8rhxaswqpf19vd3m33.