Views exposed text filter set to required shows an empty error and form error on page load

This is still an issue, and it affects the Views admin UI too

I assume this is done for a reason, I just have no idea why and what will break when you leave it out. But leaving out setAlwaysProcess() does solve this issue.

I had a conversation about that quite recently. The proposed idea was to add an _parameter to the exposed forms. Once you have that, you can detect really easily whether a exposed form was submitted or not. On the other hand, the URL structure changed to: ?foo=bar&_=

Unfortunately, removing or disabling ->setAlwaysProcess() as per #3 is not the way to go - this setting is needed to pass query values along to the exposed form. Without it, the filter input fields remain empty.

Okay, after some digging around it seems this is due to a required filter (in my case, the search keys) on the View. As the form already gets processed on load, this creates a validation error. I see two parts to this issue:

1. The form is validated even though we have no input yet.
For this, I suggest implementing/overriding exposedFormValidate on \Drupal\views\Plugin\views\exposed_form\InputRequired to remove the unhelpful error (d'uh, yes we have not submitted yet, because we just loaded the page!):

  /**
   * {@inheritdoc}
   */
  public function exposedFormValidate(&$form, FormStateInterface $form_state) {
    parent::exposedFormValidate($form, $form_state);

    if (!$this->exposedFilterApplied()) {
      // Clear validation errors when filters are not yet applied.
      $form_state->clearErrors();
    }
  }

2. The validation error message is empty.
As for this part, I am unsure where the error in question is set, and why its message is empty in the first place.

Hello,

The bug still exist in Drupal 8.2.6

Can we hope a patch?

Thx.

Somewhat mitigated by only showing for the first uncached page view, but still present in 8.3.x.

I've attached a patch for my suggestion in #9. This will remove all validation errors that are displayed before any filtering was applied. I don't think this is the best solution to the problem, but for now it may help some of us as a temporary solution.

The empty error is triggered in Drupal\Core\Form\FormValidator.php, Line 303: $form_state->setError($elements);

Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase::renderExposedForm() sets $form_state->always_process to TRUE no matter if the exposed input is empty or not.

The patch checks if the exposed form filters pass any value and sets $form_state->always_process to FALSE if there is no exposed input.

Hmm I just bumped into an issue with this patch when viewing the Redirect module's overview page. I discovered that this patch adds a default WHERE clause for "source LIKE '%%'" causing the view to initially show nothing.

Upon actually submitting the exposed filter, it does show all results as it ignores the empty "source" field...

On the other hand, it does seem like the opposite of a search, where you'd expect the user to actually enter a keyword before showing anything...

To me, the "required" checkbox on the exposed filter field implies that only these exposed filters can influence the behavior of this patch.

Patch in #16 solved the issue for me.

The patch in #16 resolves this issue on one of our projects. It still applies, but the tests need to be fixed for it.

This patch removes the error message, but I believe it also breaks the functionality of the "Required" filter setting, at least as far as I understand it.

If a filter is required, I would assume that no results are shown until that filter is populated and submitted. That is the way that this functionality works in core currently. With this patch applied, all results are returned on initial page load (when the filter is not populated).

What about this patch? It only checks for required filters, which is where the issue is.

Oops, bad diff.

Ah, 8.6.7 had some changes here, so here patch rolled against 8.6.7.

Since this code only affects the \Drupal\views\Plugin\views\exposed_form\InputRequired plugin, I'd much prefer to have the code in that class instead of the base class. We should probably override ExposedFormPluginBase::exposedFormAlter in there. Is it okay to run this logic after the pager plugin has been called (i.e. just call parent::exposedFormAlter), would it be enough to simply build the pager a second time, or do we have to make the changes in between the base functionality and the pager?

We applied the #27 and the error still appear for us

Whats going on peps? I did a patch that could resolve the problem for a while if you guys are needing, but I will leave the status as "needs works". The solution for our problem might be in this file

Switched to 8.7.x-dev, as it's still a problem as of 8.7.2. I had success with patch 16, but not patches 27 or 31.

I have the same problem :(
Has anyone found a way to fix it?
I see that all proposed patches has failed - has anyone found a solution with a clean patch?
Thanks!

I have not tested any of the patches yet, but I'll add that hiding the warning/status messages block on an individual View page is a workaround I have used. Seems like this doesn't work as I originally thought.

Anyone? Please :)

I have finally found a solution that seems to work just fine. I used the patch of user dawehner, suggested at: https://www.drupal.org/project/views/issues/1169092#comment-4932422

It should be noted that the suggested code has already been included in D8 (in /core/modules/views/src/Plugin/views/filter/FilterPluginBase.php), but in a little different way. I had to "reverse" the code back to the original suggestion of dawehner (switching required with optional, etc.) and it worked for me.

I hope that's a permissible way to do it and that it would help others :)

@stiras
Can you share a patch? Still having this problem in 8.9.13

Hey markdc, I am still having this in 8.9.16 so I am sharing a patch that fixed for me.

Here is the patch that fixes the few failed test cases for #41. Trying to fix remains as well.

Patch #41 is applying and working for me on D9.2 while with patch #42 I reproduce the same behavior as without the patch (blank error message and form input with error class on first page load)

On 9.3.6, neither #41 or #42 is working for me.

#41: Result is the same as if the field was not required.
#42: Does not fix the issue (empty error still displaying)

Just ran into this. The fail-only patch looks good, however the patch in #42 while it removes the message, doesn't remove the failed input red outline on the form field.

However, in my case I also realised that I didn't want to make the exposed filter field required at all, but instead wanted to use the 'input required' exposed form plugin.

So I kind of wonder if we should consider deprecating 'required' on text input filters, and pointing people to that plugin instead, or at least I'm struggling to think of a views use-case where the latter isn't a better option.

Just tried the patch. Breaks a ton of our other views, so that doesn't work out unfortunately as any view with filters that has no filter values entered breaks.

EDIT: sorry it's late and that's a very vague term "breaks". All other views with exposed filters, including /admin/content do not display any content until a views filter value is entered. So this affects EVERYTHING, when really we just want to not throw an error for required elements.

Updated from #42 and test cases from #47

Applied patch #57 on 9.5.x.The error in the view page is gone.But I'm still getting error in the view preview.

After patch view preview:

what about this one/

I've tested the patch in #60 and it's working for me.

Here's what I did:

1. Install Drupal 9.5.x
2. Go to Structure > Views (admin/structure/views), locate the view named Content and in the Operations column, select Edit.
3. In the left column of the view, under Filter criteria, select Content: Title (exposed), which opens a modal window to configure the filter criterion.
4. In the Configure filter criterion, select the checkbox "Required" (it should be checked) and select the Apply button.
5. Scroll down to the Preview section and see that there is an Error message displayed and the Title filter field is outlined in red.
6. Save the view and select Content from the administrative menu (admin/content). Notice that a blank Error message is displayed and how the Title field is outlined in red.
7. Apply the patch in #60.
8. Refresh the Content admin page. The error message is gone and the Title filter field is not outlined in red (appears normal) and there is a red asterix next to the title indicating the field is required. Click the Filter button and (in Claro theme) get a Javascript pop-up that says "Please fill out this field."
9. Return to the editing the Content view (step 2). Notice in the Preview, there is no longer an error message.
10. Repeated testing after clearing cache. Same results.

This patch could still use a code review, so keeping at Needs review.

working on this

Verified and tested patch #60 on Drupal 9.5.x-dev. Patch applied successfully and looks good to me.
Testing steps:
1. Goto admin/structure/views/view/content
2. Select Content: Title (exposed) from filter criteria.
3. Select Required.
4. Click on Apply.
5. Scroll Down.
6. Observe that the Error appears and the Title filed is outlined in red.
7. Apply the patch.
8. Now refresh the page.
9. Observe that the Error is gone and the Title field has a red Asterix mark.
Testing Result:
1. After applying the patch the Error is gone and the Title field is not red outlined.
Can be move to RTBC

Sorry, I don't agree with putting this to rtbc.

+++ b/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php
@@ -246,6 +246,29 @@ public function exposedFormAlter(&$form, FormStateInterface $form_state) {
+      if ($handler->canExpose() && $handler->isExposed() && !empty($handler->options['expose']['identifier'])) {
+        if ($handler->options['expose']['required'] && $handler->options['plugin_id'] != 'boolean') {

I'm not happy with the complexity here, but I don't see quick wins to make it better.

I would like it if we have strict comparison here though, I think that is needed. (!== instead of !=)

also I personally prefer it if we are more specific (so: $handler->options['expose']['required'] === true), but not sure what coding standards about that say.

Fixed the !== part. Added some comments too

Didn't ad the === TRUE because that actually broke it.

Back to rtbc with those remarks fixed. The functionality was tested in #62 and #65 already.

Adding credit for @Scott Weston as he worked on patches of a duplicate issue (#3076117: In View, Keyword Search filter's "On empty input" setting appears to have no effect.) that was closed in favor of this one. Thank you for contributing to improving Drupal, Scott!

This looks good to me now.

Committed/pushed to 10.1.x, cherry-picked to 10.0.x and 9.5.x, thanks!

At first I thought I was having an issue with Geofield but ended up here, it may still be Geofield. I've the latest updates for 9.5. Double checked updates for today and all are up to date.

Still getting error message for admin and public. The image shows two error messages because 2 view blocks on the same page using the same filters.

This has been reverted from all branches and reopened due to the regressions found prior to releasing Drupal 9.5.0 and 10.0.0:

#3327193: Regression: Views with exposed filters which are required need the apply button pressed to show results
#3313067: Fix behavior of required Views input fields in search forms

Here's some more info on the regression this caused so if people try to work on this again then we need to be sure we don't break this:

Steps to reproduce:
1. Install standard
2. Create a node of each type available (i.e. page and article)
3. Edit the content view (admin/content) and change the exposed node type filter to required and select the page and article content types.

With the change in #67 applied you will see both the page and article nodes. On HEAD (9.5.x and 10.x) you will just see the article node because the select node type filter has been applied as you would expect because the dropdown only list article and page and one has to be selected...

I can see that in Drupal 9.5.3 the patch is already included in core, but I still see problem.

I'm using the most recent version of 9.5, and I still experience the empty message issue.

Edit: Ah, I see the commits were reverted.

I modified the previous patch to only exclude required exposed text filters from auto processing. I only excluded 'string' and 'combine'. I'm not sure if there are other text plugin ids that should be excluded as well, but these are two that I came across when I encountered this issue. I did verify this does not cause the regression outlined in #77.

The MR fixes the issue I was seeing.

Can MR be updated for 11.x as the latest development branch

Also will need test case showing the issue

I found this problem also occurred with a webform plugin we were using and decided hard coding the plugin id types was a bad idea. So I reworked the patch to just test for any input regardless of plugin type. I also moved the code outside of the reset button condition so that it works when the form does not contain a reset button. This does not cause the regression in #77 as it's looking at the form state for the input values instead of the view.

I also added a test to demonstrate the problem, however, I don't have much experience with tests so if I need to change anything let me know. Opened a new merge request for 11.x, I don't think I have permissions to close the other one.

Seems the update caused a few tests to fail.

Haven't tested the new solution but it should be checked against media library as that's where the tests appear to be failing

Thanks for picking this up.

Ok, I added back the boolean plugin exclusion you had in there before. I don't quite follow why that value isn't in the form state, seems to be a behavior of the status or admin media filter, but that passes the tests anyway.

Reviewing MR 4560 for 11.x

Followed the steps from #77 for the regression that was found
With the MR applied I'm only seeing Article node

I think the test should be updated though to match that scenario, to show that the required filter runs initially.

Thanks and good work!

Ok, I have added the regression test as well.

Thanks for expanding the test coverage. Think this is ready for committer review.

I'm triaging RTBC issues. I read the IS and the comments since the revert and didn't find any unanswered questions. It would help if the proposed resolution explained how the error message would not be shown. I found that in #88.

Thanks for working on this! I do enjoy helping to complete long standing issues.

I read the MR and tested locally. I make some comment in the MR about that. One of those is about testing and because of that I am setting this to NW.

I followed the steps to reproduce in #77 on HEAD and get this error, "The submitted value All in the type element is not allowed.". That error does go away when the MR is applied. However, a check should be made to see if there a duplicate issue about that error. I am not able to do that now.

I could not find an existing ticket about that error.

I added info from #88 to the IS

I ran into the issue in #95 while writing the tests and I don't think it's related to this issue. I think it should be opened as a separate issue as it happens when a filter is required but has the "All" option checked for checkbox options.

Thanks @solideogloria ! Restoring status.

Thanks for following up on #95.

From #95,

I make some comment in the MR about that. One of those is about testing and because of that I am setting this to NW.

Unfortunately, it seems that I did not save those comments. They are saved now. And this is now back to Needs work. Sorry about the delay.

Also, can someone explain which MR we should be using, and maybe hide the other one?

This also doesn't apply to Drupal 10.2, so Needs Reroll

I made sure that the problem in #3327193: Regression: Views with exposed filters which are required need the apply button pressed to show results doesn't happen (I ensured that the required filter doesn't mean that Apply has to be clicked to see the results if the filter already has a value selected). That's the reason for the third test.

The reason for the tests should also be a bit more clear in the code's comments now.

With the fix removed these are the only two assertions in the test that fail. The assertions later in this test pass. I think that requires investigation to make sure the test is doing what it should be.

I understand that the third test passes without the code changes. However, this is just a test added to ensure that future changes to the code don't break this functionality, per #92.

@quietone The MR says there are still unresolved threads, but they were fixed in earlier commits on the MR. Can you mark them resolved? Thanks.

https://git.drupalcode.org/project/drupal/-/merge_requests/4560#note_251278

i am getting error after applying MR #102. This says that the file is no longer exists in drupal 11.x-dev

STR:
1. Goto admin/structure/views/view/content
2. Select Content: Title (exposed) from filter criteria.
3. Select Required.
4. Click on Apply.
5. Scroll Down.
6. Observe that the Error appears and the Title filed is outlined in red.
7. Apply the patch.

SS

It appears the file was renamed. It is now "test_exposed_form_required_filters.yml". You probably need to update your config or reset your dev environment. It's fine for me.

Try deleting the old file prior to patching. There aren't any references to it in the code, so it's something wrong with your setup.

This actually pertains to code in the views module, not views_ui.

MR feedback appears to be addressed and does address the issue described in the issue summary.

I pushed a minor fix to comment phrasing (didn’t accurately describe the code) and code style (unnecessary check for !$form_values combined with empty()).

However, my actual problem with this MR goes much deeper: it seems to actually break the “Required” functionality of exposed filters in a major way, i.e., rendering it almost completely meaningless (except for adding the required="required" property, which browsers can use to implement client-side validation).
To test, I simply edited the pre-installed /admin/content view to make the “Title” filter required. With current HEAD it’s true that this leads to an empty error message that definitely shouldn’t be there. However, when applying the changes in MR !4560 I instead just got the normal view, listing all content, completely ignoring that the “Title” filter should have been required. (The only change was the little red asterisk next to “Title”.) When trying to submit the form without filling out “Title”, the browser (Mozilla Firefox 122.0) prevented me from doing that, but after manually removing the required attribute from the DOM this again worked as if the “Title” filter wasn’t required, just listing all content, as before, without complaint or error message.

I’m not exactly sure what this MR is trying to do, but it seems to me like in addition to the $form_state->setAlwaysProcess(FALSE); call we also need something that prevents the view from showing any results.