Hey so I am building a website using Drupal for the first time, and I have a views page set up using exposed filters. I added a reset button as per the request of my client, but unfortunately, every time the reset button is pressed it redirects me to a google chrome page saying that the page caused an infinite redirect loop. I have tried everything I could including using better exposed filters instead of input required or basic, as well as uninstalling views and re-installing again. I'm using the latest version of drupal and the latest version of views.

Any help with this would be appreciated, and I will provide more info if it is requested (if it's an advanced information request, please also include instructions on how to obtain the info to show you, I am fairly new to Drupal and views is also a very powerful and flexible module, but is very complex and seems to have a sharp learning curve because of this).

Thank you to anyone who responds in advance.

Files: 
CommentFileSizeAuthor
#33 1807916-reset-button-fix.patch430 bytesacbramley
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1807916-reset-button-fix.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#5 drupal-1807916-5.patch618 bytesdawehner
Test request sent.
[ View ]
#4 views-exposed-form-reset-redirect-1807916-4.patch430 bytesDavid_Rothstein
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

Comments

I actually took care of this, it turns out that the problem was the site was running a dev version of drupal. I did drush pm-update drupal and it installed drupal 7.15, the non dev version, and now the reset button works fine.

I have this same issue but this is on a brand new install of drupal 7.17 and views 7.x-3.5.
This has been driving me crazy the whole day.

To recreate, simply create a view with an exposed filter and enable the reset button for the exposed filter.
Go to the view page, pick a filter then try to reset.

I'm going back to an earlier version of drupal and views to see if that fixes anything.

Reverting to drupal 7.16 (downgraded my site) fixes this issue.
I did not downgrade views. So the issue is with core.

Title:Reset Button Causes Redirect LoopReset button on exposed filters causes a redirect loop in Drupal 7.17
Version:7.x-3.5» 7.x-3.x-dev
Category:support» bug
Status:Active» Needs review
StatusFileSize
new430 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

Ouch.

@Gode, for future reference, if you ever notice a regression like this in the future, please don't hesitate to move the issue to the Drupal core queue as soon as it becomes clear that Drupal core is causing the problem! (You can do this by editing the "Project" field when leaving a comment on the issue...) In retrospect, we might have been able to catch this while it was still in 7.x-dev and avoided releasing Drupal 7.17 with this bug. (There's now an issue filed by @kenyan at #1836082: Drupal 7.17 breaks some form redirects (including views exposed filters).)

Anyway, although this was caused by core, the patch committed to core was a legitimate bug fix. It just seems like it can have unintended side effects... If it's really only Views affected (guess we'll see as time goes on?) then it may just make sense to fix in Views. I think it's a good idea for the Views code to be explicit about where it wants to redirect anyway.

Here's a patch that seems to work for me. Not sure if it has other side effects though.

Version:7.x-3.x-dev» 8.x-3.x-dev
Status:Needs review» Patch (to be ported)
Issue tags:+VDC
StatusFileSize
new618 bytes
Test request sent.
[ View ]

I can confirm that this fixes the issue for simple reset buttons, so let's get this in to fix the issue as soon as possible. Committed and pushed to get a bug-fix out. I guess views should also do a release based on this fix?

There is one possible problem, which seems to be not a central problem, but maybe bad for edge-case-users:

When you reset on anything related with ajax you might not expect a full page reload when you reset.
For example if you have a calendar which already has $_GET arguments you might loose context after that.

Attached a patch for 8.x

Status:Patch (to be ported)» Needs review
Issue tags:+Needs tests

Update the status.

@David_Rothstein thanks, fixed issue for me.

Confirming that #4 fixes the issue in D7. Thanks!

Status:Needs review» Reviewed & tested by the community

Great; fixed it for me too in D7.

Yep. Works for me too.

The patch always redirects to the View's page path, even when viewed in a Panels page.

Nevermind. Seems views forms always use $_GET['q']

Thank you for the drupal 7 patch :) it works fine with the latest versions at this day.

#4 fix also worked for me on Drupal 7.17 with views 3.5 patched.

Just another confirmation that the (one-line) patch seems to work fine against D7.

Note: I ran into this issue as well and solved it via javascript (unsetting the options and klicking the hidden submit button). For an ajax view, reloading the page seems not optimal and something similar to this might be better. However I don't want to start a discussion about this here, just share a quick thought.

Title:Reset button on exposed filters causes a redirect loop in Drupal 7.17Reset button on exposed filters causes a redirect loop

Project:Views» Drupal core
Version:8.x-3.x-dev» 8.x-dev
Component:exposed filters» views.module
Status:Reviewed & tested by the community» Needs work

Remember to move these issues to the core queue. ;)

This still needs test coverage.

I think this was already fixed in Drupal 8 (with tests) at #1826008: Exposed form reset doesn't work..

However, the Ajax issue probably still remains. Maybe there needs to be two separate issues (one in the Views queue, one in Drupal 8) for that followup?

Version:8.x-dev» 7.17

Thanks for the patch! #4 fixes issue in D 7.17

Version:7.17» 8.x-dev

Do not change version numbers

Can confirm patch in #4 above works as intended. Nice work, thanks.

Project:Drupal core» Views
Version:8.x-dev» 7.x-3.x-dev
Component:views.module» Code
Status:Needs work» Reviewed & tested by the community

This already had a separate core issue, #1826008: Exposed form reset doesn't work.

Status:Reviewed & tested by the community» Fixed

This was already committed on #5.

Patch on #4 worked for me as well. Thank you.

Is there a way to fix it in D 7.16 with new Views? I tried this patch but id didn't help me. There were not any notices about reset button problem in views 3.5 and upgraded and now I cannot use reset button on my production site.

Did you tried to run the dev version?

I tried 3.5 for my production site and didn't tried dev version. Should I try dev?

I guess this is only fixed in dev version

Looks like the fix was committed November 10, 2012: http://drupalcode.org/project/views.git/commit/8cf24f6

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

I have this issue with Drupal 7.18, Views 3.5 and Better Exposed Filters 3.0-beta3.

Status:Active» Closed (fixed)

Yes, it wasn't in Views 3.5, use Views 3.x until 3.6 comes out.

StatusFileSize
new430 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1807916-reset-button-fix.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here's a patch for 3.5 that contains the fix for people that don't want to run --dev

Status:Closed (fixed)» Needs review

Status:Needs review» Needs work

The last submitted patch, 1807916-reset-button-fix.patch, failed testing.

Status:Needs work» Closed (fixed)

Ehm, can't apply an already applied patch ;)

Hence the initial no change of status, sorry I missed the do-not-test suffix

Priority:Major» Normal

Hi, just to say, the patch in #4 worked fine for me.
Tommy

Version:7.x-3.x-dev» 7.x-3.5

Hi, I have the same issue with the reset button and views in D7.19 .
I had first the impression everything worked fine in D7 but after updating all modules and core this problem started. It is something you just don't notice immediately so you wonder when it started. Now the reset buton gives an error page.

Version:7.x-3.5» 7.x-3.x-dev
Priority:Normal» Major

Thank you, #4 worked for me.

Adding the form_state redirect (#4) helped for me too. Thanks.

work Fine.
Thanks

I'm getting Hunk #1 FAILED at 324.
executing this command in sites dir:
patch -p1 < views-exposed-form-reset-redirect-1807916-4.patch
what am I doing wrong?
ok Im an idiot, put the patch in views/plugins and ran it and it worked.
well, the patch was applied, but I still get redirected to homepage when clicking reset button in exposed filter.

Did you clear the cache after applying the patch?

yes, I did clear the cache and the reset button still redirected to the homepage

thanks for the patch

patch worked. thanks!

Version:7.x-3.x-dev» 7.x-3.5

I think it's better to write a custom module than patching the views module.

function modulename_form_alter(&$form, &$form_state, $form_id) {
  switch ($form_id) {
    case 'views_exposed_form':
      // Form Reset button fix.
      $form_state['redirect'] = current_path();
      break;
  }
}

Thats it (use the patch's content in #4), and views module stay upgradeable. Of course, You can extend with some extra condition (which view is this, check if Reset button is visible, etc.), this is just a quick solution. And of course, thanks for the patch :)

Subscribe

@danyg You prefer not fixing bugs but better go around them using custom coding? Strange approach...

@Georgique: No, I just not prefer using patches in cases like this. I don't know if it will be commited into next Views stable and the problem can be solved in a custom module, easily. If this patch won't be the part of the next stable Views update, but I'd like to update the module, the exposed views will work still thanks to the custom code.
I don't like bugs :)

@danyg and anybody still patching
if you follow the discussion above PATCH already in DEV version of VIEWS

how do I make RESET stay on the current path, it always goes to default path of the view
(someone mentioned it already for panel view)

I applied this patch and while it cleared the loop error, my AJAX paged maps stopped rendering after a "Reset" I had to turn AJAX off in the view.

Hi,
apologize for newbie question, but how I can to apply this patch from post #4?
thanks for your forbearance ;)

Moonshine,

The easiest way for a newbie to apply this patch is to open it in a text editor and check it out. The top tells you what file to change:

/plugins/views_plugin_exposed_form.inc

Open that file in a text editor too.

Then the patch tells you (about) where to make the change:

@@ -324,6 +324,7 @@ class views_plugin_exposed_form extends views_plugin {

so look in your text editor around line 324 for the line of code that follows. That gets you in the right place.

Then you will see a section of code with a NEW line of code signified with a + sign.

That line with the plus sign needs to be added to the /plugins/views_plugin_exposed_form.inc in just that place as pointed out in the patch. DO NOT ADD THE + to the /plugins/views_plugin_exposed_form.inc file.

There are a lot of tools that let you apply patches, but since this is one line of code, and you are new, just cut and paste makes sense here.

Just for future reference, if you see a line(s) of code in a patch that starts with a - sign, that is what you DELETE from the original file.

thanks for your time, that's clear for me. I will try to apply this patch with your instruction.

edit: I applied this patch, but doesn't work correctly. When I click the "reset" button, the site is redirect to my front page. Any sugestions?

p.s. display of my views is a block, not a page

People no need to patch anything
just download the latest DEV (the patch is included as per #36)

@JSCSJSCS that is not the correct way to apply patches, imagine someone trying to do that with a huge, complex patch. @moonshine102 http://drupal.org/patch/apply this explains how to apply patches through command line, the community generally have a single prefix on the path, so from the module directory you should be doing something like this: `patch -p1 < /path/to/patch`

@acbramley ...really? I pointed out this was one line of code. You assume moonshine102 is not on a Windows machine. Not everyone can just type "patch -p1" into a command line.

@JSCJSCS indeed, but advising anyone on manually applying patch file lines is not good either. There are ways to patch files on Windows, including through command line. http://drupal.org/node/60179 advises on how to do this, or if an IDE isn't being used http://drupal.org/node/75790#comment-2615716 explains other ways to do it.

This is a closed issue. Please discuss this further in the forums if need be.

Thank you, #4 worked for me.

Status:Closed (fixed)» Active

I am using Views exposed filter in a Panel Pane, with my filter exposed as block.

My filter block is in my sidebar and when I select the reset button I am still redirected to the homepage.

So isn't this still active ?

Status:Active» Closed (fixed)

... redirected to the homepage.

Not sure how this is a redirect loop?! This isssue is closed.

Assigned:Unassigned» kidfgrk

#4
worked for me too !
thanks!

I agree with danyg, I used proposed method (#50) in a custom module, I can confirm it works.

Had the same issue with 7.22 core and views 7.x-3.5,
updating views to 7.x-3.7 fixed it for me, thank you.

Assigned:kidfgrk» Unassigned

Wrongly assigned

Version:7.x-3.5» 7.x-3.7

I'm not going to re-open this issue, but I'm still have problems with the reset. I've traced the problem to the exposed_form_submit() function in view_plugin_exposed_form.inc file.

<?php
function exposed_form_submit(&$form, &$form_state, &$exclude) {
    if (!empty(
$form_state['values']['op']) && $form_state['values']['op'] == $this->options['reset_button_label']) {
     
$this->reset_form($form, $form_state);
    }
    if (isset(
$form_state['pager_plugin'])) {
     
$form_state['pager_plugin']->exposed_form_submit($form, $form_state, $exclude);
     
$exclude[] = 'pager_plugin';
    }
  }
?>

The problem is when I click the reset button $form_state['values']['op'] is never added. (it works in the admin views preview but not on the page itself) Since there is no $form_state['values']['op'] the check fails and reset_form() is never called to which the patch in #4 is placed to add the redirect back to the current page.

I've checked my code and I am not modifying $form_state at any point.

I am also still experiencing problems with the reset redirecting to the front page.

Status:Closed (fixed)» Needs review

Same here using Content Pane and Exposed Filter as Block. When i want to reset the filters, it redirects to the frontpage. Applying filters works normally and stays in current page.

Status:Needs review» Active

Needs review means that there is a patch.

Priority:Major» Normal
Status:Active» Postponed (maintainer needs more info)

I would suggest to people still having problems with this to try:

In a Pane view, in the Pane settings, set Use Panel path to 'Yes'.

HTH

#75 doesn't work for me - nor anything else in this thread. My problem is that hitting reset on an exposed filter in an embedded block (using Insert View) sends the user to the home page, making it unusable. I've tried many suggested solutions at this point; there are several threads regarding the issue, so it seems to be well-identified, yet I've had no luck at all.

I believe there are two, possibly related, but distinct issues here: the redirect loop issue (which I'm not seeing) and the "reset goes to front page" issue.

It looks like many others are having the same problem, but I can find no resolution - #50 mentions creating a custom module, but I'm a designer, not a coder, so the info is of little use for me.

Does anybody have a solution/workaround for this? I must use an AJAX inserted view (views are different for each node), so an approach that doesn't take both into account won't work.

(By way of background, this is for a retail site where images illustrating various options get inserted into the "master" node for the product, which contains specs and other information. I would think this to be a not-uncommon use case and, other than the reset issue, is working brilliantly.)

Any guidance greatly appreciated... Thanks!

UPDATE: Problem partially solved with #23 from https://drupal.org/node/1109980

@bcobin:

Let's try to be in the same page. Now I would think that Insert View could be the culprit, and I really don't know why you need it. If you check the following link: http://cubazul.net/accommodations I guess that is the same functionality you are trying to achieve. There you have a View (left side) and the same Views' exposed filters on the right side, all that is mounted inside a Panel page. And the whole View is AJAX-based (as you would be able to see interacting with the page). Do you need anything else? If you are still using Blocks, I would strongly suggest you to start using Panels.

I would ask you to try using only Panels and Views, that should do it. Including more modules would increase the probability of errors. Let us know your results.

HTH

MyXelf

Thanks for following up, @MySelf - much appreciated!

I actually am using Panels and Views - I've since posted a more up-to-date assessment at https://drupal.org/node/2077869

My use case is quite different form the example you gave. My situation involves selecting different options for a product (e.g., color, trim) and the site will display the appropriate image(s) upon select. There are several issues at play here:

Grouped Taxonomy

This works only with the patch, which has since proved to be problematic in throwing errors. The function is essential for me in that the system needs to store model numbers which would be incomprehensible to the site user, who only needs to know "red," for example.

Reset resets all items

These are high-end ranges I'm working with - in addition to color and trim, there are also different stovetop options; this needs to happen in a separate, independent selector mechanism. If a single reset resets both selectors on the page, it's a problem.

The last issue I mention ("Any" as opposed to default upon reset) is annoying and counter-intuitive for the user, but I suppose I could live with it.

In any event, if you're interested, I could send you a link within the next few days so you could see what I'm talking about - I'm currently waiting for the images, at which point it will be easier to see what's going on - or not going on, as the case may be.

Let me know and thanks again for your response!

Hi,

I have the same problem as bcobin (no 76). Pressing reset just exits the results page with the filter and takes me to the site home page. With so many people having this issue - with what is a fundamental part of the functionality - hopefully, this can be addressed asap.

Here's hoping...

I have the same problem with a view as a block. Exposed filter reset button (using AJAX), redirects user to homepage.

I solved my problem by switching the view from a block to a page (no AJAX). Maybe this will solve the problem for others until the solution is found. The text I needed at the top of the view I added in the Global Text of a Header.

Similar to above the work around i've implemented to stop this from happening is to clone my view as a page too which then allows you to set a path for the view.

After doing this the reset button refreshes the page as specified in the path rather than kicking the user out to the homepage.

Hope this helps some of you guys.

Did you clone the whole view or just the display as a page ?

Using #23 from https://drupal.org/node/1109980 (thank you @kintaro!) I created a file called exposed.forms.fix.js with the code below and put it in the scripts folder of my active theme.

(function ($) {
// Code addition to fix reset on exposed forms in AJAX - without this, reset goes to front page.
$(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);

I then added the following to the theme's .info file.

scripts[] = 'scripts/exposed.forms.fix.js'

There are still other issues with exposed filters, but at least this solves the redirect to home page issue for me. Once the site gets further along, I'll create the appropriate tpl.php file and add it there as opposed to calling the script for the entire site, but for now, I can get on with things, at least.

Hope this helps!

Thank you bcobin , this works for me!

Thanks bcobin, the script stops the redirect to the Home page, but it doesn't reset the view i.e. the search terms and results still show. Any ideas on this, I'm not a PHP coder!

Issue summary:View changes
Status:Postponed (maintainer needs more info)» Closed (fixed)

The original issue has been fixed. See comment #66.

Reset button redirecting to the home page is a separate issue. See related issues:

- #1264316: Reset button redirects to /node
- #1109980: Exposed Form Reset button Inherits the page display URL when using as a block and AJAX

Status:Closed (fixed)» Needs review

33: 1807916-reset-button-fix.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, 33: 1807916-reset-button-fix.patch, failed testing.

Status:Needs work» Closed (fixed)

Please don't open closed issues unless there is a reason for it.