WordCamp US 2026 PHP Discussion: Core Compatibility, Upstreaming, and Architectural Strategy

The Technical Divide Between WordPress Core and Modern PHP

During WordCamp US 2026, core contributors gathered under the Chatham House Rule to address the growing technical and cultural gap between the WordPress ecosystem and the broader PHP language community. Historically, WordPress has maintained a highly conservative language adoption strategy to preserve backwards compatibility across millions of deployments. However, this posture has created distinct friction points: WordPress developers are frequently viewed as isolated from modern PHP practices, and core contributors have rarely participated in shaping language evolution via PHP-FIG or the PHP Internals mailing list.

Because language features are debated and voted on within PHP Internals without active WordPress representation, major language decisions often move forward without accounting for the architectural realities of the web’s largest CMS. Conversely, frameworks such as Laravel heavily push for cutting-edge engine features, driving language design toward paradigms that do not always align with WordPress’s legacy requirements. Establishing intentional representation within PHP Internals is now seen as necessary to ensure future engine features account for large-scale CMS architectures.

Backwards Compatibility Constraints and Ecosystem Bottlenecks

The primary blocker in modernizing the WordPress codebase remains its deep commitment to backwards compatibility. Currently, roughly 18% of tracked WordPress sites continue to run on PHP 7.4—a version that reached end-of-life in November 2022. This persistent long-tail requirement prevents plugin developers from using contemporary third-party Composer packages, as modern PHP libraries rapidly drop support for unmaintained runtime versions.

This reliance on legacy runtimes creates a cascade of maintainability issues across the plugin directory:

• Dependency Resolution Conflicts: Modern PHP packages require PHP 8.1+, rendering them incompatible with core’s minimum target.
• Unmaintained Extensions: A large percentage of ecosystem plugins are inactive, with authors no longer updating code to meet modern PHP syntax standards.
• Administrative Escalations: Discussions around mitigating ecosystem drag include directly notifying inactive authors, delisting non-compliant plugins, or enforcing strictest compatibility checks in the WordPress.org repository.

Automated Tooling, PHP_CodeSniffer, and CI Discrepancies

Static analysis and automated testing between repository sub-projects present practical implementation challenges. Code originating from the Gutenberg repository has routinely introduced syntax or standard library calls incompatible with PHP 7.4. These breakages occur because the continuous integration (CI) pipelines and automated tooling configured for Gutenberg differ from the strict rulesets enforced in WordPress Core.

To solve these cross-repo compatibility leaks, core teams are focusing on two primary infrastructure upgrades:

1. Updated Static Analysis: Integrating upcoming releases of PHP_CodeSniffer containing sniffs explicitly tailored for target PHP compatibility ranges.
2. Nightly Docker Environments: Deploying automated local Docker environments that build against nightly PHP snapshots, allowing contributors to run unit test suites against pre-release runtimes seamlessly.

Gating Features, Polyfills, and Runtime Security Isolation

Core contributors re-evaluated the architectural paradigm of using polyfills versus hard feature gating based on the host runtime version. Historically, WordPress has implemented polyfills or custom internal APIs to bridge engine gaps. However, the absence of standardized polyfills has occasionally led to ad-hoc, incomplete, or vulnerable implementations within core.

// Example of conditional feature gating based on PHP engine versions
if ( PHP_VERSION_ID >= 80100 ) {
    // Execute performance-optimized native engine path
    $data = enum_exists( CustomEnum::class ) ? CustomEnum::cases() : [];
} else {
    // Fallback path or degraded execution for legacy runtimes
    $data = CustomFallbackHandler::get_data();
}

While polyfilling allows legacy environments to run newer APIs, some argue it breaks the incentive loop for site owners and web hosts to upgrade their PHP engines. Beyond polyfills, an architectural wishlist item includes advocating for a native PHP language feature that loads modules with sandboxing flags. Under such a system, dependencies or untrusted third-party plugins loaded into the runtime would automatically inherit a “tainted” flag, enforcing strict security policies at the language level.

Upstreaming Web Standards: HTML API and Engine Performance

One of the most actionable opportunities discussed involves upstreaming core WordPress innovations directly into the C-based PHP engine. A prime candidate is the WordPress HTML API, a spec-compliant, high-performance parser designed to navigate and modify HTML documents safely without regex or full DOM trees.

If spec-compliant parsers for web standards were implemented directly in PHP core, WordPress and the broader web could benefit from C-level execution speed for daily web operations:

• HTML Parsing: Moving the HTML API parsing engine into native PHP C extensions.
• URL Handling: Native spec-compliant WHATWG URL parsing within the engine.
• HTTP & Headers: Standardized, low-overhead HTTP header and query string parsing.
• MIME Detection: Enhanced low-level content-type inference.

Sponsoring or directly authoring these engine-level enhancements allows WordPress to improve its own performance profile while contributing meaningful infrastructure back to the broader PHP ecosystem.

WASM Integration and Low-Level Language Experimentation

WebAssembly (WASM) presents another major intersection between WordPress and PHP engine development. WordPress Playground already leverages PHP compiled to WASM to execute entire sites entirely client-side inside the browser or Node.js runtimes. However, previous attempts to advance a WASM RFC within PHP Internals stalled due to a lack of core engine interest at the time.

Revisiting WASM with the PHP core team offers distinct security and operational advantages. Compiling specialized PHP extensions or isolated components to WASM can dramatically reduce the attack surface of the web server. By gathering operational telemetry from real-world WASM deployments like WordPress Playground, core contributors can present concrete performance and security data to PHP Internals to support future RFCs.

Hosting Benchmarks and the Push for PHP 8.x Adoption

Accelerating ecosystem-wide adoption of PHP 8.x requires presenting web hosts with compelling financial and operational metrics. While security patches historically drove upgrade mandates, performance gains offer a more immediate incentive for infrastructure providers.

Key hosting incentives identified include:

• Resource Utilization: Demonstrating that upgrading from PHP 7.4 to PHP 8.2+ allows hosts to achieve significantly higher tenant density (e.g., running up to 40% more WordPress instances on equivalent hardware memory).
• Real-World Proof Points: Leveraging operational data from large-scale enterprise environments like WordPress.com (which already runs on PHP 8.4) to quantify CPU and latency improvements.
• Database & Engine Modernization: Aligning PHP engine upgrades with modern database features (such as vector search capabilities in updated MySQL releases) that require modern server environments.

Preparing Core and Plugins for PHP 9

Looking toward future major releases, PHP 9 poses distinct challenges for WordPress core’s compatibility pipeline. Previous major engine transitions—most notably the upgrade to PHP 8.0—introduced breaking deprecations and strict type enforcement that required substantial refactoring across core and the plugin ecosystem. If PHP 9 introduces major syntax shifts that prevent a single codebase from concurrently supporting PHP 7.4 and PHP 9, traditional release strategies will break down.

To mitigate potential fragmentation ahead of PHP 9, core developers are pursuing proactive testing pathways: unbundling test suites from static local environments, executing automated continuous integration against upstream PHP nightlies, and improving early warning notifications sent to plugin authors whose code fails basic runtime compatibility checks.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.