July was the month SandyWP stopped being only a place to make a WordPress site quickly and became a place you can actually work in one.
The through-line across almost everything below is access. Getting into a sandbox, over SSH, over SFTP, from GitHub, from Slack, from a terminal, from an AI assistant, rather than only clicking around wp-admin.
Here is the whole month, grouped by what it lets you do. Every item is on the changelog too, in the order it shipped.
Review a pull request in real WordPress
The largest thing in July: SandyWP for GitHub.
Install the first-party GitHub App, enable a repository, and a repository owner, member, or collaborator can comment on an open pull request:
@sandywp-bot deploy
SandyWP creates a WordPress sandbox running that pull request's exact head commit, installs the code as a plugin, theme, or wp-content folder, activates it, and replies with the URL in one comment it keeps updated.
Push more commits, comment deploy again, and the same preview updates in place. The URL and the database survive, so your test content does not evaporate.
The preview lives as long as the pull request does. Merge or close it and normal cleanup begins, or run @sandywp-bot delete to do it sooner.
Some details from the build that are worth knowing up front:
- Private repositories work. SandyWP mints a short-lived GitHub App installation token per job, so there is no deploy key and no stored personal access token.
- The pull request head is authoritative. There is no "deploy some other branch" command, because a comment should not get to choose what code runs.
- No build step runs. Previews deploy exactly what is committed. Commit your build output or point the preview at an installable subdirectory.
- wp-admin login links are off by default. A repository can enable them on request or for every preview. But a magic login URL is a reusable bearer link, and GitHub comments end up in notifications and logs. On a public repository that means the whole internet, so off by default was the only sane choice.
Previews use your ordinary site quota. Each one is a normal account-owned sandbox that shows up in your dashboard.
Get inside the box: SSH, SFTP, and mounting
A disposable site you can only reach through wp-admin is a limited kind of disposable site. In July that changed twice.
First, the SSH gateway learned the SFTP subsystem, which makes a sandbox mountable. Then the CLI got two commands on top of it:
sandywp ssh
sandywp mount
mount gives you the sandbox's filesystem as a folder in Finder. You edit a theme file in your normal editor and reload the browser.
No deploy step, no sync tool, no FTP client. See SSH & SFTP and the CLI.
macOS was the fiddly part, as it usually is. The CLI manages its own rclone binary because the Homebrew build cannot mount on macOS, and July included a round of mount tuning for macOS specifically.
Find out why it broke
Three separate releases, all aimed at the gap between "the site is white" and "here is the actual error".
Debug mode. A per-site Debug section that flips WP_DEBUG and friends on, then shows you debug.log in the browser.
Later in the month the viewer gained colour-coded severity, filtering, and a severity pill on each entry, because an unfiltered debug log is mostly noise. It is available on every plan.
Email Log. Every email your sandbox tries to send is captured and viewable, and never delivered.
This solves a genuinely annoying class of problem. You are testing a WooCommerce order flow or a password reset on a throwaway site, and the mail either vanishes silently or, much worse, actually reaches a real customer address left in your test data.
Now it lands somewhere you can read it. The capture also detects plugins that replace wp_mail() outright, not just the ones that hook phpmailer_init, and SMTP relay support with delivery tracking landed alongside it.
Reset to a clean slate. One click returns a sandbox to a fresh install on the same URL.
That is useful when you have spent twenty minutes wrecking a site and want to start the test again without waiting for a new one to provision. It also helps with the class of bug that only shows on a clean install.
Related: an expired sandbox can now be restored back to a running site rather than being gone for good.
Drive it from wherever you already are
AI assistants. SandyWP now runs a remote MCP server with OAuth, so you can connect it as a connector in Claude and create, inspect, deploy to, and delete sandboxes in conversation.
Later in the month an llms.txt quickstart landed, so pointing any assistant at sandywp.com is enough for it to work out how to set a sandbox up. See AI & MCP.
The terminal. The CLI can deploy a local plugin ZIP straight from your machine, and assistants connected over MCP now automatically take that faster path instead of the slow one.
Slack. The Slack app grew a lot this month.
Name wordpress.org plugin slugs in a mention and they get preinstalled on the new sandbox alongside any ZIP you attach, or added in a batch to an existing one. A slug that does not exist comes back as a suggestion rather than a quietly missing plugin.
You can also pick the WordPress version by shorthand, and a Block Kit command guide answers help.
Git. Git deployment added a one-off deploy from a tag or release, so you can ship v2.4.1 into a sandbox without disturbing the branch and auto-deploy you have configured.
Inline editing of the deployment config, a branch picker, and one-off branch deploys landed the same week.
Set up an environment once and reuse it
Blueprints arrived in late July: an environment described as a file.
So "WordPress 7.0.2, PHP 8.3, these six plugins, this theme, this content" becomes something you create in one step, instead of assembling it by hand every time.
Blueprints are also manageable from the CLI and from a connected AI assistant, and can be baked into a shareable demo site from CI.
They deliberately follow the shape WordPress Playground documents, so a Blueprint you already have has a good chance of working.
Faster, and on more versions of WordPress
Plugin preinstallation moved into the warm pool, with a wp-cli ZIP cache. The plugins you asked for are now on the site when it appears, rather than installing after you get the URL.
The create dialog will preinstall up to ten wordpress.org plugins and streams per-plugin progress while it works.
On versions: stable moved to WordPress 7.0.2, and the preview option in the create dialog tracked 7.1 through Beta 1, Beta 2, and Beta 3 across the month.
Testing your plugin against the next major before it ships is the entire point of the beta option.
Smaller things that matter
- A real changelog.
/updatesbecame/changelog, with proper release notes rather than a list of commits. - Sign in with GitHub, alongside Google.
- Shift-click range selection in the sandboxes table, and a row context menu.
- Storage quota enforcement on site imports, measured on the worker from the unpacked size. An import that would blow past your plan now fails clearly instead of half-succeeding.
- The Cloner plugin gained an OAuth connect flow, a redesigned admin UI, and a live progress bar during restores.
- A redesigned homepage, footer, and sign-in, plus the first batch of feature and use-case pages.
What we are still working on
Honest version: two of July's biggest additions are new enough to have rough edges.
GitHub previews do not run npm or Composer, which is the most common thing people ask for.
And Blueprint coverage of every Playground feature is not complete. The compatibility details are surfaced in the UI rather than hidden, so you can see what will and will not be applied before you run one.
If you hit either, tell us. Most of what shipped in July started as somebody explaining what they were trying to do and why it was annoying.
Everything above is live now. The changelog has each release with its date.
