* Create a new view for nodes
* Add a filter for Node: Published
* Make it exposed
* Make it optional
RESULT: The "Published" select box doesn't provide an <any> value such as the one that will appear in the filter form of the view when it's rendered. Same goes for Node: Sticky and Node: Promoted (at least).

CommentFileSizeAuthor
#3 kr313678.patch747 bytesinfojunkie

Comments

merlinofchaos’s picture

Hmm. I can't duplicate this. My Node: Published exposed filter, when set to optional, contains 3 options: , Yes and No. Try this with the -dev version, perhaps? I've done some work on exposed filters in dev, maybe that's why my result is different from yours.

infojunkie’s picture

I tried today's -dev version, but I got the same result. The method views_handler_filter::exposed_translate() does deal with optional params but I wonder if this guarding condition allows boolean filters:

    if ($type == 'value' && !empty($this->options['expose']['optional']) && $form['#type'] == 'select' && empty($form['#multiple'])) {
      $form['#options'] = array('All' => t('<Any>')) + $form['#options'];
      $form['#default_value'] = 'All';
    }
infojunkie’s picture

Status: Active » Needs review
StatusFileSize
new747 bytes

Attached is a patch that illustrates my point, although the UI is not ideal. The patch adds the value 'All' => '<Any>' to the boolean filter if it is exposed and marked as optional. The problem with the patch is that the user must mark the filter as optional, save the change, then click the filter again to see the new value in the drop down. The right code should immediately modify the values on the page.

@merlinofchaos: if you agree that this issue is indeed patchable, then I can work on the better patch.

arhak’s picture

Category: bug » support

+1
This is not a bug, but certainly a "must have"
Many users (on testing sites) complain about not having the chance to select "any", but they can, though it's too complex for a regular user to guess it.
Use case:
- Two filters exposed, lets say Title and Author's name
- To be the simplest say the operator is not exposed, but fixed to "one of"
- The user lands in the view:
--- there is no filter selection so everything shows up
- The user filters by two authors
- The user wants to filter by title without any specific author
--- the user can't figure out how to clear the author's filter, there is no "any" option in the select
--- it doesn't mean it isn't possible, just kind of difficult to doctrine the users that Ctrl key must be pressed to clear the selection of the last author they can't get ride of
- The user leave the page and return to have the filters clear and doesn't forget to complain about it!

arhak’s picture

Title: UI doesn't provide "don't care" value for some exposed filters when they're marked as optional » Provide "any" option in select when exposed filters is marked as optional

shortening the title

infojunkie’s picture

Version: 6.x-2.0-rc3 » 6.x-2.0-rc5

Patch also works in 6.x-2.0-rc5.

merlinofchaos’s picture

Status: Needs review » Needs work

I'm sorry, this patch is a hack. There's a whole ton of other things that have to be considered, and it only does this for one type of handler creating a completely inconsistent environment. If your plan was to do just enough to show it's possible but still make me do all the work, you've failed. You haven't addressed the fact that picking 'all' out of an array is going to cost extra work as well, and this doesn't work for all handlers with a select.

merlinofchaos’s picture

BTW, making a hack as a patch and setting it CNR while admitting it's not a workable patch just irritates me.

infojunkie’s picture

I explicitly said: "if you agree that this issue is indeed patchable, then I can work on the better patch". I never intended to "make you do all the work". So no need to get irritated please :-)

merlinofchaos’s picture

Sorry. The issue may be fixable but I am concerned about the ramifications of doing so. Exposed filters are tricky code, and I did a poorer job of it than I had intended, so there is some spaghetti in there that I'm not proud of. And one of the results is that changes to the code seems to always affect things I never intended.

The result here being: Maybe this is fixable, but be wary.

infojunkie’s picture

Your point is understood. And I should have marked the patch as "needs work" instead of "needs review", sorry about that. I'll give it attention when I can.

mindgame’s picture

I have only used Views 2.0-rc5 and now 2.0 and my boolean exposed filters always had the "any" option, but I think it should be set as default (like in Views 1).

@kratib
I thought you meant that in http://drupal.org/node/308357#comment-1022121

infojunkie’s picture

@mindgame: what I meant is that although the "Any" value appears in the exposed filter on the view, it does not appear in the exposed filter *settings*. This would give the view admin the ability to choose "Any" or "Yes" or "No" to be the default value.

davbusu’s picture

I am having the same problem...

From views_handler_filter.inc

    if ($type == 'value' && !empty($this->options['expose']['optional']) && $form['#type'] == 'select' && empty($form['#multiple'])) {
      $form['#options'] = array('All' => t('<Any>')) + $form['#options'];
      $form['#default_value'] = 'All';
    }

the line

      $form['#default_value'] = 'All';

doesn't seems to do its job.

'Yes' is always being set as the default value when i browse to the page. I tried scrolling through the code maybe to fix it myself but it is too complex for my experience...and from the little I know..I came up with a simple temp solution to set 'Any' as default when the user browses to the page..

I created a file redir.php in the root folder (where there is index.php) and wrote the following in it:

<?php
header("location: index.php?q=membersdirectory/browsebyprofession&1=All&2=All&3=All&4=All&5=All&6=All&7=All&8=All&9=All");
?>

I had fields ID'd as 1, 2, 3... etc (I set these from Views UI)...and I set their value via the URL string..

One might ask why I didn't do them directly from the Menu module in drupal...
It is because drupal outputs the URL string as %asciinumber (for e.g. & => %26) and for some reason they weren't being recognized by the exposed filter..

sorry for my english.. not so good.. I hope this helps a bit until issue is patched..

realityloop’s picture

Version: 6.x-2.0-rc5 » 6.x-3.x-dev

Any option seems to now be present, but doesn't get selected by default

Also, selecting save users last setting doesn't work if any was the last selection

AntiNSA’s picture

Priority: Normal » Critical
Status: Needs work » Active

Please tell me , I have like 5 exposed filters and I need to have the opition to have any in the select list as I have set the filters as options.... can you help me out on this?

Any is not an option for any of my filters but I really need it to be.

merlinofchaos’s picture

Priority: Critical » Normal
Status: Active » Needs work
hypothesis’s picture

I need this as well. A simple "reset" button would work as well as, not selecting any is pretty much the same as selecting all.

Here is a reset button solution, but far too complicated for my tastes:
http://drupal.org/node/99370

Also it seems to reset all exposed filters, not individual ones. Not ideal.

realityloop’s picture

found solution to my instance at http://drupal.org/node/359149
The post title "This worked for me..."

esmerel’s picture

Category: support » feature
Status: Needs work » Postponed

This is a change to the current design (or at least the design at the time this was originally opened). No work has been done on the patch for some time - I'm postponing this until someone steps up to finish the work, or the decision is made to drop it entirely.

merlinofchaos’s picture

Status: Postponed » Closed (won't fix)

I don't believe this is relevant anymore.