Malcolm Peralty

Hi Matt,

I’m publishing this as an open letter, and I want to be upfront about why. I could send it to you privately, and maybe it would land better that way. But the conversation I’m trying to start isn’t really one person’s to have. Every plugin author, agency lead, and host I know has some version of this argument running in their head, and most of them aren’t going to write it down. So I’m writing it down, in public, addressed to you because the call is ultimately yours, but with the door open for everyone else to push on it too.

A bit of background on where I’m coming from. I’ve been shipping on this stack for over twenty years now, going back to the days of running 200+ sites with bash scripts that pulled from SVN because WordPress didn’t have a built-in updater yet. From there it was PressTitan, 10up, almost two years deep inside the Drupal world at Acquia (eventually as a Senior TAM), some time at Pressable, and now I’m at Fueled as Lead Project Manager for the Systems team. So I’m coming at this from multiple angles, working with clients who have to actually ship things with WordPress and live with the result.

I want to also say that I am no expert in core development. I’ve never been a core committer. I’ve spent my career mostly on the implementation, hosting, and customer-facing side of things. So take all of this with appropriate seasoning.

Another thing I want to say up front, and that I’m not going to pretend otherwise about, is that this is a technical proposal with enormous political and economic consequences. You can’t do the things I’m going to ask without great risks to the community and ecosystem around it. I’m going to try to make the technical case because that’s the part I actually mostly understand. But I’d be insulting your intelligence if I framed this as anything other than a proposal that lands squarely in the part of your job I don’t envy. The technical argument is the easy half. You and some other key people would be the one carrying the rest.

After all of these years, the most honest thing I can say is that WordPress has two primary structural problems that no amount of Gutenberg polish is going to fix.

The runtime is still a 2003 era, PHP 4 artifact with hooks bolted on top. And the plugin contract is, basically, “trust everybody with the whole process.” Everything downstream of those two facts is a symptom. The performance ceiling. The security posture. The “just okay” developer experience. The accessibility debt in the editor. All symptoms.

The thing is, I don’t think you can refactor your way out of this from inside a backwards compatibility commitment. I really wish you could, but I don’t see how. I think you need a line in the sand.

This series is about what that line could look like. Call it WP Classic and WP Next for the sake of this discussion.

What Classic and Next Would Actually Be

Classic is the 43% of the web, frozen in architecture, supported for a decade or more, getting security patches and small UX wins forever. The bargain is “your site works forever, but we stop churning the foundations.” I think we are at a good time to do this with WordPress 7 working on completing the three modernization phases that were long ago planned with the block editor, full-site editing, and collaborative editing.

WordPress Next could have PHP 8.2+ as the floor, an object-oriented kernel with dependency injection, typed APIs, Composer-first distribution, a persistent object cache as a hard dependency, a real queue, a real CSRF story, a real permission model for plugins, and an admin that doesn’t half-render React into a WP_List_Table from 2011.

Here’s the question I know is coming, and I want to answer it before the rest of the series tries to: at what point is WP Next just Laravel wearing a WordPress t-shirt? Or Statamic, or Craft, or any of the other modern PHP CMSes that already exist? If you burn down the loop, the hook system, the database abstraction, and the admin, what’s even left that earns the name?

My short answer (the long one is the rest of this series) is that what makes WordPress WordPress was never the procedural-PHP-and-globals part. It was the editorial model, the plugin-and-theme distribution model, the install-it-in-five-minutes promise, and increasingly, the block model. Gutenberg, the Interactivity API, FSE, Playground, and Data Liberation are all genuinely WordPress in a way that wp-settings.php is not. Next keeps the parts that are actually load-bearing for the user experience and the publishing model, and replaces the parts that are load-bearing only for nostalgia. If we do this right, a content editor opening WP Next should not be able to tell. A developer opening it should immediately be able to tell, and should be relieved.

That’s the standard. Editor experience is preserved. Developer experience is rebuilt.

The Argument in One Paragraph

Here’s what I’m thinking. The cost of WordPress’s backwards compatibility posture is no longer paid primarily by hosts or core committers. It’s paid by every plugin author still shipping class-foo.php files and add_action( 'init', [ $this, 'bootstrap' ] ) in 2026. By every site reliability engineer on-call for a WooCommerce site whose autoloaded options row hit 80 MB. By every security researcher filing CVEs against plugins that can exec() anything because PHP has no capability model and WordPress has no manifest. By every agency bidding against headless Craft or Sanity and losing on developer experience. By every accessibility auditor scoring the block editor.

The bet of WP Classic plus WP Next is that the 43% is not the same population as the people building new things, and that trying to serve both with one codebase is exactly why neither is being served particularly well right now.

What I’m explicitly not arguing

Before I get into the weeds in the rest of this series, I want to clear out a few things this argument is not.

I’m not arguing for a rewrite in Rust, Go, or JavaScript. PHP 8.2+ is the right runtime. PHP has caught up enormously since 8.0. Fibers, enums, readonly properties, first-class callable, JIT compilation. It’s a different language than the one WordPress started on, in a lot of meaningful ways. The argument is to use the language we’re already on, the way the rest of the ecosystem uses it.

I’m not arguing against Gutenberg. I think the block model is one of the best things the project has shipped. I am arguing that the toolchain under it is due for a second generation, and that the PHP-side render story should be a peer, not a second-class citizen.

I’m not arguing to abandon the .org plugin directory. I’m arguing to give it security primitives that match a 2026 supply-chain threat model.

I’m not arguing for headless by default. I’m arguing for an admin that works when the editor is an island in a progressively enhanced page, which is what modern admin UX has actually converged on.

The Drupal Question, Since I Know it’s Coming

I’m going to lean on the Drupal 8 transition more than once in this series, and I want to handle the obvious objection up front because I lived through some of the aftermath at Acquia and I know how it looked from the outside.

The objection goes: Drupal 8 was the moment Drupal handed its small and mid-market share to WordPress on a silver platter. The project chased enterprise architectural purity, alienated the long tail, and the bleed never stopped. Citing Drupal as a model is citing the cautionary tale, not the success story.

That’s not wrong. It’s just incomplete.

The market share Drupal lost in 2015 was lost mostly to WordPress, because WordPress was a genuinely better fit for the small-and-mid use cases Drupal had been awkwardly serving. It was a like-for-like substitution: same buyer, easier tool, lower cost. The defection had somewhere obvious to go.

WordPress’s analogous risk in 2026 is not the same shape. The 43% is not going to defect en masse to Webflow or Shopify because those platforms serve fundamentally different buyers with fundamentally different economics. The actual defection risk is at the professional tier, the agencies and product teams who already have somewhere to go: headless Craft, Sanity, Payload, Statamic, Strapi, and a handful of others that have spent the last five years getting genuinely good. That tier is the one I’m arguing is already bleeding, and it’s the tier that WP Next is for.

So the question isn’t “will WP Next cost us market share.” Some Classic sites won’t migrate. That’s fine, that’s the point. The question is “is the tier we’re already losing worth fighting for, and is there a version of WordPress that could win it back.” I think yes on both counts. Drupal’s lesson isn’t “don’t modernize,” it’s “don’t modernize while pretending you’re not also asking your community to absorb a real cost.” Be honest about the cost. Make the value proposition obvious. Give people enough runway to make the move.

The Thing I’m Not Answering in This Post

There’s a question I owe an answer to, and I want to flag it now rather than have you discover I’m dodging it: who pays to maintain Classic for a decade?

Open-source maintenance runs on corporate sponsorship and agency contributions. If the professional tier and the premium plugin economy migrate to Next, the funding base for Classic gets thinner at exactly the moment its security surface needs the most attention. Drupal 7 made it to age 14 in part because of a paid commercial extended support program, not purely on community goodwill. I know that. You know that better than I do.

I’m going to address this in part 6 with an actual proposed structure. For now I just want to acknowledge that “supported for a decade or more” is a promise that needs an economic model behind it, and I’m not going to wave it away as “the community will figure it out.” If we don’t answer this honestly, Classic becomes a slowly-decaying security liability and the whole proposal falls apart. So it’s load-bearing, and I’ll come back to it.

Why I’m Writing This to You Specifically (and in public)

The reason I’m writing this to you, Matt, is that every person I know who ships on this stack already believes the technical argument. The plugin authors do. The hosts do. The agency leads do. The question has never really been “is the current architecture right for 2026.” It’s been “is there the will to draw the line.”

The reason I’m writing it in public is that I don’t think this is a decision that should happen behind closed doors, and I don’t think you’d want it to. The community has earned the right to push on the argument before it becomes a roadmap. If I’m wrong about pieces of this, I’d rather find out in the comments than in a private email where the only feedback loop is yours.

I can’t help but feel that the professional plugin tier (the one that attracts new developers and justifies premium economics) has been quietly losing share to modernized alternatives for five years now, and another decade of PHP-runtime stagnation accelerates that bleed to a point where the ecosystem’s center of gravity moves elsewhere. The long tail survives. I’m not really worried about it. The innovative edge is what’s at risk. The 43% deserves Classic. The next 43% deserves Next. They don’t need to be the same codebase.

The cost of the split is real and measurable. Two to three years of painful ecosystem work. Some hosts will not make the cut. Some plugin authors won’t port. Some sites will stay on Classic forever and that’s fine. The cost of not splitting is that the slow bleed of professional mindshare that has been accelerating since 2020 continues, and in ten years WordPress is where Drupal feared it would be in 2015 but isn’t, because Drupal made the call and absorbed the cost.

I’d rather we make the call. The only fork of WordPress that will ever be truly successful in my mind is the one that the WordPress community makes together.

What’s Coming in the Rest of This Series

This is part 1 of 6. Over the next few posts I’m going to get specific about what WordPress Next actually looks like.

• Part 2: The kernel. What Classic keeps, what Next burns down. The runtime, typed events, value objects, Composer, configuration, logging, the CLI.
• Part 3: The admin and editor. What Gutenberg earned and where it wandered off. Performance, accessibility, the React wager, the toolchain, the media library.
• Part 4: Performance and security. The list every host already knows. Object cache, autoloaded options, query builder, real queues, page caching. And the plugin sandboxing problem that nobody wants to talk about.
• Part 5: The plugin economy. Declared contracts. Dependency declaration. Semantic versioning. A real backwards compatibility policy. The shape of a healthier ecosystem.
• Part 6: The migration plan. How Classic and Next actually coexist without becoming a Perl 6 situation. The timeline. The constraints I want to make sure are preserved. And the answer to who pays for Classic.

I’m going to try to be specific. Named mechanisms. Before and after code. Tradeoffs I’m willing to lose arguments about. And I’m going to credit Gutenberg, Playground, FSE, Data Liberation, and the Interactivity API where credit is due, because those are some of the best things this project has ever shipped, and they’re the reason this series is worth writing at all.

I want to end this first post by saying that I know this is a lot to ask, and I know it doesn’t account for the human and political and personal weight of doing something this big. I’m writing as someone who has had the privilege of seeing this stack from a bunch of different angles, and who genuinely wants WordPress to be healthier in ten years than it is today. I might be wrong about most of this. I’d love to be in the conversation about which parts.

Thanks for reading. More to come.

AI Disclosure: Featured image generated by Gemini, and Claude assisted with the refinement of my choices, arguments, and editing of this post and series.