I am not able to reproduce the bug, I don't want to be rude but it would help me if the instructions were more detailed.
The issues says:

• Create a sticky post
• Look at a template with a query loop in it (e.g. home.html)

What settings exactly does the query loop need to have for me to reproduce the issue?

setting the inherit global query setting in the query block

I am assuming this means the option labeled with "Inherit query from template"
But I honestly do not see the bug with or without this setting, with or without the PR, using 6.0 beta or 5.9.3.

For me the reproduction steps are these:

1. Switch to TT2
2. Create an old sticky post
3. Open the home page
4. The sticky post is not at the top of the list

@ntsekouras in 066437c I added a change that unsets all query block defaults which are not editable by the user when inherit is true. That to me makes the most sense:

• when we use the global WP_Query use its defaults and settings
• allow stick post behavior to be specified even when using global WP_Query because sometimes we need sticky post exclusive query blocks: for example if I want to show sticky posts at the top in an archive page global WP_Query won't do it by default, but I can use a secondary query block.

Haven't yet looked into the sticky use case here, but sharing a comment of mine to a relevant PR about inherit.

TLDR:

I think the big issue we're having with Query Loop and inherit is that while some controls are hidden in the UI, their values are preserved and I observed that while testing with at least orderby - this value is not set in the global query. We need to have no arbitrary results from block query attributes and what we expect when we set inherit to true.

Maybe we should inherit all options from global query but maybe there are some other concerns.. @draganescu had mentioned some nuances in the sticky use cases that I'm also planning to look into more..

I'm not sure yet about this and how to approach it. Right now I'm thinking that it should be better to just hide the sticky control when we inherit. It seems confusing to have these two(and probably other controls) that override the inherit - or we should communicate that better by altering the descriptions of the controls, etc..

For the specific use case now (sticky) I feel that we shouldn't honor every option and we should hide the control too. For example it doesn't make sense to have sticky -> only and inherit. This way it will just show the sticky posts...

A solution could be specific to sticky behavior
, which is: show them only on front page if we inherit the global query. So inside this block, something like this right after the merge of args might do the trick?

if ( is_front_page() ) {
	unset( $query_args['s'] );
}

What do you think?

I think sticky posts are important for certain workflows. I would proceed from the feedback gathered here, plus a chat with @jameskoster, plus the fact that we don't really have straight answers to:

• revert changes to the query block's rendering
• simply hide any UI that contains overriding options for WP_Query if inherit is ON (do so programatically in the edit component not only to the "sticky" override).
• come back to it with better approaches, maybe even make a "sticky" posts block as a variation of query or something.

Size Change: +2.46 kB (0%)

Total Size: 1.25 MB

_{compressed-size-action}

Will this functionality be ported to 6.0.1 or 6.0.2 Seems like a big enough bug that worth including.

I did something and I see some changes that should not be here. Will fix.

@spacedmonkey I don't see why not.

My understanding is that this would just have some fallback in the case of inherit in a single page, where now it shows nothing. This is not a blocker for me as in general it doesn't make sense to have such a query in a single page. I think this is part of the context detection issue we have, where we should better handle the Query Loop based on the context it lives. --cc @aristath

If a page/post template does not exist, then the WP template system and hierarchies fallback to using the main index template. If I'm not mistaken that's why this was added... It was just an extra line of defense to accommodate scenarios like that.
It is possible to have a block theme with nothing but an index.html template... and WP should be able to handle these cases. So I should be able to build a theme with an index.html template which can handle both archives and single posts

Thanks for explaining Ari!

It is possible to have a block theme with nothing but an index.html template... and WP should be able to handle these cases. So I should be able to build a theme with an index.html template which can handle both archives and single posts

I just tested that(only index.html and inherit:true) and seems to work well because it actually adds the name param. I'd love some more testing though to be sure 😄

@ntsekouras said:

Finally, I don’t think we should rush it in core, as it’s not a bug that creates problems. To the contrary, it would be better to give it time to test it in the plugin for any regression/issues.

And so I won't be rushing this into 6.0.1 RC1 that happens in a few hours. Instead, I added the backport label to flag this for 6.0.2 release squad.

@ntsekouras I'll add the updates to the no results block. @huubi and @spacedmonkey I've added you both as co-authors since the optimisation to the query was not part of the original intention or code of the PR.

@ntsekouras while adding the update to the no results block I realized I don't understand why do we need to query anything if we render a no results page, since we know there are no results? What was the intention there?

Later edit:

It seems this block could get the information if there are no posts from context rather than re-querying just to decide if it is going to render itself.

Cherry-picked with 493d14f for WordPress 6.0.2 release.