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 example_required_handler_string.view.inc 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 example_required_handler_in.view.inc 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).

CommentFileSizeAuthor
#10 1169092-port.patch1012 bytesdawehner
#3 1169092.patch918 bytesdawehner
#1 definition.patch604 bytesdawehner
example_required_handler_in.view_.inc_.txt5.88 KBbecw
example_required_handler_string.view_.inc_.txt5.99 KBbecw
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
FileSize
definition.patch604 bytes

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.

becw’s picture

becw CreditAttribution: becw commented

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.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Active » Needs review
FileSize
1169092.patch918 bytes

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.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

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

becw’s picture

becw CreditAttribution: becw commented
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.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

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

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Status: Reviewed & tested by the community » Fixed

Committed!

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
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

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented

Yes, no red box is probably better.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Patch (to be ported) » Needs review
FileSize
1169092-port.patch1012 bytes

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

nodecode’s picture

nodecode CreditAttribution: nodecode commented

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.

Chris Matthews’s picture

Chris Matthews CreditAttribution: Chris Matthews as a volunteer commented
Status: Needs review » Closed (outdated)

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue

stiras’s picture

stiras CreditAttribution: stiras commented

Thanks to dawehner for his solution - it worked for me!