Query Loop Block: Selecting to include sticky posts ignores the set number of items per page

[sharonlaker19]

This issue is open primarily for tracking, as the relationship between the QL block and sticky posts is a discussion in the Core Gutenberg project. See this comment for details.

Quick summary

When you set the Query Loop block in the Site Editor to include sticky posts, it ignores the number of posts selected under Items Per Page. It seems to be combining the sticky posts plus the number of posts selected per page, instead of showing the set number of items per page.

Steps to reproduce

1. Start with a site on an FSE theme and X amount of existing sticky posts.
2. Set your template to use a Query Loop block.
3. Select to include sticky posts in the Query Loop block.

4. Set the Items Per Page to Y.

5. The Query Loop block in the Editor will show the selected Y amount of posts.
6. When you publish your changes, however, the page will show X + Y posts instead of the selected Y posts (including sticky).

What you expected to happen

I expected the page to only show the chosen number of items per page.

What actually happened

The page shows the chosen number of items per page, plus the sticky posts.

Context

No response

Platform (Simple, Atomic, or both?)

Simple, Atomic

Theme-specific issue?

No response

Browser, operating system and other notes

No response

Reproducibility

Consistent

Severity

Some (< 50%)

Available workarounds?

Yes, difficult to implement

Workaround details

They can use the Blog Posts block and manually select the posts they want to display, or include the sticky posts in their own category/tag.

[sharonlaker19]

• [ ] 5776006-zen

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 5776006-zen
• [ ] 6752049-zen
• [ ] 7184426-zen

[jp-imagines]

Came across this in 5450024-hc as well. Simple site on the Morden theme. Possible related issue: https://github.com/Automattic/wp-calypso/issues/61620

[zachspears]

I was able to reproduce this. I also noticed that the Query Loop block would display the correct number, including the Sticky post, if the sticky post would have been included regardless. For example, if the sticky post is three posts ago and you display three posts, then the Query Loop Block will display the correct number. If you change the Block to display two posts, it will display three posts to include the sticky post, as outlined in this issue.

Keeping Low priority due to low impact.

[dpasque]

Switching normal for low priority based on above comments.

[dcoleonline]

I encountered this today while building a site for a Built By Express customer. They needed 15 posts to show, but when a post older than their most 15 was marked as sticky, the block showed 16 posts.

[room34]

dpasque

Switching normal for low priority based on above comments.

Can you explain which of the above comments you feel warrant lowering the priority of this issue?

[dpasque]

Hi @room34! 👋

Can you explain which of the above comments you feel warrant lowering the priority of this issue?

This was a bit ago and I don't fully remember my reasoning at the time, but I'm pretty sure I was just making the labels match the priority laid out in the initial triage comment.

I did take this chance though to revisit and retriage this issue! 👍

This issue is kind of complicated! Frustratingly, it looks like this is a weird quirk in the current design of sticky posts, and has a long history of its discussion. That said, it still makes the Query Loop block pretty useless if you are in the state where you want...

1. To use sticky posts on your site, and...
2. have them included in a query, but...
3. not stuck to the top of each page, but rather just sorted to the front of the query.

Fortunately though, there's already an issue open in Gutenberg to discuss providing better handling at the Query Block level, and this issue is included in the tracking issue that lays out the next steps planned for the Query Loop block.

(For clear reference, here is the full Gutenberg URL: https://github.com/WordPress/gutenberg/issues/41184)

So, I think the discussion about the design of the block should continue on that Gutenberg issue, especially because this is something of a design change that impacts the broader WordPress community. 👍

We can keep this issue open as a cross-repo tracker issue and document WordPress.com users that are impacted or interested in the change. In the meantime, we can also use this issue as a place to help lay out alternative solutions based on site configuration and what people would like to accomplish! There are a few other blocks (like the Blog Posts Block) that provide alternative ways to listing posts.

We can also bump the priority of this tracker issue back up to "Normal" to match the categorization of this issue in the Gutenberg tracking issue.

[room34]

@dpasque Much appreciated. I agree this is a sticky (no pun intended) issue… the SQL going on behind the scenes when querying sticky posts is brain-melting. I've managed to find a workaround for the problem in my specific case, and I think at least part of the problem was a misunderstanding of what "sticky" really means. But, non-technical users are almost certainly going to also misunderstand what it means, and find themselves with an extra post getting returned in Query Loop blocks. I'm hopeful the situation can be resolved in a future update!

[dpasque]

@room34 Totally agree there with you on all of that! 🙂 I had a similar brain-melting experience diving into the history and current meaning of "sticky" haha... 😆 It's an old concept that just doesn't play very nicely (or how the average person would expect) in the new era of block themes, etc. And as the future direction doubles-down on block-based full site building, it feels like we'll need to expand our options for classifying and sorting post content within index-like blocks. Fortunately, it looks like there's a lot of discussion in the area happening in the Gutenberg space!

Glad to hear you were able to find a workaround for your current situation. 👍

[masperber]

Another report here: 6752049-zen

[masperber]

Another report here: 7184426-zen