Visual Revisions

Today I begun exploring ways to refine the contents of the template inspector for #36951 and stumbled across the idea of visual revisions. I’m thinking it might be neat to have a way to browse through past versions of a document in a more visual manner, similar to Figma.

Since revisions are just stored HTML, it doesn’t feel like a huge leap would be required to achieve something like this.

Good idea? Bad idea? Discuss on github.

Exploring a global UI region in the Site Editor

In addition to features like Reusable Blocks a number of other global concepts emerge in the Site Editor:

  • Navigation management
  • Template management
  • Styles
  • Site settings

And yet we lack a centralised area in the UI in which to manage these things. Consequently there is a lack of clarity with regards to whether a setting is local or not. For example Global Styles appears on the same plane as block settings.

As a part of #36667 I’ve been ideating on high level design options to improve this. In particular I’m drawn to a left-hand panel with an inverted color scheme as a home for features that are global in scope. The icon column is a common design pattern for adding layers of navigation that we see in software like Slack and VSCode.

One reason I’m particularly excited about this concept is that it provides an intuitive way to navigate to (and edit) your posts / pages in the site editor, something that as yet has proven tricky to get right.

A subsequent idea emerges that in the far future it could be possible to manage posts and all manner of other WordPress functionality here:

Until then, this feels like a promising idea for the Site Editor. Follow along in #36667.

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.

Concept: Creating a query builder inspired by design tools

Design Tools and their associated UI are an exciting development both in terms of the power and flexibility they will afford users, but also how they will replace chaos with consistency in the block editor UX.

I think the design does a really good job of tidying complex features / interfaces away until the user actually needs them. Not all blocks need padding, but it should be easy to add it as desired. The overall experience feels much less cluttered.

This got me thinking about one of the most complex block we have – the base Query Loop. Could we use this same design pattern to make an intuitive UI for query building? I couldn’t resist putting a quick prototype together…

The idea here is simple, when you insert a Query Loop it will display everything from a single post type (multiple post types doesn’t make much sense to me). You then add and combine filters using the familiar Design Tools UI until you’re satisfied with the output. I think this does a good job of avoiding the currently overwhelming experience when interacting with the vast multitude of options this block offers.

This pattern could not only be used to toggle filters on the Query block… maybe it’s also possible to toggle panels like Typography, Dimensions, and Border on all blocks.