Paginate links are stuck on a page number if javascript is disabled

[imath]

Working on #5960, i've noticed that in case javascript is disabled, pagination links are stuck on the last paginate link clicked.

Let's take an example on members directory :

• 60 members > 3 pages

• the directory is just displayed : pagination links are :
  • current 1
  • ?upage=2
  • ?upage=3

• You click on page 2, pagination links are :
  • ?upage=2
  • current 2
  • ?upage=2

Every component using paginate_links() is concerned. The problem is due to the fact that in this function, this part :

        $url_parts    = explode( '?', $pagenum_link );

	if ( isset( $url_parts[1] ) ) {
		wp_parse_str( $url_parts[1], $query_args );
	}

is getting the query arguments of the url, in the second part of my exemple, as we have clicked on page 2, it's getting the $_GET['upage'] which is overriding the page argument.

I suggest to use the 'add_args' argument of this function to pass the extra arguments if needed (instead of using the 'base' one) else to pass an empty array to avoid this issue.

See attached patch

[boonebgorges]

The fix looks good to me for BuddyPres.

I wonder if this is a bug in paginate_links(). imath, do you think that paginate_links() itself should be more careful about the way it overrides $query_args? I don't 100% understand what's going on here.

[imath]

Replying to boonebgorges:

do you think that paginate_links() itself should be more careful about the way it overrides $query_args?

my first impression is: i think paginate_links() is doing ok, as it gets all the query vars. Our problem is that one of it is the page one and it's not 'paged' but a custom one.

If for instance we were using 'paged' instead of 'upage', 'bpage'... there wouldn't be any trouble.

[boonebgorges]

If for instance we were using 'paged' instead of 'upage', 'bpage'... there wouldn't be any trouble.

Yeah. Now that I look at it more closely, paginate_links() (and get_pagenum_link(), which I think is part of the problem in our specific case) have hardcoded references to 'paged'. But this is only for the purpose of setting up the $defaults array. So I suppose it's the responsibility of people using the function (like BP) to override these defaults as necessary, which is what your suggested patch is doing. (As a side note, I think that it'd be possible to rework paginate_links() and related functions so that the defaults were more responsive to custom query vars, but this is a bigger job than I feel like tackling today :) )

Carry on, good sir.

[imath]

In 9260:

Make sure paginate links are correctly set in case javascript is disabled

Adding extra query arguments to the 'base' parameter of the paginate_links() function when javascript is disabled is preventing the loops to be correctly paginated. In this particular case, the pagination is 'stuck' on the second page. To be sure the pagination is correctly set, we need to pass extra query arguments using the 'add_args' parameter of the paginate_links() function.

Fixes #5967

[boonebgorges]

Looks like this might be a WP 4.1 issue. See ​https://core.trac.wordpress.org/ticket/30831#comment:2

[imath]

Replying to boonebgorges:

Looks like this might be a WP 4.1 issue. See ​https://core.trac.wordpress.org/ticket/30831#comment:2

Thanks boonebgorges, i'll run some tests on 3.9 & 4.0 to see if this commit does not have an impact on previous WordPress versions.

[sc0ttkclark]

Appears fixed as of this past week in trunk. This affected other plugins using paginate_links as documented (including Pods).

​https://core.trac.wordpress.org/changeset/31203