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.

chrisaros’s picture

Version: 8.1.x-dev » 7.x-dev
Status: Patch (to be ported) » Needs work

one small issue, I'm using Views Ajax Get module this causes the pager to display the same page over and over.
is there not a more of a specific use switch that could be used. I know its a monkey patch but on my 10000+ page site + varnish caching and view fields. this causes a huge issue.

David_Rothstein’s picture

Version: 7.x-dev » 8.1.x-dev
Status: Needs work » Patch (to be ported)

Sounds from #30 like this might need a followup for the Drupal 7 Views module in contrib, but in the meantime moving this back to be ported for Drupal 8 core. Those two things could also be split into separate issues.

joseph.olstad’s picture

Same issue as described by Chrisaros in comment #30

We recently upgraded from views 7.x-3.13 to 7.x-3.14 (released June 15th) and noticed a problem with commit from #27

commit in comment #27 causes issue as described in
#2754601: Pager always returning first page

Backing off commit #27 resolves the issues documented in
#2754601: Pager always returning first page

joseph.olstad’s picture

joseph.olstad’s picture

Status: Patch (to be ported) » Needs work

see my previous comments and related issue.

joseph.olstad’s picture

There are two ways to go with this issue.

1) workaround: use POST instead of GET on ajax calls to views (see implications explanation in last 2 paragraphs)

2) OR back off the changes so you can use GET or POST see patch from comment #3 of Pager always returning first page this patch backs off the ajax include changes made between 7.x-3.13 and 7.x-3.14 (restoring functionality that was present in views 7.x-3.13.

Implications of this number 1): The changes from the commit in comment #27 of this issue break GET , workaround is use POST, is this intended? If this is the intended behaviour of the commit then this should be documented somewhere in the README for views and also a helpful exception or error message should be created so that if someone uses GET they will be warned about using GET with an explanation.

Seeing as there's currently no helpful warning or exception message and the resulting behavior and changes to the behavior of AJAX calls in views it appears that the changes made in the commit from comment #27 were not intentional. Therefore this new functionality does not seem to be ready which is why we created a patch to back it off. See related issue #2754601: Pager always returning first page

joseph.olstad’s picture

Prior to 7.x-3.14 of views this worked fine when using the module views_ajax_get and a caching solution like boost or varnish (boost in our case). However on June 15th views 7.x-3.14 was released with the commit in comment #27 that causes the first page to always be retrieved for any requested page. Simply switching to POST is not an option for us because we need to cache anonymous requests for ajax.

We need to cache AJAX requests with (for example) "boost" or "varnish", the views AJAX requests must be using GET.

On my dev box a boost cached AJAX views "page" takes 10ms , whereas an uncached views "page" using AJAX takes about 900 ms.

I've created a patch for views that restores GET support (in tandem with views_ajax_get) , see the patch as mentioned in comment#3 of #2754601: Pager always returning first page

joseph.olstad’s picture

I dug a bit deeper into this and looked at the api for drupal_get_query_parameters , the second parameter is for "exclude" , yet we need "page", otherwise page 0 is "always" returned.

see the new patch from lucky comment#13 comment#3 in the views queue for #2754601: Pager always returning first page

@colan , since you committed part of this change in comment# 27, can you please review this new patch ?


joseph.olstad’s picture

This affects those using views_infinite_scroll which has over 25,000 reported sites running it.

Turns out we are not using the contrib module views_ajax_get.

For more more details see #2754601: Pager always returning first page comment #18 specifically.

joseph.olstad’s picture

A new 7.x patch for this in #2754601 needs reviewing. See patch #23 and comment #23

"might" need attention in 8.x as well but a quick search of 8.x code did not reveal anything obvious. For now, 7.x views 3.14 is affected and needs attention , patches doing the job for us.

joseph.olstad’s picture

There is a couple 7.x patches waiting for review
#2754601: Pager always returning first page

see patches from #23 and #26
As far as I can tell, these patches should be compatible with this issues functionality, meaning a win-win.

joseph.olstad’s picture

Version: 8.1.x-dev » 7.x-dev
joseph.olstad’s picture

Version: 7.x-dev » 8.3.x-dev

actually, views is not part of D7 core, so setting back to 8

The regression that this functionality brought in is dealt with by the aforementioned patches.

joseph.olstad’s picture

There is an RTBC patch that resolves #30

see patch #27 of
#2754601: Pager always returning first page