Sticky Posts not sticking

[scruffian]

Description

In TT2 (and all block themes I tested) when I set a post to "Sticky" it doesn't seem to have any impact on the order that the posts are displayed in.

I first noticed this when investigating a related issue, but it seems to have become more broken since then...

Step-by-step reproduction instructions

• Switch to a block theme (e.g. TT2)
• Create a sticky post
• Look at a template with a query loop in it (e.g. home.html)
• Confirm that the sticky post isn't at the top.

Screenshots, screen recording, code snippet

Environment info

• 5.9, trunk, TT2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[aurooba]

I am able to reproduce this bug! I've tested on both WordPress 5.9 and WordPress 5.9.1, with TT2.

[aurooba]

So there's a few things going on here. When you query posts, wp.data.select("core").getEntityRecords('postType', 'post', {}) with no sticky parameter, it actually doesn't give you the sticky post(s) at the top. So either this should be fixed in the REST API, or we need to alter this section of the post-template block to grab any sticky posts if they exist, and pop them on top if the query option for sticky is set to include, which in this case means if it's empty.

[scruffian]

I think an API fix makes sense.

[draganescu]

Another problem here is that when Inherit query from template is set the sticky preferences should either be hidden or they should be merged in the global query. Which one is more expected for the user? Given how the sticky behavior works in WordPress (get_option( 'sticky_posts' );) I think we should keep the sticky settings and merge them into the global query.

[draganescu]

The problem with sticky posts not sticking is because $query->is_home is not true. Only if is_home is true the sticky posts logic is executed. it is weird b/c is_home() returns true. It is not home because by default there is an s query arg which makes the WP_Query think this is a search.

[draganescu]

#40656 fixes the rendering I think, in a new PR the editor side should be also fixed.