I haven't managed to find this issue in search. Here are steps to reproduce:

  1. Install drupal 7, views, ctools
  2. Set one content type (say, articles) to list 10 comments per page (to make it easier in a moment)
  3. Create an article; add more than 10 comments to it so that it goes over 2 pages
  4. Create a view:
    • with a block display
    • using ajax
    • using a pager (I used mini pager)
    • I'd recommend something simple like a list of basic page nodes
    • to make this easier, configure the pager to show 1 item per page
    • configure the pager to have an ID > 0, so it doesn't clash with the other pager (for comments on the article)
  5. Create a handful of basic pages
  6. configure the view block to show on every page in the sidebar
  7. Visit your article page and confirm that your view block is there, and that the ajax pager works
  8. Now go to page 2 of comments on the article
  9. The ajax pager now repeatedly returns the same page of results on every click

I've verified that the ajax mechanism is working, and that the ajax call repeatedly returns the first page of results - it's not the pager itself that is broken as such, but that the same page is being returned by the server.

Non-ajax pagers are not affected, they seem to consistently return correct results across multiple pagers on a page, it's only the pages returned by ajax pagers that are faulty.

Files: 
CommentFileSizeAuthor
#14 views-ajax_pager-1482824-14.patch507 bytesrobertom
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]
#2 views-ajax-pager.patch456 bytesAlan Evans
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-ajax-pager.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

I'll be debugging this a little and posting results here as they come up ...

Status:Active» Needs review
StatusFileSize
new456 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-ajax-pager.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Actually the solution could be amazingly simple - in views_ajax(), $_POST data is merged into $_GET so that paging can be handled in $_GET, but if you're on ?page=1 then the "page" key already exists in $_GET and $_POST['page'] is dropped. I think it is actually a good idea to reverse the precedence (patch attached) so that any keys present in both are preferred from $_POST (we could assume that if a piece of data was posted, it's considered important - I personally cannot imagine a case where you need $_GET to have precedence on a $_POST request, but that's not to say that such a case doesn't exist).

In my example, $_GET['page'] is '1' whereas the more correct $_POST['page'] which is '1,1' is ignored because there's already a value in $_GET (because we're on the second page of comments on the article). The attached patch does solve this, but could potentially cause unpredictable issues elsewhere (though I do think this is unlikely - it would take more of an edge case than the edge case described here to trigger issues there).

If we don't want to go with the larger scope and slightly unpredictable reversal of precedence, we could just make an exception and explicitly adopt $_POST['page'] if present, so that the full pager array is used on ajax requests, rather than a pager array that misses the one we're interested in. Doing so might be the safer option, but feels like the less correct way to handle precedence of POST and GET.

This seems sane, but possibly could cause bizarre and edge-case-y bugs, so I'm not sold on it yet.

Maybe write that other approach anyway, so once dereine or merlin comes across this issue, they can move forward with whichever they prefer.

Just from reading the comment above i would have assumed that $_POST should override $_GET, when it is specified.

For a short time i though of using array_merge, but this doesn't really make sense, as this could lead to total invalid and strange data.

So from my perspective this is fine. As always tests would be nice.

Version:7.x-3.x-dev» 6.x-3.x-dev
Status:Needs review» Patch (to be ported)

Thanks for the steps to reproduce the issue. That's really great, so i could see that this patch fixes the problem and match the comment a bit better.

Just committed to 7.x-3.x

Version:6.x-3.x-dev» 7.x-3.3

I having the same problem with views 7.x-3.3 :

I have a main view showing the latest articles (Pager ID=0),and An ajax-enbled block view (Pager ID=1) showing the coming events (I am using the calendar module).
When I try to access content directly via the web browser every thing is fine, but I get nothing while using the ajax pager.

I've tryied to use the patch provided below but no results!

So any ideas guys?

I also wonder if there is a way to provide different identifers for pagers (instead of 'page=' get 'pager1=&pager2=') just like the date module does?

Thank you

Version:7.x-3.3» 6.x-3.x-dev

I also wonder if there is a way to provide different identifers for pagers (instead of 'page=' get 'pager1=&pager2=') just like the date module does?

you know all what views does is to use the core pager system, nothing special like extra pager arguments etc.

The actual issue here was already fixed in 7.x-3.x-dev

Thanks @Alan Evans, I just ran into this today and came to the same conclusion that GET/POST was the issue, I should really learn to search the issue queues before debugging myself! Smallest patch ever, but it work great. Didn't test anything other than ajax and non-ajax pagers on the same page.

Whew, huge help! Glad to see this is committed to 7.x dev.

Is there a backport for D6 in the works for this? I can confirm that this is happening on views 3 for D6 but I don't see any references to $_POST in ajax.inc.

If there would be some backport work for d6 someone would have posted it.

I guess the bug can be solved in 6.x-3.x as well, though time is limited.

Status:Patch (to be ported)» Needs review

#2: views-ajax-pager.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, views-ajax-pager.patch, failed testing.

Version:6.x-3.x-dev» 7.x-3.x-dev
Status:Needs work» Needs review
StatusFileSize
new507 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

Hi, sorry for my bad english.

I have this problem also on 7.x-3.x-dev. For fix this, I have to apply this patch

I have created one view and in that view, there is more than one blocks, I want to add Pager ID only for one particular block. How should I add pager ID only for one block?
When I'm going to change pager ID for particular block that time it will apply for all blocks in that view.

When I'm going to change pager ID for particular block that time it will apply for all blocks in that view.

Mark the display as overridden.