Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Probably too late for D7, but filing as a feature request for D8.
D7 introduced #limit_validation_errors so that AJAX/multistep interactions are not cluttered with validation errors on parts of the form not involved in the step. The property points a subpart of the $form array, for which validation is performed - validation is skipped for the rest of the form.
In a followup, #763376: Not validated form values appear in $form_state pushed the effect much further : if #limit_validation_errors is used, then only the elements in the $form subpart show up in $form_state['values'].
This API is fine for the primary use case this was introduced for : "add more" buttons, which shouldn't be blocked on "node title is required".
A different pattern, found on Field UI's "Manage display" is : display a subform (formatter settings), with 'Submit' and 'Cancel' buttons relevant to that subform - the 'Cancel' button should skip validation within the subform.
Using #limit_validation_errors is tricky here, because it would require we explicitly specify 'the rest of the form' (without the subform) - really difficult, and completely unfriendly for modules altering the form. The fact that form element not mentioned in #limit_validation_errors are hidden from $form_state['values'] makes it even worse.
What we need here is an alternate #skip_validation_errors option, that has a reversed semantics : lets you specify a part of the form where validation errors are skipped - i.e the complement of what you'd put in #limit_validation_errors.
Comments
Comment #1
yched CreditAttribution: yched commentedHm, the tricky bit of course being : how would #limit_validation_errors and #skip_validation_errors coexist in the same form... :-/
Comment #2
rfayyup
Comment #3
sunHm. I rather think that those "embedded field settings forms" in Field UI should be entirely separate forms; i.e., not part of the wrapping Field UI overview form. AJAX can happily submit an injected sub-form only. Having the settings form in a more atomic fashion also allows to expose it in entirely different locations (e.g., edit-in-place-alike functionality/contextual links).
Comment #4
yched CreditAttribution: yched commented@sun : Hm, interesting take.
"AJAX can happily submit an injected sub-form only"
Not sure what that would look like, though. The D7 ajax framework + $form_state / rebuild behavior made a really nice match for this kind of form as Field UI currently implements it.
Comment #5
effulgentsia CreditAttribution: effulgentsia commentedSubscribe, though I'm also wondering why "Cancel" needs anything to be validated. Why not
#limit_validation_errors => array()? With #622922: User input keeping during multistep forms, rebuilding should still preserve input values for purposes of ensuring that the HTML returned by the AJAX doesn't clear out in-progress modifications of the rest of the form. Does it make sense for a Cancel button's submit handler or form rebuilding logic to rely on anything in $form_state['values']?I'm not opposed to something like #skip_validation_errors in D8. Just wondering how to solve the Field UI issues in D7.
Comment #6
yched CreditAttribution: yched commented@eff : Yes, "Manage display" already heavily relies on #622922: User input keeping during multistep forms (which was godsend to keep iterative forms reasonably simple)
#limit_validation_errors => array() was what I originally went with in #796658: UI for field formatter settings. After #763376: Not validated form values appear in $form_state, we had to make sure that $form_state['values'] contained a minimal set of vital values in #896162: Write tests for the Field UI formatter settings form (first couple comments).
Now that you mention it, it's not clear to me either why the 'Cancel' button needed that - apparently it was clear to me when I explicitly fixed it in #896162-2: Write tests for the Field UI formatter settings form :-)
Anyway - maybe 'Cancel' is a wrong example here. The case applies to the 'Edit settings' button : needs a #limit_validation_errors without getting an empty $form_state['values'] (needs to 'cancel' any open settings form on other rows, ditching validation errors, and open the settings form for the current row and its currently selected formatter).
Don't worry about fixing Field UI forms. As is, they should be fine for D7. I just mean that with the awesome powa of D7 ajax + $form rebuilding for iterative forms, this won't be a rare pattern.
Comment #7
attiks CreditAttribution: attiks commentedsubscribing for #1239910: META: tracking other issues about validation
Comment #8
geek-merlinsub
Comment #21
smustgrave CreditAttribution: smustgrave at Mobomo commentedWonder if this is still needed for D10 with so little movement?