Is the writing is on the wall for the WordPress theme as we know it?

The essence of a WordPress theme is: layout (templates) + style = presentation. 

The template and global style editing features of the site editor are soon going to provide users with tools to create and manage these elements visually in their WordPress back-end. Community initiatives like the pattern directory present opportunities to enrich these features exponentially.

So the question emerges: If I have the power to tailor the individual components that make up a “theme”, supplemented by curated suggestions from the community while doing so, then what purpose does a single bundle of predefined layouts and styles serve? 


I imagine a world where the idea of themes being discrete entities that you install and switch between goes away. Instead, the “default theme” in WordPress is nothing more than a generic version of the templates and styles necessary for the most basic site to operate.

On top of this, flows exist in the UI that enable users to perform bespoke activities, like creating a different layout for a specific post category archive.

In such a flow the user would be presented with contextual layout options that are pulled in directly from the pattern directory. Oh, you want to create a new 404 template? Here are dozens of neat options to choose from, ordered by popularity, rating, you name it. This feels much more powerful than having to accept whatever your theme supplies – especially as it’s unlikely that you chose your theme because of it’s 404 template!

Styles can work in a similar way. Imagine selecting an appealing color palette from a community driven library, directly in the Styles panel of the Editor, and having that cascade across your entire site. Ditto for typography. These tools can all combine in flexible ways to get you 90% of the way toward your desired design destination. 

Naturally you can fine tune everything on a per-block basis as required, and even choose to contribute your creations back to the color, type, or layout directories, further enriching those libraries.

On that note, maybe new economies begin to emerge – imagine paying a small tip to install a comprehensive type scheme devised by some A-list design studio. An App Store for style?


No doubt it would still be possible to export your templates and color / type styles as a single theme bundle. But in a world where folks have freedom of expression on a much more granular level, I wonder about the utility of such a package.

When you’re able to easily apply different aspects of design to a single post, a single template, a site header, or even a single block, the concept of a “theme” starts to feel much less monolithic. I’m excited to watch these features interact as they grow and evolve.

Refining the Posts List block

For those not familiar with how WordPress works under the hood, The Query block (and its friends Query Loop and Query Pagination) can be tricky to understand. Attaining this knowledge shouldn’t really be a requirement to do something simple like display some posts from a category on a page that you’re creating.

The existing Posts List block helps with discovery, but upon insertion users are still faced with the Query and it’s associated complexities:

Taking the Posts List block for a spin

The experience is especially bad at the moment, because options like “inherit query from URL” are practically useless in the context of editing a post or page, and Query Pagination doesn’t work at all.

Today I explored how we might extend the Posts List variation so that it feels more like a unique block that stands by itself, and obfuscates some of the complexity of the underlying Query. The concepts are described in the video below:

An optimised version of the Posts block

Summary of changes

Here’s what changed:

  • “Posts List” renamed simply to “Posts”
  • Query Loop block is hidden in the UI
  • Post type selector is removed
  • “Offset” and “Include sticky posts” options moved to “Advanced” panel
  • Confusing “inherit query from URL” setting is hidden
  • Filtering options tidied up
  • Layout and ordering options tidied up (icons need some attention)

This is my first take on this block, so changes will no doubt be forthcoming. You can follow along on https://github.com/WordPress/gutenberg/issues/32268

Refining template flows in the post editor

Template exercises in relation to a single post are accessed through the following interface(s):

In #31591 I outlined some of the issues with this initial UI implementation, and opportunities to enhance the overall UX:

For block templates, the experience can be enhanced with visual previews of the templates. Since this is the future, we can embrace it.

This UI lacks hierarchy. Changing templates will likely be the most common activity so this interface should be most prominent.

The “Create a custom template” modal could elaborate more on what templates are

When there are many templates, a search can be useful

When the default template is selected, it is duplicated in the template list

Consolidate the “Back” button (to move from editing the template back to the post) in to the top bar

I presented the following design solutions:

Changing a template

Editing a template

Creating a new template

There will be some debate about whether access to these flows should exist in the Inspector (sidebar) or the top bar. In the long term I expect them to reside in the top bar, but the Inspector may serve as a transitional home for them. The UI has been designed in such a way that it can sit in either location with equal comfiness.

Contextual editing clarity

One of the most challenging elements to get right in the site editing UX is where and how we draw lines between the different editing contexts.

Until now, no lines have been drawn at all. In both the Site Editor and the Template Editor, if you’re able to see content, you can edit it directly, free of any friction whatsoever. Of course there are benefits to this – direct manipulation is a compelling argument. But as documents become more complex, and template editing more prevalent, drawbacks emerge.

In the go/no go discussion (re FSE in 5.8) last month the Query block came under scrutiny:

I think, also, to be honest, this is a bit too powerful right now. You can essentially modify any of your post’s actual content, feature images, and so on. This should probably not be the default. It should probably be something that you have, like, one more step to get there.

Matías Ventura

The same argument can be made in regards to template editing. Being able to edit the content of a post while also editing the post template blurs the lines between these two very different exercises, and undermines the very existence of separate content and template editors in the first place.

The issue is compounded when you consider the query block. Imagine inserting a Query in a page, then navigating to edit the Page template. Suddenly it’s possible not only to edit the content of every single post on your site in the context of a template editing session, but also to mistakenly drop that query in to the page template itself and potentially break the appearance of your whole site. Similar problems will surface when it becomes possible to edit templates for archives and search results.

You may argue that an experienced user would not make these kind of mistakes, and for the most part I agree. But with the template editing UI coming to 5.8 it will not only be experienced users who have access to this powerful feature.

It is my opinion that we should test some prototypes that add friction to content editing exercises that are outside the context of the current exercise. That is to say: if I open a page and engage the template editor, I should not be able to directly manipulate the content of that page. Likewise, when I insert a query in a post, I should not be able to directly manipulate the content therein.

You can probably guess what is coming at this point… 🙂 Yesterday I opened a draft pull request that serves as a proof of concept. It is very rough, but with some css hackery I was able to spoof making post block content un-editable in the template editor. Here’s a video:

Blocks like the Post Title, Post Content, Post Date etc can be selected, and their attributes can be modified. But their actual content is gated by an overlay UI similar to the one we’re exploring for template parts and reusable blocks.

It doesn’t feature in the PR, but it is quite easy to imagine some simple interactions that “unlock” edit-ability of the content. It might be a double-click, a keyboard modifier, a lock icon in the block toolbar, or a combination thereof.

The objective here is primarily to establish clear definition between content editing and template editing. I’m increasingly of the opinion that this will be a critical pillar of the UX if we’re to pursue dedicated views for these different editing contexts.