Problem
Bounded runtime entries with processIdentity require isolated PHP state while reusing one Playground server, its mounted filesystem, extensions, and runtime services.
The current HTTP request-worker approach does not provide that isolation: the request worker may already have loaded the managed WordPress installation. A project-owned PHPUnit bootstrap that loads its own WordPress tree then fails on inherited symbols such as add_filter(). Generic proc_open() spawning remains inside the same PHP-WASM environment and does not solve the collision.
Project bootstrap mode also currently prepends the managed /wordpress/wp-load.php, which violates project ownership, while PHPUnit configurations without a bootstrap are rejected even though native PHPUnit accepts them.
Upstream dependency
WordPress Playground issue: WordPress/wordpress-playground#4145
WordPress Playground PR: WordPress/wordpress-playground#4146
The Playground PR exposes runInFreshProcess() with preserved mounts/configuration and collision-free concurrent code execution.
Required changes
- Route bounded code executions with a process identity through
playground.runInFreshProcess().
- Remove the HTTP request-worker endpoint and payload-file transport.
- Preserve per-entry runtime environment injection, including
bootstrap=none.
- Let project bootstrap mode own WordPress loading instead of prepending managed
wp-load.php.
- Permit project-mode PHPUnit configurations that declare no bootstrap.
- Fail clearly when the selected Playground backend lacks clean-process support.
Acceptance criteria
- A project bootstrap may define
add_filter() without colliding with managed WordPress symbols.
- Concurrent bounded entries retain isolated PHP state and their own service environment.
- Existing non-bounded Playground commands retain current behavior.
- Focused runner/bootstrap tests pass.
- Downstream TeamCity-equivalent validation passes all 680 PHPUnit suites with zero failures, timeouts, or cancellations.
Problem
Bounded runtime entries with
processIdentityrequire isolated PHP state while reusing one Playground server, its mounted filesystem, extensions, and runtime services.The current HTTP request-worker approach does not provide that isolation: the request worker may already have loaded the managed WordPress installation. A project-owned PHPUnit bootstrap that loads its own WordPress tree then fails on inherited symbols such as
add_filter(). Genericproc_open()spawning remains inside the same PHP-WASM environment and does not solve the collision.Project bootstrap mode also currently prepends the managed
/wordpress/wp-load.php, which violates project ownership, while PHPUnit configurations without a bootstrap are rejected even though native PHPUnit accepts them.Upstream dependency
WordPress Playground issue: WordPress/wordpress-playground#4145
WordPress Playground PR: WordPress/wordpress-playground#4146
The Playground PR exposes
runInFreshProcess()with preserved mounts/configuration and collision-free concurrent code execution.Required changes
playground.runInFreshProcess().bootstrap=none.wp-load.php.Acceptance criteria
add_filter()without colliding with managed WordPress symbols.