How to Test WordPress PHP Snippets with Playground (and Why wp-now Is Done)

On 8 June 2026 the Playground team published the deprecation notice: wp-now is done; migrate to the Playground CLI. A few weeks earlier, on 19 May, they shipped Run PHP examples anywhere with WordPress Playground — an official guide for embedding runnable PHP as Playground snippets. The June "What's new for developers" roundup put both in the same section for a reason. The project is standardizing on one way to spin up WordPress in a browser or a local CLI, and they want docs and reviews to use it.

If your current "test" is activate-on-production-and-hope, this is the week to change the habit. PHP 8.4 is fully supported on WordPress 6.8+ as of the May 2026 support clarification, 7.0 is days old, and fatals from dynamic properties and stricter types are showing up in snippet libraries. Testing is not optional polish.

What Playground is (and is not)

WordPress Playground runs WordPress in the browser via WebAssembly. No host, no Docker required for the simple case. You can pin a WordPress version, a PHP version, and a set of plugins. The CLI is the replacement for wp-now when you want the same engine on disk, in CI, or in a PR preview.

It is not a clone of your WooCommerce catalog. It will not reproduce a host-specific php.ini, an object cache drop-in, or Imagick/Ghostscript on a particular host. Use it to answer: *does this PHP parse, hook, and render on a clean site at this WP/PHP pair?*

For money paths, still use staging. For "does this filter notice on 8.4," Playground is faster than a full staging refresh.

A snippet-sized workflow

1. Recreate the smallest site that can exercise the snippet. If the snippet targets WooCommerce checkout, install WooCommerce in the Playground blueprint. If it targets a CPT you registered in another snippet, load both. Isolated tests that omit the dependency produce false greens.

2. Match PHP to production. The May clarification retired the "beta" label on PHP 8.x. Recommended production is 8.3+; hosts are moving to 8.4. If production is 8.4 and Playground defaults older, you will miss the fatal. Pin php: 8.4 in the blueprint.

3. Paste or mount the snippet as a plugin file, not as a theme edit. A mu-plugin or a single-file plugin is the right shape. If you already use a file-based manager (FluentSnippets, SnipVault), you are mounting a file you already have. That is the hidden benefit of file-based storage.

4. Trigger the hook on purpose. Load the front end, wp-admin, a REST route, WP-CLI inside the CLI. A snippet that fatals only on admin_init will look fine on the home page.

5. Read the error, do not just reload. Playground surfaces PHP errors if you ask it to. A white screen without a log is how people "test" and still ship.

Official PHP snippet embeds

The 19 May Playground post is aimed at people who write documentation: you can embed a runnable PHP example so the reader executes it in the browser instead of copying blindly into functions.php. If you maintain internal runbooks or client handoff docs, steal that pattern. "Here is the snippet" plus "here is a Playground that already has it active" beats a gist.

Version 3 of the Playground GitHub Action (guide published 2 June 2026) is the complementary piece for plugin authors: PR previews that boot WordPress. Snippet libraries that live in GitHub can use the same idea — a preview that loads the branch's snippet directory.

Where SnipVault fits

Playground is an environment. It does not replace a deploy gate.

In SnipVault the Snippet Engineer runs a sandbox probe against the site you are actually editing: the PHP executes in a request that is allowed to fatal without taking down the admin. That catches the class of bugs Playground also catches (parse errors, missing functions, 8.4 type fatals) plus the class it cannot (this site's plugins, this site's object cache).

The sequence we recommend for anything that can take checkout down:

• Draft on a Playground or local CLI at the right PHP version
• Open a PR if you use GitHub sync
• Probe on staging via the sandbox
• Publish to production with the security audit still green

Skipping to the last step is how you get the incident in recover from a fatal PHP error.

Migrating off wp-now

If your muscle memory is npx wp-now start, read the 8 June Make/Playground post and switch the alias. The CLI is the supported local path. Saved Playgrounds and the Sites API (v3.1.35 and neighbours) are what you want for demos you reopen next week instead of re-clicking a blueprint.

Do not keep a shadow dependency on a deprecated tool because "it still works." It will not be the thing that gets PHP 8.5 or WordPress 7.1 fixtures first.

A note on AI-generated snippets

Playground is also how you should treat chatbot output. Paste the PHP into a disposable site, not into production. Core now has an AI Client and Connectors as of 7.0; more generated code is going to land in snippet plugins whether we like it or not. The Abilities API makes agents more capable. It does not make their first draft correct.

If the agent lives in admin — ours does — the sandbox is the Playground-shaped step that runs against *this* stack. If the agent lives in the browser, you are the one who has to open playground.wordpress.net. Either way: do not let the first execution be a customer request.