Fix wrong boolean radio field validation error label

Has there been any progress on this issue? I’m encountering a similar situation where a field becomes visible and required based on a specific field selection, yet the 'N/A' option remains available. Any insights on resolving this?

I worked on a patch removing the "N/A" option from the field when conditional_fields set the form-items to required. Since this is CSR we needed to do some magic to detect the "N/A" option and hide it accordingly.

I also updated the phpstan because the CI pipeline gave me problems.

Claude Code says:

Potential issues:

1. Hide/show is only inside the legends.length !== 0 branch (lines 141 and 157). If a boolean field renders without a legend element, the N/A option will never be hidden/shown. This seems like it could be a bug — the hide/show should likely happen regardless of whether legends exist, i.e. moved outside the if (legends.length !== 0) block.
2. Selector fragility — [id*="component-none"] is a substring match. If any unrelated input happens to contain "component-none" in its ID, it would be caught. A more precise selector (e.g., [id$="-component-none"] with a suffix match) would be safer, though in practice this is likely fine for Drupal's ID conventions.
3. No value reset — When hiding the N/A option, if it was currently selected, the user is left with a hidden selected option. It might be worth unchecking it and selecting the first visible option when hiding.

PHPStan Baseline

The baseline was expanded significantly with new suppressions. This is fine as a separate concern (updating to a newer PHPStan version or stricter rules), but it's unrelated to the boolean field fix. Mixing unrelated changes in the same branch can make review harder.

Summary

The fix is straightforward and addresses the issue. The main concern is point 1 — the hide/show logic is nested inside if (legends.length !== 0), which means it won't apply to boolean fields that don't render with a . Worth verifying that boolean fields always have a legend in Drupal's form rendering, or moving the hide/show outside that conditional.

Removing the note about the duplicate required asterisk since it is addressed in #3476905: Fix required field indicator appears twice.

Seems this issues has some history in core.

I am submitting this MR as a draft because it addresses the front-end/UI side of the issue, but there appears to be a deeper back-end validation problem for radio widgets: the empty conditionally-required radio was not failing validation.

If I understand correctly, conditional fields doesn't fiddle with validation handling, it simply removes empty, un-required form values so they're ignored by validation. When conditionally-required, it allows the empty value through, and normal validation kicks back the required error. If that is correct, then Drupal isn't recognizing the conditionally-required radio value as required, even when empty. Not sure if that may still be the case if forced to submit _none.

I tried a workaround (see #1561272: Conditionally required fields are not required) of marking the field both required and conditionally required. That did not work correctly either: validation still fired even when the dependency was not triggered. But, being marked required in field settings, it removes the N/A option as well. Since marking the field required removes the N/A option, this may not be a matter of Conditional Fields failing to neutralize an empty submitted radio value. Instead, it may be that Conditional Fields is not correctly bypassing required validation for radio widgets when the dependency is not triggered.

So, this draft MR improves the UI behavior, but the back-end handling of conditionally required radio widgets needs additional investigation.

Yep, backtracking to current 4.x without the N/A removal, it does require the radio value when "N/A" (_none) is chosen, but not when empty.

The only problem with that is, for Boolean fields, the validation error message is of the first radio option rather than the actual field label. Perhaps there's a core bug reported for this?

Okay, I think I've boiled it down.

• #3267246: ['#states']['required'] broken for radios will be captured in #2951317: Radios element missing "required" attribute.
• #2951317: Radios element missing "required" attribute will handle the N/A removal and appropriate initial and state JS handling of required classes and attributes.
• This issue then becomes just a matter of ensuring Boolean field errors correctly show the field label rather than the option label.

For those looking to see the N/A option is not shown when a radio field is required: #2951317: Radios element missing "required" attribute.

Needs review. Should try with and without the patch from #2951317: Radios element missing "required" attribute.

I think we should explicitly test one additional case here: for Boolean radios, does selecting No (0) pass validation correctly once the field is conditionally required?

In current Require on Publish work, Boolean radios pass when Yes is selected, but No is still being treated as empty/required on publish. That suggests we may have a remaining falsy-value handling problem separate from the N/A hide/show behavior.

That will help confirm whether the current fix fully resolves required-state handling, or whether Boolean 0 still needs special handling.

Good news. It seems that is just a problem with Require on Publish. This MR correctly treats No (0) as a valid response to Boolean Radio fields.

So, still just needs verification noted in #24. :)

I had to roll back the regression test because I couldn't get it working.

Tests would be a good thing to have, yeah.

@benstallings, as noted in #24, were you able to vet this with and without the patch from #2951317: Radios element missing "required" attribute?

No, sorry, I did not try it with the patch from the other issue.

My local tests were with the patch. So, if you're seeing it worked, then we're verified good-to-go.

Still just needs tests. :)

@jcandan while a test would be nice to have, I don't see a way forward for writing one. Do you? If not, maybe we can set this back to reviewed & tested?