WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 13 down vote accepted

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. :)

share|improve this answer
I agree PHP_INT_MAX would have been better IMO, but would have confused me at the time more. I really like your explanation, it confirms that I was thinking along the right lines. I just didn't want to make any assumptions. – Jason Green May 29 '13 at 14:40
So is this used only in the case of a filter on get_pagenum_link affecting existing page numbers? (since paginate_links() uses get_pagenum_link() by default anyway). Seems like an extreme edge case to me, unless I'm missing something? – Cai Jul 3 at 22:34
@Cai Looks it has been a real problem once. Code bases maintained over a long time tend to be filled with workarounds for edge cases. – toscho Jul 4 at 6:11
It looks like paginate_links() didn't always use get_pagenum_link() by default so I'm wondering if this is a convention from before then and if the 'unlikely integer' is really needed (or if the real workaround was simply get_pagenum_link())? – Cai Jul 4 at 8:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.