Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I haven't managed to find this issue in search. Here are steps to reproduce:
- Install drupal 7, views, ctools
- Set one content type (say, articles) to list 10 comments per page (to make it easier in a moment)
- Create an article; add more than 10 comments to it so that it goes over 2 pages
- 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)
- Create a handful of basic pages
- configure the view block to show on every page in the sidebar
- Visit your article page and confirm that your view block is there, and that the ajax pager works
- Now go to page 2 of comments on the article
- 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.
Comment | File | Size | Author |
---|---|---|---|
#64 | interdiff_61-64.txt | 0 bytes | philltran |
#64 | ajax_views_pager_element-1482824-64.patch | 1017 bytes | philltran |
#14 | views-ajax_pager-1482824-14.patch | 507 bytes | robertom |
#2 | views-ajax-pager.patch | 456 bytes | Alan Evans |
Comments
Comment #1
Alan Evans CreditAttribution: Alan Evans commentedI'll be debugging this a little and posting results here as they come up ...
Comment #2
Alan Evans CreditAttribution: Alan Evans commentedActually 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.
Comment #3
tim.plunkettThis 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.
Comment #4
dawehnerJust 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.
Comment #5
dawehnerThanks 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
Comment #6
Aminouvic CreditAttribution: Aminouvic commentedI 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
Comment #7
dawehneryou 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
Comment #8
Chaulky CreditAttribution: Chaulky commentedThanks @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.
Comment #9
sokrplare CreditAttribution: sokrplare commentedWhew, huge help! Glad to see this is committed to 7.x dev.
Comment #10
PixelClever CreditAttribution: PixelClever commentedIs 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.
Comment #11
dawehnerIf 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.
Comment #12
Baibhav Kumar CreditAttribution: Baibhav Kumar commented#2: views-ajax-pager.patch queued for re-testing.
Comment #14
robertom CreditAttribution: robertom commentedHi, 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
Comment #15
amol211 CreditAttribution: amol211 commentedI 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.
Comment #16
dawehnerMark the display as overridden.
Comment #17
DeFr CreditAttribution: DeFr commentedI 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.
Comment #18
lmeurs CreditAttribution: lmeurs commentedGreat 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?
Comment #19
alesr CreditAttribution: alesr commentedI 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.
Comment #20
dawehnerI'm curious whether the first hunk in http://cgit.drupalcode.org/views/commit/?id=d08465d solved that problem ...
Comment #21
paranojik CreditAttribution: paranojik as a volunteer commented...not really. The patch in #14 strips away the "page" parameter, the commit you mention doesn't.
In my opinion this is RTBC.
Comment #22
colanWe'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.
Comment #23
DeFr CreditAttribution: DeFr at Axess Open Web Services commentedLet's re-upload the patch :-)
Comment #24
DeFr CreditAttribution: DeFr at Axess Open Web Services commented@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.
Comment #25
colanTests 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.
Comment #26
DeFr CreditAttribution: DeFr at Axess Open Web Services commentedTest passed, reseting to RTBC.
Comment #28
colanThanks!
Comment #30
chrisaros CreditAttribution: chrisaros commentedone 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.
Comment #31
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedSounds 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.
Comment #32
joseph.olstadSame 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
Comment #33
joseph.olstadsee patch from comment #3 of Pager always returning first page
Comment #34
joseph.olstadsee my previous comments and related issue.
Comment #35
joseph.olstadThere 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
Comment #36
joseph.olstadPrior 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
Comment #37
joseph.olstadI 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
newpatch fromluckycomment#13comment#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
Comment #38
joseph.olstadNOTE:
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.
Comment #39
joseph.olstadA 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.
Comment #40
joseph.olstadThere 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.
Comment #41
joseph.olstadComment #42
joseph.olstadactually, 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.
Comment #43
joseph.olstadThere is an RTBC patch that resolves #30
see patch #27 of
#2754601: Pager always returning first page
Comment #44
LendudeTried 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.
Comment #45
joseph.olstadThe 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
Comment #47
joseph.olstad@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
Not sure if this code affects the use case.
Comment #48
sittard CreditAttribution: sittard commentedYeah 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.
Comment #49
sittard CreditAttribution: sittard commentedJust 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
Comment #52
malcolm_p CreditAttribution: malcolm_p commentedComment #53
malcolm_p CreditAttribution: malcolm_p commentedComment #54
malcolm_p CreditAttribution: malcolm_p commentedIt 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.
Comment #57
hilly510 CreditAttribution: hilly510 commentedThe patch in #54 helped with my issues using views_infinite_scroll
Comment #59
aralnoth CreditAttribution: aralnoth commentedThe 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.
Comment #60
joseph.olstadI triggered tests on the latest patch
Comment #61
philltran CreditAttribution: philltran at Symmetri Technology commentedAdded a line from @hilly510 to patch of comment #54 targeting 8.7.x. This helped get views_infinite_scroll working for me.
Comment #64
philltran CreditAttribution: philltran at Symmetri Technology commentedRe-rolled patch from #61 against 8.9.x.
Comment #73
DamienMcKennaThe patch currently has this line:
That doesn't do anything with the $current_page variable, should it be assigned to the something in $pager_options?
Comment #74
joseph.olstadYa 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
Comment #75
DamienMcKennaThanks for the suggestion. #59 still applies to 10.1.x. It didn't solve the problem I'm facing.
Comment #76
joseph.olstad@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.
Comment #77
DamienMcKennaFWIW 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