Suppress validation of required fields on ajax calls

I can think of another use case that I find even more strange (and unfriendly to the user):

Suppose you had an "add item" and a "remove item" ajax button to add and remove elements with required fields on them.

Now the user can click "add another item" and easily get their new element. But to remove it he needs to enter all the required fields to make the validation pass so he is allowed to delete the element again.

The new test also passes if we just empty out #limit_validation_errors.
Why can't we just do it this way?
Maybe more test coverage will help illustrate.

Patch needs re-roll.

Applied patch in #17
Working fine. Updating patch.

Now the developer has the option to suppress the whole validation with setting

#limit_validation_errors = array()

But by using this even the custom validation introduced by the developer will be suppressed

That's.. not true! I'm pretty sure you can use '#element_validate' together with '#limit_validation_errors = []' on a form element and the element validation handler will be called. I'd vote for a won't fix here :)

Hi

I am using Drupal Version 8.6.1. I have same problem in select drop-down ajax( a required field). I had this issue in Drupal 8.5.x. So I updated the Drupal to 8.6.1 but issue is not fixed. Please find the attachment

I have applied the patch also. But it is not working. Please help me to fix this issue. Thanks

Thanks everyone for working on this! This bit us too and hard.

Our use case is the Ajax Dependency module. (Which in turn we need for our distribution's "conditional fields", as the jS-based conditional field module is too limited and imho currently broken beyond repair.)

On our organisation profile, we have an org_type field, which may be business, or nonprofit, or both, but must not be empty and thus is required. Using said module, we change access to other fields (like refs to nor-profit or non-profit taxonomy terms).
This issue bites us e.g. if a user 1) erroneously chooses 'nonprofit' 2) removes the 'nonprofit' checkmark, then the ajax call breaks as the reqired field now is empty thus invalid.

Note that setting nonrequired or limiting validation or hacking #element_validate is not an option, as the field must be required in the final submit. So we need a solution where there is no validation on ajax (exactly: the ajax triggered by a field change), but not on submit.

I even wonder if there is a use case for validating ajax-on-field-change that is a form rebuild and not a submit.

Let's see what el testbot says to this plain rebase.

Now with CS fixes.

OK. The rebased patch did not fix my use case. Also i realized that #limit_validation_errors on the ajax-on-value-change element fixes my use case.

To summarize:
* To suppress all validation when we want to only rebuild the form, use #limit_validation_errors=[]. It also works on ajax-on-value-change elements (which i did not realize first, also see the related docs issue)
* What the OP needed was to suppress only some validation on an element, but not their custom validation

So no contrib blocker at all, and "sorry for the noise" ;-).

@geek-merlin - How did you resolve your issue with #limit_validation_errors ?

I am facing this issue a lot when having multiple select fields dependent on each other, once selecting a parent field the child field gets populated but when I change the parent field again, I get an error -
"An illegal choice has been detected. Please contact the site administrator."

I tried using limit_validation_errors on all the fields but no luck.

Can you please tell me where did you use it - in the form_alter or ajax_callback?

I think i am in the same situation as JAINV18, currently blocking development of Focused Entity Reference.

Hi @JAINV18 and @mlncn
I was facing the same issue and used #limit_validation_errors property to fix it.
Here is the sample code.
NOTE: Reference taken from (#12) https://www.drupal.org/project/business_rules/issues/3051993

function mymodule_form_form_id_alter(&$form, FormStateInterface $form_state) {
  $form['myfield']['widget']['#ajax']['#limit_validation_errors'] = array();
}

I have now another use case:

The AI content suggestions would be nice to have as ajax callback, but the required field of the entity form could be skipped during validation, because for example you want the title to be suggested by AI and it is required.

I have re-rolled the patch for Drupal 11.1.x and removed the change in WidgetBase class, as it might be out of scope. Let's first create the possibility of skipping validation of required fields in general, so that contrib or custom modules can implement this in their code.

I have also opened a MR for easier collaboration.

I'm currently using Claro and it looks like this:

The last comment is for issue #3489572: AI Content Suggestions: Allow summarize, analyze, suggest title and taxonomy terms based on the rendered HTML of the entity

I have rebased the MR branch on current main.

Uploading the static patch for using in composer based projects

This appears to be missing test coverage.

Added tests

I must say, I was hesitant about the addition of #suppress_required_fields_validation when we already have #limit_validation_errors.

But the field_widget_actions use-case of AI actually demonstrates the need for #suppress_required_fields_validation. #limit_validation_errors cannot be used, since #limit_validation_errors completely skips validation + makes respective form-values not available (what's right, since they are not validated).

We want to keep the form validating, keep form values, but ONLY skip required-field validation. This is not possible atm and the new proposed suppress_required_fields_validation fills the need.

That said, I got convinced, it makes sense to add this.

However, I'm not sure about the proposed resolution design. Why is #suppress_required_fields_validation only working for ajax operations? Why are we not following #limit_validation_errors and make it possible for every submit-button? Whether or not the button uses AJAX or not seems to be a separate topic. Thus, shouldn't this be a general feature/option like #limit_validation_errors ?

Also, MR has a test fail, so this is needs work.

Rebased the MR branch on current main (afe536a).

The MR was 571 commits behind main, so I rebased locally to clear the merge conflict block. Two conflicts came up; both were structural, not behavioural:

1. core/lib/Drupal/Core/Form/FormBuilderInterface.php — main had added a new HTMX_REQUEST constant in the same spot where this MR adds AJAX_SKIP_REQUIRED_VALIDATION. Resolved by keeping both constants with their respective docblocks.
2. core/tests/Drupal/Tests/Core/Form/FormValidatorTest.php — both sides added new use statements in the imports block. Resolved by keeping all three (CsrfTokenGenerator, FormBuilderInterface, FormErrorHandlerInterface) in alphabetical order.

No logic changes were needed in FormValidator.php, RenderElementBase.php, or any of the test additions — those auto-merged cleanly.

I also re-ran the manual test on the original (un-rebased) MR branch beforehand to confirm the feature works as intended:

• With 'suppress_required_fields_validation' => TRUE on the AJAX trigger, clicking the button while a #required sibling field is empty fires the AJAX callback cleanly and produces no required-field error.
• With the flag set to FALSE (or absent), the same click produces the standard "field is required" error — confirming the flag is the deciding factor and that normal form submission still enforces required fields.

Patch attached: 2476569-suppress-required-fields-validation-rebased.patch — 8 files changed, 193 insertions, 1 deletion. Cleanly applies on top of afe536a7949.

The Needs Review Queue Bot tested this issue. The merge request has merge conflicts and cannot be merged. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I have rebased the branch, the failing Workspace Media Library integration test looks irrelevant to this change.

Would be good to re-run that failed test to make sure please.

It is green now.

Reading this again and is it really a bug or a feature request?

Regardless will need a change record though as a next step

On the scope of suppress_required_fields_validation (re: @fago question from above)

In my view I feel keeping this option scoped to #ajax is correct.

AJAX callbacks are semantically intermediate operations, they rebuild the form, they do not submit it. Required fields exist to enforce data completeness at the point of final submission. Skipping required validation during a form rebuild is coherent, skipping it on a final submit is not.

A generalised, non-AJAX version of this option would allow a regular form submission to silently bypass required fields, a different use case, and a harmful one from a UX perspective.

If a developer needs to skip required validation on a non-AJAX button today, #limit_validation_errors = [] already exists for that, with the known tradeoff of suppressing custom #validate handlers. That tradeoff is a separate problem worth solving separately.

In my POV the #ajax boundary is the right semantic scope here.

I have 1 security concern: the suppression flag is client-controllable

The current implementation reads the flag from the request query string in FormValidator::doValidateForm(). It does not verify that the element which triggered the AJAX call actually declared suppress_required_fields_validation => TRUE. Any client can opt in by appending the parameter to any AJAX request.

A concrete example:

// A contact form with required Name and Email fields.
// Its AJAX button does NOT set suppress_required_fields_validation.

// Attacker manually crafts the AJAX request:
// POST /contact?ajax_form=1&ajax_skip_required_validation=1

// Result: required validation is suppressed even though
// the form never opted in.

Required-field validation is a UX constraint rather than a hard security gate, but bypassing it without form-author opt-in breaks the contract the form defines. Unless there is something in the core that will prevent it, which I'm not aware of.

I see this as a approach: check the triggering element's #ajax settings server-side: for example, reading $form_state->getTriggeringElement()['#ajax']['suppress_required_fields_validation'], instead of trusting a client-supplied query parameter. The query param could then be dropped entirely maybe ?!

Bug vs. feature (re: @smustgrave)

I too see this as a feature request (or task), not a bug.

AI disclosure: I used Claude Code to review the MR diff, analyse the tests, summarise the comment thread, and surface gaps. The reasoning and positions are my own. I reviewed everything before posting.

Pushed a rework implementing @abhisekmazumdar's suggestion: the opt-in is now read from the triggering element's server-side #ajax['suppress_required_fields_validation'] rather than a request parameter, so it can't be forced by a crafted request. I kept the ajax_form check so it stays AJAX-only — if JS is off and the same button submits the full page, required validation still applies.
Also removed the AJAX_SKIP_REQUIRED_VALIDATION constant and its query-param injection in preRenderAjaxForm & added a test.

On the scope question from #63: confirmed with @fago that we keep this scoped to #ajax — it's for the intermediate AJAX rebuild, not the final submit.

Created CR: https://www.drupal.org/node/3592386

The fixes done by @petar_basic look good to me.

Still needed before RTBC

1. Simplify the suppression check in FormValidator.php

There is an extra variable in the suppression logic that is not needed and makes the code harder to follow. The check already ensures suppression only applies to required fields by design, the extra gate is redundant. The flag should only check whether it is an AJAX request and whether the triggering element opted in.

2. Add a test proving custom validators still run

The core argument for this feature raised by @fago in #63: is that unlike #limit_validation_errors = [], this option does not suppress custom element validators. That claim has no test backing it up. A unit test should confirm that when suppress_required_fields_validation is TRUE, a custom #element_validate handler still runs and its errors are still reported.

3. Document the new #ajax option in the Form API

suppress_required_fields_validation is not mentioned in the #ajax property documentation. A developer looking at the Form API docs has no way to discover this option exists. It needs a one-line entry wherever the other #ajax sub-keys are documented.

AI disclosure: I used Claude Code to review the MR diff, analyse the tests, summarise the comment thread, and surface gaps. The reasoning and positions are my own. I reviewed everything before posting.