Inconsistent behavior with exposed filter in block AJAX

It might be good if you would use the "enter key" :)

Sadly i don't get what you mean, where is the bug ... Read http://drupal.org/node/571990 first, please.

I think it would be fair if you describe the bug :) I cannot/don't want to search the bug on your page :)

AS per the submission guidelines, if this seems to be localized to a field from Location, then it's Location module's issue and should be posted there. Note that there are some difficulties with using javascripty widgets and AJAX together that may be very difficult to solve because the framework we have does not handle adding more javascript to the page when AJAX is called, so this may be a weakness that is not easily fixable.

No updates in 30 days.

Re-opening this issue, because I experienced something similar on a site I am working on. I think I narrowed down the symptom, and I replicated the issue on a clean install of Drupal + Views with some dummy content. Specifically, the issue is when you display a view in a block and the exposed form is rendered in a block as well. Whether AJAX is enabled or not, the form redirects to the homepage and you see the filter variables in the query string. See the before and after screenshots in the attached files "views-796530-6-1.png" and "views-796530-6-2.png" respectively. This seems very similar to the symptom in the original post of the issue, except it doesn't seem to be isolated to the Location module. I also ran some debugging when AJAX is turned on, and you get a "$(this).ajaxSubmit is not a function" error on line 77 in js/ajax_views.js.

I haven't pinpointed the issue, but it appears that when the exposed filter is rendered as a block it loses the context as to where the block it is related to is being displayed. This actually makes sense because the blocks could conceivably be rendered on different pages and on multiple pages as well. Kind of a complex problem to solve, so maybe the answer is that the block display shouldn't have the option to "Expose form in block".

Thanks,
Chris

@cpliakas
Thanks for replicating this with Views only. It would be even more helpful to get an exported View showing this as well.

@merlinofchaos
I think the description could have enough details as it is, so I'm bumping it you to see if you have any idea. Otherwise I suggest postponed until we get an exported View. :)

Part of the issue is that "exposed form in a block" is not compatible with AJAX, so it doesn't try to use it.

"Exposed form in a block" should possibly not be an option for views without a path. That might be the best answer for all.

"Exposed form in a block" should possibly not be an option for views without a path.

I fully agree with this. It does not work as expected, both with and without AJAX. Again, I think that simply removing the option is the way to go, as it will prevent people from trying something that won't work.

Thanks,
Chris

My steps to recreate this using Quickstart 0.9 VM:

Drush a D7 clean install with ctools and views (I can provide the command line, make file, or vm image if needed).

Enable Views UI.
Enable forums.

Add three vocabularies, each with several terms (doesn't matter too much how many terms).
Add a forum container and move the default forum into it (I doubt this forum stuff even matters).

Add a new view, type=Term,

default set to:

add a filter, type Taxonomy Vocabulary, one of, check all but one of the vocabularies, exposed, force single, limit to set of items.
add fields, Vocabulary Name, Term ID, Term,
ajax = yes
Save it

add a block
machine name block_view_all_tax
name View all tax
Save it

Add content, title whatever, some text in the page whatever,
Give it a main menu link
Give it a url "show_tax"
Turn off comments
Save it

Go to Structure/Blocks and find - then configure the view_all_taxonomy_terms block.
put it in "content" show only on the page "show_tax"
Save it

Then go home, click the menu link to the show_tax page.

Three problems surface:

First up:

Notice: Undefined index: #value in forum_form_alter() (line 589 of /home/quickstart/websites/hack.dev/modules/forum/forum.module).

The form has no #value key defined in the vid array (it has #default_value but not #value).

Second up the html source shows

form action="/" method="get" id="views-exposed-form-view-all-taxonomy-terms-block-view-all-tax"

which has the wrong action url - I'm new to drupal but I'm betting is should be /show_tax

Finally it looks like ajax has a problem:

An error occurred while attempting to process /views/ajax: Cannot call method 'toLowerCase' of undefined

That error now seems to pop up randomly at places in the views editor.

I've attached the view. I can provide the quickstart vm image but I'll need some notice.

Can anybody point me to an overview of how this was supposed to work? What code was supposed to have created the $form array originally?

I notice ctools makes vid forms (with #default_values) all over the place - should they have been making a #value key as well?

How many other problems might be hiding behind these three? I threw a module to together to intercept that form and create the #value key and fix the #action value. No dice. I'm left with an ajax error about some undefined variable.

Notice: Undefined index: #value in forum_form_alter() (line 589 of /home/quickstart/websites/hack.dev/modules/forum/forum.module).

That's forum.module -- nothing I can do about that.

form action="/" method="get" id="views-exposed-form-view-all-taxonomy-terms-block-view-all-tax"

No, blocks don't go to an associated page for exposed filters. That's assuming a connection is not there. That's the reason that blocks support exposed filters only by ajax.

Finally, the view you exported is against Drupal 7; this issue is for Drupal 6. You've already opened an issue for the Drupal 7 version. Please, do not hijack other issues. It makes it very difficult for us to work and doesn't help you in the slightest.

Sorry for the hijack of this issue but someone closed the other issue as a dup of this one. I didn't notice the version had changed.

Anyone with a fix for this in D6 then?

To fix this issue simply override the #action of the exposed form with the current path. This submits the form to the current page the block is on instead of the view page.

function HOOK_form_views_exposed_form_alter(&$form , &$form_state){
  // Overrides the views exposed form url to be the current one
  // Avoids odd views redirect to views page from an exposed form in block
  $form['#action'] = request_uri();
}

Hope this helps someone.

Thank you, it did. I assume this issue is something that isn't solved simply, but let me add my +1. This override worked for me, I'm using a 'content pane'-type display with an exposed filter in a block, all put together in a panel. I hope it doesn't affect other things on the site as yet unseen.

The override in #17 works perfectly. I didn't notice any collateral effects by now.
I use it for a view with the "Views Fluid Grid - jQuery Masonry" display and the "Fields" row style + an exposed filter in a block.

Fixed with the latest versions of Views module.

Still experiencing some issues with this, and I've opened a follow-up here: #2597067: Exposed filter block AJAX, issue with differing path and disabled JS