The exposed form reset button does not work for the filters. It just redirects to the homepage. If I use firebug and look at the form I see:
<form accept-charset="UTF-8" id="views-exposed-form-careers-block" method="get" action="/" class="views-processed">

Obviously it is the action that is incorrect and I do not know why it is doing that. Here is the page it is causing problems:

http://firstwind.silvereastdesign.com/about/careers

Comments

dawehner’s picture

Category: support » bug
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Can you please try out the beta release? There are so many things fixed it's impossible to count/remember

esmerel’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
brandy.brown’s picture

Version: 7.x-3.0-alpha1 » 7.x-3.0-rc3
Status: Closed (cannot reproduce) » Active

I am using Views 3 and am having the same problem. I have multiple exposed filters on an AJAX enabled view. I am also using quicktabs, but I don't think that's an issue as I have tested this problem with views that are not using quicktabs.

vlooivlerke’s picture

Same problem here with exposed form filters and Ajax

Works with Ajax and exposed forms if filters are not exposed.

brandy.brown’s picture

vlooivlerke are you using the Better Exposed Filters module?

vlooivlerke’s picture

no, Let me have a look at it thanks.

I am building a view and will post link for all to see soon.

greggles’s picture

Status: Active » Postponed (maintainer needs more info)
Todd Young’s picture

I am having the same issue, and I am not using QuickTabs. To work around the problem I used jQuery to set the onlick of the reset button to the same page name and added '?name_op=contains' after it (the default operator for my 'name' field) - this dumps the form values.

vlooivlerke’s picture

Here is a link to my site with an reset button
http://wikivillage.co.za

It works on Ajax paging
HS and autocomplete fields
and exposed sort filter and pager

To test, dont make any search just clcik rest (more than once)
Notice how the comapact forms labels move from within the search fields to top labels.
When you see this the form is broken and "HS and Autocomplete dont work any more"
To fix, page one page and all returns to normal

I needed this to go live on my production site so I have hidden the "JS errors of HS" when reset button is clicked via css:hidden. Not a good solution
Any ideas?
o yes, it is on a local server in South Africa so the website will take long to load (3rd word problems, not drupal)

dawehner’s picture

I'm a bit confused because this site works fine for me. Maybe you have already fixed this in the meantime?

What happens if you remove HS? Maybe you should check that out and then report an issue against HS.
If we should develop a proper fix we need a good way to reproduce your issue.

vlooivlerke’s picture

The issue is with "views-processed"

If you use ajax views and you click on search or reset buttons (more than once) the view-processed css change, causing form elements to break in style and function

http://drupal.org/node/1246672

thoughtcat’s picture

I get the same (or similar) problem. I've created a view with a page and block display. Both have "reset" buttons set in "exposed form style", but when you click "reset" in the block, it takes you to the page view instead of resetting the block view. The reset button works OK in the page view.

rlangille’s picture

I have experience the same issue, and tested it on a vanilla install of Drupal with views. To recreated it, simply create a view that has a block display, exposed a few basic items such as published and promoted status as filters, enable ajax, and set the block to display on any page except the home page. When the reset button is clicked, the user is redirected to the home page instead of resetting the filters.

stongo’s picture

In D6 this problem was solved by the method $view->override_path()
This method no longer exists for D7 'view' class
I am also having this issue and unsure how to fix it.

brandy.brown’s picture

as an update: the reset works as expected when used with exposed filters on a gmap or calendar view ... just not on a regular unformatted list or grid, etc.

jh81’s picture

Version: 7.x-3.0-rc3 » 7.x-3.3
Component: User interface » Code

Same problem here when using quicktabs. I really need a fix for this as it makes the quicktabs pretty useless because it takes you back to the page when you reset the filters and you loose the quicktab.

alx_benjamin’s picture

I use quicktabs, exposed form in the block and panels. Quicktabs are in one column, block with the form in another column.
Form uses AJAX.

Submit button works as it should updating results in the quicktabs. However reset button redirects to the view page.

I've temporarily fixed reset button with this jQuery code:

$('#reset-button').click(function(){
$('#views-exposed-form').each(function(){
this.reset();
});
$('#submit-button').click();

return false;
});

This clears/resets content of every field in the form and triggers 'click' action on submit button.

Hope this was helpful.

jh81’s picture

For #17, how/where are you adding the jQuery code for the fix?

erin814’s picture

Having the same issue here. I have exposed filters and a grid style layout for views. When I hit reset, it works in the admin view but on the live view, it redirects to the homepage.

esmerel’s picture

Status: Postponed (maintainer needs more info) » Active
osopolar’s picture

Somehow the inherit from page does not work for the reset button, but for the form elements it's working. As a workaround I use this code in a custom module:

/**
 * Implements hook_form_alter().
 */
function custom_form_views_exposed_form_alter(&$form, &$form_state) {
  // Workaround, because on a Ajax-Request the url of the current panel page gets lost
  // and "/" is used instead.
  if (isset($form_state['view']->current_display) && 'panel_pane_1' == $form_state['view']->current_display && $form['#action'] = '/') {
    // Fix action URL.
    $form['#action'] = '/' . $_GET['q'];
  }
}
osopolar’s picture

Now some more info about I found debugging the problem:

The exposed form action is build in view.module:
$form['#action'] = url($view->display_handler->get_url());

In my case $view->display_handler->get_url() means views_content_plugin_display_panel_pane::get_url() and because I set inherit_panels_path for my panel pane to true views_content_plugin_display_panel_pane::get_path() gets called. override_path is not set, so parent::get_path() will be called which should be views_plugin_display::get_path(). But neither $this->has_path() nor $this->get_link_display() is set.

The question is, how to get the url/path into the view and back to the $form['#action']?

kentoro’s picture

I had the same issue (on blocks with exposed filters) I followed the code provided by #17 and changed it to fit my forms.
this is my code inside my js file.

$(document).delegate('#edit-reset','click',function(event)
  {
    event.preventDefault();
    $('form').each(function(){
    $('form select option').removeAttr('selected');
    this.reset();
    });
   $('.views-submit-button .form-submit').click();
    return false;
  });

It will also take care of the selected items in dropdown lists,etc. I'm sure there is room for improvement but i just wanted to share how i solved the issue, enjoy!.

corvus_ch’s picture

[#1881884: Reset does not work broken on pages with multiple displays.] contains an example on how this can be reproduced. In the situation there, the ajax behavior does not get attached to the reset button unless you refresh the page.

Comment #21 does fix this problem, but i consider this more a hack than a real solution.

warmth’s picture

I'm having the same issue, subscribing...

mstef’s picture

Reset not working for me with AJAX views. I get an endless redirect when clicked.

damiankloip’s picture

@mstef: have you upgraded your version of views, this shoudl already be fixed, and not the same as this issue. #1807916: Reset button on exposed filters causes a redirect loop

mstef’s picture

ah - i thought i had the latest dev in, so I didn't see that issue. thanks damian.

dawehner’s picture

So is it just me, or can we mark this issue as fixed?

damiankloip’s picture

Status: Active » Fixed

Well the patch is committed. Not sure there is any value in talking about this more. If people haven't updated views, that's their problem :) let's close it.

iLLin’s picture

Status: Fixed » Active

This has not been fixed in the latest DEV. #22 has the start of troubleshooting as the AJAX block still inherits the page displays URL. There is no real solution in this thread only work arounds. @damiankloip, not sure which patch your talking about?

I used code from #21 and that caused a redirect loop like @mstef encountered but updating to the latest views fixes the redirect issue. The original problem on this thread still exists.

iLLin’s picture

Title: Exposed Form Reset button does not work » Exposed Form Reset button Inherits the page display URL when using as a block and AJAX
Version: 7.x-3.3 » 7.x-3.x-dev
GBain22’s picture

I am using Views 7.x-3.5 and Views Better Exposed Filters 7.x-3.0-beta3

The issue is obviously that a block of content with an exposed view MUST use Ajax as their is no URL for it to append an arguments to. I have tried using the Jquery code from post #23 but this just gave me an error saying "Uncaught TypeError: Property '$' of object [object Object] is not a function" so I cannot use it.

Has anyone else resolved this?

iLLin’s picture

You can use the same approach as #21. Just change it to your display name.

kentoro’s picture

That sounds as a conflict problem are you adding the jquery as drupal standards?

(function ($) {

  // Use jQuery with the shortcut:

}(jQuery));

more info https://drupal.org/node/171213

bcobin’s picture

Same problem here - I've had to disable AJAX for the view, which I don't want to do. Reset on exposed filters sends user to the front page with a query string like ?tid=92&tid_1=All&op=Reset.

With AJAX disabled, things work as expected. There seems to be two issues under discussion here: the redirect loop issue (which I'm not experiencing) and the redirection to the front page, which is my current problem.

Using latest versions of everything, including Views 7.x-3.x-dev - has there been any recommended solution here? Any guidance much appreciated... thanks!

kentoro’s picture

Are you using the jQuery update module? because I'm not and my solution #23 is just working fine.

bcobin’s picture

Thank you, @kentoro - I am using jQuery Update and (as I'm developing the site) the Twitter Bootstrap theme. Inserting your code in the theme .js file does, indeed, work a treat!

Thank you very much - I suppose I'll leave this open for now insofar as it seems like more of a workaround than a solution... but I'll take it!

Thanks again - you've been a huge help!

kentoro’s picture

My pleasure :)

kentoro’s picture

Priority: Normal » Minor

Changing the priority to minor since there is a workaround.

bcobin’s picture

One more thing (unfortunately):

I have two exposed forms on the page - one for each of the major options. Reset resets both, which rather defeats the purpose.

Is there any way around this? Thanks again for any guidance...

cm1se7en’s picture

Thanks osopolar #21
I'm OK with $form['#action'] = current_path();

kentoro’s picture

@bcobin
Hey,
It's true that my solution #23 was made for only one form in the page BUT your forms should have a class or id with it, since I was using the jQuery selectors you could specify that as ('#form1-#edit-reset') is clicked, then reset, then the same for the other one.
insted of the more general ('#edit-reset') Hope it helps.

PTL’s picture

Thank you for your code from #23. I can solve it now.

bcobin’s picture

@kentoro

Yes - a belated thank you for your code! For unrelated reasons, I've settled on a slightly different mechanism that requires only a single exposed form on the page, so #41 is no longer an issue for me.

It's all working great and the site will be super-cool - I'll post back here when it's up, but for now, thanks so much for taking the time and being so quick on the uptake... I am grateful!

tsonye’s picture

I know this thread is quite old now but I am having the same 'reset-button-homepage-redirect' issue and I can't seem to apply the workarounds mentioned in this thread.

Specifically, can someone explain where I need to write the .js code in #23

Any help will be much appreciated!

kentoro’s picture

Hi, you should place it inside your theme's custom js file.
see no:38 by becobin, when he puts the code inside his theme's js it works as it should

jh81’s picture

The code in #23 does not work for me. I am using the current version of Views and I have a large number of views all of which use Ajax and some that use QuickTabs. All of my views have the same issue where clicking the reset filter button either redirects you to the page or redirects you to the site home page. Does anybody know when this is going to be fixed? This thread is over 2 years old and I have had this issue for about the same amount of time. Its very frustrating that I cannot provide a reset filter button to my users.

hillmore’s picture

The code in #23 worked fine for me (Drupal 7.24 / Views 3.7). Thanks kentoro!
@jh81: for testing purpose, you can try to create a html block with the following code and add it to the content region of your theme.

<script>
(function ($) {

  $(document).delegate('#edit-reset','click',function(event) {
    event.preventDefault();
    $('form').each(function() {
      $('form select option').removeAttr('selected');
      this.reset();
    });
    $('.views-submit-button .form-submit').click();
    return false;
  });

}(jQuery));
</script>
jh81’s picture

@hillmore, I was able to get this working following your directions. Thanks!

pixel6’s picture

Issue summary: View changes

The code in #23 worked fine for me too! Thanks.

jamesdixon’s picture

Code #23 was close to working for me, but was not reseting text fields. The following snippet got the reset button working for me:

(function ($) {
  $(document).delegate('.views-reset-button .form-submit','click',function(event) {
    event.preventDefault();
    $('form').each(function() {
      $('form select option').removeAttr('selected');
      $('form input[type=text]').attr('value', '');
      this.reset();
    }); 
    $('.views-submit-button .form-submit').click();
    return false;
  }); 
}(jQuery));
stongo’s picture

All this jquery is good, but it still doesn't address the bug. What happens if a client has a javascript disabled?
This used to be fixable in Drupal 6 (see comment 14) properly with php, and isn't anymore in D7

PhilY’s picture

Hi,

#52 doesn't seem to work with Better Exposed Filters but only on regular Views filters

PhilY’s picture

Here is what I did to have it working with both regular Views exposed filters and BEF filters: the filters need to be exposed in their own block, which is not possible with Ajax blocks except by using the Views Block Exposed Filter Blocks module.

So, here is my process (Views 7.x-3.7, BEF 7.x-3.0-beta4):

  1. the views main output is a block
  2. view's Ajax is set to 'on' to have exposed filters being displayed
  3. exposed filters settings: autosubmit + reset button + hidden submit button
  4. this way, resetting is messy (leads to homepage)
  5. thanks to 'Views Block Exposed Filter Blocks' module, expose the view's filters in a block
  6. place the exposed filters' block so it can be shown with the view
  7. et voilà: reset button works, even on multilingual site

Hope this will help some readers ;-)

PS: no need of module hack or js/jQuery script

i.bajrai’s picture

I think everyone here is having an issue when the view is in a block.
However I have this issue but in a slightly different way.
My module is injecting the view via a custom menu callback, therefore in the view there is no page URL created.
I have solved it by having the view use AJAX.
However when the exposed form uses autosubmit if you press enter while the throbber is spinning it will post to the form action again.
Perhaps views need to read the page URL if a page url is not provided?

phoang’s picture

For anyone use the #1109980-21: Exposed Form Reset button Inherits the page display URL when using as a block and AJAX solution, I used this as specific form and it works for me.

/**
 * Implements hook_form_alter().
 */
function HOOK_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {
  if ($form['#id'] == 'your-form-id-block') {
    $form['#action'] = array();
  }
}
kentoro’s picture

Status: Active » Needs review

@jamesdixon nice you extended it to fit your needs, the problem there is that there are many input elements in HTML5 that are not of type text, such as url, telephone etc. I was going to extend this when i saw the comment on #55 which seems to be at a glance a better option.
could anyone test the solution on #55 further?

kunkunkun’s picture

It also happens when using exposed filter in a view content pane.

Anybody’s picture

Here you can find a solution that replaces the default reset functionality by an AJAX version. It doesn't have the problems described above. http://julian.pustkuchen.com/node/659

I hope it helps some of you as a workaround.

jenstechs’s picture

The code in #52 was the only one that worked for me. Thank you, combination of commenters!!

mxlav’s picture

#60 worked nicely thanks @Anybody!

jelo’s picture

#60 worked nicely for me as well. Thanks!

jelo’s picture

I just noticed that the patch in #60 does not work if the view has exposed filters and one of the filters has the option to "Remember last selection" ticked. It won't reset that field to ANY then...

Darvanen’s picture

#55 did the trick for me, thanks @PhilY!

franksj’s picture

We went with #52 but then we got complaints that the URL was too long and when we hit reset, we want to have just the clean url. So, for instance, http://drupalissoawesome.org/viewmaster instead of http://drupalissoawesome.org/viewmaster?title=&field_single_term_tid=&fi....

Instead of looping through the forms and unselecting everything, then calling the Search button, I started playing around with simply taking the user back to where they started.
Like so:

(function ($) {
    $(document).delegate('.views-reset-button .form-submit', 'click', function (event) {
      window.location = window.location.href.split('?')[0];
      return false;
    });
}(jQuery));

This way, when we click Reset, it doesn't bother with any resubmitting, clearing options, or anything. It behaves as though the user clicked the link to the page/view again.

Maybe not a one size fits all, but it definitely fit what we were trying to do.

Darvanen’s picture

So simple. Thanks franksj, worked for me (on another site where I couldn't use #55).

phileas75’s picture

#52 works for me ! Thx

JWBrown’s picture

Thank you, PhilY, your solution at #55 using that module worked for me!

dgtlmoon’s picture

Status: Needs review » Needs work

#55 worked for me, but I'm unsure if this is a fix or just a workaround

Darvanen’s picture

It's a workaround, but, to be honest, with D8 released we may not be that likely to get a fix for this in D7.

milos.kroulik’s picture

Workaround from #55 works also with Views content panes. But it would be great, if there would be a way to change URL.

alinaBasa’s picture

Using a view without a url and BEF the only solution was #66. Thanks

capfive’s picture

Great fix with the javascript! Thanks this really helped! (#66)

Alauddin’s picture

#66 works for me as well, but ran into issue where it gets applied to ALL my views with BEF exposed filter.

I only wanted to apply this to non-ajax view filters, so added 'noajax-filter-reset' class to views that needed this reset.

hope it helps others.

      // Start of views reset https://www.drupal.org/node/1109980#comment-10421063
         $(document).delegate('.noajax-filter-reset .form-submit.my-views-filter-reset', 'click', function (event) {
         window.location = window.location.href.split('?')[0];
         return false;
         });
       // end of views reset
weynhamz’s picture

Get bitten by the same problem here, exposed form with AJAX enabled will be redirect to homepage, has to disable AJAX. It has been almost half decade, hasn't there be a real fix instead of this js workaround?

scotself’s picture

Also implemented #66 for its simplicity. Thanks!

nmalinoski’s picture

URL inheritance issue seems to be occurring for me (view block, AJAX on, input required), but in my case, the URL it inherits is an admin URL, so users end up with an Access Denied message--from clicking the Reset button! It gets even better when you disable JavaScript--the Apply button sends users to the same access-denied admin page.

Using Views Block Exposed Filter Blocks alleviates the issue, but this is something that should work out of the box (so to speak).

amogiz’s picture

#66 works perfect for me.
Great thanx !!!!!!!

amogiz’s picture

#66 works perfect for me.
Great thanx !!!!!!!

acrosman’s picture

I agree with @nmalinoski that this should work correctly by default. The JS from #66 worked in our use case, but it's hardly the best possible solution.

diamondsea’s picture

I got around this in #2781117: Configurable timeouts on auto-submit, ignore Enter key option by using AJAX with the CTools patch on that ticket, using the "Ignore Enter Key" option to prevent the ENTER key from causing the action tag to fire. You'll still have the wrong-action issue if JS isn't enabled, but it works otherwise.

If it works for you, please Review/RTBC it and then I can submit the 3-line Views patch (described in the description).

neilsavage’s picture

#23 worked for me when selecting exposed filters with dropdowns. I had a search form enabled as well so I added a line to clear that as well:

$(document).delegate('#edit-reset','click',function(event)
    {
    event.preventDefault();
      $('form').each(function(){
      $('form select option').removeAttr('selected');
      $('form input').attr('value', ''); 
      this.reset();
      });
      $('.views-submit-button .form-submit').click();
      return false;
    });
jasonflaherty’s picture

I didn't see this post in the comments, but this module helped my quicktab / views block exposed filters issue: https://julian.pustkuchen.com/node/659

Thanks to the author!

joelpittet’s picture

Title: instagram integration » Exposed Form Reset button Inherits the page display URL when using as a block and AJAX
Issue tags: -Social Timeline - instagram integration

Hmm not sure what that change of title was all about...

maxplus’s picture

Hi,
working with views content panes and views filters with ajax: #66 helped me out, thanks!

alibenski’s picture

Hello,

jQuery script in #52 worked for me - using BEF, view selective filter, and dependent filter with AJAX. Thank you.
Also, I used JS Injector module since this code was messing up a certain functionality of the reset button of a Views block without a page display in another part of my website. Just wanted to share this information in case you find yourself on the same boat.

afireintheattic’s picture

#52 worked great! Thank you!

arunkumark’s picture

+1
The patch #52 working perfectly to reset exposed form. Am using exposed form in my CTools popup, it works as expected.

Aporie’s picture

Thanks #60 worked for me.

ogomez78’s picture

I'm concerned that there may be multiple ajax views exposed forms on the same page so I wanted to limit the scope of the reset event to only the form the button clicked is in. Also if the Better Exposed Filter module is in use, there may be checkboxes, and radios that need to be cleared as well, so that would need to be added to this code below.

I added this code below to my theme's scripts.js file:

// Fix ajax reset button

$('.views-reset-button .form-submit').click(function (e) {
  e.preventDefault();
  $(this).closest('.views-reset-button').siblings('.views-exposed-widget').find('select option').removeAttr('selected');
  $(this).closest('.views-reset-button').siblings('.views-exposed-widget').find('input[type=text]').attr('value', ''); 
  $(this).closest('.views-reset-button').siblings('.views-submit-button').find('input').trigger('click');
});