WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 4 years ago

#38845 new enhancement

Implement HTML5 input validity constraints in customizer settings — at Version 1

Reported by: westonruter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.6
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description (last modified by westonruter)

Ever since #28477 controls in the customizer have supported custom HTML5 input types along with new input attributes passed via the control's input_attrs param. The support, however, has been lacking because when a user supplies something that violates some of the constraints (such as pattern or step) there is nothing that blocks the setting from being saved (using setting validation model in #34893). So using the input_attrs along is in fact somewhat harmful if it is not accompanied by the same constraints being applied in the setting's sanitize_callback or validate_callback. The browser's built-in input validation error UI also does not show because no form actually gets submitted, and there are no calls to the poorly-supported input.reportValidity() method.

To address these issues, I suggest that the default validity_callback for WP_Customize_Setting could look for any associated controls and then check the type of the value against the control's type and also check the value against the validation constraints defined in the control's input_attrs param, such as min, max, pattern, step, maxlength, and so on. In this way, a setting's sanitize_callback/validate_callback wouldn't even need to be defined since the validation constraints would be defined declaratively and checked automatically.

It's not exactly the best pattern, however, for the setting's validation constraints to be defined on the control. So there could be a new validation_constraints param on WP_Customize_Setting where the validation input attributes could be defined instead of the on the control's input_attrs. A control could then automatically populate it's own input_attrs by copying from the setting's validation_constraints.

These changes will ensure that setting validation routines will apply and error notifications will be displayed when settings fail validation on the server with a full refresh, selective refresh, or changeset update. In order to get the browser's native validation error reporting to appear, the JS control logic can be updated to call input.reportValidity() if it is available (it's currently only implemented in Chrome).

See feature plugin: https://github.com/xwp/wp-customize-input-validity-constraints

Change History (1)

#1 @westonruter
5 years ago

  • Description modified (diff)
Note: See TracTickets for help on using tickets.