Skip to:
Content

BuddyPress.org

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#5967 closed defect (bug) (fixed)

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

Reported by: imath Owned by: imath
Milestone: 2.2 Priority: normal
Severity: normal Version:
Component: Appearance - Template Pack Keywords: has-patch commit
Cc:

Description

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

Attachments (1)

5967.patch (7.5 KB) - added by imath 6 years ago.

Download all attachments as: .zip

Change History (9)

@imath
6 years ago

#1 follow-up: @boonebgorges
6 years ago

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.

#2 in reply to: ↑ 1 @imath
6 years ago

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.

#3 @boonebgorges
6 years ago

  • Keywords commit added; 2nd-opinion removed

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.

#4 @imath
6 years ago

  • Owner set to imath
  • Resolution set to fixed
  • Status changed from new to closed

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

#5 follow-up: @boonebgorges
6 years ago

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

#6 in reply to: ↑ 5 @imath
6 years ago

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.

#7 @sc0ttkclark
6 years ago

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

#8 @johnjamesjacoby
6 years ago

  • Component changed from Component - Any/All to Appearance - Template Pack
Note: See TracTickets for help on using tickets.