Exposed filters with remember me does not clear if everything is submitted empty

Subscribe for Views 7.x-dev.
Could this issue have the same root cause as #801868: Fields' Title (sorting) Links does not remember previous filter values?
Both could be refrased as: "Filter is not Remembered when manipulating the page"

Edit: 801868 didn't solve the issue, but revealed that the filter is not cleared in variable $_SESSION['views'][$this->name][$display_id] .

OK, I think my latest "hack" will fix this. I posted the patch to another thread. (And now it looks like it doesn't belong there). You can grab it at: http://drupal.org/node/801868#comment-4330078. merlinofchaos's patch on the same thread is for something else.

Please check it out and let me know.

subscribe

Did you try my patch, mdorrell? Please let me know if it fixes the problem for you.

Yes, I did try your patch, and it seems to be working for me, thanks!

So this is a duplicate of #801868-20: Fields' Title (sorting) Links does not remember previous filter values

Actually, it's not a duplicate. I didn't fully understand what naveen was asking on the other thread, so I mistakenly posted the patch for this issue over there. (Please read my explanation, post #22.)

The other thread is about a bug with sorting, and merlinofchaos has the proper patch for that. Use this patch for this issue.

I see no patch attached.

Also, you don't mark patches RTBC if they're yours. If it's not yours, there's no history here. I'm confused, and suspicious.

Oh I see. You actually linked to a patch attached to another issue.

You've got balls, I'll give you that, marking your patch RTBC. No, I am not interested in adding hidden fields to the query. I specifically remove a bunch of crap from the URL and I'm not adding more.

merlinofchaos,

I apologize for marking the patch RTBC. I should have reviewed the guidelines more carefully.

Could you give a reason for the "won't fix" status? Just because you don't want to accept my solution, that doesn't invalidate the issue that's being brought up here.

This isn't my issue anymore. I've fixed the problem on my sites and I was just trying to be helpful so that hundreds of other people don't have to go through the in-depth debugging like I did to find out what was going on.

jjwhitney, can you post your patch in this issue itself? I was confused, too, mixing up both issues.
Even if the patch is not OK for the final solution, it's a good start.
I'm having troubles with Remember on D7, but I won't reopen this issue until I have tested on the newest Views-dev.

OK, I'm posting the patch here as well to provide clarity. This patch is for Views 6, but it should also work for Views 7. (Both versions suffer from the same problem.) The two issues fixed by this patch are:

#1: For some filters, when blank filter settings are applied, the URL generated looks like: "http://mysite.com/view?". In this case, views doesn't clear the session.

#2: Visiting a view with extra URL parameters causes the filters (stored in the session) to be lost: "http://mysite.com/view?non_views_parameter=something".

(Note of interest): Platforms that have the $_SERVER['REQUEST_URI'] variable (Maybe only Apache?) can also fix #1 by checking to see if the URL ends with "?".

The issue is that it's pretty rare to end up in a state where a submission looks exactly like a non submission. It can happen, but I don't want to add cruft to *all* submitted URLs for this very rare state.

I would have expected this to be a fairly common problem: it will happen whenever all the exposed fields of a view are multi-select options or checkboxes (provided by Better Exposed Filters).

Exposed views consisting of multi-select options and/or checkboxes could be detected, and the behavior in my patch could be applied selectively, but that would just make the code more complicated and wouldn't fix #2 (see above), which allows the developer to use URL parameters for other things on the page. (What happens if there's another pager in a block unrelated to the exposed view, for instance?)

I agree that this is a real issue, and shouldn't be marked at not fixed. I don't like the way that this patch adds a hidden field to every submission, but it works. I'd say anyone having this problem can use this patch, but a different solution would be better for the permanent fix. The problem is trying to figure out how to determine the difference between the form submission, and just linking to the page.

1) Views doesn't offer checkboxes for this reason. That's why I don't have them as exposed options.
2) Multi-select options where no options are selected are relatively rare
3) Especially when there's nothing else in the exposed filter to tag it onto.

Views 2.x is receiving critical bug fixes only, anyway.

In Views 3, for D6 and D7, I'm not really convinced this actually fixes anything, since it doesn't really affect the logic that puts the default values in there in the first place. That's a pretty big code change to fix. I'm just not comfortable with it. Yes I'm aware there's an issue here, but I don't believe this is an acceptable fix, and I'm not sure there is one.

Here's a new suggestion (a feature request, basically) for Views 3. I think a lot of people would love to see support for HTTP POSTs on the exposed filters. The request method could be configured by editing the view or modifying the exposed form programmatically. This would offer the following advantages. (These are off the top of my head, I'm sure there are more.):

1) The URL would be kept clean.
2) The URL could be used for other things. (No one seems to be commenting on the current lack of ability to do this.)
3) Blank filters would no longer be an issue.
4) It would be possible to create multiple exposed filters on one page (without using AJAX).
5) Checkboxes could be included in views. ;-)

What do you think? It seems to me that supporting POST requests could work as a thin layer on top of Views Exposed Fields. Just how hard would it be to work it in?

In Views 3, an exposed form plugin could probably accomplish that, so that's a good place to play with it without impacting current functionality at all.

I might be willing to create a plugin if there's a reasonable chance that it'll be adopted by either Views or Better Exposed Filters. Is there a possibility that you'd merge my code into Views? Also, if you've got any implementation tips, they'd be much appreciated. I've only worked with Views 3 on a very basic level, and I've never written any Views plugins.

There's also the Views Hacks module and the Views Bonus Pack, both of which might be willing to accept such a thing.

I'm not yet sure I think it should be in core Views but I am not against it. I need to think about it.

Go ahead and ask in the various contrib modules if they'd be interested in such a thing, and get back to me on the result?

I posted a feature request for Better Exposed Filters a couple of days ago, but I haven't heard anything back yet, so I'll give Views Hacks a try next.

Just a quick note to mention that I'm considering this for addition into Better Exposed Filters, but have to see how it will jive with the recent addition of displaying exposed filter options as links. I'm guessing they'll be incompatible so you can only get one or the other...

Anyone following this issue is welcome to submit patches on the BEF issue for this topic: #1137720: POST for exposed filters.

Thanks.

jjwhitney, this saved me. Thanks a lot. The frustrating thing is that the problem doesn't even arise in the first place in the views preview display. However, as soon as you try it on the actual view it doesn't work. Fortunately this patch fixed it for me in Drupal 7.

I've been looking for a solution into this and finally the patch in #13 worked for me, thanks!

My use case: I have a list of user activity that you may filter on. The filter is a multi-select dropdown that by default has none of the options selected - meaning it lists 'all' activity. When making selection(s) the list filters to specific activity type(s). The problem was that once you filtered something you couldn't deselect it anymore and go back to the 'all' listing - it would always persist on having something selected. The patch fixes this.

Trivial re-roll of the patch in #13 to fix some code style issues and a PHP notice. #13 seems to work for me as well, though I realize that the issue is marked as "won't fix"...

For what it's worth, I do think this is a valid issue, one I just run over (although I appreciate it was like after a lot of years), but still, and I think it's a good fix.

Patch applies with fuzz but OK to views 3.11, there it goes into my makefile.

#27 worked for me. What a relief. Spent an hour thinking it must have been to do with ajax or auto-submit, but it was just a regular Views bug...

Some work has been done around remember me in #1881910: Exposed filters exclude each other for 3.16 so the patch in this issue no longer applies.

Attached is a rollback for the latest dev.

Although on the related issue, there's a regression reported which needs to be followed up: #2867734: REGRESSION: Single ajax checkbox filters are broken

Oops, type on the patch.

Well, it wasn't quite working with the new additions, so refactored the patch a bit.

I too have a multi select exposed filter which works fine until the user tries to remove their selections and finds that the items are re-selected after submitting the form.

Thank you for providing this updated patch.

Last patch fix issue.

@hanoii Thank you.

I re-open this issue, because the problem still exist.

Maybe add a hidden field is not the best solution but it works.

When updating from 7.x-3.15 to 7.x-3.17 this problem was introduced in my Drupal project (no change in 7.x-3.18 btw.)

Patch #33 works for me.

#33 looks great. Changing the status to RTBC.

I can confirm that #33 works great with Views 7.x-3.18, thanks a lot!

Patch in #33 works well for me too. Thanks very much!

Patch in #33 works well for me, but if I unselect all filters in one action. But if I clear filters one by one it doesn't work (.

See #44.

Patch #33 works for me as well.
Regarding #44, I've tested both only unselecting 1 filter as well as unselecting all filters. In both situations the issue was resolved with patch #33.

So unless #44 can supply us with reproducible steps for his issue I see no reason to mark this as needs work.

When you say the problem still exists, are you using other modules to customize the exposed filters, e.g. BEF? Have you tried views_expost?

Hi! To reproduce the issue in #30 / #44 (including https://www.drupal.org/project/views/issues/2867734) you need to enable 'Use AJAX' on the view.

In these cases the patch does not work because the view still applies filters from $_GET - even if the form was submitted with no filters.

I think the fix is to check the $_POST['apply_filter'] in combination with the $_GET.

I have opened a merge request, using the new process https://git.drupalcode.org/project/views/-/merge_requests/6

But I haven't resolved the issue yet.

Instead of this should we just have a "reset" option to reset the values?

I have updated the merge request: https://git.drupalcode.org/project/views/-/merge_requests/6

It includes the patch in #33 by @hanoii.

I have added a modification to ajax.inc to allow 'blank' filters that have been applied in $_POST to override filters set in the URL $_GET, when the form has been submitted via AJAX.

I came up with this simpler patch.
It works in all cases for me (Ajax/no Ajax).
Please try it.

Can anyone point to a core issue for how this is handled by Drupal 8 / 9?

@Damien
There's an issue here: #1248332: "Remember" feature of exposed filters doesn't work with AJAX and is generally fragile
But it's the opposite: Remember does not always remember.
Anyway, looking at code this doesn't seem to be handled in D8/9 either.