WordPress reaches full-suite effective parity as the Axum server phase begins.

The 30 July coverage snapshot records 1,017 internal functions out of 2,143, 539 / 654 core functions and 2,649 passing Zend tests. The application milestone is larger still: the complete WordPress core suites now run at effective oracle parity.

Complete WordPress baselines

The one named difference is deliberate and documented: stream_get_wrappers() lists only wrappers phpr actually implements. Returning a larger, plausible list would violate the project's “correct or absent” rule.

The workload also drove broad extension work: media byte parity through system libgd plus native EXIF and fileinfo, XSLT through system libxslt with PHP callbacks, complete ext/tidy through libtidy, SAX XML, broader mbstring codecs, Argon2 password hashing and an intl subset.

Watch WordPress running on phpr

This recording shows the project working against a real WordPress installation and provides a visual companion to the measured test and HTTP results described above.

Video hosted by Loom. Open the recording on Loom ↗

Measured language and extension coverage

Performance and memory became measured engineering

The optimization work is not summarized by a single benchmark. The current reference band places full-suite CPU at 2.06–2.11× of the oracle, down from roughly 4.1×; the WordPress media group is at 2.58×, with a current footprint band around ~3.0–3.1×.

The path included a Zend-style cycle collector, in-node GC walk marks, descriptor ownership fixes, growable strings, a keyless hashed-array index, compile-side stub elision and exact memory census work. Most importantly for a resident server, WP-72 reduced the measured residual from about 2.11 KiB per request to 0.0010 KiB/request, with 0.000 retained objects per request in the defining triplet.

The Axum worker-actor phase

With request teardown measured flat, the project opened the Axum route. A VM contains Rc-based state and is !Send, so the accepted architecture pins ownership to dedicated OS-thread workers and dispatches requests through message passing. The current queue is still unbounded; bounded backpressure remains a shipping gate.

At the current snapshot, the worker path explicitly executes request_start → vm.run → request_shutdown → request_end. Each dedicated worker now keeps one RetainSet for its lifetime, and two sequential requests through that worker passed the byte-parity gate. The request still receives a newly compiled module and a fresh VM, so this is persistent worker state—not yet reuse of the same VM instance.

The next proof boundary

The next gates are intentionally narrow: two requests through the same VM must match a fresh run; a K=10 amplification must stay flat; fresh and reused paths need an oracle pair; and shutdown order must be verified for handlers, buffers, destructors, sessions and failures. Only after those gates can throughput, queueing and long-lived worker economics be measured honestly.

Laravel remains the next major framework validation target after the current performance and server boundary work, while extension gaps and robustness continue in parallel.