This summer I had the pleasure of attending and speaking at WordCamp US 2026. Along the way I dined with Woo developers, gave beginner support at the Happiness Bar, staffed parties for Woo and Automattic for Agencies, and even got trapped in a Waymo with a few WordPress legends.
There’s too much to jam into one post, so I thought I’d narrow in on one conversation I found myself having a lot: how agencies and agents can work with block themes. To be fair, it’s my fault, since that was the topic of my talk:
Over the course of a few days, I heard a lot about where block themes are winning (seriously, even Redditors are recommending block themes more than ever). We also have responsive design controls, so that’s a huge win!
But I also heard where block themes still need architectural improvements for agencies. I surveyed and spoke with a number of theme and agency developers about their workflows and learned about all the custom tooling they’ve built to mitigate these issues.
There’s been good work on some of the difficult site editor UX/UI from folks like Dave Smith, but that’s more focused on beginner users. Agencies have a different concern with the site editor, and many of the pain points in the agency workflow (mostly around governance and version control) are only more apparent as agentic coding enters their toolkit.
Code moves up, content moves down
I spent much of the talk covering the history of WordPress, from the five-minute install to the era of the customizer and page builders. The point was that WordPress has always prioritized the no-code design experience, with the fulfillment of that in the Site Editor.
WordPress has everything developers need- REST APIs, CLI, authentication, and architecture. But when it comes to front-end design, it’s still missing some modern pieces.
Agencies want to control the design with code, they need diffs and version control and deployments and rollbacks. More than that- AI agents love writing code, and it’s much easier for them to modify front-end design in a codebase than clicking through a no-code interface.
The visual, no-code interface is still important for end users, but harder for the developers building for end-users.
Components are the missing feature
Components are a key primitive in any design system, widely used in our industry, and the topic I was asked about the most. Not that everyone used the word “components”, but the pain points they described around concrete pieces of design, defined and controlled from your code base, are solved by components.
Components are foundational pieces of UI, reusable and overridable, but controlled globally. Your header is a component, as is a newsletter CTA, a blog post hero, a footer, and a hundred other reusable pieces of content on your site.
Blocks are pseudo-components, but blocks are too expensive and specific for most broad design needs (and especially for agentic coding). If you’re creating a website where everything is a custom block, you’re losing a lot of the benefits of the block editor. And building blocks with more blocks inside is a painstaking process with multiple files to track, a heavy build process, minimal governance, and state management issues.
We could also look at block patterns as a type of design component, along with template parts, HTML blocks, and a few other primitives that I’ll get into. The problem with these? WordPress has multiple solutions (patterns, parts, synced patterns, blocks, PHP blocks, HTML blocks, etc) that offer a component experience, but each has its tradeoffs.
- Patterns can live in a theme or database, but lose their connection to any version control or design governance once added to a post. I’ve also seen generally negative feedback around the new ‘Edit Pattern’ workflow that arbitrarily locks the design settings.
- Synced patterns are more like components with override-able props, but cannot be coded in the theme at all and the editable props you have available are limited.
- Template parts are a vague pseudo-synced pattern, and it’s unclear why the distinction exists. However, the UI where you can offer alternate design variations for the same template part area is a useful feature we should borrow.
- PHP-only blocks offer an interesting middle-ground – can be version controlled, can be built with custom HTML and PHP, can have clear definition of which fields are editable, and can use block style supports. Overall they lack the visual editing experience (for now, more on that later), have limited field supports, and have no ability to leverage existing blocks.
Or we can view this comparison in table form:
| Patterns | Synced patterns | Template parts | PHP-only blocks | |
|---|---|---|---|---|
| Design/structure is git/theme controlled | Partial — source can live in a theme, but inserted instances are detached | No | Partial — can originate in a theme but may be overridden in the database | Yes |
| Custom HTML | No | No | No | Yes |
| Allows PHP | Before entering, not after | No | No | Yes |
| Globally synced | No | Yes | Yes | Yes |
| Specific editable fields | No | Partial — editable overrides are limited | No | Yes |
| Visual editing | Yes | Yes | Yes | Limited |
| Can use existing blocks | Yes | Yes | Yes | No |
| Block style supports | Through their blocks | Through their blocks | Through their blocks | Partial- only applies to the outer wrapper |
| Alternate design variations | No | No | Yes | Partial — through styles or block variations |
There’s a few more options I didn’t include in this table, but would include custom blocks, plugins like ACF/SCF, and the updates to the HTML block that enable you to mix custom HTML and core blocks. It’s an interesting, if undiscoverable, step in an intriguing direction.
As I’m writing this, there’s a new PR that lets you pull registered synced patterns within PHP-only blocks. Once I understood it, I generally liked it. But my default feeling is oh great, one more confusing thing. Why do I need to create a block and a synced pattern now and then combine them somehow? Can’t we make this easier?
Decisions, not options
Most people I talk to see these tradeoffs as roadblocks towards block theme adoption, especially in agentic workflows. Each feature attempts to solve the same problem, but none of them does so completely, from a high-level product point of view. It’s also unclear from the user’s perspective why we have so many options for solving what are essentially the same problems.
That was one of the key themes of my talk. WordPress claims to offer Decisions, not options, but instead it’s given us so many options, and left agencies/agents with a rash of decisions to make.
I genuinely appreciated Matt Mullenweg’s “Tech needs to be simpler” segment at the WordCamp US Keynote where he asked the audience:
Have we taken a lot of things that could be simple, and added a lot of complexity?
I think my table above answers that questions. We need to come back to first principals and actually ask ourselves, what do WordPress users want? Do they want more options? Or do they want less? We need to rethink patterns and template parts. We need to bring in the industry standard solution: component.
To start the conversation, I spun up a quick proof of concept and dug more into this topic over on YouTube.
The video just covers some basic discoverability issues, but there’s more that needs to be done around block bindings, more block override support, group/inner block areas, etc. There’s a lot of work to do.
WordPress 7.1 made dreams come true with responsive design controls. If WordPress 7.2 or 7.3 came out and the headline was “WordPress introduces components”- would you be excited?
Leave a Reply