WordPress PHP compatibility revisited at WCUS 2026

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Every few years the WordPress project sits down with itself and asks the same awkward question: are we a PHP project, or are we a WordPress project that happens to be written in PHP? For most of the twenty years I have been shipping sites on this stack, the honest answer has been the second one. That is not a criticism — it is what makes WordPress viable for the kind of clients we work with. The question is whether that answer is still serving us in 2026.

A small, deliberately quiet conversation at WordCamp US 2026 poked at exactly that. It was held under Chatham House Rule, which usually means the interesting parts do not get written down. This one did — Anne McCarthy published a recap on Make/Core, and it is worth reading twice, because it is the clearest statement I have seen in years about where the WordPress-PHP relationship is actually stuck.

I want to walk through what was said, what it means for anyone running production sites, and what I would actually do about it as an agency — because most of the “PHP 7.4 problem” advice you read online is written by people who do not have to explain a hosting migration to a client on a Tuesday morning.

What is actually new

On September 3, 2026, Anne McCarthy posted a recap of a WordCamp US session titled simply “WordCamp US 2026: PHP conversation” on Make/Core. The attendee list is a who’s-who of the people who actually push code — @jorbin, @johnbillion, @obenland, @griffbrad, @joemcgill, @dmsnell, @jason_the_adams, @desrosj, @mdawaffe, @4thhubbard, @westonruter, @annezazu — and the conversation covered why the WordPress and PHP communities keep talking past each other.

The headline number is that roughly 18% of websites still run PHP 7.4. That is the constraint everything else hangs off. PHP 7.4 stopped receiving official security fixes in November 2022, and the wider PHP ecosystem — Composer packages, testing frameworks, Symfony components — has almost entirely moved on. WordPress has not, because WordPress keeps a support window that is unusually long for a modern piece of software, and the plugin ecosystem inherits that window whether it wants to or not.

The recap flags three specific pain points that agencies will recognise. First, Gutenberg’s automated tooling and Core’s automated tooling do not agree on what “PHP 7.4-compatible” means, which is why syntax that flies through the Gutenberg pipeline occasionally lands in Core and breaks on old servers. An upcoming PHP_CodeSniffer release with improved sniff coverage is expected to close some of that gap. Second, a nightly PHP Docker container for local Core testing was proposed, with initial work in Trac #65904. Third — and this is the interesting one — there is renewed appetite for upstreaming WordPress’s HTML API work, and adjacent URL and HTTP-header parsing, into PHP itself. Dennis Snell’s team has effectively written a spec-compliant HTML5 parser in userland PHP; putting the primitives in the language would benefit every framework, not just this one.

The other genuine idea is WASM. Not “cross-compile WordPress to run in the browser” — that is Playground, and it exists. The proposal here is the reverse: an official PHP extension that lets a running PHP process load and execute sandboxed WebAssembly modules. Imagine image processing that does not require ImageMagick or GD installed on the host at all, or version-pinned modules for parsing untrusted input. This is early-stage — the recap describes it as a follow-up conversation to start, not a decision — but the framing is the healthiest I have seen on the WordPress-PHP axis in a while: fix the language, not the CMS.

Why it matters for WordPress and WooCommerce people

If you build sites for a living, none of this is abstract. The 18% figure is your long tail of clients — the ones on cPanel hosts they set up in 2019, still paying £4 a month, whose sites happen to be doing €40,000/month through WooCommerce. Every plugin author reading this has an issue tracker full of “please support PHP 7.4 forever” comments, and every hosting company reading this has a support inbox full of “why did the update break my site” tickets. That is the shape of the problem.

The practical consequences of the WCUS discussion, if the follow-up actions land, are small in isolation and large in aggregate. Better sniff detection in PHP_CodeSniffer means fewer PHP 7.4 regressions escaping into Core patch releases. A nightly PHP Docker container means Core contributors can actually reproduce the reports they get from hosts. HTML API primitives in native PHP would remove one of the persistent performance ceilings in Gutenberg’s server-side rendering — you would no longer be walking a tag tree in userland PHP for every block render.

WooCommerce is the shop that pays the rent on the ecosystem, so the second-order effects matter there most. WooCommerce 11.x is comfortable on PHP 8.1+; the dual API work needs modern PHP just to compile the type signatures cleanly. Any move that shrinks the PHP 7.4 tail directly widens the runway for Woo to keep raising the floor without stranding stores.

What I would do (or not do) about it

If you run one WordPress or WooCommerce site: upgrade to PHP 8.2 or 8.3 now, on staging first, and stop reading think-pieces about it. The single biggest performance and security lever most sites have not pulled is still the PHP version. On the client work we ship, moving a Woo store from 7.4 to 8.2 typically clips 30–40% off backend response time on cart and checkout without touching a single line of code. That is real money for stores of any size.

If you run an agency: audit your portfolio next week. Group sites by PHP version and by hosting provider. The uncomfortable truth is that most PHP 7.4 sites in 2026 are not there because the code needs it — they are there because nobody has renegotiated the hosting contract or run the plugin compatibility matrix. That is a two-hour job per site, not a rebuild. Bake it into your retainer this quarter and the WordPress 7.2 / WooCommerce 12.x floor will not catch you out.

If you build plugins: read the recap and then read your own composer.json. Follow the pattern the WooCommerce team is using — a hard minimum that tracks the WordPress recommended version, plus a soft minimum documented in the readme. Do not carry PHP 7.4 support out of guilt. The users who need it are almost always the users who are one plugin update away from a fatal error anyway, and holding your codebase back to protect them is not the kindness it looks like.

What I would not do is chase the WASM extension idea into a client build today. It is a good conversation, not a shipping feature. Same for the HTML API upstreaming — it will take years, and the userland WP_HTML_Tag_Processor is already the right tool to build against in 2026.

The bit of the recap I liked most was quiet. It was the acknowledgement that WordPress’s long support window is a feature, not a failure — and that the fix is not to shorten the window but to invest more in the automation that makes the window cheaper to hold. That is a mature framing, and it is the one I would keep in mind the next time a well-meaning developer on X tells you the project should just drop PHP 7 and move on.