Why do you need an unlikely integer in paginating?

by

The paginate_links Codex function reference has some sample code that’s being reposted all over the net.

It has a section that uses a variable called $big = 999999999; // need an unlikely integer:

echo paginate_links( array(
    'base' => str_replace( $big, '%#%', esc_url( get_pagenum_link( $big ) ) ),
    'format' => '?paged=%#%',
    'current' => max( 1, get_query_var('paged') ),
    'total' => $wp_query->max_num_pages
) );

And is used in str_replace in the echo paginate_links function.

Is this some form of encapsulation?

1

Note the get_pagenum_link( $big ): This will create an URL (not a link) based on the number provided in the first parameter.

That function is used to get the basic pattern for the URL, and the high integer is used here, because:

  1. You must provide an integer as argument.
  2. The resulting URL is filtered with apply_filters('get_pagenum_link', $result) and might be changed by plugins. This risk is slightly higher for numbers matching existing pages, for example when a plugin implements separate titles for sub-pages.

So this is just a … dirty convention, a signal to other plugins: Don’t change that please! I think PHP_INT_MAX would have been better, but still ugly. And I wonder how many plugin developers know that.

The number is then replaced with the placeholder needed in paginate_links().

What you see here is an incomplete API. Try to learn something from this example – do not release incomplete APIs, or your docs will look embarrassing. 🙂

Leave a Comment