Query Loop Block Improvements

[mtias]

These are some notes for tracking improvements to Query block.

Prioritized for WordPress 5.8:

• Expand inline descriptions to help explain terminology and function better.Add helpful text to Query Loop block #32694

The "inherit query" setting is very obscure. There's a few things we need to address there:

• Don't make it the default for patterns. [Patterns]: Update Query patterns to have inherit:false #31856
• Add more context (what is it inheriting?) and perhaps only show the setting if the block is being used within a template. Context detection for Query block #30369 Add helpful text to Query Loop block #32694

The other part that is tricky is the live editing. It can be super useful for some contexts but it is a bit too much as a default.

• Make "editing" an optional setting. Query block: Disable editing of content by default #32317
• Make "editing" disabled by default. [Block Library - Post blocks]: Make post blocks uneditable when inside Query block #32505

Currently the relationship between Query and Loop is still a bit confusing. I'd propose making some adjustments to the names:

• Let's consider changing the names from "Query" and "Loop" to "Query Loop" and "Post Template" for more clarity. [Block Library]Rename QueryLoop to PostTemplate and change Query label #32514

---

Follow up iterations

Expand on the editing flow by having something similar to the isolated part or modal view as a way to edit both the template and content. Related to:

• Supplementary editing flow for "The Loop" template Supplementary editing flow for "The Loop" template #26190
• Consider again the implementation of the "Posts List" variation. Refine the Posts List block #32268
• Hide the Query Loop block from the inserter Hide the Query Loop block from the inserter #37081
• Make text color options conditional depending on the Link Settings inspector option Conditionally show or hide inspector settings depending on other block settings #36972
• Rename inner blocks to something more user-friendly that doesn’t say Query (e.g. Next Page) Rename Query- inner blocks to be more user-friendly #37079

[priethor]

Make "editing" an optional setting and disabled by default.

It could also be worth exploring a "click-through" interface like with reusable blocks in #29337

[ntsekouras]

Consider again the implementation of the "Posts List" variation.

What do you mean here?

[jameskoster]

It could also be worth exploring a "click-through" interface like with reusable blocks in #29337

I believe this is only one half of the editing consideration. The click-through will help in terms of boundaries and general selection interactions, but there is also the contents of the innerblocks (IE the actual post content) to think about. Editing the title of post B while editing post A can be quite confusing.

[mtias]

@ntsekouras having a version of Query that doesn't include the inner Loop (because it doesn't need to show prev/next links nor query titles) and is called "Post List" or something similar to that, allowing us to treat Query as the building block for themes but something more familiar (like Latest Posts) for users.

[youknowriad]

Is there any important remaining thing here that is mandatory in 5.8? Should we remove this issue from the board?

[Clorith]

Looking at the checklist in the initial post, there's still a fair bit of outstanding issues (or just needs an update), most importantly I would say is the edit feature.

I've noticed this is still on by default, and will lead to user confusion (if I edit something in a page, I expect it to be within the context of that page, not that it changes globally on my site). Even with the extra checkboxes for "are you sure you want to update these secondary pages", they're checked by default, and I often don't second-guess the confirmation screen, I should use it for a double-check, but to me it's become "just another double-click I need to make".

[jameskoster]

Make "editing" an optional setting and disabled by default.

I'd like to propose the solution in #31461 (comment) for this. The use case is virtually identical.

---

I wonder if we can decrease reliance on the confusing "inherit query from URL" option through contextual variations. Similar to what we've done with the Header / Footer template parts.

When editing a post, I would never want a query to inherit from the URL. Also, the UX to display a post list relies on the user inserting a "Query" block... this is not very intuitive. I would suggest:

• The Query block cannot be inserted in to posts at all, and is strictly a template-only block.
• Instead, I can insert a "Posts" block which is a Query variation and shares most properties. The exceptions being: it has a relevant icon / description, and the "inherit from URL" option is removed entirely.

When editing a template, you will want the query to inherit from the URL most of the time. So we can just make that the default, and move the option to the "Advanced" panel. In fact... if we implement post-type variations as outlined above, we can probably remove this confusing option altogether. The result is:

• If you want to insert a post list in a template or a page, you insert the "Posts" block (which is a Query variation).
• If you want to insert a query that inherits from the URL in a template, you insert the "Query" block.

[priethor]

Is there any important remaining thing here that is mandatory in 5.8? Should we remove this issue from the board?

I think there are still a couple of things that should be addressed before 5.8, like changing the block name, clarifying the inheritance option, and disabling editing by default.

[jameskoster]

I think there are still a couple of things that should be addressed before 5.8, like changing the block name, clarifying the inheritance option, and disabling editing by default.

I put a design prototype together that explores some of these issues. Many of the concepts we've been working on for the template editor can potentially be applied here as well.

Sound on:

Query.block.mp4

Click-through pattern for template parts and reusable blocks: #31109
Content-locking: #31461

Edit: I realise that a variation to display posts wouldn't support pagination, so we could simplify the structure significantly in that use case by removing the template block:

[youknowriad]

Removing this from the 5.8 broad as I believe we got all the 5.8 targeted improvements in already.

[annezazu]

Feedback from the FSE Outreach Program consistently points to confusion around what settings live in the block toolbar vs the settings in the sidebar. For example, folks seem to expect the ability to change the number of items shown in the sidebar rather than the toolbar. Could an audit of these various settings (including their naming) be added to this issue to help improve the experience?

[priethor]

Added prioritized items for WordPress 5.9, as the Query block will be instrumental in block theme building.

[priethor]

De-prioritized items from WP 5.9 and moved them down to the further iterations section.

Because there is only a handful of improvements left, we can close this tracking issue and continue work on the specific tickets. 🚀