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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

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
FileSize
456 bytes

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
FileSize
507 bytes

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
FileSize
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 (for Drupal 7) » 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)

Thanks!

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 ?

Thanks

joseph.olstad’s picture

NOTE:
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

Lendude’s picture

Status: Needs work » Closed (cannot reproduce)

Tried to reproduce this in 8.3.x

- Set the Content view to use ajax
- Added a block to it
- Set the block pager to ID 1
- Made sure I had enough content to show the pagers
- Tried both pagers, both worked as expected

Since there are other issues addressing the follow up for this in Views D7 I'm closing this for D8. If anybody has steps that can reproduce this in D8, please feel free to open this back up.

joseph.olstad’s picture

Status: Closed (cannot reproduce) » Needs review

The use case is as follows :

You want a fast Web 2.0 site so you want to cache Ajax in Json , in order to do this you need Ajax get , not post

In my use case I use boost but to test this you don't need boost

In Ajax post the results are as expected but in Ajax get the same page results keep coming when you request next paged results in a show more. So create a js function to request views Ajax paged results and compare them with Ajax post results vs Ajax get

I have fixed this 7.x-3.14 regression in a patch in related issue and seeing as this regression was introduced first to d8 and back ported to 7.x it is probably still a problem in 8.x as it is new to 7.x-3.14

Ajax post is useless for boost and probably varnish also that is why Ajax 'get' is imperative for this use case

Our website is high traffic and lots of anonymous hits we need caching json to work properly

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joseph.olstad’s picture

@sittard has reported that this fails in D8 8.26

If this was fixed in 8.3.x can you show the code?

I compared ajax_view.js 8.2.6 to 8.3.x

diff ajax_view.js ajax_view8.3.x.js
131,132d130
<    *
<    * @todo remove .size() replace with .length.
137c135
<     return !this.$view.parents('.view').size();
---
>     return !this.$view.parents('.view').length;

Not sure if this code affects the use case.

sittard’s picture

Yeah it's worth pointing out that this issue has been ongoing for us since at least Drupal 8.1.3 (and possibly earlier). Our user case might also be specifically related to the use of the module Views Infinite Scroll - https://www.drupal.org/project/views_infinite_scroll and more specifically this issue:
https://www.drupal.org/node/1839474

Although testing with this module uninstalled lead to duplicate records in the paged results.

Feel free to create a new issue as I'm not 100% sure this one is still on topic.

Thanks.

sittard’s picture

Just tested this with a clean install of Drupal 8.2.6 and are experiencing issue with Duplicates records. Not 100% sure this is related so have created a new issue:

Views Pager includes duplicates with Random Sort:
https://www.drupal.org/node/2856572

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

malcolm_p’s picture

malcolm_p’s picture

malcolm_p’s picture

It seems to me that the problem lies in ViewAjaxController.php which is trying to set the pager id using the pager_element POST parameter. However, it is doing this incorrectly and thus the id doesn't get set and the view returns incorrect results.

Status: Needs review » Needs work

The last submitted patch, 54: ajax_views_pager_element-1482824-52.patch, failed testing. View results

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hilly510’s picture

The patch in #54 helped with my issues using views_infinite_scroll

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

aralnoth’s picture

The patch in #54 not working for me. The pager in a block view not working at all, allways returns the first page. I have created a new patch that working for me use case.

joseph.olstad’s picture

Status: Needs work » Needs review

I triggered tests on the latest patch

philltran’s picture

Added a line from @hilly510 to patch of comment #54 targeting 8.7.x. This helped get views_infinite_scroll working for me.

Status: Needs review » Needs work

The last submitted patch, 61: ajax_views_pager_element-1482824-61.patch, failed testing. View results

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Status: Needs review » Needs work

The last submitted patch, 64: ajax_views_pager_element-1482824-64.patch, failed testing. View results

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

DamienMcKenna’s picture

The patch currently has this line:

    $view->getPager()->current_page;

That doesn't do anything with the $current_page variable, should it be assigned to the something in $pager_options?

joseph.olstad’s picture

Ya this was fixed in D7, would be nice to fix in Symfony Drupal.

@DamienMcKenna, I think patch #59 makes more sense than patch 62 or 64

suggestest re-rolling #59 instead, only 1 error , not two.
#1482824-59: Block display view ajax pager does not advance with multiple pagers on a page when the first pager > 0

DamienMcKenna’s picture

Thanks for the suggestion. #59 still applies to 10.1.x. It didn't solve the problem I'm facing.

joseph.olstad’s picture

@DamienMcKenna, too bad, I recall enjoying the fix for D7, cannot recall if I worked on this or came accross it yet for D9/D10 but I believe the same/similar issue exists in D10.

DamienMcKenna’s picture

FWIW the bug I ran into ultimately came from a bug in Facets v3 that was fixed in the dev branch but not available as a new release yet - #3379445: Facets breaks all AJAX views that uses pagers even without facets