Fields' Title (sorting) Links does not remember previous filter values

Afaik views does not store the input in the exposed filter. It uses url parameters for this.
If you disable javascript on the view, you will see urls like http://views.dev/mynodes?type=story

5. Now visit the views page again (example_view) - (Don't refresh, make sure the url has no query params)

If you remove the query params views cannot know anymore that there are an selected filters.

All in all i would say this is a behavior by design.

naveen did you ever find a solution? if so please post it so others can benefit.

I created a screenshot of the error and exported a view that corresponds. Sorry for the squiggles.

I talked with merlinofchaos on irc, and indeed the values are supposed to be stored in the session, and the form is only supposed to change when it thinks it has received new values.

Assigning this to dereine. Dereine, re-assign this to merlinofchaos if you can't figure it out.

The remember feature is just part of the exposed forms.

The sort remembering is done with the url.

I'm wrong, sry

When you re-sort, all of the filter values are supposed to be included with the sort. "Remember" isn't actually at issue here. Maybe the filter values are not properly making it into the sort.

Following up on merlin's comment we

Need to check the query params that are in the actual sort click. It *should* include the 'current' filters (Regardless of the remember setting).

A very simple manual testing worked fine here

Need to check the query params that are in the actual sort click. It *should* include the 'current' filters (Regardless of the remember setting).

As you see on http://drupal.org/files/issues/returned.jpg the page url is changed. Then the sort link can't be build right.
So it's somehow works like expected

I've run into this bug, too. This is triggered when URL parameters for one exposed filter cause $_SESSION parameters in another filter to be ignored. Notice "type=sponsor_carousel" in "pickedsomestuff.jpg" and then "order=title&sort=asc" in "sortsto.jpg". I've made a patch which makes sure $_SESSION parameters aren't ignored (unless, of course, they really are overwritten by a URL parameter).

BTW, you can replicate this on any exposed views by simply going to the view and giving the URL a single "junk" parameter like: ?testparameter=forget_all_my_session_parameters

Subscribing.
Could this issue have the same root cause as #1080164: Exposed filters with remember me does not clear if everything is submitted empty?
Both could be refrased as: "Filter is not Remembered when manipulating the page"

@johnv
So please try out the patch. This is an important part you can contribute to the project.

This patch works fine in D7,too, without side effects. ==> RTBC

Some remarks for future reference:
- It does not solve the issue 1080164 i mentioned in #11.
- This issue contains an exposé about the filters: #968984: Exposed Filter in Embedded View not working

Please use proper code style

+      if (!empty($_SESSION['views'][$this->name][$display_id])) {
+        foreach ($_SESSION['views'][$this->name][$display_id] as $param => $val)
+          if (!array_key_exists($param, $this->exposed_input))
+            $this->exposed_input[$param] = $val;
       }

If you don't use "{}" it's easy to produce new bugs in the future.

Voilá

No, this patch can't work, because for empty filters the browser will sometimes not post a value.

Try it with a string filter of some flavor. Set it to remember. Type in some data. Now remove that data and submit -- you can't remove it.

Good point, merlinofchaos. (Thanks so much for all your Drupal work, BTW. You're really incredible!) Would it make sense then to change things so that the browser _does_ always post a value? Even for empty filters? Another possibility would be to simply clear the session variable when a new filter is applied.

Thoughts?

I have applied the patch anyway, because the process is better then before.
Indeed, sometimes an empty exposed filter is not cleared, as was reported in #1080164. I tried to track it down, and got this far:
- filtervalue is taken via _build() and accept_exposed_input() from $this->validated_exposed_input.
- $this->validated_exposed_input is set in exposed_validate() from $form_state['values'].
- But in triggering function exposed_form_submit(), $form_state['values'] is already populated, and not cleared!
This is as far my 'root cause' goes. I cannot find where $form_state is populated itself.
I tested with views_handler_filter_term_node_tid.inc

merlinofchaos: I'm running into the issue you brought up even without my patch applied. Some filters don't add any parameters when they're left blank, so it's possible to click "apply" and get a url without any parameters (a single "?" appears at the end of the url). In this case, view.inc thinks that it needs to load data from the session. (This makes it impossible to "clear" the filters.)

After taking a long look at this, I've come up with a simple hack that solves both problems at once. I've introduced a URL parameter that is sent every time the filter is applied. This way, we can know for sure whether the filter values should come from the URL or the session. There's probably a more elegant way, but I'm not very comfortable with making Views modifications. It's too easy to cause accidental side-effects.

Please test and let me know if this patch works. Thanks!

Hmmm... I already found one small problem with my patch: VBO chokes when exposed_input is null. I've fixed that now. Check it out!

What's funny about this entire thread is that I was exactly right about what was wrong in #7, but somehow nobody actually investigated it.

Views uses a technique in multiple places to ensure that exposed filter data gets through -- it needs to do this for a lot of things, not just tablesorts. The data is available and can be added to things like the pager and query parameters for summary links.

It turns out, it wasn't being added in tablesorts at all.

This was broken in the pager, too, and nobody noticed, so when I went to the pager to use the same technique, that wasn't working. If my comments in #7 had been taken seriously, and that path investigated, we probably would've found this other pager bug months ago. I realize the comment itself was kind of terse, but nobody actually asked what I meant, either. Oh well, so it goes.

So I have fixed both, committed and pushed. The patch used is attached, just so you can see what I changed.

merlinofchaos,

It looks like your patch fixes a completely different issue than the one I was trying to address. My patch fixes the problem where Views (all versions) is confused about whether the URL parameters contain updated filter values. The latest, #20, really solves two issues at once:

1: 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". (This is the problem addressed by my initial patch.)

2: 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 (e.g. http://drupal.org/node/1080164)

My fix probably doesn't belong in this thread, so in the future I'll be posting to http://drupal.org/node/1080164. Thanks!

Thanks jjwhitney, your patch in #20 works for me, solved the issue with filters stored in the session being lost - using Views 6.x-2.12.