Can the technology behind WordPress Playground help other PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php projects run in the browser?

Joomla contributor Herman Peeren is exploring that with Joomla Playground, an early community project that runs Joomla in a browser tab. You can explore its administrator and frontend without installing a local PHP server or setting up a database.

For me, the interesting part is what this brings back to the shared tools. Joomla introduces different queries, workloads, and assumptions, revealing compatibility and performance lessons that contributors can investigate together.

What Joomla Playground shares with WordPress

The project builds on two components from the WordPress ecosystem.

The first is PHP.wasm. Joomla Playground uses the @php-wasm packages developed in the WordPress Playground repository to run PHP as WebAssembly in the browser. Joomla’s files and database also operate locally. The second is wordpress/mysql-on-sqlite. A Joomla-specific adapter connects its MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com driver to this library, allowing MySQL queries to execute against SQLite. You can inspect that connection in the database adapter.

The browser architecture follows a familiar pattern: a worker runs PHP, a service worker routes requests, and an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. displays the CMS. Joomla adds its own startup logic, configuration, and Blueprint steps around that foundation.

Exploring Joomla without a local setup

Open Joomla Playground in a recent Chromium browser, such as Chrome or Edge. It starts a temporary site and automatically signs you in to the administrator. The toolbar lets you switch between the administrator and the public site. The project’s guide documents Joomla 6.2 and 5.4, with PHP 8.3, 8.4, and 8.5. It also describes controls for saving a site in your browser, importing and exporting ZIP files, and inspecting captured email without delivering it. Project guide

I suggest exploring the multilingual Heritage demo. A Joomla-specific JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. blueprint prepares content in English, Dutch, German, French, and Spanish, using demonstration data from Clifford E Ford. If you are preparing a workshop or demonstration, pay attention to persistence. Temporary sites disappear when you reload the page or close the tab. Saving keeps the site in that browser; exporting gives you a copy you can move elsewhere.

Lessons from running another CMS

Herman’s report provides concrete findings for contributors to explore. His tests included PHP.wasm 3.1.60 and MySQL-on-SQLite 3.1.1, so these observations are starting points for reproduction against current upstream code.

SQL compatibility

Joomla exercised SQL behavior that needed additional handling, including prepared statements, missing functions, server variables, and binary comparisons. One case affected login: session identifiers stored as binary values did not match the string comparisons Joomla used to retrieve them. Herman added local workarounds in the database adapter.

These cases could become regression tests for the shared database library. That is a practical benefit of testing another application: it exposes behavior that WordPress alone may not exercise.

Faster browser saves

Saving thousands of individual files to browser storage proved expensive. Herman switched to a shared base ZIP plus a snapshot of changed files, using Playground’s filesystem journal to track modifications. In his local measurements, saving dropped from 13 seconds to approximately 0.3 seconds. The implementation also replaces snapshots atomically and uses a per-site lock to prevent competing writers. Storage implementation

My reading is that this approach deserves testing with WordPress workloads. Those figures describe Herman’s Joomla tests; they do not establish the same improvement for WordPress Playground.

Making the site usable sooner

Two other findings involved requests sharing a single PHP worker. An unavailable network connection could leave a request waiting for minutes, blocking those behind it. Background search indexing also repeatedly entered the queue ahead of page navigation.

Herman enabled PHP networking through browser fetch and split indexing into smaller batches that yield between requests. Deferring indexing roughly halved the Heritage demo’s reported time to become usable, while the toolbar showed the remaining work. Report, sections 13, 18, and 24

For someone opening a demo, the practical question is simple: when can I start using the site? These findings give contributors specific cases to investigate around network failures and background Blueprint work.

Learning across the PHP ecosystem

Joomla Playground shows how this collaboration can work in both directions. Shared infrastructure makes another CMS easier to explore, and that CMS brings integration experience that can help improve the infrastructure. For educators and community organizers, there is also an immediate benefit: people can explore the software before spending time configuring an environment.

Try Joomla Playground, explore Herman’s source code, and share reproducible findings in the issue tracker. Thank you to Herman, Milana, and the contributors across these projects for making this exchange possible.

Which PHP application would you like to explore in the browser, and what would you test first? Please go to the Playground Channel and share with the team.

Did your contact form generate the notification you expected? Was the right welcome message generated for a new user? WordPress Playground now gives you a way to inspect those emails while you test a site in your browser. Open Dev Tools → Email to see messages generated by the current Playground, without setting up a mail server or checking a real inbox.

The Email tool starts empty and shows messages generated by the current Playground.

How email capture works

When WordPress sends a message through its normal wp_mail() path, PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php writes it to a sendmail-compatible program. Playground captures that message in the browser instead of delivering it. The website parses the captured message and adds it to the Email panel for the current site. You can select a message to check its subject, sender, recipient, time, and body, including an HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. preview when the message contains HTML.

The work arrived in stages: sendmail capture in PR #3996, forwarding captured messages to the website in PR #4103, and the Email viewer in PR #4000.

Try it in a fresh Playground

You can generate a sample message without installing a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.:

1. Open playground.wordpress.net and wait for WordPress to load.
2. Select Dev Tools in the Dock, then Email. A fresh site shows No emails yet.
3. Open Dev Tools → Terminal, select PHP, paste the snippet below, and select Run. The Terminal loads WordPress for you.

$sent = wp_mail( 'reader@example.invalid', 'Playground email test', 'Hello from WordPress Playground.' );echo $sent ? 'wp_mail() returned true' : 'wp_mail() returned false';

4. Return to Dev Tools → Email and select Playground email test. Check the recipient, subject, and message body. The message appears in Playground; nothing is delivered to reader@example.invalid.

You can also test a WordPress action instead of running PHP. For example, create a user under Users with Send the new user an email about their account selected, then inspect the generated messages. Once a plugin is installed, perform the action that normally sends its message and check the same panel. The Terminal guide has more on running PHP against the active site.

Which plugins benefit?

The Email tool is useful wherever a plugin sends messages through WordPress’s usual mail path:

• Forms: Submit a contact or lead form and check the notification’s recipient, subject, and submitted fields.
• Registration and membership: Check welcome, approval, invitation, and account messages after a user action.
• Commerce, bookings, and events: Inspect order, reservation, and confirmation emails while testing a workflow.
• Email templates and notifications: Compare generated text or HTML across settings, themes, and WordPress versions.

Plugin developers can offer a Playground demo that lets testers complete an action and inspect its email in the same browser session. Contributors and documentation authors can also use it to reproduce WordPress notification behavior without supplying a working mailbox.

What the Email tool does not test

A captured email is not a delivered email. Even when wp_mail() returns true, that only shows the message was accepted for processing; it does not prove that an external recipient received it. The Email panel helps you inspect messages sent through Playground’s sendmail capture path. A plugin that sends through a separate SMTP connection or provider APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. may bypass that path, so use an appropriate delivery test for those integrations.

Messages in the Email panel belong to the current Playground runtime session. Reloading the Playground website tab or reopening a saved site clears the captured messages, even though the WordPress site itself can persist. Wait for Playground to finish loading before triggering a test action; messages sent during initial Blueprint setup may not appear.

Try the feature on WordPress Playground. If a message does not appear, report the steps in the Playground repository, including the plugin or WordPress action you tested and whether it uses wp_mail() or another mail service.

WordPress Playground has shipped two new features: an integrated Terminal for PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php and WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, and a group for developer tools options on the Dock. The compact Dock keeps the everyday actions in view while giving developers a direct path to the tools for inspecting and changing a site.

From the Terminal, you can inspect content, check configuration, test a WordPress APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., or make a quick change without setting up a local environment or leaving playground.wordpress.net. It runs against the active Playground, so a command reads or changes the same WordPress site visible behind the panel.

The New group for Developer Tools in the Dock

Visit playground.wordpress.net and wait for WordPress to start. The Dock at the bottom of the screen shows New, Playgrounds, Site Settings, Export, and Dev Tools. In its compact state, it hides the developer-facing buttons to give people exploring WordPress a simpler toolbar.

Select Dev Tools next to Export to expand the Dock. It reveals Blueprint, Database, Terminal, Files, Logs, and Email. Then select Terminal to open the runner for the current site.

Playground remembers whether the developer tools were shown or hidden across page reloads. Collapsing them keeps an unfinished Terminal or Blueprint draft, so you can reopen the tool and continue.

The other new feature is Terminal, which opens with two modes:

• PHP runs short PHP snippets with WordPress already loaded.
• WP-CLI runs WordPress command-line commands against the active site.

Each mode keeps its own input, results, and command history, so you can move between PHP and WP-CLI without losing your place.

Explore WordPress with PHP

PHP mode provides a syntax-highlighted editor with line numbers and a few ready-to-run examples. You can select examples such as Versions, Site URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, List posts, Create post, or Active plugins, edit the code, and select Run.

WordPress is loaded for you, and the opening <?php tag is optional. For example, this snippet lists the titles of the site’s posts:

foreach ( get_posts() as $post ) {
	echo $post->post_title . "\n";
}

You can also inspect versions and configuration:

echo 'WordPress ' . get_bloginfo( 'version' ) . "\n";
echo 'PHP ' . phpversion() . "\n";
echo 'Site URL: ' . get_site_url();

Each submission is evaluated independently. Variables from one run are not available in the next run, but changes made through WordPress APIs remain in the active Playground. For example, update_option() changes the site’s database just as it would when called by a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party..

Use Ctrl+Enter or Command+Enter to run code from the keyboard. If the snippet is incomplete, it remains in the editor so you can finish it. Parse and runtime errors appear with concise messages, including a useful source position when available.

Manage the site with WP-CLI

Switch to WP-CLI when it’s the quickest way to inspect or change WordPress. Try a read-only command first:

wp option get blogname

The leading wp is optional, so option get blogname works too. On the first WP-CLI run, Playground downloads the WP-CLI executable if it is not already available. Later commands reuse it.

Here are a few useful commands to try. Run each line separately:

wp core version
wp plugin list
wp post list --fields=ID,post_title,post_status
wp option get siteurl

You can also create content directly:

wp post create --post_title='Created from the Playground Terminal' --post_status=publish

The result reports Success: Created post followed by its ID. Run wp post list --fields=ID,post_title,post_status again to confirm the title and publish status. To view it in WordPress, close the Terminal and enter /wp-admin/edit.php in the Dock’s address field, then open the post from the Posts screen. Refreshing the welcome page alone will not display the new post. Each time you rerun the create command, it creates another post.

Set up real test scenarios

WP-CLI is especially useful for preparing a test site before you check the result in WordPress. You are building a plugin or want to check how a theme will behave in a specific screen. These examples run in a fresh Playground and use a terminal command to prep the test.

Test a WooCommerce cart and coupon

Start Playground with WooCommerce active. The plugin adds its own wp wc commands, and --user=admin gives them the permissions needed to manage store data. Create a published test product and a 10% coupon running those two commands separately:

wp wc product create --name="Playground Test Mug" --type=simple --status=publish --regular_price=19.99 --sku=playground-test-mug-01 --user=admin

wp wc shop_coupon create --code=PLAYGROUND10 --discount_type=percent --amount=10 --user=admin

Open the shop on the WordPress site, add Playground Test Mug to the cart, then apply PLAYGROUND10 under Add coupons. In a fresh Playground test, the product appeared at $19.99, and the coupon reduced the cart total to $17.99.

The commands create the fixtures; adding to cart and applying the coupon still happen in the browser. See the WooCommerce command reference for other store operations.

Prepare posts for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. or Themes testing

When a feature needs more than one sample post, generate twelve published posts in one command:

wp post generate --count=12 --post_type=post --post_status=publish

The generated posts appear in Posts. In the Playground test, they also fill the blog’s first page and expose a second page of posts, giving testers content for pagination, sorting, search, or bulk-action checks. See the WP-CLI post generation reference.

For a focused blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-editor smoke test, create a post with saved Paragraph block markup:

wp post create --post_title='Block smoke test' --post_status=publish --post_content='Block smoke test'

Use the post ID reported by the command to open /wp-admin/post.php?post=ID&action=edit, replacing ID with that number. The test post opened as a Paragraph block in the editor. For a plugin block, replace this example with that block’s actual saved markup: markup that does not match the block’s definition can trigger a validation warning. The block markup guide explains the format.

A command runner, not a full shell

The integrated Terminal focuses on PHP and WP-CLI. It is not a general-purpose shell, and it does not provide an interactive TTY.

Pass every required value as part of a WP-CLI command. Commands that wait for interactive input are rejected instead of interpreting unavailable input as an empty value. Long-running interactive commands such as wp shell and wp server are not supported.

This constraint makes browser-based execution more predictable. It also protects a command from unexpectedly changing WordPress after a failed attempt to read from standard input. The same fail-fast behavior now applies to the Blueprint wp-cli step, so Blueprint commands must also provide their required arguments explicitly.

A faster path from question to answer

The Terminal fills the space between clicking through wp-admin and building a local development environment. Plugin developers can check an option or active plugin list while reproducing a bug. Documentation authors and learners can run WordPress PHP examples in context. Contributors can inspect a test site before exporting it or sharing a reproducible Blueprint.

The Terminal arrived in pull request #3808, Add Terminal to the Dock, building on an earlier request to integrate WP-CLI into the Playground website. The Dev Tools Dock update made that growing set of tools easier to show or hide.

Thanks to Alex Kirk for developing the Terminal and to the contributors who built and refined the Dock controls.

Try it and share feedback

Open WordPress Playground, check the new features, and tell us what you think. If you find a bug or have an idea for the workflow, open an issue in the WordPress Playground repository or join the #playground channel in Making WordPress Slack.

WordPress Playground is not a single interface. A developer may use the Playground CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. for local work, a Blueprint to describe a reproducible site, or playground.wordpress.net to create and share a browser-based demo. An AI agent needs to know which surface owns each part of a request.

PR #56 in the WordPress agent-skills repository updates the wp-playground skill around that idea. Instead of keeping CLI commands, Blueprint advice, browser links, and debugging notes in one long procedure, the skill becomes a small routing layer with focused references.

The result gives agents a clearer model of the whole Playground ecosystem. In this post, we are going to cover the main updates on the WordPress Playground agent skill, which is present in the WordPress repository. If you want an introduction post, I do recommend reading the previous post about the Playground agent skill.

What changes for Playground users

• A developer starting a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. locally gets the current start workflow and a check that the plugin is active.
• A reviewer receiving a demo link gets correct encoding, public hosting and CORS requirements, and a fresh-browser verification step.
• A mixed request can move from Blueprint authoring to local execution and browser sharing without one skill pretending to own every concern.

The headline benefit is consistency across surfaces: the answer changes with the workflow, while the underlying model of Playground stays coherent.

Why the previous skill reached its limit

The previous 101-line SKILL.md put local execution, Blueprint guidance, browser sharing, and debugging in one procedure. That created three failure modes:

• Browser support was too shallow to explain the Query API, persistence, or the difference between window.playgroundSites and the active window.playground client.
• Blueprint guidance existed in both wp-playground and the dedicated blueprint skill, creating two sources of truth.
• The common plugin and theme workflow still led with server --auto-mount after the Playground CLI documentation had moved the typical development loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop to start.

The current high-level workflow is:

cd <plugin-or-theme-root>
node -v
npx @wp-playground/cli@latest start

The server command remains useful when an agent needs explicit mounts, a disposable environment, CI behavior, or fine-grained runtime control. The important change is teaching the agent to choose, not treating one command as the answer to every local workflow.

Route by intent, then load the detail

The new wp-playground wrapper starts by classifying the request:

Request type	Owner	Expected outcome
Write or review Blueprint JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.	blueprint skill	Current schema, supported steps, and valid resources
Run a plugin, theme, or Blueprint locally	wp-playground → CLI reference	Appropriate command, mount strategy, and verification
Debug Xdebug or a stuck CLI run	wp-playground → debugging reference	Relevant logs, flags, and worker guidance
Create a browser link or automate a browser site	wp-playground → website reference	Correct URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org or APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. surface with browser constraints
Combine authoring, local execution, and sharing	Wrapper composes the routes	One staged workflow with clear ownership

Mixed requests can use more than one route. For example, “write a Blueprint, run it locally, and give me a reviewer link” uses blueprint for the JSON, the CLI reference for local execution, and the website reference for sharing.

This is progressive disclosure in practice. The entry file drops from 101 to 52 lines. The complete bundle grows because it documents more capability, but an agent loads that depth only when the request needs it.

Browser sharing becomes a first-class route

The website reference distinguishes three control surfaces:

1. URL setup through Query API parameters, Blueprint fragments, and blueprint-url.
2. Browser site management through the Sites API at window.playgroundSites.
3. Runtime interaction through the JavaScript API client exposed as window.playground.

That distinction prevents several common mistakes. playgroundSites manages site records, persistence, and the active site. The Playground client reads and writes the WordPress virtual filesystem, runs PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php, makes requests, and navigates the visible site. URL parameters configure a site before it boots.

The reference also documents boundaries that matter when an agent generates a share link:

• Small inline Blueprints should be encoded once with encodeURIComponent(JSON.stringify(blueprint)).
• Larger JSON files and ZIP bundles should use ?blueprint-url=<public-url>.
• Hosted files must be public and allow cross-origin loading.
• A browser Playground cannot read an arbitrary local filesystem path.
• The final URL should be checked in a fresh browser session.

These details turn “make a Playground link” from a plausible-looking string into a repeatable handoff. The official troubleshooting guide confirms that raw JSON in a fragment, double encoding, private URLs, and missing CORS headers are frequent failure modes.

At the same time, the blueprint skill now explicitly owns Blueprint JSON and bundles, and the debugging reference replaces stale worker advice with current flags. The router can therefore choose a source before the agent starts composing an answer.

What the benchmark showed

To measure the impact, I compared three configurations:

• The new version.
• The previous skill.
• A control that answered from general model knowledge without consulting a skill.

The benchmark used the four scenarios added by the PR: CLI auto-mounting, website sharing, a mixed Blueprint/CLI/browser request, and current Blueprint schema authoring. Every configuration received the same prompts running on GPT 5.5 Sol. The two skill configurations could read only the files from their pinned revision, while the control could not read skill files or references.

On this four-scenario, 24-assertion regression suite:

Scenario	New skill	Previous skill	Without skill
CLI auto-mount	5/5 (100%)	4/5 (80%)	1/5 (20%)
Website share URL	6/6 (100%)	5/6 (83.3%)	2/6 (33.3%)
Mixed Blueprint, CLI, and website workflow	6/6 (100%)	6/6 (100%)	3/6 (50%)
Current Blueprint schema	7/7 (100%)	7/7 (100%)	6/7 (85.7%)
All assertions	24/24 (100%)	22/24 (91.7%)	12/24 (50%)

Six criteria inspect the execution trace rather than the final answer. Five explicitly require the agent to use or route through a skill, so they necessarily penalize the no-skill control. Removing all six produces a cleaner comparison of answer content:

Answer-content score	New skill	Previous skill	Without skill
Passed criteria	18/18 (100%)	16/18 (88.9%)	11/18 (61.1%)

The final PR revision passed 24/24 checks: 100% on this four-scenario, 24-assertion regression suite. Only two content checks separated it from the previous skill:

• It chose npx @wp-playground/cli@latest start for the common plugin-development workflow.
• It required public, CORS-enabled hosting with Access-Control-Allow-Origin: * for Blueprint files, bundles, and referenced assets.

The Blueprint-only scenario did not distinguish answer quality; all three configurations passed its six content checks. That is evidence of preserved behavior, not improvement.

This is a focused regression suite, not a general model leaderboard. It uses one run per prompt, does not measure run-to-run variance, and grades guidance rather than live Playground execution.

Review improved the architecture

The pull request’s review history also shaped the final structure. Review feedback asked for an explicit routing procedure, top-level failure modes, stronger delegation to blueprint, and direct one-hop links from the wrapper to each reference.

The final revision removes reference-to-reference handoffs. A CLI or website reference now sends the agent back to the wrapper when the request changes direction. That keeps every focused file one hop from SKILL.md and makes the routing model easier to inspect.

Consistency across surfaces

The improvement is not merely a higher benchmark score. It is a more consistent developer experience across the CLI, Blueprints, and browser sharing. A request can move from a valid Blueprint to a local run and then to a reviewer link while each skill remains responsible for one concern.

PR #56 was merged on July 25, 2026. You can inspect the complete change set and use the four scenarios as starting points for testing real Playground tasks.

WordPress Playground is often used as a one-off browser sandbox: open a link, test a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party., close the tab.

That is useful, but plugin and theme development usually involves more than one sandbox. You may need a clean site for reproduction, a saved site for ongoing debugging, another site pinned to a different PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php version, and a way to inspect all of them without clicking through the interface.

Recent Playground updates make those workflows easier to automate. The Playground website now makes a site management object available to JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com running on its top-level page. Code in the browser console or a browser automation tool can access it through window.playgroundSites to list and switch sites, save temporary sites, rename saved sites, change runtime settings, or get the active site’s PlaygroundClient.

This post shows how plugin and theme developers can use that APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. from the browser console to speed up real workflows.

One interface for site management

Before these updates, anything outside the Playground UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. had to recreate site management behavior itself. MCP tools, browser-native WebMCP, DevTools experiments, and UI components all needed some way to list sites, save them, rename them, or switch the active site.

The new PlaygroundSitesAPI gives those workflows one shared interface. After the Playground website loads, JavaScript running on the page can call that interface through window.playgroundSites. This makes site management scriptable without relying on brittle UI automation.

In practical terms, you can now open DevTools and run:

window.playgroundSites.list();

The result is an array of site records:

[
  {
    slug: "quiet-river",
    name: "Quiet River",
    storage: "temporary",
    isActive: true,
  },
];

The storage field tells you whether the site is temporary, saved in browser storage, or saved to the local filesystem. Temporary sites disappear on reload unless you save them first.

The API at a glance

The workflows in this post use these coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. methods:

Method	What it does
list()	Lists all known Playground sites and marks the active one.
getClient()	Returns the PlaygroundClient for the active site, if it has booted.
isReady()	Resolves when the active site has booted and its client is ready.
rename(newName)	Renames the active saved site. Temporary sites must be saved first.
saveInBrowser(name?)	Saves the active temporary site to browser storage.
saveToLocalFileSystem(name?, handle?)	Saves the active temporary site to a local directory.
setPhpVersion(version)	Changes the PHP version for the active saved site.
setNetworking(enabled)	Enables or disables networking for the active saved site.
delete(siteSlug)	Deletes a saved site by slug. Temporary sites cannot be deleted this way.
setActiveSite(siteSlug)	Switches to another site and waits for it to boot.
createNewTemporarySite(siteSlug?, settings?)	Creates and activates a new temporary site.

The API is available after Playground loads its saved sites. If window.playgroundSites is undefined, wait until the Playground UI has finished loading. Then call await window.playgroundSites.isReady() before running commands that need the active site’s client.

See the Sites API documentation for the complete reference, including methods for autosaved and explicitly saved sites.

Run the examples on the Playground website

The examples below use the Sites API on playground.wordpress.net. Open the website, wait for the Playground UI to load, open your browser’s DevTools console, and run await window.playgroundSites.isReady(). You can then paste the examples into the console. A browser automation tool such as Playwright can run the same JavaScript while it controls a tab open to the Playground website.

This API belongs to the Playground website. It is not part of the @wp-playground/client package or the Playground CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress., and it is not exposed by /remote.html when you embed Playground in another application. For embedded sites and test automation that starts its own Playground client, use the JavaScript API instead.

Scenario 1: Create a clean plugin test site

When debugging a plugin issue, start with a fresh site that matches the target environment. The example below creates a temporary site using PHP 8.4, the latest WordPress release, and networking enabled:

const slug = await window.playgroundSites.createNewTemporarySite(
  "plugin-test-php-84",
  {
    phpVersion: "8.4",
    wpVersion: "latest",
    networking: true,
  }
);

console.log(`Active test site: ${slug}`);

Use this when you need a clean environment before installing a plugin or reproducing a report. The site is temporary at this point, so changes will not survive a reload.

Scenario 2: Save and rename a reproducible bug report

Once you reproduce a bug, save the site before making more changes. Saving turns a temporary site into a browser-stored site:

const saved = await window.playgroundSites.saveInBrowser(
  "Plugin compatibility test"
);

console.log(saved);

The returned object includes the site slug and storage type:

{
  slug: "plugin-test-php-84",
  storage: "opfs",
}

After saving, you can rename the active site:

await window.playgroundSites.rename(
  "Plugin compatibility test - PHP 8.4"
);

That sequence matters. rename() only works on saved sites. If you call it on a temporary site, Playground throws:

Cannot rename a temporary site. Save it first.

Scenario 3: Switch between saved test sites

When you keep separate sites for different reproduction cases, list them and switch by slug:

const sites = window.playgroundSites.list();

console.table(
  sites.map((site) => ({
    slug: site.slug,
    name: site.name,
    storage: site.storage,
    active: site.isActive,
  }))
);

To activate one:

const target = window.playgroundSites
  .list()
  .find((site) => site.name.includes("Plugin compatibility"));

if (target) {
  await window.playgroundSites.setActiveSite(target.slug);
}

setActiveSite() waits for the selected site to boot before resolving, so follow-up commands can safely assume the active site is ready.

Scenario 4: Inspect plugin state with PHP

The site management API gives you access to the active site’s PlaygroundClient. That client can run PHP inside the WordPress environment.

function phpResponseText(response) {
  return "text" in response
    ? response.text
    : new TextDecoder().decode(response.bytes);
}

await window.playgroundSites.isReady();
const client = window.playgroundSites.getClient();

if (!client) {
  throw new Error("The active Playground site has not booted yet.");
}

const response = await client.run({
  code: `<?php
require_once "/wordpress/wp-load.php";

echo json_encode([
  "php" => phpversion(),
  "wp" => get_bloginfo("version"),
  "active_plugins" => get_option("active_plugins"),
]);
`,
});

console.log(phpResponseText(response));

This lets you query plugin data in the WordPress database directly, without navigating through wp-admin. You can replace the PHP with targeted checks for options, active theme data, custom post types, or plugin-specific database rows.

For example, to inspect one option:

const response = await client.run({
  code: `<?php
require_once "/wordpress/wp-load.php";
echo wp_json_encode(get_option("woocommerce_currency"));
`,
});

console.log(phpResponseText(response));

Playground uses SQLite for WordPress storage, so prefer WordPress APIs like get_option() and $wpdb over database-specific SQL behavior.

Scenario 5: Change runtime settings for a saved site

Sometimes a bug only appears with a specific PHP version or with networking enabled. Once the active site is saved, you can update runtime settings directly:

await window.playgroundSites.setPhpVersion("8.3");
await window.playgroundSites.setNetworking(true);

These methods require a saved site. If the active site is temporary, save it first:

await window.playgroundSites.saveInBrowser("Network test");
await window.playgroundSites.setNetworking(true);

This is a good workflow for compatibility testing:

1. Create a clean site.
2. Install and configure the plugin.
3. Save the site.
4. Switch PHP versions.
5. Re-run the same plugin checks.

Scenario 6: Create a small compatibility checklist

You can combine the API calls into a manual checklist from DevTools. This example creates a site, saves it, gathers basic version information, and leaves the result in the console:

async function prepareCompatibilitySite() {
  function phpResponseText(response) {
    return "text" in response
      ? response.text
      : new TextDecoder().decode(response.bytes);
  }

  const slug = await window.playgroundSites.createNewTemporarySite(
    "compatibility-check",
    {
      phpVersion: "8.4",
      wpVersion: "latest",
      networking: true,
    }
  );

  await window.playgroundSites.saveInBrowser(
    "Compatibility check - PHP 8.4"
  );

  await window.playgroundSites.isReady();
  const client = window.playgroundSites.getClient();
  if (!client) {
    throw new Error("The compatibility site has not booted yet.");
  }

  const response = await client.run({
    code: `<?php
require_once "/wordpress/wp-load.php";
echo wp_json_encode([
  "site_url" => get_site_url(),
  "php" => phpversion(),
  "wp" => get_bloginfo("version"),
  "theme" => wp_get_theme()->get("Name"),
]);
`,
  });

  return {
    site: window.playgroundSites
      .list()
      .find((site) => site.slug === slug),
    info: JSON.parse(phpResponseText(response)),
  };
}

console.log(await prepareCompatibilitySite());

This is not a replacement for a full test suite. It is a fast way to prepare and inspect a browser-based testing site when you are triaging a report.

How this fits recent Playground updates

Recent Playground work also added deeper AI and browser automation hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. through MCP and WebMCP. The same centralized site management API supports those integrations, so AI agents and browser-native tools can manage Playground sites through explicit operations instead of clicking through menus.

For example:

• list() maps naturally to “show me my Playground sites.”
• setActiveSite(slug) maps to “open the site named Plugin compatibility test.”
• saveInBrowser(name) maps to “save this reproduction so I can come back later.”
• getClient() gives tool layers access to PHP execution, HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. requests, and filesystem operations.

The result is a cleaner foundation for agent workflows. A coding agent can keep one site for investigation, another for a clean reproduction, and another for verifying a fix, all without depending on visual UI state.

For setup instructions, see Connect AI coding agents to WordPress Playground with MCP. For URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org-based configuration options such as php, wp, networking, and site-slug, see the Query API documentation.

Practical limits

There are a few details to remember:

• window.playgroundSites is only available after Playground finishes loading saved sites.
• Temporary sites must be saved before you can rename them, delete them, or update their PHP/networking settings.
• Call isReady() before getClient() when the active site may still be booting. Until the site is ready, getClient() can return undefined.
• saveToLocalFileSystem() may open a browser directory picker when you do not pass a directory handle.
• Browser storage is still browser storage. Clearing site data can remove saved Playground sites.

Try it

Open playground.wordpress.net, wait for the site to finish loading, then open DevTools and run:

await window.playgroundSites.isReady();
window.playgroundSites.list();

From there, create a temporary site, save it, switch between saved sites, and use getClient() to inspect WordPress state with PHP. For plugin and theme developers, this turns Playground from a single sandbox into a small fleet of browser-based test environments.

The playground team has been working on a brand-new interface for WordPress Playground, and we would love your help testing it before it officially launches. Whether you are using a laptop or a mobile phone, we want to know how the new UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. feels, responds to, and works with your clicks and taps.

You do not have to test everything. Pick one or two modules below, explore them, and tell us what worked well or what could be improved.

🔗 Test environment: Open the new Playground UI

What We Are Looking For

While testing, please pay attention to:

• Clear text: Are buttons, labels, descriptions, and instructions easy to understand?
• Logical mechanics: Do workflows behave as you expect? Is it clear what each action will do?
• Design issues: Do you see overlapping text, clipped content, missing controls, or broken layouts?
• Helpful feedback: What feature or small change would make the experience smoother?

Testing on Desktop and Mobile

If possible, try the UI in both a desktop browser and a mobile browser.

On mobile:

• Swipe the bottom toolbar horizontally to find tools that are not currently visible, such as Files, Logs, or Export.
• Tool panels open over the site. Use the X button to close a panel.
• In the Files panel, tap Browse files to open the file tree.
• Use the file upload control instead of drag and drop.

Please do not upload private files, passwords, APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. keys, or other sensitive information while testing.

Choose Your Testing Adventure

Module 1: Create and Manage Playgrounds

A good starting point for a five-minute test.

1. Open the test environment and wait for the initial Playground to finish loading. A Playground is created automatically when the page opens.
2. Select New in the bottom toolbar.
3. In the Blueprint gallery, select Vanilla WordPress. Selecting the card immediately creates a fresh Playground.
4. Open Site details. Change the WordPress version or PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php version, then select Create a fresh Playground. Verify that the new Playground uses the selected versions.
5. In Site details, select Rename Playground and give it a recognizable name. You can also rename it from Playgrounds → Actions (⋮) → Rename.
6. Open Playgrounds, open the current Playground’s Actions (⋮) menu, and select Save in browser storage. Confirm that its status changes from an autosave to a permanently saved Playground.
7. Refresh the browser. Open Playgrounds, find the site under Saved, and open it again. Saved Playgrounds and Recent autosaves are listed separately.
8. Open the saved Playground’s Actions (⋮) menu, select Delete, and confirm the deletion.

Note: Autosaves are periodic snapshots and may not include every recent change. Use Save in browser storage when you want to keep a Playground.

What to look out for:

• Did the initial and fresh Playgrounds load successfully?
• Was it clear that changing a version creates a fresh Playground?
• Were rename, save, restore, and delete actions easy to find?
• After refreshing, was the difference between Recent autosaves and
  Saved clear?
• Could you reach every action comfortably on mobile?

Module 2: The Blueprint Experience

Test the different ways to start and inspect a custom setup.

1. Select New → Blueprint gallery.
2. Search or browse the gallery and read the descriptions shown on the cards.
3. Select a Blueprint card. The card launches a fresh Playground immediately, so there is no separate details screen.
4. After it loads, open Blueprint in the bottom toolbar to inspect its blueprint.json file.
5. Select New → Blueprint URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, enter a publicly accessible Blueprint URL, and select Create Playground.
6. Select New → Write a Blueprint, edit the example JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., and select Create Playground.
7. To keep the resulting site, use Playgrounds → Actions (⋮) → Save in browser storage. To download the Blueprint itself, open Blueprint and select Export.

Be careful: In an editable autosaved Playground, Run Blueprint and reset site recreates the Playground and replaces its files. In a permanently saved Playground, the Blueprint editor is read-only.

What to look out for:

• Was the gallery easy to browse and search?
• Was it clear that selecting a card would immediately create a Playground?
• Did the Blueprint URL and raw JSON workflows show useful validation and error messages?
• Was the difference between saving a Playground and exporting a Blueprint clear?
• Did the selected Blueprint finish without crashing?

Module 3: Files, Database, and Logs

Test the developer tools.

1. Launch a Playground and open Files.
2. On mobile, select Browse files to reveal the file tree.
3. Try Create new folder and Create new file. Enter a name, confirm it, and verify that the item remains visible after you select something else.
4. Open a harmless file such as readme.html, or use the test file you just created. Add a short comment, select Save file, reopen the file, and confirm that the change remains. Avoid editing wp-config.php for this test.
5. Use Upload files to upload a small, non-sensitive test file. On desktop, you may also try dragging a test file into the file manager and report whether that works.
6. Open Database. Select Open Adminer or Open phpMyAdmin, then browse a table without changing its data. If the viewer cannot install or reports a download/fetch error, include the exact error in your feedback.
7. Open Logs. Confirm that you see either a clear Nothing logged yet state or relevant PHP, WordPress, and Playground messages. If you are comfortable doing so, trigger a harmless warning in a test file and check whether it appears.

What to look out for:

• Did newly created files and folders persist after focus moved elsewhere?
• Was the editor comfortable to use with a mobile keyboard?
• Were save and upload results clearly communicated?
• Did Adminer or phpMyAdmin open successfully? Were installation errors useful?
• Did the Logs panel clearly explain an empty state and distinguish message types?

Module 4: Import, Export, and Sharing

Test how Playground data moves between environments.

1. In an active Playground, open Export.
2. Under Download a copy, select Download as .zip. The ZIP should contain the current files, database, and edits.
3. Select New → Import zip → Choose a .zip file… and import the ZIP you just downloaded.
4. After the imported Playground loads, check that its pages, settings, files, and content were restored.
5. Open Export and select Copy link. Paste the result somewhere safe and verify that it is a usable URL. Important: This link recreates the original Blueprint setup only. It does not include later edits to files or content.
6. Optionally, test Export to GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ using a disposable repository you can modify safely. Connect your GitHub account and try exporting a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party., theme, or wp-content directory. The GitHub connection is not retained after a browser refresh.

👀 What to look out for:

• Did ZIP creation finish in a reasonable time?
• Did importing the ZIP restore the current site accurately?
• Did the UI clearly explain what the copied link includes and excludes?
• Were clipboard permission errors understandable?
• Was the scope of the GitHub export clear before anything was pushed?
• Were success, progress, and error messages helpful?

How to Share Your Feedback

Found a bug or have an idea for a better workflow? Please include:

• Your device, operating system, and browser.
• The module and step you tested.
• The steps needed to reproduce the problem.
• What you expected to happen and what actually happened.
• Your thoughts on text clarity, mechanics, and visual design.
• Screenshots or short screen recordings, when possible.

Remove private information, access tokens, repository secrets, and personal files from screenshots or recordings before posting them.

👉 Share feedback, bugs, and ideas in the official GitHub issue:

New Dock UI review — Issue #4092

You will need to sign in to GitHub to post a comment.

Thank you for helping us make WordPress Playground better for everyone. Happy testing! 🚀