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.

Ideating on template part flows

The Template Part block existing in the Site Editor isn’t much more than a proof of concept right now. The recent addition of the area taxonomy has enabled us to present semantic variations for things like headers and footers, but many key flows remain ripe for design optimisation. This week I shared some ideas on how we might make improvements to the template part block in Gutenberg.


Creating something like a site header is currently a rather arduous process. You must:

  1. Insert the Template Part block
  2. Click “Create new template part” button
  3. Assemble inner blocks
  4. Manually assign the template part to the appropriate area in the “Advanced” panel of the Inspector
  5. Give the template part a name

For the average user this is way too complex. With template editing functionality coming soon these concepts will be exposed to users in the Editor for the first time ever, and so a need to simplify emerges.

My first idea is to reduce the number of steps required to create something like a header, and augment the process by presenting contextual block patterns in order to help folks get started more quickly. Here’s a video demonstration:

I propose that we re-purpose the “Header” and “Footer” template part variation blocks to serve as pseudo wizards. In doing so we can replace steps 2-4 from above and deliver the following flow:

  1. Insert “New Header” block
  2. Select a block pattern

In this case we know the user is creating a header so the area can be assigned behind the scenes. Likewise we can automatically apply a more useful name based on this context and ask the user if they’d like to add a custom name after-the-fact.

A “Start blank” affordance is offered in case no suitable block patterns match the needs of the user.

The pattern carousel that appears in the modal is a reused component. The same UX is presented to users when getting started with something like the Query block.


The process to insert an existing template part is also rather tiresome. Imagine you wanted to insert your “Standard Header” template part in a new page template, right now you have to:

  1. Insert the Template Part block
  2. Click “Choose existing”
  3. Find the template part and insert it

Not only is this flow longer than it needs to be, it also relies on users understanding the technical relationship between template parts and their taxonomic areas. I can’t imagine that many folks looking to insert a site header would expect to do so via the abstract “Template Part” block unless they’re already familiar with WordPress theming paradigms.

The solution here seems fairly simple – expose all published template parts in the various inserters. Here’s a diagram:

Published template parts can be inserted directly in a single click

This makes the blocks easier to understand based on how they appear in the inserter (categorised and supplemented by the icon) which will be particularly important when viewing search results.


One benefit of semantically related template parts is that it enables us to provide a handy swapping mechanism so that users can interchange same-kind layout areas on-the-fly. A the moment this is accessed through the “Replace” button in the template part block toolbar:

Swapping a template part

I think it’s fair to say that we can make some refinements here!

First of all there is a question to be answered around how useful search will be in this flow. It seems unlikely to me that a site would have so many headers that a search would be required to find the right one. You may argue that there may be enough generic template parts and I would agree with you, but I would also say that it seems unlikely that one would ever need to swap one generic template part for another. Swapping only really seems useful when semantic context is present.

I love reusing flows and components wherever possible, and see no reason not to reuse the modal from before in this flow as well. When you elect to replace a template part, its relatives can be displayed in a modal like so:

The diagram above demonstrates the “Grid” view rather than the “Carousel” view from the video above. Both views will have their merits based on screen size, the particular template part being swapped, and so on. By reusing this component we get access to that affordance “for free”.

That’s it for now! This is all very much a work in progress, and you can follow along with progress in this tracking issue on github.

Another concept for contextual block pattern insertion

This one is proving rather tricky to get right! Feedback on previous iterations from the Full Site Editing Go / No Go discussion that took place this week indicates that seeing the pattern carousel on the canvas can be problematic.

It’s beginning to feel like one of those situations where a little friction in the UX can actually be quite helpful in helping the user to pause for a moment, and take in what is happening.

For linear end-to-end flows like this I often find that modals work well as they help establish the focus that is necessary to complete the task. So here’s a take on the pattern selection UI built in to a modal:

Inserting something complex like the Query block will trigger the pattern selector and give users a head start

This modal would be triggered on mouse-up to account for blocks being dragged from the inserter on to the canvas.

A nice thing about encapsulating this flow in a modal is that it can be entirely consistent regardless of entry point. This virtue could be valuable since there are many circumstances in which a user might find themselves inserting a block pattern; creating a template from scratch, transforming a block, editing a template part, and so on.

Zooming out to re-order root level blocks and discover contextual block patterns

An idea Joen and I have discussed a lot recently is providing users with a way to zoom out a level from the thing they’re editing in order to make more sweeping changes to the composition of their document.

This affordance can be a very useful tool when working with something like a template, where you might want to move a block over longer distances.

The notion of zooming out and revealing more of the “canvas” also creates an opportunity to introduce other features that perhaps do not fit in (or work so well) in the regular view. Pattern suggestion springs to mind as an obvious candidate.

A new Mode?

One way to add this feature to the Site Editor would be through a new Mode. Accessible through the menu in the top bar, or via an individual block’s toolbar, it would put these powerful features at a users fingertips in a variety of common flows.

Here’s a quick video mockup to demonstrate.

As the new Mode is engaged a number of changes occur:

  1. Root level blocks are reduced in size, spaced out, and their Toolbars are hidden.
  2. These blocks can be clicked to return to edit mode, or – if dragged – easily moved around the document.
  3. When a block is selected in this mode, any contextual block patterns are exposed via a carousel.
  4. Children of root level blocks are locked and cannot be manipulated.

Clearly there is a lot of work still to do here, but I think it’s an exciting concept because despite being such a powerful feature, it could be relatively straight-forward to implement in a piecemeal fashion.

Perhaps the initial iteration is only accessible while editing templates. Subsequent iterations can include pattern discovery for template parts, and then other block types. Finally the Mode can be introduced to the post editor as well.