Query Loop: Default settings don't render any items when inserted in content

[fabiankaegy]

The Query Loop block can exist in two different modes:

1. Default: Inheriting from the Global template
2. Custom: Allowing the user to define the Post Type etc. manually.

This works great in the context of editing a Template. But when you insert a Query block inside content and leave the settings on "Default" it shows you a list of posts in the editor. But on the frontend it never displays anything because there is no global query to inherit from.

Proposed Solution

When there is no global query to inherit from the "Default" settings should display X (global posts per page setting) posts of the default posts post type.

[alaczek]

I encountered the same issue - it is quite confusing.

Here are some screenshots:
Editor view, with Query Loop block inserted inside a page content:

The live preview of the static "About" page:

When there is no global query to inherit from the "Default" settings should display X (global posts per page setting) posts of the default posts post type.

I don't know that this is true - when Query Loop Block is inserted into a post or page the query returns that specific post or a page. This is expected but, I agree this might not be the desired outcome (plus it's very confusing because of the differences between editor and preview).

What if instead of defaulting to the "Default" setting, the Query Loop block defaulted to Custom option? The Custom option is set to display posts, newest to oldest, including sticky posts, 10 per page, which I believe would be closer to what people expect when inserting Query Loop block, and it would also help with discovery of all these extra query settings.

It might also be worthwhile to consider switching the Query Loop block initial state to "Custom" regardless of if it's inserted in a page/post or a template. The Default (which used to be called "inherit from template") feels like a more advanced option of the two, and with more potential to confuse.

[autumnfjeld]

Suggestion: instead of "Default" what do you think about the label "Inherit"? It is much more specific, the word default isn't very helpful.

If someone doesn't know what "Inherit" means, at least it is a hook to go googling for. "Inherit query loop" is better than "Default query loop" IMO.

Point in case, google's autocomplete:

[richtabor]

What if instead of defaulting to the "Default" setting, the Query Loop block defaulted to Custom option? The Custom option is set to display posts, newest to oldest, including sticky posts, 10 per page, which I believe would be closer to what people expect when inserting Query Loop block, and it would also help with discovery of all these extra query settings.

Template-wise, the Query Loop should almost always be "Default", to allow the template to orient the block.

Ideally, the default state of the Query Loop would render the index template's query loop (using posts per page, "post" post type, etc). That way it "just works" and you don't have to switch to "Custom" unless it's an explicit decision to do so.

[richtabor]

This works great in the context of editing a Template. But when you insert a Query block inside content and leave the settings on "Default" it shows you a list of posts in the editor.

An alternative is to have the "Query Type" control available when editing via a template. Not 100% sure about it, but what do you think? cc @WordPress/gutenberg-design

[jasmussen]

I quite like the word "Default" over "Inherit". Default suggests that this is what you should have selected if you're not sure what you're doing. It's also what you should be using most of the time. That supports this:

Ideally, the default state of the Query Loop would render the index template's query loop (using posts per page, "post" post type, etc). That way it "just works" and you don't have to switch to "Custom" unless it's an explicit decision to do so.

It should just work. Custom disconnects this from reading settings in WordPress, which will accumulate confusion over time: why isn't my template respecting my updated reading settings?

An alternative is to have the "Query Type" control available when editing via a template.

Not sure what you mean, do you mean hiding this control in templates and showing when editing a query on, e.g. a page?

From my read here, the issue is that in the page/post editor, an inserted Query loop set to default shows posts, but when you preview/publish said page/post, nothing appears. This feels like a bug, and if the frontend shows no posts for a particular query, then neither should the editor. That seems the first issue to fix, bringing these two in sync. That's assuming it's intended that the query loop should not show posts in this context.

Either that's enough to get users to understand that they need to provide a custom query for anything to show up. If it isn't, we could potentially show a notice, just like we show yellow contrast notices, that "This query did not return any results."

[jameskoster]

An alternative is to have the "Query Type" control available when editing via a template. Not 100% sure about it, but what do you think? cc @WordPress/gutenberg-design

This is pretty much what I've been advocating for a long time.

My understanding aligns with @alaczek... technically the frontend is correct here; a Query placed inside a page and set to inherit will retrieve data from the page itself. This has no practical use (that I can think of), so it seems reasonable to me that a Query inside a Content block would always be custom.

[jasmussen]

technically the frontend is correct here; a Query placed inside a page and set to inherit will retrieve data from the page itself. This has no practical use (that I can think of), so it seems reasonable to me that a Query inside a Content block would always be custom.

I'm not personally a fan of changing a block default based on where you insert that block, but happy to defer to other consensus here. Mostly though, if the frontend for the default query shows something different than the editor, we should fix the editor bug. This would be necessary even if we did flip the defaults, so when you toggled default, it'd show the actual end result, 1:1 with the frontend. Useless sure, but current behavior feels like a misleading error.

[jameskoster]

We should double-check whether the frontend behavior is correct. If it is then the idea isn't to change the default; it's to hide the 'Query type' control altogether, because it's not serving any practical purpose.

[mikachan]

I've started taking a look at how to address this, and currently have a draft PR here: #65067.

I'm not sure if I'm going in the right direction, but I wanted to share early in case it looks promising. I think the current front end behavior is correct, but I'm still not sure if this is intuitive enough for the end user. In any case, this draft PR at least aligns the Editor and front end query results.