\Drupal\views\Plugin\views\HandlerBase exposes these methods, allowing an "extra options" form
public function buildExtraOptionsForm(&$form, FormStateInterface $form_state) {}
public function validateExtraOptionsForm($form, FormStateInterface $form_state) {}
public function submitExtraOptionsForm($form, FormStateInterface $form_state) {}
Extra Options Form validation errors will prevent the form form being submitted, but, the errors are not displayed anywhere. This is confusing for site builder because they might think that the submit has been successful.
In core there are only 3 filters using this:
Currently, all extra options form elements in all of the above filter plugins are configured to always pass form validation. Therefore, there is no way to trigger a form validation error in core and manually test for this bug, without a patch to change this code.
This bug was first detected by claudiu.cristea while working on #2784233-129: Allow multiple vocabularies in the taxonomy filter. In this issue's MR a new required vids form element is being added to TaxonomyIndexTid::buildExtraOptionsForm. If that element is left empty, the form is not submitted (as expected) but no error messages are displayed anywhere.
Further more, this bug was also experienced by scott_euser in the development of the EntityReference filter (which is now in core) (see #2429699-486: Add Views EntityReference filter to be available for all entity reference fields, specifically the section titled Conditionally required fields within selection hanlders in that comment).
The EntityReference filter handler displays the selected Entity Reference selection handler's options within the Extra Options form. If any of those form fields fail validation, the form doesn't submit (good) but no error messages are displayed (bad). There is an outstanding todo in EntityReference::validateRequired referencing this issue.
As mentioned above, a patch file is needed to manually test for this bug.
The patch file drupal-validation-of-errors-in-extra-options-muted-3163740-9.patch will modify the TaxonomyIndexTid filter to remove the default value Vocabulary field and sets the field to required. This will enable the Vocabulary form field to be left empty to trigger a validation error.
Follow the instructions outlined in comment #8 below.
Make the validation error displayable but adding the following code to ConfigHandlerExtra::validateForm to instruct ajax to re-render the form. The same code can already be found in \Drupal\views_ui\Form\Ajax\ConfigHandler::validateForm and \Drupal\views_ui\Form\Ajax\Display::validateForm.
if ($form_state->getErrors()) {
$form_state->set('rerender', TRUE);
}
Show the validation error to the user.
None.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | Screenshot 2025-08-29 at 2.42.58 PM.png | 45.05 KB | smustgrave |
| #9 | drupal-validation-of-errors-in-extra-options-muted-3163740-9.patch | 735 bytes | scott_euser |
| #8 | screencast-drupal9.ddev_.site-2022.07.25-20_37_34.gif | 3.74 MB | scott_euser |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare changes, plain diff MR !13056
Comments
Comment #2
larowlanComment #3
codersukanta commentedI would be helpfull if you add steps to reproduce in issue summary.
Comment #6
tintoIt's been 2 years since the request for steps to reproduce/test this issue, so I am changing the status to Postponed (maintainer needs more info) and adding 'Add steps to reproduce' to the remaining tasks in the issue summary.
I second #3 in that it would really help to be able to resolve this issue (or push it forward). If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active".
If this issue summary does not receive any additional information in the coming months, I suggest someone other than me may consider closing this issue.
Comment #8
scott_euser commentedAttached patch allows us to reproduce this in core by changing the vocabulary selection to be required and removing the default value.
Steps to reproduce:
Comment #9
scott_euser commented...and the patch sorry!
Comment #10
scott_euser commentedNote that this stops https://www.drupal.org/project/drupal/issues/2429699#comment-14623083 from being properly implemented
Comment #15
tame4tex commentedComment #16
tame4tex commentedSo this ended up being a simple fix.
ConfigHandlerExtra::validateFormwas missing the code to instruct ajax to re-render the form so that error messages are included. Specifically:I have added a test and fixed this bug. I have also updated the IS with the steps to reproduce and the proposed resolution.
Comment #17
smustgrave commentedLeft 2 small comments on the MR.
If you are another contributor eager to jump in, please allow the previous poster(s) at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!
Comment #18
tame4tex commentedThank for the review smustgrave!
Resolved one comment and added justification for the new test class in a reply on the other comment. Back to NR.
Comment #19
smustgrave commentedSo I tried to follow the steps in #8 but the tags field is using radio buttons so something is always selected. Are there other steps?
Comment #20
tame4tex commentedComment #21
tame4tex commented@smustgrave I have updated the IS which explains and highlights the need for the patch file to enable manual testing. I have also added extra details on where this bug is being encountered.
Comment #22
smustgrave commentedOkay I am seeing if I hack that views module file that errors aren't appearing.
With the MR I see
All threads have already been resolved so believe this one is good to go.
Comment #23
quietone commentedAll the changes are in views_ui module, so changing component.
Comment #25
catchCommitted/pushed to 11.x, thanks!