[wp-trac] [WordPress Trac] #30831: paginate_links() now needs add_args=false

WordPress Trac noreply at wordpress.org
Tue Dec 23 16:21:05 UTC 2014


#30831: paginate_links() now needs add_args=false
--------------------------+-----------------------------
 Reporter:  bobbingwide   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  4.1
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 With WordPress 4.1 my simple call to paginate_links() now requires me to
 specifically set `add_args=false`.

 If this parameter is not set, then on any "page" after 1, all the links
 point to the current page.


 I have a number of shortcodes which implement their own pagination. They
 use query parms named bwscid''n'', where ''n'' is an integer representing
 the shortcode instance to be paginated. This allows multiple shortcodes to
 appear on a page and each to be individually paginated.

 e.g.
 http://www.oik-plugins.com/2014/12/pagination-not-working-properly-
 wordpress-4-1/?bwscid3=2&bwscid4=3


 Prior to WordPress 4.1 the code was
 {{{
 function bw_navi_paginate_links( $id, $page, $pages ) {
   $base = add_query_arg( "bwscid$id", "%_%" );
   $format = "%#%";
   $args = array( "base" => $base
                , "format" => $format
                , "total" => $pages
                , "current" => $page
                , "before_page_number" => "["
                , "after_page_number" => "]"
                );

   $links = paginate_links( $args );
   e( $links );
 }
 }}}

 Now with WordPress 4.1 I need to add another entry to the $args array.
 {{{
    , "add_args" => false
 }}}


 Can anyone confirm that this is what I should have expected from the
 changes in 4.1?


 BTW. The codex still says that the default for add_args is False (sic).
 BTW2. The current documentation in
 https://developer.wordpress.org/reference/functions/paginate_links/
 formats %_% incorrectly.

 PS. I think this is the reverse of #24606.
 PPS. This change does not adversely affect code running on 3.9.

 Conclusion: I have a solution to my problem but there is a need to change
 the codex and potentially a need for some more unit tests.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30831>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list