For Views filter handlers, setting the exposed filter "required" option to true has no effect, or an unexpected effect. Two examples:

  1. The views_handler_filter_string filter handler forces the exposed filter to be required; however, a View with an exposed string filter will return results even when no default value is set and the exposed filter is empty. The attached demonstrates this with an exposed node title filter.
  2. When a filter using the views_handler_filter_in_operator handler is set to "required", the view automatically returns results using the first filter option, even when no default value is set in the filter configuration and the exposed filter is empty. The attached demonstrates this with an exposed node type filter.

If this is an issue that needs fixing, I'm willing to write, review, or test a patch, but it is unclear to me where in the execution of a view this should be checked. It seems that the "Input required" exposed form plugin addresses part of the issue by requiring a user to click the exposed filters' "apply" button before displaying results, but it does not require a value in the exposed filter forms, and there is still a 'required' checkbox on most exposed filter configuration forms (and in many existing exported View configurations).

#10 1169092-port.patch1012 bytesdawehner
Test request sent.
[ View ]
#3 1169092.patch918 bytesdawehner
Test request sent.
[ View ]
#1 definition.patch604 bytesdawehner
Test request sent.
[ View ]
example_required_handler_in.view_.inc_.txt5.88 KBbecw
example_required_handler_string.view_.inc_.txt5.99 KBbecw


new604 bytes
Test request sent.
[ View ]

About the first view, after a while i found out the problem:

$handler->display->display_options['filters']['title']['expose']['required'] = FALSE;

In general i don't know how you managed to set the flag , but this patch fixes the problem, already commited.

If you want to require input you should use the exposed form plugin for input required, not put this in the general handler, because
this is indeed a valid use case.

As far as I can tell, the "input required" exposed form plugin just requires that the user click the "apply" button before results appear; it doesn't actually require any input. Additionally, exposed filters still have a checkbox labeled "Required". If this checkbox doesn't do anything, should it be removed?

p.s. The view in example_required_handler_string.view_.inc_.txt is exactly as exported by Views--so if the 'exposed' flag is set, it's because of the standard Views export process.

Status:Active» Needs review
new918 bytes
Test request sent.
[ View ]

As earl said on irc there should be no error message if a filter is required but it's empty, because you apply this form by simply browsing to the url.

So the question is just, what should happen once you input nothing. It should display nothing.(the empty text)
For a string textfield this means that unless you add something to the textfield you don't get any results.
You can achieve this using #required

Additonal this patch takes care that the #required value is always stored as expected.

The #required message isn't displayed at the moment, but i have no idea why.

Status:Needs review» Reviewed & tested by the community

The patch in #3 works for me. When #required is set on a form array (rather than a specific element), form_set_error() is called with an empty message(s). That should be fine in this case.

If you try it out you will see no "red box", but this seems to be wanted.

Status:Reviewed & tested by the community» Fixed


Version:7.x-3.x-dev» 6.x-3.x-dev
Status:Fixed» Patch (to be ported)

Does this need a backport? cherry pick hash is 7aabc31

Yes, no red box is probably better.

Status:Patch (to be ported)» Needs review
new1012 bytes
Test request sent.
[ View ]

Okay here is the patch backported. Some review and testing is highly welcomed.

I'm guessing the D7 patch needs to be rewritten for the latest dev version. I'm coming from #1877678: Exposed filter gets error class without submitting it, which, once it's committed, will re-expose this never-fixed issue. This is just a heads up. I'd suggest waiting until that issue has been committed so we can actually see the issue and test the patch here.