In Drupal.views.ajaxView.prototype.attachPagerAjax() all pager links are fetched and ajaxified via attachPagerLinkAjax(). At the bottom of that function:

this.pagerAjax = new Drupal.ajax(false, $link, this.element_settings);

Since that function is called for every link in the pager and this is always the Drupal.views.ajaxView object, this.pagerAjax is overwritten for EVERY link except the last one. Meaning only the last link's ajax object is stored, anywhere, making the storage completely useless.

Since backward compatibility is a thing (even though it's a bug), I propose adding a new property to Drupal.views.ajaxView:

In the constructor:

this.links = [];

In attachPagerLinkAjax() at the very bottom:

this.links.push(this.pagerAjax);

So all links are available in the Drupal.views.ajaxView object:

// If there's no 'previous' link, [0] will be page 1 or next or whatever, you can figure that out at runtime.
var prevLink = Drupal.views.instances['xxxxxxxx'].links[0];

Another option is to add the ajax object to the actual link. Also in attachPagerLinkAjax() at the very bottom:

$link.data('views-ajax', this.pagerAjax);

Whichever one you want, or anything else, as long as the Drupal.ajax objects are stored somewhere retrievable and not immediately overwritten.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rudiedirkx’s picture

Title: this.pagerAjax in Drupal.views.ajaxView.prototype.attachPagerLinkAjax is overwritten by the next link » this.pagerAjax in attachPagerLinkAjax() is overwritten by every next link

Shorter title

rudiedirkx’s picture

Two patches (one by one, because apparently the patch upload is broken!?):

1. ...-link_data uses jQuery's .data() to add the ajax object to the link

rudiedirkx’s picture

Status: Active » Needs review
FileSize
953 bytes

2. ...-links_array adds the ajax objects to a new .links array in the Views pager object

I like 2 better than 1. More centralized.

Combined the patches are 3 lines of code and it fixes a major bug IMO.

rudiedirkx’s picture

Component: User interface » Code
Priority: Normal » Major
FileSize
886 bytes

Re-roll of method 2 (in #3).

Please fix this!

rudiedirkx’s picture

sheldonkreger’s picture

Status: Needs review » Reviewed & tested by the community

This works for me in 7.x-3.11. Also ran in production for quite some time in 3.10.

colan’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Can we get this as one patch instead of two? Don't worry about the automated testing; it's broken.

rudiedirkx’s picture

Status: Postponed (maintainer needs more info) » Reviewed & tested by the community

It is one patch. #4 is the only active file.

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.

rudiedirkx’s picture

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

Status: Needs review » Needs work
rudiedirkx’s picture

Status: Needs work » Needs review
FileSize
949 bytes
rudiedirkx’s picture

Status: Needs review » Reviewed & tested by the community
DamienMcKenna’s picture

RTBC seems ok per #6.

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.