I’ve been chewing on this idea for a few years now. And after reading Joost de Valk’s piece about WordPress needing a real refactor and Jean Galea’s response to it, I figured it was time to stop talking about it in DMs and just write the thing down.

The problem

The PHP foundation of WordPress is still fundamentally the same procedural, globals-everywhere, hooks-all-the-way-down architecture it’s been for twenty years. It works. Obviously it works, as it runs a huge chunk of the web. But “it works” and “it’s a good foundation to build on for the next decade” are very different statements, especially now that the tools we use to write code are changing fast.

AI bots are genuinely good at navigating structured codebases. Anything with clear boundaries and structure. But point them at WordPress core and they start creating a lot of nonsensical AI slop; they’re useful, but nowhere near as useful as they are with more structured modern systems. The architecture that was always clunky is now actively costing us, because the tools that are supposed to help can’t navigate it.

If you’ve spent any time in Laravel or Symfony, you know what a modern PHP codebase feels like. Service containers, clear request lifecycles, PSR compliance, real dependency injection. Then you come back to WordPress core and you’re back to global $wpdb, a thousand implicit hook side-effects, and function files that are essentially bags of loosely related procedures. It’s not that you can’t build things, it’s just that the architecture fights you at every level of abstraction.

“BackPress”

BackPress was originally built as the framework that was supposed to underpin WordPress itself. It was extracted out as a standalone library and was intended to be the shared foundation that WordPress, bbPress, and other projects would all build on. In practice, bbPress 1.0 used it, and as far as I know, that was about it. WordPress itself never actually ran on BackPress, which is kind of ironic given that was the whole point.

The project went dormant. The name is just sitting there, gathering dust.

I’m suggesting we bring it back from the dead, but with a completely different purpose. Instead of being the framework underneath WordPress, BackPress could become the backwards-compatibility layer that lets the old WordPress live on top of a new one.

What I’m proposing

Not a rewrite-from-scratch without backwards compatibility. That would kill the project.

Instead, I think WordPress should be implemented as a proper modern CMS. Laravel, Symfony, whatever foundation floats the boat of the people in charge. Something with real structure, PSR compliance, a service container, the works. This becomes the default. New installs get this. New plugins target this. New themes are built for this.

But when you update an older site, or just need to run legacy plugins or a theme that was built for the old world, you flip a switch during setup to implement a new BackPress.

BackPress takes over the traditional directory structure (wp-admin, wp-content, wp-includes), the whole familiar layout. It’s a compatibility shim that re-implements the old WordPress PHP APIs on top of the new engine. Your old plugins call add_filter() and get_post() and WP_Query and all the rest, and BackPress translates those into whatever the modern core uses underneath. Think Wine on Linux, or Rosetta on Apple Silicon. The old code doesn’t know it’s running on something new.

The important thing: BackPress is not installed by default. Starting fresh, you never touch it. You never see wp-includes. You never deal with the global scope spaghetti. You get the clean architecture from day one. BackPress is the bridge you walk across, not the destination.

Why this matters now

The WordPress ecosystem is massive and valuable. Nobody sensible wants to torch that. But we can’t keep pretending that the PHP foundation from 2003 is going to carry us forward indefinitely.

BackPress gives us a way to respect the past without being trapped by it. New projects get a clean start. Legacy sites get a supported path. And eventually, maybe in 10 years or so, the number of sites still running BackPress drops to near zero, and you quietly deprecate it.

No drama, no big bang rewrite, no abandoned plugins. Just a clear line between “the new way” and “the bridge that keeps the old way running while you migrate.”

Transition period

In order to ease the transition, the current stable WordPress could remain in place for a year, while a long-term beta release is tested on the community. This gives plugin and theme developers enough time to convert their code to the new system. An AI-powered automatic converter could even be provided, which could do its best to convert old plugins and themes to the new system. It wouldn’t be perfect, but it could alleviate most of the effort required for developers to make the transition.