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.
Comment | File | Size | Author |
---|---|---|---|
#33 | 1807916-reset-button-fix.patch | 430 bytes | acbramley |
#5 | drupal-1807916-5.patch | 618 bytes | dawehner |
#4 | views-exposed-form-reset-redirect-1807916-4.patch | 430 bytes | David_Rothstein |
Comments
Comment #1
Gode CreditAttribution: Gode commentedI 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.
Comment #2
kenyan CreditAttribution: kenyan commentedI 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.
Comment #3
kenyan CreditAttribution: kenyan commentedReverting to drupal 7.16 (downgraded my site) fixes this issue.
I did not downgrade views. So the issue is with core.
Comment #4
David_Rothstein CreditAttribution: David_Rothstein commentedOuch.
@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.
Comment #5
dawehnerI 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
Comment #6
dawehnerUpdate the status.
Comment #7
herrtl CreditAttribution: herrtl commented@David_Rothstein thanks, fixed issue for me.
Comment #8
MyXelf CreditAttribution: MyXelf commentedConfirming that #4 fixes the issue in D7. Thanks!
Comment #9
Vacilando CreditAttribution: Vacilando commentedGreat; fixed it for me too in D7.
Comment #10
kenyan CreditAttribution: kenyan commentedYep. Works for me too.
Comment #11
webavant CreditAttribution: webavant commentedThe patch always redirects to the View's page path, even when viewed in a Panels page.Nevermind. Seems views forms always use $_GET['q']
Comment #12
Fredj94 CreditAttribution: Fredj94 commentedThank you for the drupal 7 patch :) it works fine with the latest versions at this day.
Comment #13
joaomachado CreditAttribution: joaomachado commented#4 fix also worked for me on Drupal 7.17 with views 3.5 patched.
Comment #14
1kenthomas CreditAttribution: 1kenthomas commentedJust another confirmation that the (one-line) patch seems to work fine against D7.
Comment #15
s.Daniel CreditAttribution: s.Daniel commentedNote: 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.
Comment #16
xjmComment #17
xjmRemember to move these issues to the core queue. ;)
This still needs test coverage.
Comment #18
David_Rothstein CreditAttribution: David_Rothstein commentedI 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?
Comment #19
ghan CreditAttribution: ghan commentedThanks for the patch! #4 fixes issue in D 7.17
Comment #20
marcingy CreditAttribution: marcingy commentedDo not change version numbers
Comment #21
TechnoTim2010 CreditAttribution: TechnoTim2010 commentedCan confirm patch in #4 above works as intended. Nice work, thanks.
Comment #22
tim.plunkettThis already had a separate core issue, #1826008: Exposed form reset doesn't work.
Comment #23
dawehnerThis was already committed on #5.
Comment #24
cdmo CreditAttribution: cdmo commentedPatch on #4 worked for me as well. Thank you.
Comment #25
motomc CreditAttribution: motomc commentedIs 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.
Comment #26
dawehnerDid you tried to run the dev version?
Comment #27
motomc CreditAttribution: motomc commentedI tried 3.5 for my production site and didn't tried dev version. Should I try dev?
Comment #28
checker CreditAttribution: checker commentedI guess this is only fixed in dev version
Comment #29
okeedoak CreditAttribution: okeedoak commentedLooks like the fix was committed November 10, 2012: http://drupalcode.org/project/views.git/commit/8cf24f6
Comment #31
RealGecko CreditAttribution: RealGecko commentedI have this issue with Drupal 7.18, Views 3.5 and Better Exposed Filters 3.0-beta3.
Comment #32
tim.plunkettYes, it wasn't in Views 3.5, use Views 3.x until 3.6 comes out.
Comment #33
acbramley CreditAttribution: acbramley commentedHere's a patch for 3.5 that contains the fix for people that don't want to run --dev
Comment #34
weekbeforenextComment #36
MrHaroldA CreditAttribution: MrHaroldA commentedEhm, can't apply an already applied patch ;)
Comment #37
acbramley CreditAttribution: acbramley commentedHence the initial no change of status, sorry I missed the do-not-test suffix
Comment #38
tds2012 CreditAttribution: tds2012 commentedHi, just to say, the patch in #4 worked fine for me.
Tommy
Comment #39
johan2 CreditAttribution: johan2 commentedHi, 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.
Comment #40
Georgique CreditAttribution: Georgique commentedComment #41
ram4nd CreditAttribution: ram4nd commentedThank you, #4 worked for me.
Comment #42
johan2 CreditAttribution: johan2 commentedAdding the form_state redirect (#4) helped for me too. Thanks.
Comment #43
thepaladin CreditAttribution: thepaladin commentedwork Fine.
Thanks
Comment #44
dave.erwin CreditAttribution: dave.erwin commentedI'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.
Comment #45
ptmkenny CreditAttribution: ptmkenny commentedDid you clear the cache after applying the patch?
Comment #46
dave.erwin CreditAttribution: dave.erwin commentedyes, I did clear the cache and the reset button still redirected to the homepage
Comment #47
gurubydesign CreditAttribution: gurubydesign commentedthanks for the patch
Comment #48
j0rd CreditAttribution: j0rd commentedPatch #4, resolves these issues in admin views module.
#1882634: Redirect loop when resetting admin views filter on D7.18
#1844510: Views "Reset" button causes infinite redirect loop
#1899282: Clicking "Reset" in the node list view results in an endless redirect loop
patch appears to exist in views-dev, so we're (y)
Comment #49
jlongbottom CreditAttribution: jlongbottom commentedpatch worked. thanks!
Comment #50
danyg CreditAttribution: danyg commentedI think it's better to write a custom module than patching the views module.
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 :)
Comment #51
kingswoodute CreditAttribution: kingswoodute commentedSubscribe
Comment #52
Georgique CreditAttribution: Georgique commented@danyg You prefer not fixing bugs but better go around them using custom coding? Strange approach...
Comment #53
danyg CreditAttribution: danyg commented@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 :)
Comment #54
GiorgosK@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)
Comment #55
JSCSJSCS CreditAttribution: JSCSJSCS commentedI 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.
Comment #56
moonshine102 CreditAttribution: moonshine102 commentedHi,
apologize for newbie question, but how I can to apply this patch from post #4?
thanks for your forbearance ;)
Comment #57
JSCSJSCS CreditAttribution: JSCSJSCS commentedMoonshine,
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.
Comment #58
moonshine102 CreditAttribution: moonshine102 commentedthanks 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
Comment #59
GiorgosKPeople no need to patch anything
just download the latest DEV (the patch is included as per #36)
Comment #60
acbramley CreditAttribution: acbramley commented@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`
Comment #61
JSCSJSCS CreditAttribution: JSCSJSCS commented@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.
Comment #62
acbramley CreditAttribution: acbramley commented@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.
Comment #63
tim.plunkettThis is a closed issue. Please discuss this further in the forums if need be.
Comment #64
NMEBB CreditAttribution: NMEBB commentedThank you, #4 worked for me.
Comment #65
kclarkson CreditAttribution: kclarkson commentedI 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 ?
Comment #66
damiankloip CreditAttribution: damiankloip commentedNot sure how this is a redirect loop?! This isssue is closed.
Comment #67
Thanos Lappas CreditAttribution: Thanos Lappas commented#4
worked for me too !
thanks!
Comment #68
NenadP CreditAttribution: NenadP commentedI agree with danyg, I used proposed method (#50) in a custom module, I can confirm it works.
Comment #69
BenMirkhah CreditAttribution: BenMirkhah commentedHad 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.
Comment #70
Stevel CreditAttribution: Stevel commentedWrongly assigned
Comment #71
pschuelke CreditAttribution: pschuelke commentedI'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.
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.
Comment #72
Colin @ PCMarket CreditAttribution: Colin @ PCMarket commentedI am also still experiencing problems with the reset redirecting to the front page.
Comment #73
silentbob CreditAttribution: silentbob commentedSame 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.
Comment #74
dawehnerNeeds review means that there is a patch.
Comment #75
MyXelf CreditAttribution: MyXelf commentedI 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
Comment #76
bcobin CreditAttribution: bcobin commented#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
Comment #77
MyXelf CreditAttribution: MyXelf commented@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
Comment #78
bcobin CreditAttribution: bcobin commentedThanks 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!
Comment #79
campbdy CreditAttribution: campbdy commentedHi,
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...
Comment #80
thalemn CreditAttribution: thalemn commentedI 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.
Comment #81
Colin @ PCMarket CreditAttribution: Colin @ PCMarket commentedSimilar 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.
Comment #82
silentbob CreditAttribution: silentbob commentedDid you clone the whole view or just the display as a page ?
Comment #83
bcobin CreditAttribution: bcobin commentedUsing #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.
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!
Comment #84
silentbob CreditAttribution: silentbob commentedThank you bcobin , this works for me!
Comment #85
McJax CreditAttribution: McJax commentedThanks 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!
Comment #86
imclean CreditAttribution: imclean commentedThe 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
Comment #87
kristygislason CreditAttribution: kristygislason commented33: 1807916-reset-button-fix.patch queued for re-testing.
Comment #89
dawehnerPlease don't open closed issues unless there is a reason for it.
Comment #90
stomerfull CreditAttribution: stomerfull commented#4 working for me too :-)