Make WordPress Core

Opened 16 months ago

Last modified 6 months 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 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 (8)

#1 @westonruter
16 months ago

  • Description modified (diff)

#2 @celloexpressions
14 months ago

  • Keywords needs-patch added
  • Version set to 4.6

+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.

#3 @westonruter
14 months 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.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

11 months ago

#5 @jbpaul17
11 months ago

  • Milestone changed from 4.8 to 4.8.1

Per yesterday's bug scrub, we're going to punt this to 4.8.1.

#6 @westonruter
9 months ago

  • Milestone changed from 4.8.1 to 4.9

#7 @westonruter
8 months ago

  • Milestone changed from 4.9 to Future Release

#8 @westonruter
6 months ago

In 41387:

Customize: Use input event instead of keyup or propertychange events when listening for changes in wp.customize.Element instances.

Ensures that a control's Element is updated in response to pasting into the field. Also fixes issue where inputs using "new" HTML5 types (like url and number) were not updating in the preview during keystrokes. The use of input was previously blocked due to needing to support IE9, but this is no longer a concern since IE<11 is no longer supported.

See #38845, #28477.
Fixes #35832.

Note: See TracTickets for help on using tickets.