Views caching cannot be combined with Ajax on cached pages

I am getting this exact error just with a clean install with Views, an exposed filter and ajax enabled with the view in a block. Nothing fancy and no other modules involved. Not sure why, I set up these types of basic views all the time. I also noticed that Chrome web inspector throws this error:

Uncaught TypeError: Cannot read property 'top' of null

(see below)

I spoke too soon, it turned out to be an issue with my theme where I had the Views block in a custom node block using a theme preprocess function. Once I moved the block to a standrad region within page.tpl.php, it works fine, my bad.

Unfortunate hack to get around this problem.

Was anybody able to resolve the issue. My issue isn't just the scroll-top on the Ajax paging. My view has exposed filters and after the submission, seems like the DOM ID has changed and once I alternate between ajax paging and filters, the 'Offset' variable is undefined. I do have a custom template for the view and embedding two views on that page which have different pager ID(s).
Thanks!

I have also experienced this and spent some time debugging. I launch a modal from node form. During the pre-processing of the view (in theme.inc) js settings get added to the view. If you close the modal and re-open it, it adds the js settings again. Now there are two Drupal.settings.views.ajaxView objects.

I was able to implement a work around where I added a click event to the close button to remove the ajaxView settings. But this is just a workaround. I think the real problem lies in the fact that the ajaxView settings do not get removed when the modal closes.

I am running in the same issue, my view block is inside a node content via a preprocess function. On Ajax Refresh the view fails with this js error. Is there anyone who has a workaround for my situation?

Hey all.

I was getting "Uncaught TypeError: Cannot read property '$el' of undefined." I had added a flipClock from flipclockjs.com. It's a pretty baller countdown clock, actually. Everything worked great in Firefox. Firefox is a javascript bull, don't stop for nothin'. But Chrome was choking and nobody could add items to their cart (bad).

This is how I fixed my error. I was getting the error on submit of Commerce add to cart form. I had added a custom object via Drupal behaviors like so:

(function ($) {
  Drupal.behaviors.addflipclock = {
    attach: function (context, settings) {
      //my amazing object being loaded here
    }
  };
})(jQuery);

The problem was, this was getting added again on ajax refresh. Drupal behaviors runs again on ajax refresh. So what I needed was a regular old jQuery document ready function:

jQuery(document).ready(function($){
     //my amazing object being loaded here, except only once per page load.
  }
})(jQuery);

Alright, hope that was useful to somebody, sometime, somewhere.

@glass.dimly: It still doesnt work in IE.

I've put together an alternative patch that checks for the existence of the element to scroll to before we attempt to scroll to it. If it doesn't exist, nothing happens.

Am wondering if we should always ensure that the viewsScrollTop command should always come after any insert commands created by views, maybe I should take a look at that as well...

I have looked into this quite a bit and have found that the HTML returned from Ajax contains the wrong ID, and the expected "correct" ID is passed to command viewsScrollTop, which no longer exists in the DOM. I can get this consistently if the Ajax rendered data or query are cached.

Here is an example of some commands that Ajax returns when it has broken:

{
    "command": "viewsScrollTop",
    "selector": ".view-dom-id-2e9403d39aae5f8b54fac491ea8a390b"
}, {
    "command": "insert",
    "method": "replaceWith",
    "selector": ".view-dom-id-2e9403d39aae5f8b54fac491ea8a390b",
    "data": "\u003Cdiv class=\u0022view view-ideas-landing view-id-ideas_landing view-display-id-block_1 view-dom-id-e243b89b17c18ee323ccec837191e53b (...)",
    "settings": null
}

I trimmed down the data key but the main thing to notice is are the different view-dom-id-* classes referenced, view-dom-id-2e9403d39aae5f8b54fac491ea8a390b selectors and view-dom-id-e243b89b17c18ee323ccec837191e53b in the HTML that is replaced. After this runs once, the selectors will never work again.

I've traced it so far to views_ajax():

$commands[] = ajax_command_replace('.view-dom-id-' . $dom_id, $view->preview($display_id, $args));

This is the DOM replacement command for the view. At this stage, $dom_id is correct but the ID in the HTML returned by $view->preview() is not, so that's the next place to look.

Possibly not the end-game solution (or maybe it is), but this did the job for me.

Actually it turns out "\S" is a bit too inclusive if it appears last in the list of classes, here's a manually edited patch with "\w" instead.

I am testing this out. That change is going to need an inline comment of explanation.

+1 in general. The strategy in #20 that the view display's DOM ID on the page may be old and this ensures that its is not replaced with a new DOM ID, which breaks JavaScript.

I suggest this inline comment, or similar:

// Return HTML with the same DOM ID that was sent by the browser.

As for the regex replacement, it could suffer all the usual problems: mainly slowness. It may make sense to set the limit param of preg_repace() so as not to search the entire string. I think we need to replace just one instance (or two?).

Has anyone experimented with D8 to see if the bug is there?

#20 is problematic for me on views with multiple exposed filter groups in blocks.

#20 wasn't compatible with Views Field View, attached patch addresses this.

@cilefen: Not sure what you mean by "filter groups". Do you mean multiple exposed blocks for multiple views on the same page, or do you mean multiple exposed filters for a single view.

@sipra.patra: I don't see why we need a views tag for an issue in the views queue.

@MustangGB: I mean the latter.

In that case I'm unable to reproduce as I'm using it with multiple exposed filters in a block and it's working.

This may be a separate issue, but I'm working with Views Autorefresh and run into the problem where the cached view simply reloads the same cached version of itself, causing a useless refresh of redundant data.

I've gone ahead and added an additional parameter "bypass_cache" in views_ajax() to optionally bypass the view cache prior to previewing the display for the AJAX command.

See proposed changes in attached patch.

Hi,

We have the same problem on Drupal 8.

Tnx @MustangGB

patch #1877238-25: Views caching cannot be combined with Ajax on cached pages works well for me.

I'm unable to reproduce @cilefen error.

I think patch #28 is unrelated to this issue.

I would remove patches #12 and #28 from display and reset the issue as RTBC

The patch not works for me when used with views with exposed filter inside ctools modal window (Entity Reference View Widget)

+++ b/includes/ajax.inc
@@ -68,7 +68,7 @@ function views_ajax() {
+      $commands[] = ajax_command_replace('.view-dom-id-' . $dom_id, preg_replace('/view-dom-id-\w+/', 'view-dom-id-' . $view->dom_id, $view->preview($display_id, $args), 1));

the regex should take in account also - (minus sign) since the \w flag does not include it or otherwise a valid dom id can be replaced with an invalid one. In my case it transform
view-dom-id-MYVIEW-MYDISPLAY
in
view-dom-id-MYVIEW-MYDISPLAY-MYDISPLAY

Taking in account minus sign in the regex fix the problem for me

The patch take in account the comments in#34

@willzyx is that an interdiff in #35? If not could you explain why the previous RTBC'd patch is not included in your patch?

@joelpittet the previous RTBC'd patch was the patch in #25, as stated by @robertom (see #30) , and is included in the latest patch.

Anyway you are right.. here a one-line interdiff for a one-line patch :)
the only change that I've made is change the regex used for replace the DOM ID from '/view-dom-id-\w+/' to '/view-dom-id-[a-zA-Z0-9_-]+/' since, as explained in #34, the DOM ID can contains dashes (here the proof) and the previous patch doesn't takes in account this

#35 resolved issue for me. I have not found any issues so far.

@willzyx my confusion I was looking at the larger last patch in #28 by accident.

The proof link was very helpful!

Looks fine to me.

Out of laziness I have not tried reproducing this on Drupal 8. But in #29 someone wrote that they did. Has anyone else been able to do so? If so we will need a D8 core issue opened.

@cilefen, looks like the same thing in D8, created a clone: #2895446: Views caching cannot be combined with Ajax on cached pages

Thank you for investigating.

Committed. Thank you all.