For Views filter handlers, setting the exposed filter "required" option to true has no effect, or an unexpected effect. Two examples:
- 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 attachedexample_required_handler_string.view.inc
demonstrates this with an exposed node title filter. - 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 attachedexample_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).
Comment | File | Size | Author |
---|---|---|---|
#10 | 1169092-port.patch | 1012 bytes | dawehner |
#3 | 1169092.patch | 918 bytes | dawehner |
#1 | definition.patch | 604 bytes | dawehner |
example_required_handler_in.view_.inc_.txt | 5.88 KB | becw | |
example_required_handler_string.view_.inc_.txt | 5.99 KB | becw |
Comments
Comment #1
dawehnerAbout the first view, after a while i found out the problem:
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.
Comment #2
becw CreditAttribution: becw commentedAs 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.Comment #3
dawehnerAs 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.
Comment #4
dawehnerThe #required message isn't displayed at the moment, but i have no idea why.
Comment #5
becw CreditAttribution: becw commentedThe 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.Comment #6
dawehnerIf you try it out you will see no "red box", but this seems to be wanted.
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted!
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedDoes this need a backport? cherry pick hash is 7aabc31
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedYes, no red box is probably better.
Comment #10
dawehnerOkay here is the patch backported. Some review and testing is highly welcomed.
Comment #11
nodecode CreditAttribution: nodecode commentedI'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.
Comment #12
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedThe 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
Comment #13
stiras CreditAttribution: stiras commentedThanks to dawehner for his solution - it worked for me!