Feature request: Query Loop - Disable the "Inherit Query from Template" setting by default when the QL is added to a page

[masperber]

What problem does this address?

When a Query Loop is used in a template, it is often used to display posts of a certain taxonomy, and it inherits the taxonomy query from the template that created it.

A Query Loop might also be added to a page in order to make a blog page, displaying recent posts. In this case, the "Inherit Query from Template" setting will cause the QL to display no posts at all because the Page template does not contain any taxonomies to inherit. This could be confusing for a user who doesn't understand the "Inherit Query from Template" setting because the QL Block will display posts correctly in the page editor, but the QL will appear blank on the website.

What is your proposed solution?

Disable the "Inherit Query from Template" setting by default when the QL is added to a page and/or remove the setting in this context.

[carolinan]

In addition, only some templates can inherit a query. For example, a query block in a front page template, 404, or custom template (the type you assign to a post or page) does not display anything if the setting is enabled.

[felixarntz]

Just discovering this issue as I was about to open a similar one: Based on the findings in #49904 and WordPress/wordpress-develop#5104, I agree the default and UI for the "Inherit Query from Template" setting (inherit sub attribute) should be revised.

Here's what I propose:

• Leave the default to true when the block is used within a block template or template part, since in that case relying on the main query makes sense to be the default.
• Change the default to false when the query block is used within a specific post (i.e. post of any post type, whether it's post, page, product, etc.): It makes no sense to use the main query within a specific post, here's why:
  • If you're visiting that post specifically in the frontend, it would contain just that same post again, nested within itself -> makes no sense.
  • If you're visiting that post within any archive (e.g. the home page, a category archive, etc.), it would contain the same list of posts, contextually depending on which archive you're on.

So really, it makes no sense to inherit the main query within a specific post. Why would you want to have the same query as is already visible on the page within a post on that page, especially given that it would change depending on where you are? Where the query loop block does make sense within a specific post is for example to display an entirely separate query, e.g. other posts in a specific category or something like that. But such use-cases would not rely on inheriting the main query.

Therefore I think at a minimum we should change the default for those usages to false, but IMO we could even disable/hide that control entirely in this circumstance, since I don't think it has any value there.

cc @gziolo @youknowriad

[gziolo]

Leave the default to true when the block is used within a block template or template part, since in that case relying on the main query makes sense to be the default.

That is the current default behavior and it makes perfect sense in this context.

Change the default to false when the query block is used within a specific post (i.e. post of any post type, whether it's post, page, product, etc.): It makes no sense to use the main query within a specific post

I agree that it would be the best approach to change that value upon insertion, and we could use a block variation registered only in that context that would take care of the necessary modification.

Therefore I think at a minimum we should change the default for those usages to false, but IMO we could even disable/hide that control entirely in this circumstance, since I don't think it has any value there.

I couldn't agree more with all the points @felixarntz raised. We would still need to respect the Query Loop blocks inserted with the inherit set to true in the context of post content, but once the editor gets loaded with the same setting to false, we could no longer allow enabling it again.

I would love to hear from @ntsekouras who helped to shape how Query Loop block works today to ensure we don't miss anything important.

[ntsekouras]

I have nothing more to add here. I agree with the issue/comments and I actually had a PR for that, which might had some nuances and also didn't get much traction, and I eventually closed it.

[gziolo]

I have nothing more to add here. I agree with the issue/comments and I actually had a PR for that, which might had some nuances and also didn't get much traction, and I eventually closed it.

I see in the PR some logic that sets the inherit value during the initial render which might be fine, too. I don't have strong opinions about the approach. Whatever works best. The other aspect that we would need to add would be also based on a similar technique for detection for the context would be finding the switch that allows enabling inherit again.

[metabreakr]

+1

Ran into this issue today.

[annezazu]

Adding this to the polish board in hopes someone might be able to tackle this :)

[meffordh]

Apologies for my tenuous grasp on the concepts but I could be one of the many users that run into this issue. I cannot quite understand why if I create a page with inherit=false for the sub-property of a query loop block, through the rest api, with a working query loop block, it subsequently defaults to only inherit the global context for the template.

Here is a sample of working block code that renders fine when pasted from one page to the next in the back end editor, but if a user creates content remotely and this exact same native block code is used, it seems to be edited by another process and the sub-query parameters are wiped out, or appear to be in the editor but not in the database? and the database is not what's used. Is there a method to disable this or use what is actually stored in the content for the query loop sub-properties, by chance?

Any background info or if this is the wrong place please advise, otherwise +1 from me

Here's the sub-property portion of the gutenberg native unedited block, If a user Pastes this from one page to another, it loads without issue
{"perPage":"9","pages":"1","offset":0,"postType":"page","order":"desc","orderBy":"date","author":","search":","exclude":[],"sticky":","inherit":false,"parents":[123]}} -->

If a user Imports or use REST api or otherwise for the same code block, it subsequently becomes the below in the editor, although I actually think it is the same as above in the database? (this shows no related results in the editor in the example where it's a page and the user is trying to use the query loop to display a list of pages related to the parent, obviously given the params)
{"perPage":10,"pages":0,"offset":0,"postType":"post","order":"desc","orderBy":"date","author":"","search":"","exclude":[],"sticky":"","inherit":true,"taxQuery":null,"parents":[]}} -->

And on the front end, rendered, it actually shows 1 result, per behavior described above, the page itself.

Thanks

[peteringersoll]

I'm putting together a meetup presentation and ran into this issue. So I went back to the "Taking advantage of query loops" training video where it is recommended to disable "Inherit Query from Template." This is again repeated later in the video.

The recommendation is to toggle it off "to customize the query." It's not clear what happens when you toggle it on, other than "certain customization options will be hidden." To see the query look right in the editor and then to not see any results on the front end is not only confusing, it could be a big time waster for someone to figure out.

[priethor]

Considering @ntsekouras' Context detection for Query block would cover and solve this issue as well, are we ok closing this issue in its favor?

[priethor]

Closing then in favor of #30369; we can reopen if necessary.