[wp-trac] [WordPress Trac] #18897: query_posts / WP_query parameter 'offset' should play nicely with 'paged'

[WordPress Trac]

#18897: query_posts / WP_query parameter 'offset' should play nicely with 'paged'
------------------------------------------+-----------------------------
 Reporter:  here                          |       Owner:  wonderboymusic
     Type:  enhancement                   |      Status:  reopened
 Priority:  normal                        |   Milestone:  Future Release
Component:  Query                         |     Version:  3.2.1
 Severity:  normal                        |  Resolution:
 Keywords:  has-patch commit needs-codex  |     Focuses:
------------------------------------------+-----------------------------

Comment (by coffee2code):

 Updated [attachment:18897.diff] with [attachment:18897.3.diff] in order to
 add support for negative offsets [comment:14 as suggested] by
 @bradyvercher.

 The previously proposed [attachment:18897.2.diff] was not a sufficient
 change to add support for negative offsets as it broke the basic
 functionality of 'offset' (`test_query_offset()` failed).

 18897.3.diff also adds the following unit tests:

 * `test_query_negative_offset()` : Test use of negative offset by itself
 (since no paging is involved, it should have no effect in this situation)
 * `test_query_negative_offset_and_paged()`: Test use of negative offset in
 conjunction with paging.
 * `test_query_large_negative_offset_and_paged()`: Test use of large enough
 negative offset that would try to reach before first possible post.

 With negative offset support, it would be possible to have defined a
 front-page posts_per_page of, say, 5 (to show posts 1-5). Then on
 subsequent pages have posts_per_page be 10 with an offset of -5 (to yield
 posts 6-15 on page 2, 16-25 on page 3, etc).

 That should satisfy @bradyvercher's functional request. We still have the
 notion brought up that we shouldn't fix a bug because people hacked around
 it. As [comment:21 I argued] earlier, this is clearly a bug that
 developers knowingly worked around so they should be prepared for that bug
 to get fixed.

 The original patch soaked in trunk for 4 weeks before getting reverted.
 Maybe the latest can get in on 4.2-early?

 ''(Note: this .3.diff patch does not account for
 [attachment:18897-unittests.diff] since the unit test re-added in that
 patch hasn’t been removed from core unit tests yet. Should that unit test
 get remove as per #30284 at some point, then both 18897.3.diff and
 18897-unittests.diff will need to be applied unless a fresh patch that
 does so is added.]''

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