WP_Query with posts_per_page and sticky posts

[yukataninja]

When using WP_Query with showposts=some_number and you have one post set as a sticky that is out of the range of some_number, the query returned will have some_number plus one posts returned. If the sticky post is within the range of some_number then only some_number of posts is returned by WP_Query.

Example Normal: have 3 posts in order:
Post 1,
Post 2,
Post 3

my_WPQuery = new WP_Query("showposts=2");

This will return Post 1 and Post 2

Example Error: have 3 posts in order:
Post 1,
Post 2,
Post 3 (<-- make sticky)

my_WPQuery = new WP_Query("showposts=2");

This will return 3 posts (Post 3, Post 1, Post 2).

Expected to return 2 posts (Post 3, Post 1).

Example OK: have 3 posts in order:
Post 1,
Post 2 (<-- make sticky),
Post 3

my_WPQuery = new WP_Query("showposts=2");

This will return 2 posts (Post 2, Post 1).

[janeforshort]

Punting due to feature freeze. Reconsider with next release.

[Denis-de-Bernardy]

there is an argument that lets you disable stickies. see how it's done in the recent posts widget.

[apatheticresistance]

I've never commented on the Wordpress Trac before, so forgive me if I'm doing this wrong. But I don't think this issue should be closed. Disabling stickies won't produce the intuitively desired result. From the original example:

have 3 posts in order: Post 1, Post 2, Post 3 (<-- make sticky)

my_WPQuery = new WP_Query("showposts=2");

This will return 3 posts (Post 3, Post 1, Post 2).

But intuitively it should return 2 posts (Post 3, Post 1). I've tried using the new "posts_per_page" and it seems to produce the same result.

[Denis-de-Bernardy]

You are completely correct in that it is not intuitive. But there's no easy workaround without re-engineering of the WP_Query class.

Intuitively, we'd need to look-up sticky posts first, and then change the query's LIMIT statement accordingly. Doing so, however, introduces a new issue, which is what happens when a sticky post should be returned as part of the result anyway. Quite arguably, we could end up stripping stickies from all non-singular queries where they might appear, but the performance impact is not benign.

The least problematic ends up being the current setup, with you using the caller_get_posts argument.

[brocheafoin]

Changing title so that it conforms to up-to-date parameter name (i.e. not showposts, which has been deprecated for a while).

I am still able to reproduce this bug in 3.0.4, so adding version info as well.

Once I find the time to install 3.1, I'll test for this bug and maybe take a stab at it.

[ciantic]

Reproduces with 3.4 alpha.

To maintain backwards compatibility there could be sticky_posts_as_first bool in addition to this ignore_sticky_posts.

It should ideally work when using cat also, the stickies does not work with new WP_Query("cat=xx") at the moment.

[SergeyBiryukov]

Version number indicates when the bug was initially introduced/reported.

[chavo]

I'm looking for same code and I can't to figure out how to do it. Did you find a solution?

Thanks in advance.

[JasonWoof]

Here's a patch to fix this bug: ​http://jasonwoof.com/downloads/0001-Fix-pagination-with-sticky-posts-fixes-9300.patch

I removed 48 lines of craziness (resorting the results of the query, and doing an additional query to get sticky posts that wouldn't otherwise be on the first page)

I used the conditional that decides when there should be stickies at the top, and used it to add a sorting clause to the sql query so the sticky posts come at the beginning, and are paginated with the LIMIT clause as they should be.

This is against WordPress 3.2.1. I hope it is useful for fixing the latest version too.

[JasonWoof]

patch to fix the bug (in version 3.2.1)

[wonderboymusic]

We aren't going to fold stickies into the main SQL statement. post_per_page + number of stickies that don't intersect is longstanding behavior