[wasm-posix-kernel] WordPress Playground Web under wasm-posix-kernel - Proof of concept

[mho22]

Summary

Adds an experimental dev:experimental-posix-kernel mode to the Playground website that boots WordPress in an iframe under nginx + PHP-FPM running on wasm-posix-kernel, instead of the existing PHP.wasm Asyncify/JSPI runtime.

This PR is stacked on top of #3604 (the CLI-side proof of concept). The first 15 commits in this PR belong to that PR; the last 7 are the new web work — see "Commits" below. Like #3604, this is for visibility / posterity, not ready to merge: it depends on the same five upstream-pending kernel fixes tracked in mho22/wasm-posix-kernel#50.

The constraint while implementing was additive only — every change is a new file under packages/playground/remote/ or packages/playground/website/, plus three minimal sibling edits (package.json script, two project.json targets, one new vite config per package). The classic npm run dev path is untouched and continues to boot Playground exactly as before.

What this adds

A new npm run dev:experimental-posix-kernel script that:

1. Boots the website at http://127.0.0.1:5400/website-server/ with COEP credentialless + COOP same-origin overlaid on the parent document, so an embedded iframe can be cross-origin isolated and use SharedArrayBuffer.
2. Serves the remote iframe at :4400 with COEP require-corp, COOP same-origin, DIP isolate-and-require-corp, Service-Worker-Allowed: /, and aliases /remote.html to a sibling /remote-posix-kernel.html entry.
3. From inside the iframe, spawns a Comlink worker that:
   • downloads WordPress + the SQLite integration through the existing CORS proxy (allowlist broadened to wordpress.org / downloads.w.org / GitHub),
   • builds a SAB-backed VFS image (binaries, /etc files, nginx + php-fpm configs, fpm-router, wp-config.php, wasm-optimizations mu-plugin, dinit service tree, streaming zip extraction),
   • boots BrowserKernel + HttpBridgeHost, polls waitForNginx until any HTTP status comes back,
   • runs the WordPress install over HTTP POST against the in-kernel server,
   • exposes LimitedPHPApi via a KernelLimitedPHPApi shim so existing v1 blueprint steps work against the kernel-resident WordPress.
4. Forwards every iframe HTTP request to the in-kernel nginx via requestStreamed (scope strip → origin-form → Host + x-playground-absolute-url injection → COEP/COOP/CORP header injection on the response).

Demo:

WASM_POSIX_KERNEL_DIR=/path/to/wasm-posix-kernel \
  npm run dev:experimental-posix-kernel
# Open http://127.0.0.1:5400/website-server/ in incognito Chrome

Commits (web port)

Only the last 7 commits are new in this PR — the first 15 are inherited from #3604:

1. 993af91 Experimental posix-kernel (web): nginx + PHP-FPM VFS image
2. bd5e063 Experimental posix-kernel (web): WordPress preparation
3. 869845e Experimental posix-kernel (web): kernel boot orchestrator
4. 57edf38 Experimental posix-kernel (web): KernelLimitedPHPApi shim
5. ad93171 Experimental posix-kernel (web): Comlink worker endpoint
6. f2b71de Experimental posix-kernel (web): iframe boot + entry HTML
7. 5abc1c4 Experimental posix-kernel (web): Vite configs + nx target

Why this is experimental

• Stacked on [wasm-posix-kernel] WordPress Playground CLI under wasm-posix-kernel - Proof of concept #3604 — which itself depends on five unupstreamed kernel-side fixes (PHP-FPM stack-size, kernel wakeBlockedPoll snapshot, host chown error swallowing, node-kernel-worker-entry bundle, PHP wasm size optimization) tracked in mho22/wasm-posix-kernel#50.
• Submodule pinned to a DO NOT MERGE - CI artifact branch in wasm-posix-kernel because release-tag artifacts aren't fetched by the in-tree workflow yet. The submodule needs its own upstreaming before this PR is mergeable.
• Auto-login mu-plugin not yet ported. Classic Playground's login blueprint step relies on a cookie-setting mu-plugin in packages/playground/wordpress/src/index.ts. Kernel mode has KernelLimitedPHPApi.defineConstant + a playground-defines.php mu-plugin to inject PLAYGROUND_AUTO_LOGIN_AS_USER, but the cookie-setting half isn't wired. A defensive goTo unwrap in boot-playground-remote.ts short-circuits the V1 redirection-handler URL in the meantime; once auto-login lands the unwrap must be removed.
• Normal-mode Chrome serves the WordPress zip truncated from the HTTP cache (keyed to downloads.w.org / GitHub, outside our origin, so site-data clears don't touch it). DevTools → "Disable cache" boots cleanly. Incognito is the workaround for now.
• Production / build / preview paths are out of scope. The new vite config covers dev only; the website's existing build pipeline is untouched.

Notable design choices

• Cross-origin isolation — three headers on the iframe, two on the parent. SAB requires COI; for an embedded iframe to be COI'd both the iframe response and the parent document must opt in. The parent uses COEP credentialless so cross-origin sub-resources (analytics, Octokit) keep loading without CORP. WordPress front-end responses don't ship COEP themselves (only wp_set_up_cross_origin_isolation on wp-admin pages), so requestStreamed injects COEP/COOP/CORP on every bridge response before constructing the PHPResponse.
• x-playground-absolute-url on every bridge request. wp-config reads the header and uses it as WP_HOME / WP_SITEURL — avoids a boot-time substitution pass. nginx doesn't auto-forward arbitrary headers to fastcgi, so both location blocks in the in-VFS nginx config explicitly pass it through.
• Origin-form URL on the bridge. requestStreamed strips the scope and reduces to origin-form before posting to the bridge. Absolute-URI form hangs nginx — RFC 7230 §5.3.2 allows it on origin servers but the kernel-resident nginx doesn't.
• /cors-proxy.php? instead of /cors-proxy/?. offline-mode-cache.ts:shouldCacheUrl returns true for cors-proxy URLs (same-origin in dev), routing them through cacheFirstFetch which truncates around 19 MiB on HTTP origins. Pathnames ending in .php short-circuit the cache, so the .php? form bypasses it; the vite cors-proxy prefix still forwards because the rewrite no-ops for .php? paths.
• Late-binding LimitedPHPApi over Comlink. The worker endpoint installs throwing stubs for every name in LIMITED_PHP_API_METHODS at construction; doBoot constructs a KernelLimitedPHPApi and rebinds those names via bindApiMethods. Comlink resolves method paths at message-receive time, so post-boot rebinding is visible to the iframe immediately.
• waitForNginx polls because dinit returns before services bind. kernel.boot() resolves as soon as the kernel itself is ready, not when dinit's child services have bound their sockets. The boot orchestrator polls GET / until any HTTP status comes back (404 counts — nginx is up).
• Per-spawn output capture via single-slot hook. BrowserKernel's onStdout / onStderr are constructor-time singletons (no per-pid routing). The boot installs a single-slot activeCapture handler that the spawn adapter swaps in before each kernel.spawn and clears in finally; the adapter's inFlight promise serializes spawns so the global slot is unambiguous.

Open follow-ups (deliberately out of scope)

1. Wire auto-login (port the cookie-setting mu-plugin from @wp-playground/wordpress, then remove the goTo unwrap in boot-playground-remote.ts).
2. Normal-mode Chrome zip-cache truncation — either accept "incognito-only for dev" or apply cache: 'no-store' on fetchZipBytes.
3. Build / preview / production bundling. The new vite config covers dev only. Production paths need a separate pass once the kernel artifacts are npm-installable.
4. Replace the wasm-posix-kernel submodule with an npm-installable package — same blocker as [wasm-posix-kernel] WordPress Playground CLI under wasm-posix-kernel - Proof of concept #3604.

Test plan

The 25 existing playground-remote unit tests continue to pass:

npx nx test playground-remote

Manual boot in incognito Chrome:

WASM_POSIX_KERNEL_DIR=/path/to/wasm-posix-kernel \
  npm run dev:experimental-posix-kernel
# Open http://127.0.0.1:5400/website-server/

The iframe should render the WordPress front page end-to-end.

🤖 Generated with Claude Code