[wp-trac] [WordPress Trac] #45337: Strange pagination issue

[WordPress Trac]

#45337: Strange pagination issue
------------------------------------------+-----------------------------
 Reporter:  sachit.tandukar               |       Owner:  (none)
     Type:  defect (bug)                  |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Rewrite Rules                 |     Version:  4.4
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:
------------------------------------------+-----------------------------
Changes (by jeremyfelt):

 * keywords:   => needs-patch needs-unit-tests
 * version:  4.9.8 => 4.4
 * severity:  major => normal
 * milestone:  Awaiting Review => Future Release


Comment:

 Hi @sachittandukar, thanks for opening a ticket.

 This seems similar to #28081, but likely different enough to have its own
 ticket. That deals with the `paged` query variable and this deals with
 `page`. This was partially fixed in #11694, which introduced the current
 `page` checking in [34492].

 There are (at least) two ways in which this presents itself:

 First: when a request is made to any `is_singular()` post/page with `/2/`
 appended to the URL, WordPress checks for an instance of `<!--nextpage-->`
 in the content. If it exists, and it matches the page number, `$success`
 is set to `true` and the page is loaded. If the next page marker does not
 exist, there is no current check that flags the content for 404 if a page
 number is part of the URL. For that, we could do something like
 [attachment:"45337.diff"] to return a 404 if content is not paged.

 Second: (highlighted in the ticket description), when a page is set as the
 `page_for_posts`, `is_singular()` is false and the logic handling `<!--
 nextpage-->` is skipped entirely. Earlier in the process, the query object
 was populated with posts, so as far as `handle_404()` is concerned,
 `is_home()` is `true` and the page can be loaded as is. The fix for this
 seems a little more complicated and _could_ be handled earlier in the
 process.

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