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.

#23 views-ajax_pager-1482824-14.patch507 bytesDeFr
#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


Alan Evans’s picture

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

Alan Evans’s picture

Status:Active» Needs review
456 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.

tim.plunkett’s picture

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.

dawehner’s picture

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.

dawehner’s picture

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

Aminouvic’s picture

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

dawehner’s picture

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

Chaulky’s picture

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.

sokrplare’s picture

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

PixelClever’s picture

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.

dawehner’s picture

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.

Baibhav Kumar’s picture

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.

robertom’s picture

Version:6.x-3.x-dev» 7.x-3.x-dev
Status:Needs work» Needs review
507 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

amol211’s picture

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.

dawehner’s picture

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.

DeFr’s picture

I can confirm that this is broken right now in 7.x-3.x dev. The detailled steps in the IS can be used to reproduce the issue, with an important exception: it doesn't do it for every pager item, only for the first one. The first link has no 'page' query string in its URL, which means that there's no corresponding post data either ; the one in the original page load thus take over, and clicking page 1 brings the user to page 2, with no way to go back.

The patch in #14 is probably the more backward-compatible approach to the problem.

#1786524: AJAX pager does not work if page number set in URL is probably a duplicate of this issue.

lmeurs’s picture

Great patch! It solves the problem from #1786524: AJAX pager does not work if page number set in URL, it looks more stable than the patch from #1786524-11: AJAX pager does not work if page number set in URL and has been successfully tested by the test bots, but since the initial issue differs too much I cannot set RTBC... Anyone else?

alesr’s picture

Component:block displays» Code
Status:Needs review» Reviewed & tested by the community

I can confirm the patch in #14 fixes the problem and it is still applicable to the latest Views 7.x-3.x-dev version.
Marking as RTBC and #1786524: AJAX pager does not work if page number set in URL as a duplicate.

dawehner’s picture

I'm curious whether the first hunk in http://cgit.drupalcode.org/views/commit/?id=d08465d solved that problem ...

paranojik’s picture

...not really. The patch in #14 strips away the "page" parameter, the commit you mention doesn't.

In my opinion this is RTBC.

colan’s picture

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

DeFr’s picture

Status:Reviewed & tested by the community» Needs review
507 bytes

Let's re-upload the patch :-)

DeFr’s picture

@colan : As far as I can tell, the 7.x-3.x branch is flagged as not passing the test suite, so the test is postponed. I see you've mentionned in #2623840: Views (D7) patches not being tested that this got fixed, but https://www.drupal.org/node/38878/qa seems to still have the branch as failing. As a result, the test request is postponed until the branch is passing.

colan’s picture

Tests don't run until the branch passes on its own. We just got it to pass again now so it looks like all of the tests are automatically re-queueing. There will be a large number of them now so please be patient.

DeFr’s picture

Status:Needs review» Reviewed & tested by the community

Test passed, reseting to RTBC.

  • colan committed 4264f5f on 7.x-3.x authored by robertom
    Issue #1482824 by DeFr, Alan Evans, robertom: Block display view ajax...
colan’s picture

Project:Views» Drupal core
Version:7.x-3.x-dev» 8.0.x-dev
Component:Code» views.module
Status:Reviewed & tested by the community» Patch (to be ported)


Version:8.0.x-dev» 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.