[wp-trac] [WordPress Trac] #27282: WP_Query returns more results when there are sticky posts

[WordPress Trac]

#27282: WP_Query returns more results when there are sticky posts
--------------------------+-----------------------------
 Reporter:  markoheijnen  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Query         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:  stickies needs-unit-tests has-patch => needs-patch


Comment:

 bendoh - Thanks for restarting this conversation. The sticky logic in
 `WP_Query` is not great, and your patch makes a couple of important
 improvements. After writing some tests for the existing functionality
 [31439], as well as tests for what I see as the primary bugs in the
 current logic [attachment:27282.tests.diff], I have a couple thoughts and
 pieces of feedback on your patch.

 First, a clearer enumeration of the bugs. The tests in [27282.tests.diff]
 suggest three distinct but related problems with the current
 implementation:

 1. When looking at the home page, stickies are jammed onto the top of the
 page. This increases the total number of items on the page. Say you have
 posts_per_page=10 and you have 3 stickies, one of which would have
 naturally appeared on the first page of results, and the other two of
 which would not have. The home query will return 12 posts. If I understand
 correctly, this is the particular manifestation of the bug being reported
 in this ticket.
 2. Directly related: Results on page 2 should be offset by the total
 number of stickies displayed on page 1. So if posts_per_page=10, and 2
 stickies are added to the front page, the first post on the second page
 should be the 9th oldest post, *not* the 11th oldest.
 3. If a post is stickied which would have appeared on the first page
 anyway (say, the 5th oldest post), it will be removed from its normal
 order and put at the top of the page. If a stickied post would normally
 appear on page 2, it currently appears in two places: at the top of page
 1, and in its normal order on page 2. This seems incorrect at a glance -
 posts should only appear once in the paged results.

 The approach in your patch fixes all three issues. However, it fails two
 other tests added in [31459]:

 a. It doesn't respect `'post__not_in'`. See
 `test_stickies_should_obey_post__not_in()`.
 b. The stickies are being ordered differently. In the current
 implementation, stickies are ordered by 'post_date'. See
 `test_stickies_should_be_included_when_home_is_true()`.

 I'm somewhat concerned about what happens when the number of stickies is
 more than posts_per_page. On the current implementation, all stickies will
 be shown on the front page, no matter what. (See #23336 for some
 discussion.) With your patch, stickies will fall into the normal
 pagination flow, which may mean that stickies get sent to the second page
 and beyond. While I think that this behavior is more logical, I also think
 it's bound to cause some consternation. Do you have a sense of other
 software handles this problem? What do popular forum packages do?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27282#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform