Here's a quick test that will instantly expose a major architectural flaw in WordPress.
Try it right now:
- Install the WordPress Twenty Twenty Four Theme.
- Create a template called “My Template.”
- Switch to the WordPress Twenty Twenty Five Theme.
- Now try to find “My Template” in the Templates area.
Gone. Vanished. Your work, disappeared.
This isn't a bug—it's a feature. And it reveals the most fundamental flaw in the world's most popular content management system.
What is a Theme, Anyway?
The vast majority of the WordPress community doesn't seem to understand the difference between design and architecture.
Ask ten WordPress professionals to tell you what a "theme" is and you'll get two distinct answers. Half will tell you it's the "look and feel" of your website. The other half insist it's the "architecture" of your site.
Both groups are right—and both are wrong. That confusion is WordPress’s biggest problem.
Over the last two decades, WordPress has trained an entire generation of developers, designers, and users to think that themes should simultaneously control how things look and how they work. The platform has made this confusion seem normal, even inevitable.
Walk into any WordPress meetup, browse any WordPress forum, or listen to any WordPress podcast, and you'll hear this confusion played out in real time. Someone will ask about changing their site's appearance, and the advice will be "just switch themes." Someone else will ask about adding functionality, and they'll get the same answer: "find a theme that does that."
The community has collectively accepted that themes should handle everything from color schemes to portfolio galleries, from typography to e-commerce functionality, from simple styling to complex database queries. This acceptance has created a false equivalency between fundamentally different concepts.
What makes this particularly problematic is that many WordPress professionals have built entire careers and businesses around this confused model. Theme developers market their products as complete solutions rather than design systems. Users have been conditioned to expect themes to be all-in-one packages. The entire WordPress economy has adapted to this architectural mistake.
The result is a community where basic web development principles are not just misunderstood but actively contradicted by the tools themselves (and in more ways than one).
What Themes Should Be (But Aren't)
The dictionary definition of "theme" couldn't be clearer:
Theme:
A distinctive style or character, typically one used in artistic works, literature, or design.
Notice the keywords: style, character, artistic, design, aesthetic. These all point to one thing: look and feel.
In web development terms, themes should control two things: styling (colors, textures, spacing) and patterns (the physical layout of content). Change these, and you've changed the "look and feel."
From a technical standpoint, these changes involve HTML and CSS, not architecture.
Architecture, of course, is the underlying codebase that generates what users see. But WordPress doesn't work this way. It treats themes as architecture.
This fundamental confusion creates a false choice for users: they think they're selecting a visual style, but they're actually locking themselves into a technical quagmire that determines how their entire site functions.
This distinction matters more than most people realize.
In proper web development, themes are like clothing for your website. You can change them freely without affecting what's underneath. WordPress themes, however, are more like the skeleton, organs, and nervous system. Change themes, and you're performing major surgery on a living system.
The confusion runs so deep that WordPress has essentially redefined what the word "theme" means to millions of people. While good developers treat "theming" as a superficial styling layer, WordPress has turned the concept into all-or-nothing packages. This linguistic hijacking has made it nearly impossible for the community to have clear conversations around these topics.
When a user says they want to "change their theme" on most other platforms, everyone understands they want to change how their site looks. When a WordPress user says the same thing, they might be talking about changing colors, or they might be talking about completely rebuilding their site's functionality. The words have lost their meaning because the underlying concepts have been deliberately muddled.
WordPress' Architecture Trap
WordPress's architecture consists of a database and a maze of core templates: index, home, front-page, single, and many others.
These are "templates" in the literal, technical sense. They're code-based instructions that generate content and structure dynamically. The problem is that there's no single source of truth for these. Rather, they're packaged separately into every single theme in the ecosystem.
Better yet, each theme comes with its own unique interpretation of how WordPress should work based on what the theme developer chose to include or not include and what special features they decided to bake in (or leave out).
Additionally, choosing a theme means you're now reliant on the theme developer–not WordPress–to keep that architecture up to date.
And, most important of all, it means themes are fundamentally incompatible with each other. Even though two block themes are built with the same block editor, the block-based patterns can't be shared from one theme to the other. And switching themes – well, you already saw what happens if you did the opening experiment.
See, in proper web development, there's a principle called "separation of concerns." Keep architecture separate from appearance. This allows infinite flexibility: you can update the foundation without breaking the design, and swap designs without touching the foundation.
WordPress violates this principle catastrophically. Every theme is essentially a different application masquerading as a design choice.
The Gutenberg Opportunity (And How It Was Wasted)
In 2016, WordPress founder Matt Mullenweg announced Gutenberg, a block-based visual editor. Initially designed to improve the editing experience, it eventually evolved into a full page builder (an evolution that, the last time I polled them, over half of the WP ecosystem didn’t even realize had happened).
This presented a golden opportunity to fix WordPress's architectural sins. A React-based block editor could have enabled users to freely build, exchange, and sell patterns, templates, and components, making sites infinitely scalable and swappable.
The timing was perfect. The web development world was moving toward component-based architectures. React was gaining massive adoption. Modern development practices were proving that modular, reusable components could solve the exact problems WordPress themes had created.
Gutenberg could have been WordPress' salvation. Instead of forcing users to choose between incompatible theme architectures, the block system could have created a universal language for WordPress sites. Every component, every pattern, every template could have been built once and used everywhere.
One more step, a unified style system, would have made mixing and matching seamless. Users could have mixed patterns from different developers, combined templates from various sources, and built truly custom sites without architectural constraints.
Instead, Mullenweg doubled down on the failed distributed architecture model, announcing a Block Theme Library that would house individual block themes. The opportunity to unify WordPress was squandered in favor of maintaining the status quo.
The Real-World Consequences
We're told the block editor is WordPress's future. Yet the fundamental problems remain unsolved, and in some ways have gotten worse.
Love the Ollie theme but want to use some of the patterns from Brian Gardner's work? Impossible. They're fundamentally incompatible, despite both being "block themes" that supposedly use the same underlying technology.
Stretch a random block theme to its limits and then realize you need more robust patterns? You can't simply switch themes. As our opening test demonstrated, you'll lose all your templates. This also means that you'll lose main pages (like your Home page) if you follow the completely insane page-as-template model that WordPress promotes (another article for another day!).
But the problem runs deeper than lost templates. You'll also lose any custom styling, specialized layouts, and unique functionality that was built into your original theme choice.
If WordPress had proper architecture, you'd have infinite patterns to choose form, paired with core functionality that works regardless of the look and feel choices you need to make.
Every designer, every developer, every agency could contribute to a shared ecosystem where their work enhances everyone else's.
Instead, WordPress has created thousands of isolated islands. Each theme is its own walled garden, incompatible with every other theme, forcing users to start over whenever they want to change directions.
This fragmentation has stifled innovation. Developers waste time rebuilding the same basic functionality for every theme. Designers can't build on each other's work. There are 857 carousel plugins. Users get trapped in decisions they made months or years ago, unable to evolve their sites without starting from scratch.
It's a mess of an ecosystem.
The Fix
All of this can be fixed without abandoning WordPress––we don't even have to sit around waiting for Automattic to get its ducks in a row.
In fact, this next era of WordPress is already here.
Etch represents what WordPress should have pivoted to: a Unified Visual Development Environment on a single, official architecture that respects fundamental principles and practices.
Etch combines the power of an IDE with the efficiency and ease of a visual page builder, with no compromises and one crucial advantage: everything you build instantly and automatically becomes WordPress core blocks.
Every heading, paragraph, pattern, loop, component, and template integrates seamlessly with WordPress's core functionality.
But unlike traditional WordPress development, themes are obsolete. You install the Etch theme and then completely forget about it, because it's only there to plug the hole in WordPress' broken architecture.
All your work is done in Etch's interface (not the theme) and everything you build instantly becomes portable, reusable, and compatible with every other Etch installation.
With Etch as the single, unified development environment for WordPress, block themes become obsolete. Custom blocks become unnecessary. You never think about themes again. You focus on building your site, with no limitations on pattern sharing, component sharing, template sharing, or anything else.
Want to use three different pattern libraries? Done. Mix templates from different developers? No problem. The artificial barriers that have plagued WordPress for over a decade simply disappear.
This isn’t just about convenience; it’s about unlocking WordPress’s true potential. Unified architecture allows creativity to flourish, portable components accelerate innovation, and true themes let designers focus on design instead of wrestling with technical limitations.
And your clients? They see the simple Gutenberg interface with the ability to edit whatever you've allowed them to edit, just as easy as Gutenberg is today.
Do their edits break Etch? Of course not, they're seamlessly synced together at all times. Edits in Etch carry over to Gutenberg and vice versa, effortlessly.
The Bottom Line
WordPress's architecture crisis isn't a technical accident. It's the inevitable result of fundamental design decisions made over two decades ago, decisions that made sense when websites were simple and static, but that have become increasingly problematic as the web has evolved.
The Gutenberg project could have fixed everything. It had the backing, the resources, and the technical foundation to create a truly unified WordPress experience. Instead, it perpetuated the problems, adding new complexity on top of old limitations.
For millions of WordPress users, this means continued frustration, lost work, and artificial limitations. Every time they hit a wall, every time they can't use a pattern they love, every time they have to start over because themes are incompatible, they're experiencing the consequences of these architectural decisions.
For the web development community, it represents a massive missed opportunity. WordPress powers over 40% of the web. If it had proper architecture, it could have created the largest, most collaborative design ecosystem in history. Instead, it remains fragmented, with thousands of developers solving the same problems in isolation.
The question isn't whether WordPress will eventually solve these problems. The question is whether users will wait for solutions that may never come, or embrace alternatives that work today.
The architecture crisis is real, but you are no longer forced to consent to the chaos.
The choice is yours.
Kevin is a WordPress and web development educator, speaker, and the founder of three WP plugins: Etch, Automatic.css and Frames.