[Regression] Views 7.x-3.13 added a hardcoded exposed filters description text

I have the same problem.

See #339384: Default option <Any> not set in exposed filters when terms are selected

Not using BEF on my current project, but I think it's that Views appears to be adding a default #description value for a taxonomy term node TID filter, so when you expose it the text you referred to is displayed, unless you are already removing descriptions from your form elements (where it won't show).

Being time poor right now my rapid solution was to add in an exclusion of showing the $element['#description'] value in my implementation of theme_form_element(). Alternatively you could modify this in a hook_form_alter() or theme_select() for instance... If anyone has a more robust solution then please share, otherwise I think this is just something that may have been added to the recent Views update that seems a bit incorrectly getting through to display or geared towards a UX decision...

Modifying via an exposed_filter_form preprocess might be a preferred approach or if you can do it via BEF. Hope that helps.

Thanks,
Luke

Yes - this was introduced by a commit attached to that issue, as linked to at https://www.drupal.org/node/339384#comment-10548388
Described as

Issue #339384 by colan: Added help text to keep the exposed filter terms list unset to keep unfiltered "Any" option default.

We are not using BEF(?), and just did a standard Views version upgrade to see this turn up.
Yes it would be nice if there was a non-hacky way to make this not happen.

Yep, manifesting on multiple projects after upgrades for me also. Dreadful.

It would be great if this text had an opt-in sort of option or something, if not just plain being removed... It wrecks layouts because it's so long, and it's confusing and not intuitive for users. Most computer dummies don't even know how to leave a select list blank by toggling a select list item off if something is already selected, and in many situations plain old views doesn't even have the "Any" option mentioned in the text.

As a basic suggestion, I think the Exposed filter description should override it and not just appear underneath this text, as then at least we'd have a quick hack to just add a space to the description or something to get rid of it.

For those that want this left blank, the above is what you need to do with BEF to override it if you just want it gone and not replaced also, add a space to the description.

I simple return to view 3.11 and work fine. The problem is in view 3.13.

See my patch from #15 #339384: Default option not set in exposed filters when terms are selected. I found this issue over a month ago and unsetting the description in exposed_form fixed it for me.

This is a Views issue.

Can we put this to major? This has the potential to ruin the layout on front end exposed filters on 850.000 websites..

Instead of removing it, why don't put configuration option to show or hide this description. Put it as default, but can hide it.

Instead of removing it, why don't put configuration option to show or hide this description. Put it as default, but can hide it.

That would be fine with me, as long as by default, it is disabled, so this is backwards-compatible. If people feel the same, change this issue to a Task and retitle it.

Configuration options like that only bloat the software.

The description doesn't even make sense to me in case of a single select,
and "leave blank" is kinda vague. Could be improved

I concur with cilefen.
Otherwise, remove altogether, please.

IMO: added value is minimal from usability point of view.

It has been fixed already in #339384: Default option <Any> not set in exposed filters when terms are selected

@cliefen: please don't change the status of this issue. You say this was fixed in #339384 but this other discussion just contains some wayarounds. While these wayarounds work fine this is not something that we, developers, are gonna apply to all million running Drupal sites to just get rid of this text.

This issue still remains active and will we considered fixed when new views-7.x-3.14 is rolled and the problem is gone from it.

@pawel.traczynski it was indeed committed. I won't argue with you.

@pawel.traczynski Can you suggest what other work is needed on this issue?

The reason I marked it fixed is because that is the usual procedure as documented in Status settings of issues:

Fixed (#)
The issue has been resolved (usually by committing a patch). Issues that remain in this state without any additional comments will automatically be set to "closed (fixed)" after two weeks. This gives interested parties time to reactivate the issue if they see a problem with the fix and also allows time to see that a change has been made.

So issues are marked "fixed" regardless of release status. Here is the commit that fixed it. It may be that what we need is another issue to prepare the 7x-1.4 release, maybe marking it Critical. This one should be closed as a duplicate, like I did in #15.

I could be that I am wrong and this is not fixed. We can check that by trying the 7.x-3.x-dev release.

I updated the prior comment with the correct commit, which was https://www.drupal.org/commitlog/commit/1174/e5c8b65610fbfb93215466c2f23...

I see. Thanks for all these explanations.
Anyone knows when fixed release 3.14 is gonna be published and recommended? :)

As @cilefen's comments, a patch has been committed that fixes this and so this problem is solved in 7.x-dev (I used 7.x-3.13+29-dev to solve this). Release of 7.14 does not block this from being "fixed".