Exposed Form Reset button Inherits the page display URL when using as a block and AJAX

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

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.

Same problem here with exposed form filters and Ajax

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

vlooivlerke are you using the Better Exposed Filters module?

no, Let me have a look at it thanks.

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

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.

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)

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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'];
  }
}

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']?

[#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.

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

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

@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

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

So is it just me, or can we mark this issue as 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.

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.

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?

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

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!

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!

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...

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

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

@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!

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!

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.

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>

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

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

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));

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

Hi,

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

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 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?

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();
  }
}

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

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.

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

#60 worked nicely thanks @Anybody!

#60 worked nicely for me as well. Thanks!

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...

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

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.

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

#52 works for me ! Thx

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

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

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.

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

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

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

#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

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?

Also implemented #66 for its simplicity. Thanks!

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).

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

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

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.

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).

#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;
    });

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!

Social Timeline - Can you provide these files please for instagram integration:
Set Instagram Credentials
Copy the Client ID into the files in the libraries folder: instagram_auth/instagram.php and instagram_auth/instagram_hash.php4

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

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

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.

#52 worked great! Thank you!

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

Thanks #60 worked for me.

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');
});

Thanks, using #66

In my case I was dealing with a block ajax view that had exposed filters and selection history stored in a session for both anonymous and authenticated users. Tried all of the above and more... The only thing that resolved this for me was a simple:

$('.your-view-selector .view-filters form').attr('action', window.location.pathname); (don't forget the Drupal.behaviors wrapper)

P.S. This will successfully reset your filters, but will reload the same page instead of redirecting to front page

I was dealing with an ajax block auto-submitting view, that memorizes selection of multiple exposed filers for bot authenticated and anonymous users.
None of the above has helped. What did resolve this for me was a simple:
$('.your-view-selector .view-filters form').attr('action', window.location.pathname);
(Don't forget the "Drupal.behaviors" wrapper)

This is by no means a proper fix. It will reload your current page when you reset the filters. But resetting will work and you won't get redirected to the front page.

Confirmed #55 works without needing to fool with any extra JavaScript additions. It's also nice to be able to position the filters where I want, now that both the filters and the view are separate blocks!

#57 worked great. Worked on Drupal 8 !

Thanks @phoang

using #66, works perfectly! Views version: 7.x-3.20

#52 works like a charm for me! Thanks @jamesdixon!

I tried all the potential fixes offered in this thread and I could still not get the previous results AND searchbox contents cleared with the Reset button. I ended up installing the Views Better Exposed Filters module and using it in conjunction with the following script added to either a Global Text Area (within the View you're using), or in a basic Block added to the Content region.

Hopefully this save someone a lot more time than it took me to get it all working.

<script>
(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));
</script>

#23 solved my problem. Thanks

@GuyManDude, that's @JamesDixon's fix from #52. Trying to pass it as your own? Sheesh.

Thanks @JamesDixon you Drupal rockstar; I plugged in your code and... boom... working reset button.

Hahaha @robbdavis thanks for brightening my day bud! Glad I could help you out :)

#52 code works for me, but search value remains in search field but output gets updated with empty value. Can someone help me on this?

Based on #17, this is the simplest workaround:

(function ($, Drupal, drupalSettings) {
  Drupal.behaviors.exampleReset = {
    attach: function (context, settings) {

      let $resetLink = $('.views-exposed-form input[data-drupal-selector="edit-reset"]');
      $resetLink.click(function(){
        window.location.replace('https://' + window.location.hostname + window.location.pathname);
        return false;
      });

    }
  };
})(jQuery, Drupal, drupalSettings);

Core: 8.9.13

I believe this is a duplicate issue of
https://www.drupal.org/project/drupal/issues/2844823

The workaround options are:
1. Do not group your views together (page, embed, block) to avoid the incorrect action value
2. Preprocess hook to fix the form action
3. Javascript behavior to fix the form action

There is no indication of a patch to verify, but if there were one, I think it would be on the other issue.
My assumption, although, in case anyone else is stumbling across this.

On our project using Drupal Core: 9.3.5, on an Export CSV view attached to a Block view the latter of which is using Better Exposed Filters, the 'Download CSV' button was working fine, but the 'Reset' button also triggered the CSV download.

The code in #106 worked for me to get round this (many thanks for that @handkerchief), but I tweaked it slightly, just to use the Drupal behaviors context variable:

(function ($, Drupal, drupalSettings) {
  Drupal.behaviors.resetButtonBehavior = {
    attach: function (context, settings) {
      $(context).find('.views-exposed-form input[data-drupal-selector="edit-reset"]').on('click', function(){
        window.location.replace('https://' + window.location.hostname + window.location.pathname);
        return false;
      });
    }
  };
})(jQuery, Drupal, drupalSettings);

The compromise, as many other posters in this issue thread have noted, is that the page reloads rather than just resetting the filters, but this is certainly better than the faulty behaviour of the 'Reset' button beforehand. I still feel a better solution needs to be incorporated into Core at some point.

I also reaffirm what @staceroni writes in #107 and will cross-post on that other useful issue thread mentioned there.

Still using #66 in d7.

For Drupal 9, #110 didn't work for me. I used the following in my js file:

(function ($) {
	$(document).ready(function () {
		//
		// code to fix reset button issue on views filters jumping to wrong display  https://www.drupal.org/project/drupal/issues/1109980
		$(document).delegate(
			".views-exposed-form input[data-drupal-selector='edit-reset']",
			"click",
			function (event) {
				event.preventDefault();
				window.location.replace(
					"https://" + window.location.hostname + window.location.pathname
				);
				return false;
			}
		);
		//
	}); //end document ready
})(jQuery);

This is being triaged as part of bug smash. This issue duplicates an existing issue which has a WIP fix on it.

This is a duplicate of #3163940: Viewsform has incorrect form submit URL if loaded through ajax