use_ajax setting gets lost when exposed filter form is added as a block inside of a panel

use_ajax setting gets lost when exposed filter form is added as a block inside of a panel

Using Views 6.x-2.7

I tried to use an exposed filter form in a block (for the purpose of setting into a Panel), and found that the "Apply" button would not honor the "Use AJAX" setting I had set for the display. In my case, the view results and the exposed filter form are in the same page (just using Page Manager for laying out the pages and want the filter to be in a different area of the screen...).

When the view's basic setting "Exposed form in block" is set, a block gets created automatically (something like "Exposed form: search_results-block_1" appears in the Blocks admin screen). Then when doing "Add content" to a panel in Page Manager, this block element is available in the "Views" window. A pretty outstanding feature in my opinion, which I hope to leverage in future projects as well.

I had set "Use AJAX" to "yes" for this display (as well as the Default display), though this setting wasn't getting honored when I would click the "Apply" button. What would happen is that the form would submit form values in a GET string to "/", which is what the "action" attribute is set to for AJAXy forms because the Drupal.settings.views.ajax_path ("/views/ajax") will stand in when the submit event fires. So instead of remaining at:

http://www.example.com/recent

... and having the main view container refresh on success, the window redirected to:

http://www.example.com/?tid[]=210&view_name=search_results&[... snip ...]

... in an new page load without triggering the $.ajaxSubmit at all. It appeared that the AJAXiness of the form was lost, and for no apparent reason. I started digging into the js, and found that $.ajaxSubmit (in views/js/ajax_view.js) was "undefined", which seemed really odd.

At any rate, adding the block as a "regular" block in the page worked fine.

It turns out that the jquery.form.js file was not getting included in the head of the page when added as a block within a Panels pane, which accounted for $.ajaxSubmit not being defined at all. Figuring out why the file was not getting included took a little while, however.

My finding is that the render_exposed_form() function (~ line 409, views/includes/view.inc) is attempting to honor (a perhaps deprecated) $this->ajax setting to determine whether this is an AJAXy form. Rewriting the conditition to look for the use_ajax setting on the display handler gives the top-level view::use_ajax property the correct value. Essentially, that did the trick.

Around line 413 in view.inc, the execution chain immediately proceeds to the form render operation (invoking "views_exposed_form" hook using the $form_state variable to deliver the view:: object). So without $form_state['view']->use_ajax (i.e. view::use_ajax) set to TRUE, views_exposed_form will not include "/misc/jquery.form.js". Without this js getting included, the "Apply" button will only submit the form values to the "/" action in the form.

A patch is attached, and looks like:

--- includes/view.inc   2009-09-15 10:57:11.000000000 -0700
+++ includes/view.inc   2010-09-09 10:39:53.000000000 -0700
@@ -406,8 +406,9 @@ class view extends views_db_object {
       unset($form_state['rerender']);
     }

-    if (!empty($this->ajax)) {
-      $form_state['ajax'] = TRUE;
+    // Look for use_ajax setting on the display ($this->ajax seems deprecated...)
+    if ($this->display_handler->get_option('use_ajax')) {
+      $form_state['view']->use_ajax = TRUE;
     }

     $output = drupal_build_form('views_exposed_form', $form_state);

If this change makes sense to the maintainers, please verify the patch. I'm happy to post any additional information if clarification is needed.

Cheers,
-- mysterlune