Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #35562, comment 3


Ignore:
Timestamp:
01/22/2016 11:21:55 AM (9 years ago)
Author:
birgire
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35562, comment 3

    initial v1  
    1 The problem is that {{{WP::handle_404()}}} is executed long before {{{setup_postdata()}}} where the {{{content_pagination}}} filter currently lives.
     1The problem is that {{{WP::handle_404()}}} is executed long before {{{WP_Query::setup_postdata()}}} where the {{{content_pagination}}} filter currently lives.
    22
    3 I don't think we want to remove a restriction in {{{WP::handle_404()}}} that makes sure the current page number doesn't exceed the maximum number of content pages.
     3I don't think we want to remove a restriction in {{{handle_404()}}} that makes sure the current page number doesn't exceed the maximum number of content pages.
    44
    5 If we want to keep it, I suggest we try to move the content pagination logic (including the {{{content_pagination}}} filter) from the {{{setup_postdata()}}} up to the {{{WP::handle_404()}}} method.
     5If we want to keep it, I suggest we try to move the content pagination logic (including the {{{content_pagination}}} filter) from the {{{setup_postdata()}}} up to the {{{handle_404()}}} method.
    66
    77The current content pagination isn't supposed to work for secondary loops anyways, as far as I understand it, even though the {{{content_pagination}}} filter is available to all loops through {{{setup_postdata()}}}.