Editing global content via the Query block

Live editing post data inside a Query block – whilst editing something else like a page – requires some demanding mental gymnastics in terms of the UX. Users are required to understand that editing block properties (like position and alignment) are local to the page, while any data changes (like updating the publish date or the post title) are global. None of this is made very clear in the current experience as you are able to fluidly perform either action.

Me – https://github.com/WordPress/gutenberg/issues/32317

Today I explored a solution that adds a layer of friction between editing two global entities within the same view. There’s nothing really new here, I’m essentially building upon a concept I’ve shared before for the template editor. The use case is virtually identical.


  • Clicking anywhere on the Query will select it
  • Only when the Query has been selected can you interact with its children
  • Selected children exhibit some unique characteristics:
    • A semi-transparent overlay indicates that the block contents cannot be edited directly
    • Other blocks of the same type in the Query are highlighted with a dashed outline
    • The parent container exhibits a dotted outline
    • Content editing is accessed via:
      1. Click the more menu in the toolbar and select the “Edit” option
      2. Click the lock icon in List view
      3. Double-clicking the block
    • While a child block contents are being edited the following visual treatments are used to indicate it is a separate entity
      • Other blocks outside of the scope of that post are dimmed significantly
      • The post itself displays the isHiglighted treatment
      • The document title in the top bar is updated. This is based on the notion of displaying the document title in the top bar (#27093) and the existing pattern in the template editor of moving back to a referring entity.

There is quite a lot of redundancy built in to this concept, and some of it may be overkill. For now I’m throwing everything at the wall to see what sticks. Perhaps we can exercise some subtraction as we separated the wheat from the chaff.

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

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.

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.