Default option <Any> not set in exposed filters when terms are selected

We had a similar issue and after some tracking down we seemed to find indications that the issue was being casused by this line of code

if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier])) {
  $form_state['input'][$identifier] = $default_value;
}

Amending to

<?
if (empty($form_state['exposed']) && !isset($form_state['input'][$identifier])) {
$form_state['input'][$identifier] = $default_value;
}
?>

resolved the issue not sure if this is the right solution but it appears to 'work'.

The underlying syptom is that even though exposed_translate in views_filter_handler adds the any value and sets the #default to all upon initial rendering this values is ignored and the value stored in $form_state['input'][$identifier] is used.

Patch attached

Same problem here. What I found however is that selecting the "Limit list to selected items" option in the filter gives the expected behavior of Any selected by default. It's only when that option is NOT selected that it seems to give the unexpected result of selecting the first actual item in the list (instead of Any).

Ok, the patch makes no sense.

That particular piece of code is dealing with the fact that #default_value doesn't work entirely as expected during $_GET based forms. So what it's doing is placing a proper default in the input if one doesn't exist. The way that code is changed it basically just deactivates the code entirely, which will break other setups.

I've tried testing this a couple of different ways, and in my tests the $default_value is always being set correctly. In the view that was exported, please note that the fact that you have items selected is causing the issue. Please ensure you do *not* have items selected; selecting items when the filter is exposed sets the default value. Because you can select multiples but the exposed filter form only accepts one, the first one you selected is the default.

I've found about the same problem here.

This is the problem:

1 - I have a profile field defined with one checkbox: Yes / no. That's all.

2 - I have a Views with a exposed filter for this profile field. Filter is set to "optional". Remember is set to "no". No values are selected in the filter config. It appears as two radio buttons, yes/no.

I expect the filter to get all values by default, but when I read the query, I notice this is taking "0" (box unchecked) as default value. This is a part of the query:

WHERE (profile_values_my-value.value = 0) ...

This happens with all profile fields I've defined as checkboxes.

Ah! you just saved me with this "Limit list to selected items" option!

How about being able to select what value(s) are selected to filter the results in the default view? Isn't this badly needed?

Added some help text for this in http://cgit.drupalcode.org/views/commit/?id=24188c4 for 7.x-3.x.

Feel free to provide a patch for backporting to 6.

@colan
Just noticed that help text after updating my 7.x-3.x version..
Uh... It's quite confusing and totally looks weird when using something like BEF.
And there's no way to hide it?

I really don't see how this text is helpful in any way:

As long as this works properly with plain ol' regular Views, I'd recommend opening a new ticket for this in the BEF queue (unless there's one already).

@colan
Even without BEF it looks weird and confusing:

What I mean is that I'm not fond of adding lengthy descriptions that cant be changed (...) to the front end of a website..
Especially if they don't make any sense at all, which is the case here.. How does it even make sense to leave a single select "blank" ?

Maybe there's something else wrong on my site modifying this.. I should check.

After applying the patch from @colan in #10 the description text is showing up on the front end of our application in an exposed filter. Meaning end users will be able to see it. This is happening with and without BEF.

After some digging I believe I found the issue. The description is being added in, but when it hits the exposed_form function in views_handler_filter.inc the description text should be removed for the current exposed element ($this->options['expose']['identifier']).

I'm uploading the patch for your review.

Moving this back to Views until we get it resolved there.

The text -- Leave blank for all. Otherwise, the first selected term will be the default instead of "Any" -- . showed up on my BEF exposed filter when I upgraded to Views 7.x-3.12. As a workaround for now, I am using String Overrides to replace the text with nothing (rather than apply the patch).

I'm also quoting the "Leave blank" text in the comment here so search engines will pick it up. I think this may start showing up widely as people upgrade Views. It took me a while to find this relevant issue.

Just had this issue after upgrading to views 7.x-3.12. The patch from neuquen in #15 appears to work fine.

#15 removes the backend text and realigns the exposed filters but then adds the text "Select terms from vocabulary vocab_name" underneath the filter label, in my instance (drupal 7.41 & views 7.x-3.12).

3.12 is officially broken anyway and has been replaced by 3.13. I suspect that won't last long either if this issue persists. I've reverted to 3.11 in the meantime until I get a chance to test 3.13.

It would appear that the messages appear on the front end with 3.13 as well so will stick with 3.11.

I am having the same issue, not just with one site but multiple sites all doing the same thing. Leave blank for all. Otherwise, the first selected term will be the default instead of "Any"

Other than this being annoying it does not seem to break any functionality. yet.

I can confirm that since upgrading to 7.x-3.13 I also get the message "Leave blank for all. Otherwise, the first selected term will be the default instead of "Any"" next to BEFs. Tried updating BEF to current Dev version, did not help.

Will revert Views back to 3.11.

Update to 7.x-3.13 and getting description too.

Just for the test i added some other description in BEF and it displays ok (i tried random text, then tried "< blank >" and got same error on both occasions, altough "< blank >" works and hides the description.

Error:
Notice: Undefined index: vid in better_exposed_filters_exposed_form_plugin->exposed_form_alter() (line 990 of \sites\all\modules\better_exposed_filters\better_exposed_filters_exposed_form_plugin.inc).

This update (adding the text "Leave blank for all. Otherwise, the first selected term will be the default") caused regression on existing sites, by displaying new, un-modifiable text, where previously there was none, and breaking the layout of previously-themed forms.

Regression introduced here:
http://cgit.drupalcode.org/views/commit/modules/taxonomy/views_handler_f...

Editing the 'description' by way of views UI just appended to it and there seems to be no clean way to make this set text go away now.

@Jedd Casella

My patch does not add any new text. It only unsets the description text so that text must be coming from somewhere else in your code.

My clients just noticed this and started complaining. I patched Views, removing the #description array element.

I solved it by removing line 198
'#description' => t('Leave blank for all. Otherwise, the first selected term will be the default instead of "Any".'),
from modules/views/modules/taxonomy/views_handler_filter_term_node_tid.inc

Yep, this description has to go.

A even bigger bug is that the description I can add to a view filter via the UI, it does not replace the description but adds another div to it.

#28 the best way to remove this bag

#28 solves bad appearance of views.

Had the same problem. Introduced since views 7.x-3.12 I think. Should be applied to latest version and -dev also, IMHO. I hate to patch sources :(

Documenting this this way is an arguable win, but it should have been conditional that I'm in the admin UI. (The opposite of what the "Fix" in #15 is doing.) The message is for that one form, it should be added for that one form, not added universally, then removed for exposed forms. Hypothetically I could be reusing filters' form elements from within a complex template and not via exposed filter form, and it shouldn't show up then either.

It's pretty disappointing that for such a high profile contrib module, this change made it straight into a stable release without getting caught, and remains in the current stable release without a fix several months after its introduction when it is so easy to improve. Even if an improved solution was complex it could easily and immediately be reverted while the improved solution is developed.

I don't like it, but everything else in here seems to assume a duality between exposed form|options form and I won't fight that, so I placed this in an existing conditional, preventing it from appearing on exposed forms.

And here's a patch from scratch, attempting to follow d.o's standard and make the test bots happy.

Should there be any any question of applying this, please do not delay and please instead apply the revert patch above. There is no excuse to nitpick and leave people's sites broken.

#28 fixed it for my. wow upgrades today followed by more patches.

Instead of haking views it's better to remove this new unremovable description in a custom module.

This is my temporally fix:

/**
 * Implements hook_form_alter().
 */
function YOURCUSTOMMODULE_form_alter(&$form, &$form_state, $form_id) {
  switch ($form_id) {

    case 'views_exposed_form':
      // Temporally fix BUG: https://www.drupal.org/node/339384
      foreach($form AS $key => $element) {
        if (is_array($element) && isset($element['#description'])) {
          unset($form[$key]['#description']);
        }
      };
     break;

  }
}

Patch in #36 confirmed as a working solution

I was finally able to reproduce this. I committed #36 with an added comment.

Let's do the same for D8.

Yeah, that totally makes sense. For now adding new strings is probably more of a 8.1.x issue ...

The patch in #36 appears to be working for me.

@donaldp that is good to hear because it has been committed.

Committed/pushed to 8.1.x, thanks!

I think adding strings is probably OK in patch releases - it doesn't require a re-translation, just a new translation, and a single untranslated string in the Views UI isn't going to notice much, but for now moving to 8.0.x and leaving RTBC in case I've got that wrong.

I've seen other issues which allowed string additions, though I don't remember which ones.

Yeah I think it's fine, we should document this better though.

Cherry-picked to 8.0.x, thanks!

The patch at #36 results in notices from better_Exposed_filters

Notice: Undefined index: vid in better_exposed_filters_exposed_form_plugin->exposed_form_alter()

Nevermind, there was stil a space left in the better_exposed_filter description, removing it made the notice go away