Views with exposed filter (ajax enabled) inside modal window (ctools)

I'm getting this in some very specific conditions..not using modal windows. It's actually a result from this issue for Quick tabs (#1864800: Ability to force AJAX fetch of tab content every time a tab is toggled). Not sure what is causing it though.

I believe it has something to do with this: http://drupal.org/node/1864800#comment-6861108

After reloading a View via an AJAX call, the DOM ID in the JS settings aren't cleared. So it's using a selector that no longer exists because the settings contain old data.

Just wondering whether this could be a duplicate of the other issue?

Well the other issue I linked to has to do with the Quicktabs module. I was working on a patch and I came across this issue/bug with Views. I think I'm going to open a new issue with View and link around to all the semi-related issues.

Yea like you said, I think this is actually happening after a filter submit (or sometime, only after numerous filter submits). Something seems to be causing it to return a different DOM ID.

Here's a link back to a related issue: #1877238: Views caching cannot be combined with Ajax on cached pages

I encountered the same issue when using exposed filters multiple times with the entityreference_view_widget module.

The issue is caused by launching multiple ajax instances of a view (in this case with a ctools modal window), which will append a JS setting for each view DOM ID. If the modal window is closed the DOM element doesn't exist anymore, causing a JS error.

This can be fixed by checking if the DOM element actually exists before attaching events to it.

I had this same issue and patch in #7 solved the problem. Thanks!

I was having the same issue and patch #7 fixed it for me too. Thanks.

I am getting the same error using Better Exposed Filters with views with ajax enabled. When I apply the patch the view works again but it appears to be loading the entire page again rather than using ajax. The functionality seems the same as when you set BEF to automatically resubmit when the exposed filter is changed. Could there some sort of fallback happening here and the ajax functionality is simply being removed by adding the conditional in the patch? I am using views 7.x-3.7.

#7 fixed it for me too, particularly using Entityreference View Widget module and exposed filters inside its modal dialogs.

I had the same issue with views 7.x-3.8 but it seems that the issue was fixed in the next commit.

commit 710a5368c0f71100aaa51de01695d5beb11b5e8b
Author: Earl Miles
Date: Thu May 29 13:27:56 2014 -0700
Use a safer way of finding the exposed form.

Yes, commit mentioned by Boyan seems to fix it (with much less code), so we can close the issue with the current release of Views (3.8)

In fact, the commit mentioned in #7 broke Entity Reference Views widget, because the view-filters div is not rendered inside the view, the $exposed variable is wiped in a preprocess_views_view in order to be rendered above the form embedded into the modal to avoid conflicts.

@jsacksick, I have in production several Entity Reference Views widgets with exposed filters, running smoothly under Views 3.8 and ERV 7.x-2.0-beta3+2-dev. Please, let us know additional info and/or how to reproduce the problem you have found.

@interdruper : the commit mentioned is not included in the 3.8 version, try to switch to the dev version and you'll see.

You are right @jsacksick, that commit breaks Entity Reference Views modal forms, Ajax error is returned after submission.

Anyway I cannot reproduce now the original issue with my current configuration (Views 3.8 recommended release and ERV 7.x-2.0-beta3+2-dev), dialogs keep running fine after reopenings, may be the issue in my case is hidden by other reasons.

Patch #7 fix the problem with ERV in your tests? (it did in my original tests...) If so, we should return back the patch #7 to RTBC state, and report the issue with the recent views patch.

I haven't tested the patch in #7, did you try using the dev version of views? (to reproduce the issue)

I think this line needs to be reverted because it does fix ERV.

The exposed filters are not inside the this.$view so it will never find them.

I had the same problem with this error, but with views rendered within blocks on a page. Weird as never come across this before even though I've been doing exposed filters with views blocks for some time.

I was on version 3.8, and agree that the patch included in #7 works great! However, I noticed that the commit in #12 was in the dev version which, after updating to dev, fixed my problem too. I do agree with @joelpittet & @interdruper though that if this already committed fix breaks something else (ERV), then it should probably be reverted and/or reworked.

With that in mind, I've re-rolled the patch provided in #7 by @klaasvw for the dev version. Call it a double fix for now, until the previous fix is reverted. Seems to work great for me!

It's not a big patch, it is mostly whitespace and as @klaasvw mentioned, it just checks the DOM element actually exists first.

@joelpittet - can you open a new issue for the bug you're experiencing and submit your patch there? Cheers.

Patch #20 didn't apply for me on Views 7.x-3.x-dev.
Here's a re-roll.

@steve.stotter it's from this issue, that's why I put it here... It's to revert part of this commit in #12

I can confirm #19:
this.$exposed_form = this.$view.children('.view-filters').children('form');
from #7 breaks ajax exposed form
And now it's in Views 7.x-3.10, so this patch must be reverted.

I can confirm that the exposed form ajax functionality breaks after I updated to 3.10 from 3.8.

Patch from #21 works well here ! Thank you!

I use Entity Reference View Widget since i update to Views 3.10, exposed filter in ctools modal failed due to Use a safer way of finding the exposed form..
I'm fact, i used 7.x-2.0-rc2 version of Entity Reference View Widget , and this version not set any main view div.
It seems the last version resolve issue 7.x-2.0-rc6, and now a main div with .view-dom-id-XXX is define, and the above mentioned commit work fine.

Summary : works fine for me with :
Views 7.x-3.10
Ctools 7.x-1.7
Entity Reference View Widget 7.x-2.0-rc6

Re-posting #19

+++ b/js/ajax_view.js
@@ -57,7 +57,7 @@ Drupal.views.ajaxView = function(settings) {
-  this.$exposed_form = this.$view.children('.view-filters').children('form');
+  this.$exposed_form = $('form#views-exposed-form-'+ settings.view_name.replace(/_/g, '-') + '-' + settings.view_display_id.replace(/_/g, '-'));

The reason this needs to be reverted is because when you expose a filter in a block it's no longer inside the div of the view and can be placed anywhere on the page.

Though I like the intent behind the commit (removing specific selectors is usually a good thing) it just doesn't work in this case :(

I changed one thing to make the jQuery faster by using just the ID instead of form#ID.

I totally agree that the "fix" introduced by merlinofchaos made the situation worse, so let's fix that. In case somebody figures out what earl tried to fix, we could do it on top of it.

PS: Does anyone know what the situation in D8 regarding the patch is?

.

Hi,
I've found a problem with the current patch committed with 96a54e0.

We where displaying 2 copies of the same view with the same display id on a page and found the exposed form for the second form was not working.
The issue is that the jQuery selector used in 96a54e0 assumes the view name and display id is unique on the page. My patch [fix-views-duplicate-display-id-1809958.patch] just adds the view as the context for the jQuery selector which fixes the problem.

Moving back to Needs review, it sounds like the last patch introduced new bugs.

I've got the error "cannot read property 'top' of null" when using exposed filters.
Patch #34 worked for me, but I have only one view at the page.

I had trouble applying the patch in #34, made a new one that dit work for me. The proposed solution in #34 for adding the view as context to the jquery selector worked for me.

@Harley Bussell, @pefferen, @J-Lee, and @samuel.mortenson. The $view would refer to the view listing itself. If you expose a form in a block, it can literally be placed anywhere on the page and not inside the $view. It you target the form only inside the $view element you will miss it. I think the troubles you may be having are not related to this, I could be wrong but what makes you think narrowing the selector will help solve this?

My only guess is that you have two exposed forms on the same page with the same ID (bad HTML), likely one behind the modal and one inside the ctools modal. Maybe inspect the HTML on the page this is happening and confirm that is not the case?

Please consider closing this back up and opening a different issue to resolve these other problems.

@joelpittet Narrowing the selector helps solve the problem as it scopes the following logic to the relevant exposed form, not the first one returned by the selector. You're right that this is a problem with "bad HTML", but that's a Views problem in that it doesn't expect users to embed the same View with exposed forms multiple times on one page. You're also probably right that adding context would break exposed forms in blocks, so we'll need to come up a new fix.

@samuel.mortenson thank you for confirming and narrowing down where the problem is.

I wonder if we can 'tag' the exposed forms with a data attribute or something so it knows what view it's related to? That way it's not ID dependent?

This is still ID dependent, but adding the dom id to the selector works in the case where I encountered this issue.

I looked in other commits in the 3.12 release but did not find where the dom id is appended to the exposed form element's id attribute, so I'm not sure if this is a general enough solution.

Is this missing the backend code that append the "view_dom_id" to the exposed form's normal ID?

Thanks a lot, it worked for me in FF and Chrome, but it still doesnt work in IE.
Have error message at:
"Drupal.views.ajaxView = function(settings) {
var selector = '.view-dom-id-' + settings.view_dom_id;
this.$view = $(selector);
........."

Applying patch #41 didn't work for me, but #37 works just fine. Scenarios in which patch #41 do not work:

Scenario 1 - Adding Node Pane with panels IPE using the node_pane module:

I'm adding node pane with panels ipe using node_pane module which provide me the ability to select an existing node directly from a list that is built with views and has an exposed filter. I was facing the same with exposed filters after closing and opening the popup a second time .
Patch #37 fixes the issue , #41 doesn't.

Scenario 2 - Adding Views with panels IPE:

This is a side effect of patch #41 since it's not related to views in modal.
I've added two views using panels ipe in a page , both views with exposed filters. With patch #41 , clicking on the submit button of the exposed form do not trigger ajax and reloads the page

#37 work for me. I have 1-page with 3-view panes and 1-exposed filter from one of the panes. The other two panes also have exposed filters that don't need to be included on the page. I believe this is because they share the same "Filter identifier" from the "more" section of the filter.

Thanks.

#37 Works for me, thanks.

I have 2 exposed input filters using field collection views.

Cheers,
Dave

#37 works great!
Hope this is going to be merged into the next version of Views.

Regarding #41, @ezeedub, check your views.module:2046, it probably is:

$form['#id'] = drupal_clean_css_identifier('views_exposed_form-' . check_plain($view->name) . '-' . check_plain($display->id) . '-' . check_plain($view->dom_id));

which is neither the 7.x-3.14 or 7.x-3.x one.
I had the same issue with the version distributed with the latest Open Atrium (7.x-2.64) distribution.

That patch would make sense, form ids would be unique even if multiple instances of the same view were to be included in the same page (and why not?).

In fact, the id could be even shorter using by using simply the dom_id. I'm not sure of the implications but since the id has to change to be unique, well, let's go for it.

#37 doesn't make sense though, IDs should be unique.

TL;DR:

1. 7.x-3.14 works in most cases;
2. if you have two instances of the same view, #34 or #37 would not be a proper fix;
3. rely on dom_id for that purpose. You can use #41 but you will also have to patch views.module:2046, or try attached patch.

OK, Additional information here. Seems that #41 fix has been used in conjunction with this patch:
https://www.drupal.org/files/issues/1735096-views-multiple-instance-expo...

My patch might not be a good idea if you haven't applied that one.

I'm linking the issue 1735096, which would be a better place to discuss the multiple instances issue.

I have also run into this issue discussed in comments #34 and down.

For now, I've successfully applied the patch from #37, per other's feedback.

I second ak55's comment here - I'm wondering if there's any work on getting this fix committed into the module itself so that we don't have to keep track of the need for this patch in future updates.

Thanks for the work on these fixes!

I am affected by #1877238: Views caching cannot be combined with Ajax on cached pages if the Ajax rendered data or query are cached.

#37 works for me
#41 does not work for me

#37 works for mee as well

Be careful when considering those patches as actual fixes. I don't know for sure if this is related to this but I am fairly confident it is. For some reason in views_plugin_exposed_form.inc in method render_exposed_form() line 161 form is built with drupal_build_form() which calls out drupal_reset_static('drupal_html_id') and this means that every element which put together after this views is called could possibly get wrong html ID (read reserved). The bug it generates isn't obvious until you have some ajax elements, like ajax form, which rely on the unique html id. For example my case was that all the forms that were rendered after the view that had exposed form in block and ajax enabled got wrong html id and the forms stopped working correctly.

I think this issue cant be considered as fixed before the resetting of drupal_html_id static variable is avoided during exposed form rendering.

By looking at the code in drupal_build_form() I have come to conclusion that avoiding the drupal_static_reset('drupal_html_id'); which is actually called out at drupal_process_form is inevitable. Can anyone confirm.

Long story short:
views exposed form + exposed in block + ajax results in drupal_static_reset('drupal_html_id'); and will therefor potentially break other forms on the page.

PS. My view is also a block

Note this patch on a similar (possible duplicate) issue: https://www.drupal.org/node/1877238#comment-11562657

Are there any reasons for not committing #37?

Without #37 patch 96a54e0 introduces the very bugs it set out to fix (I can *no longer* use views in a ctools modal more than once).

@usta read why #37 is not correct in my response #38 and #40. It breaks exposed filters when placed in a block somewhere else on the page.

---

#49 seems to work for me. I had the issue with linkit_picker while attached to wyiswg. linkit_picker module attaches a view with form alter to the linkit form

Reroll of #49.

Some how I have this "Notice: Undefined property: view::$dom_id i views_exposed_form() (linje 2114 af .../views/views.module)." with the last patch 1809958-63-use-dom-id.patch.
This one views-undefined_var_ajax_exposed_filter-1809958-37.patch works just great so I've rerolled it: https://www.drupal.org/files/issues/2018-06-14/views-undefined_var_ajax_...

#64 works great, thanks!

#64 works great, thanks!

#64 worked like a charm

#64 worked, but created a new issue for me.
Different situation, but same ajax enabled exposed filter.
When I have the exposed form in a different region (included with a context), then instead of ajax filtering I get a page refresh.
Attached path should resolve both issues.

Fixing Undefined property: view::$dom_id in views_exposed_form() of my previous patch.

Patch #70 did not run its test cleanly and could not be applied:

15:34:47 The patch attempt returned an error.  Error code: 128
15:34:47 Patch Failed to Apply
15:34:47 fatal: corrupt patch at line 30

I can confirm patch #70 definitely does not work.

If using an Ajax view for listing comments with a comment form (not within a modal window), the patch causes an "Invalid form POST data." error and can no longer post comments.

Patch #64 has not caused any problems, but seems as though @Andras_Szilagyi is still having issues so will leave this as needs review.

Hi @ron_s, thx for your review.

Could you help me with steps to reproduce ?

For now I'm uploading a patch which does not fail on latest 3.x-dev (sqlite and postgress seem branch not patch related to me).

#68 works Thanks

The related issue https://www.drupal.org/node/1735096 seems to have a better patch that expands on the solutions being proposed here.

I've tried many patches from this queue but only the patch from related issue worked for me https://www.drupal.org/files/issues/2019-05-07/1735096-views-multiple-in...