Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Query Loop shows wrong number of posts on the front end with sticky posts #1253

Open
frzsombor opened this issue Jun 23, 2024 · 1 comment · May be fixed by #1255
Open

Bug: Query Loop shows wrong number of posts on the front end with sticky posts #1253

frzsombor opened this issue Jun 23, 2024 · 1 comment · May be fixed by #1255
Labels
triage Awaiting review

Comments

@frzsombor
Copy link

frzsombor commented Jun 23, 2024

Description

On a website I have sticky posts, that I want to show in one Query Loop with the non-sticky posts, together limited to 3 posts. If I set a limit in the Query Loop, the sticky posts are not counted and this causes a problem in the layout. For example, I have 2 sticky posts and 5 non-sticky posts (7 posts all together). If I want to show only 3 posts and I set this limit, 5 posts will be rendered by the Query Loop: the 2 sticky (not counted) and 3 additional non-sticky posts.

Steps to reproduce

  1. Create 3 posts in WP
  2. Set one post to be sticky
  3. Add a query loop on a page and set limit to 1
  4. Block editor will show one post, but on the rendered page there will be two

Expected behavior

When I set a limit on Query Loop, I expect that to be the maximum number of rendered posts.

Actual behavior

Currently sticky posts are not count as posts, so they will always be part of the loop (if not excluded) and limit applies to additional non-sticky posts only.

References

This is a related live issue in Gutenberg here: WordPress/gutenberg#41184 as part of WordPress/gutenberg#41405.
However, as this is a very frustrating bug for those who are actually building a blog/news website, I think this could be fixed in GenerateBlock - as it has a custom query loop block anyways. Also Gutenberg has 5K+ open issues so maybe this won't get fixed soon on their end.

Related: #1252


Additional notes: WP Sticky posts are a complete mess. Sticky posts are always loaded with a different query in WP and prepended to the array of the actual query results. This means if we set an offset (like offset:3) and/or any limit, and we also have sticky posts, WP will first load ALL the sticky posts, then run the query on everything else excluding(!) sticky posts and apply the offset and limits on those non-sticky posts. So, we will get all the sticky posts first in the array (no matter what offset/limit we use), then everything else WITH offset and limit.

For example:

Posts [9] [8 *sticky] [7] [6] [5 *sticky] [4] [3] [2] [1]
Posts rendered [8 *sticky] [5 *sticky] [9] [7] [6] [4] [3] [2] [1]
Query include sticky, offset 3, limit 4
Expected [7] [6] [4] [3] - stickies and [9] removed by offset, return four(!) results from the remaining
Result [8 *sticky] [5 *sticky] [4] [3] [2] [1] - stickies still present, [5] and [4] skipped, six(!) results

I think it might be a good idea to completely ignore WP Query sticky handling (run all queries with sticky status ignored) and only when user set sticky:include, handle sticky posts with a custom function or a better query. I've submitted a PR for limiting the number of rendered posts with PHP, because at least that way it won't break the layout if given by a design, we have to work with exactly a maximum number of posts.

@frzsombor frzsombor added the triage Awaiting review label Jun 23, 2024
@frzsombor frzsombor changed the title Query Loop shows wrong number of posts on the front end with sticky posts Bug: Query Loop shows wrong number of posts on the front end with sticky posts Jun 23, 2024
@iansvo
Copy link
Collaborator

iansvo commented Aug 20, 2024

@frzsombor Thanks for the report. Just an FYI, I wasn't able to reproduce this until I had around 5-7 posts and at least 2 were sticky. It's definitely weird and something we can see about addressing in the 2.0 release where we'll have a new and improved query block and such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Awaiting review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants