Default selections in exposed filters don't persist properly

Remember is absolutely supposed to set a cookie, so I'm not how sure tracing where that gets set will help you. That part is behaving correctly.

When the cookie/value isn't present, then it should indeed use the default setting in the filter, and that may be a bug. I will investigate.

What I experience in RC1 is that the default values are neither kept in the preview nor in the actual view. When enabling the remember checkbox for a filter a cookie is set and the entered values are remembered. Unchecking the remember checkbox resets the filter to no value.

This is still an issue in the -dev version. I can't find any way to get the exposed filter to pick up the default value of a textfield (I haven't tried other types of fields). I've tried checking and unchecking the 'remember' option, but that doesn't seem to have any effect. No matter what I try, I the exposed filter value shows up empty.

I'm using Node:Title and Node:Updated date as tests.

I think this is a bug, I assume if a value is set in the UI it should show up as the default value in an exposed filter.

I've been digging around but haven't been able to find a way to get this working. The only bit of a clue I have is that these values are correctly displayed in the UI, which uses the function show_expose_form() to create the form. That function has a test that looks like it's intended to keep those default values in there.

But when I look at a view with an exposed form rather than looking at the filter data in the UI, that function is never triggered. Instead the form is built using the function views_exposed_form() which automatically sets the values to match $_GET, which is empty.

I see there is a function set_exposed_input() which looks like it might work to get those default values in there, but that function is not used anywhere in the code that I can see.

I'm really not sure what else to try or how this is intended to work.

I think the big part of the problem here is that because of the way $_GET works, I don't think we can tell the difference between didn't send input and erased the input and hit return. It may not be possible to have default input in a textfield.

I think we can tell the difference in the $_GET -- $_GET is completely empty of everything but 'q' before you submit the form. If submit the form with empty values $_GET is not empty, it has keys for all the filters with empty values.

Well, not all; for example, checkboxes that aren't checked don't appear in the query string at all (which is frustrating).

But beyond that, this is something that's happening deep within fapi. I've confirmed and #default_value is getting set, which means the default string should actually be appearing. But FAPI can't really tell if a submit happened or not, so it just thinks a submit happened every time, and it overrides the default value with the nothing value that it 'received'.

The real problem here is that fapi can handle select boxes properly this way, but apparently textfields are another matter.

I'm leery of deciding FAPI can't handle this and peeking into the $_GET values to make decisions, particularly with a system as fluid as this.

I think it's the custom form.inc handling in Views. I played around with it and this patch works for me, but I don't know if it will break something I'm not seeing.

I'm not sure how robust this is. Will it work on page 2 of an exposed filter form? (a page will be set), which will end up in #post, for example.

I don't know either, but the interesting thing is that if you don't artificially put a value into #post the default values work fine. And FAPI isn't doing that, it's being done in Views. But it's still quite odd that select widgets work either way, but textfields don't.

Well sure, the default values work fine...but then you won't get any input. =)

No, the change only affects you if there is no submit, which is when we want to see the default values. If I input and submit a value, it still works and my input value, even if it is erasing the existing value, overrides any default. Or am I misunderstanding something?

BTW, all the form caching makes this really hard to test -- I have to keep checking things in a fresh window to be sure that neither the browser, nor Views, nor FAPI is caching what I'm seeing :(

I think this is more or less fixed in -dev now.