Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add a native PHP runtime backend for representative performance testing

Open
  • Is something wrong?
#2,473 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
mariadb, php, typescript
Domain
backend, databases, infrastructure, performance, security

Research direction

Start with the existing runtime-backend contract, runtime-core and recipe callers, then trace the managed-service, browser routing, artifact capture, lifecycle, and safety-boundary contracts. A native backend is done when the same recipes can select it or Playground, capture concurrency and OPcache evidence plus provenance, run the baseline benchmarks, and leave existing Playground behavior unchanged.

Written by the indexing model from the issue text.

Description

Problem

WP Codebox currently executes contained WordPress browser workflows through the Playground PHP-WASM backend. That backend is excellent for portable, isolated functional proofs, but its execution characteristics can dominate application latency and prevent production-representative performance conclusions.

A controlled local benchmark using identical three-command no-op recipes measured:

Runtime First command, including startup Warm command 1 Warm command 2
Large full-stack WordPress application on Playground 39.0 s 17.8 s 14.0 s
Stock WordPress on Playground 34.8 s 0.7 s 0.5 s

Application bootstrap checkpoints attributed roughly 12-16 seconds of each warm request to wp-settings.php, with approximately 235 MB peak memory. The current backend also serializes upstream requests through one PHP instance to protect mutable runtime state. These properties are deterministic and safe, but they differ materially from native PHP with persistent OPcache, concurrent request workers, and a conventional database.

This means Codebox can answer functional and matched-cohort questions, but it cannot currently support claims about production-representative absolute latency for large WordPress applications.

Desired capability

Add an optional native PHP runtime backend behind the existing Codebox runtime-backend contract. The implementation may use a local container or another contained native process model, but runtime-core and recipe callers should remain implementation-neutral.

The backend should provide:

  • Native PHP execution with explicit PHP version provenance.
  • Persistent OPcache configuration and evidence.
  • Multiple request workers or equivalent realistic HTTP concurrency.
  • A disposable conventional database service, such as MariaDB, through existing managed-service contracts.
  • Existing Codebox recipe commands, browser routing, network policy, artifact capture, lifecycle, and safety boundaries.
  • Deterministic teardown and no access to ambient host credentials or production state.
  • Machine-readable backend and environment provenance so results from native and Playground backends cannot be confused.

Acceptance criteria

  • The same backend-neutral WordPress recipe can select Playground or native execution without changing workflow commands.
  • A browser workflow can boot WordPress, execute authenticated fixture requests, and capture existing browser/network evidence on the native backend.
  • Parallel browser requests are served with a documented concurrency model.
  • OPcache status/configuration is captured in reviewer-safe evidence.
  • A baseline benchmark reports cold startup, warm no-op PHP requests, and a dynamic WordPress request for both backends.
  • Native-backend artifacts clearly identify that timings are locally representative evidence, not production RUM.
  • Existing Playground behavior remains unchanged.

Non-goals

  • Replacing Playground as the default portable backend.
  • Adding application-specific paths, constants, fixtures, or package assumptions to runtime-core.
  • Claiming local native measurements are production RUM.

Immediate downstream value

A downstream large-application editor benchmark needs matched feature-on/feature-off latency evidence. Playground can retain the functional proof while this backend provides a credible performance lane using the same recipes and artifact contracts.

AI assistance

OpenAI gpt-5.6-sol via OpenCode assisted with repository inspection, controlled benchmark execution, architecture analysis, and drafting this issue. Chris Huber directed the investigation and tracking decision.

Dominant language
TypeScript
Stars
17
Forks
4
Avg merge
1h 11m
Merged PRs (30d)
39

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/wp-codebox

All issues in Automattic/wp-codebox

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.