Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add a native PHP runtime backend for representative performance testing

Aperta
  • Qualcosa non va?
#2,473 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@chubes4 ci sta già lavorando.

Dal 3/9/2026.

  • #2475 di @chubes4 — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
mariadb, php, typescript
Ambito
backend, databases, infrastructure, performance, security

Direzione di ricerca

Inizia con il contratto runtime-backend esistente, i chiamanti di runtime-core e delle ricette, quindi traccia i contratti di managed-service, routing del browser, acquisizione degli artefatti, ciclo di vita e confine di sicurezza. Un backend nativo è completo quando le stesse ricette possono selezionare questo o Playground, acquisire evidenze sulla concorrenza e su OPcache oltre alla provenienza, eseguire i benchmark di baseline e lasciare invariato il comportamento esistente di Playground.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
18
Fork
4
Merge medio
1h 32m
PR unite (30g)
36

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Automattic/wp-codebox

Tutte le issue di Automattic/wp-codebox

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.