Opened 8 years ago
Last modified 7 years ago
#38845 new enhancement
Implement HTML5 input validity constraints in customizer settings
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 )
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 (8)
#3
@
8 years ago
Actually, I think this should tie in directly with #39634 and the creation of REST API endpoints for settings. We should re-use JSON Schema as much as possible to define what settings look like. Ideally the input_attrs
for the control could be derived from the schema for the setting.
+1. I think it could make sense to support both defining the patterns in the setting and automatically checking the
input_args
on the control where those are relevant.