FAQ

Frequently asked questions.

Maturity, compatibility, architecture and realistic expectations for the project.

Is phpr production-ready?

No. It is an experimental runtime under active development. WordPress, MySQL, HTTP and large application suites are real milestones, but security review, packaging, cross-platform validation, extension completeness and sustained-load behavior are not ready for a production PHP replacement.

Does WordPress actually run?

Yes, in the measured development environment. WordPress 7.0.1 installs on real MySQL through native MySQLi and is served through phpr -S; front pages, login, REST, wp-admin, pretty permalinks and media paths have byte-parity gates. The full single-site and multisite test suites are at effective oracle parity.

Why say “effective parity” instead of zero differences?

Each complete WordPress suite has one declared test-name difference. stream_get_wrappers() lists only wrappers phpr truly implements rather than pretending user-registered wrappers are available. The difference is documented and stable by name.

Is this a PHP-to-Rust transpiler?

No. phpr parses PHP source, lowers it into intermediate representations, compiles bytecode and executes that bytecode in a VM written in Rust.

Which PHP version is the oracle?

The current oracle is PHP 8.5.7. Global function and Zend-corpus figures use the complete measurement from 30 July 2026; the server-lifecycle status is updated through 31 July 2026.

Do existing C extensions work?

Not as binary-compatible PECL modules. Some surfaces are native Rust implementations, such as MySQLi and fileinfo. Others use focused FFI to system libraries such as libgd, libxslt, libtidy and zlib, with behavior still verified against PHP.

Is phpr faster than PHP?

Not generally. Current WordPress measurements put full-suite CPU in a 2.06–2.11× reference band and the media group at 2.58× of the oracle. The project has made large, measured gains, but these are development benchmarks rather than a production performance promise.

Is the new Axum server already persistent and async?

Not yet. Axum and a dedicated-thread worker-actor architecture exist, the lifecycle is explicitly wired, and each worker now keeps a persistent RetainSet. The current path still creates a fresh VM per request; same-VM reuse gates, load evidence and native non-blocking I/O remain future steps.

Is the project affiliated with PHP, Rust or WordPress?

No. It is an independent project. PHP, Rust and WordPress are named to describe the compatible language, implementation technology and principal application workload.

How can I contribute?

Choose an official test, extension gap or request-lifecycle fixture; reproduce it under PHP 8.5.7, implement the smallest faithful difference and rerun the relevant named gates without regressions.