[Website] Route WordPress through wasm.wordpress.net on WP Cloud - #4468

#4511 added the ?reprint opt-in and is merged. This PR adds the WP Cloud host rule and deployment wiring on trunk. It uses the single-range static-file responses merged in #4507.

Keep the app, Dock, PHP runtime, and storage on playground.wordpress.net. With ?reprint, render WordPress on wasm.wordpress.net. Without the flag, WordPress stays on the app domain.

playground.wordpress.net        address bar, app, trusted PHP runtime
└── wasm.wordpress.net         WordPress iframe, only with ?reprint

Request handling

All host and path rules live in the existing packages/playground/website-deployment/custom-redirects-lib.php, reached through playground_handle_request(). Only the configured WordPress host (wasm.wordpress.net in production) takes an early path that serves the wordpress-sandbox/ subdirectory. Other hosts continue through the existing app logic. There is no separate router or parallel app handler.

• The app host keeps the existing request handler: rewrites, conditional and unconditional redirects, directory indexes, MIME types, custom headers, cache exceptions, HEAD handling, and native PHP environment setup. There is no replacement app handler or new app-side PHP allowlist.
• The WordPress host serves existing files only from the built wordpress-sandbox/ directory. It contains the small request-helper page and service-worker/thumbnail-worker loaders. Missing files and paths escaping the directory return 404. No app redirects or native PHP endpoints run on this host. WordPress pages come from its browser service worker.

files/
├── index.html, remote.html, api.html, assets/, ...
└── wordpress-sandbox/
    ├── wordpress-bridge.html
    ├── sw.js
    └── assets/<hashed-thumbnail-worker>.js

The build writes app-origin URLs into those small files once. PHP serves their bytes without constructing JavaScript or rewriting HTML for each request. The worker filename comes from Vite's source-file mapping, so there is no PHP list of hashed filenames or query-based exception for arbitrary JavaScript files.

Both hosts use the same app-host bundles, PHP binaries, and WordPress downloads. Assets allow cross-origin loading and HTTP caching. Static-file transfers use the range support from #4507. Existing app cache exceptions remain, including no-store for the app/API entry pages and identity encoding for static ZIP archives. Sandbox bootstrap responses use private, no-store.

Existing external iframe and SDK embeds keep working without a referrer or new URL parameters.

Normal deployment

The website deployment workflow sets the two origins once:

PLAYGROUND_APP_ORIGIN: https://playground.wordpress.net
VITE_WORDPRESS_SITE_URL: https://wasm.wordpress.net

Vite uses VITE_WORDPRESS_SITE_URL for the browser's sandbox selection and PLAYGROUND_APP_ORIGIN for the sandbox files' shared-script URLs. The SSH step passes those same values to apply-update.sh. That one script checks the origins, installs the release, replaces the entry, and purges the edge cache. There is no second installer script. The entry records the sandbox origin; the PHP library and deployment script do not hardcode production domains. Request headers and query parameters cannot change the configuration.

apply-update.sh installs the setup as follows:

1. Check that the required build entry files exist. Check both public hosts and direct access to a harmless private-path probe. Refuse activation if private URLs are readable or a service-worker URL redirects.
2. Put the complete build and request library under /srv/htdocs/.playground-releases/release.<random>/.
3. Back up the old public entry and move old public build files outside htdocs. Otherwise Nginx could serve them on the WordPress host before PHP checks the hostname. A failed file move stops activation.
4. Replace custom-redirects.php in one rename. It calls the existing library with that release's build path. Retain previous private releases and entry files for rollback, then purge the WP Cloud edge cache.

Personal WP keeps its existing entry, file layout, and separate deployment script. Native PHP endpoint credentials still come from WP Cloud persistent data.

Before activation

Both names must map to the same WP Cloud site, with valid TLS and canonicalize_aliases=false. Nginx must deny direct access to .playground-releases, including encoded paths. PHP cannot create that deny rule; the deployment script checks for HTTP 403 through both hosts before putting the build there.

wasm.wordpress.net currently redirects to the app. Removing that redirect does not clear a browser's cached 301. Test the helper and service-worker URLs with the old redirect cached before activating this setup.

The first deployment moves the old public build and can briefly interrupt requests. Later deployments retain the previous private release. The deployment guide covers verification, rollback, and removing obsolete backups.

Limits

The separate-origin protections apply only to sessions started with ?reprint. Ordinary sessions still run WordPress on the app origin and can access its OPFS and CacheStorage, including data used by opted-in sessions. Reopening a saved clone without the flag returns its WordPress code to the app origin.

WordPress cannot directly read an existing parent document or its OPFS, or call its connected PHP API. It can still embed a fresh app/API document and connect to that document. That path to saved storage remains unresolved. This is not complete protection for saved files or native directory handles. Running Playgrounds still share one WordPress origin, without per-site HTTP authorization.

Testing

The contract test builds the real sandbox directory, runs the complete apply-update.sh in a temporary directory, and tests the installed PHP entry. Public probes and the cache-purge API are stubbed. The preview and upgrade-test servers also serve the built sandbox directory, so the browser suite exercises that file-serving path. Checks use alternate configured hostnames and cover invalid origin settings, incomplete uploads, failed private-path/redirect probes, failed old-file moves, sandbox restrictions and symlink/traversal rejection, existing redirects (including referrer-based redirects), directory/index handling, set-aside files, the plugin-proxy rewrite and persistent-data setup, native PHP HEAD behavior, custom cache/agent-cluster/archive headers, shared-asset headers, integration with #4507's static-file sender, HEAD/OPTIONS, release switching, and rollback files. These tests do not prove the live Nginx or TLS configuration.

Follow the deployment guide to check both HTTPS hosts and blocked private URLs. Save a post, switch saved sites, open a database tool, try a disposable local folder, and test an unchanged no-referrer embed. Confirm WordPress cannot read or alter a private OPFS file created by the parent.