Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 7 years ago

#28477 closed enhancement (fixed)

New Built-in Customizer Control Types

Reported by: celloexpressions's profile celloexpressions Owned by: ocean90's profile ocean90
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: has-patch commit
Focuses: ui, administration Cc:

Description

Devs shouldn't need to create custom customizer controls for commonly-used inputs such as textarea, number inputs, etc. Additionally, we should (and easily can) support all of the html5 input types via fallback handling for unknown types. This makes it even easier to build options into the customizer and shifts the need for custom controls to more advanced uses.

This ticket is for discussion and potential inclusion of control input types that could be added to the base WP_Customize_Control. Anything added here would be used with something like:

$wp_customize->add_control( $setting_id, array(
	'type' => 'textarea',
	...
);

The base WP_Customize_Control currently supports the following types:

  • text
  • checkbox
  • radio
  • select
  • dropdown-pages

Adding a fallback type handler gives us full support for input types such as email, url, hidden, date & time formats, etc. This is accomplished by passing the control type to the type attribute of the input element and otherwise treating it as a text input. We could also add some JS to provide a more consistent experience across browsers and for browsers that don't support things like date & time input types, but I'd consider that a future enhancement (as those are implicitly, not explicitly supported). If we were to do that, passing a color type, for example, would result in the behavior similar to WP_Customize_Color_Control (although in that case it requires a standalone control). I would recommend adding some CSS to handle a few easily-supportable types (mostly for input widths).

If we add a few more properties to the WP_Customize_Control class (min, max, step), we could also fully support number and range input types. This would be similar to how the choices parameter is specific to the radio and select input types.

Finally, there are a few other field types that are commonly used. This might be a good time to add a couple of types such as textarea that can be implemented in the base WP_Customize_Control.

Attachments (9)

28477.default.diff (628 bytes) - added by celloexpressions 10 years ago.
Add default handling to support additional input types that don't require special handling (email, url, etc.).
28477.diff (4.0 KB) - added by celloexpressions 10 years ago.
Add core customizer control support for textarea, number, and range, and fallback/implicit support for other input types.
28477.test-plugin.php (1.1 KB) - added by celloexpressions 10 years ago.
Test plugin that creates a bunch of controls with different types.
28477.test-plugin.png (37.5 KB) - added by celloexpressions 10 years ago.
Test plugin output with 28477.diff applied, in Chrome 35 (left) and Firefox 29 (right).
28477.2.diff (3.3 KB) - added by celloexpressions 10 years ago.
Add core textarea type, support for arbitrary types and attributes.
28477.3.diff (3.4 KB) - added by celloexpressions 10 years ago.
Remove explicit text type output, don't use a whitelist of allowed attributes.
28477.4.diff (3.3 KB) - added by celloexpressions 10 years ago.
Refresh with descriptions.
28477.5.diff (3.9 KB) - added by celloexpressions 10 years ago.
Restore textarea type that fell out of .4.diff.
28477.test-plugin.2.php (1.4 KB) - added by celloexpressions 10 years ago.
Revised demo/test plugin with input_attrs(), several input types, and the new description field.

Download all attachments as: .zip

Change History (25)

@celloexpressions
10 years ago

Add default handling to support additional input types that don't require special handling (email, url, etc.).

#1 @celloexpressions
10 years ago

  • Keywords has-patch added

28477.default.diff is the fallback handling part; this is the first step of several things we could do here.

@celloexpressions
10 years ago

Add core customizer control support for textarea, number, and range, and fallback/implicit support for other input types.

@celloexpressions
10 years ago

Test plugin that creates a bunch of controls with different types.

@celloexpressions
10 years ago

Test plugin output with 28477.diff applied, in Chrome 35 (left) and Firefox 29 (right).

#2 @celloexpressions
10 years ago

  • Keywords dev-feedback added

28477.diff does pretty much everything I suggested in the ticket description. I'm not sure that we should do all of it (particularly the number & range parts), but it's all worth considering.

The attached screenshot and test plugin demonstrate the purpose of the fallback type handler. This allows us to implicitly support all sorts of input types that devs can use with minimal effort. If, for example, someone needs a time or date field and only needs to support Chrome, they can do so quite easily and rely on the browser's support for that input type. Any of these input types is treated as a text input by browsers if the type is unrecognized.

Currently, most developers would just create a text control for a url field, but with this proposal they could just as easily use url, taking advantage of potential improvements that the browser might implement for that specific input type (contextual on-screen keyboards, for example).

#3 follow-up: @westonruter
10 years ago

@celloexpressions I really like this.

For feedback, what if instead of a $numerical property, it instead implemented an array of input attrbutes (e.g.$input_attrs), and then all provided attributes would get serialized and inserted into the <input> element. This would make it easy to add support for pattern and other attributes.

Additionally, should not there also be some default server-side validation for controls with these input attributes provided? I suppose it would actually be the domain of the associated customize setting, but it would be nice if there was a low-priority filter that would get added automatically to enforce the HTML5 validity constraints.

@celloexpressions
10 years ago

Add core textarea type, support for arbitrary types and attributes.

#4 in reply to: ↑ 3 @celloexpressions
10 years ago

Replying to westonruter:

For feedback, what if instead of a $numerical property, it instead implemented an array of input attrbutes (e.g.$input_attrs), and then all provided attributes would get serialized and inserted into the <input> element. This would make it easy to add support for pattern and other attributes.

Great idea! 28477.2.diff adds the textarea type and generic handling for arbitrary types and input attributes. I put in a whitelist of allowed attributes, not sure if that's needed. I'd rather not do that for input types, as that might imply explicit support for those (in terms of styling, supporting JS, etc.).

In terms of validation, I don't think we can do anything here since that's up to the setting (other than maybe making additional functions available).

Usage (not that you would ever use all of these attrs together):

$wp_customize->add_control( $setting_id, array(
	'label'     => $label,
	'section'   => $section_id,
	'type'      => $type,
	'input_attrs' => array(
		'min' => 0,
		'max' => 10,
		'step' => 2,
		'class' => 'test-class test',
		'style' => 'width: 50%;',
		'placeholder' => __( 'Placeholder' ),
		'pattern' => '[a-zA-Z0-9]+',
	),
) );

#5 @westonruter
10 years ago

In case it is helpful, I applied your patches to the Git repo clone and opened a PR for code review, collaboration, and any additional commits: https://github.com/x-team/wordpress-develop/pull/14

#6 @westonruter
10 years ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.


10 years ago

@celloexpressions
10 years ago

Remove explicit text type output, don't use a whitelist of allowed attributes.

#8 follow-up: @celloexpressions
10 years ago

  • Keywords dev-feedback removed
  • Milestone changed from Future Release to 4.0

Per chat with nacin, we don't need to validate input attributes against a whitelist, and the existing text type output can be removed, as the fallback type handling results in the same output when type = text.

Only outstanding issue here is whether (or to what extent) core should style different possible input types. Applying our standard input styling for all inputs may be the best solution here, but we could probably land the php side of this now.

This will conflict with #27981; I'll just update the other patch once the first one lands.

This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.


10 years ago

@celloexpressions
10 years ago

Refresh with descriptions.

#10 @celloexpressions
10 years ago

28477.4.diff refreshes to account for [28927].

#11 @westonruter
10 years ago

  • Keywords commit added

@celloexpressions
10 years ago

Restore textarea type that fell out of .4.diff.

@celloexpressions
10 years ago

Revised demo/test plugin with input_attrs(), several input types, and the new description field.

#12 @ocean90
10 years ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

In 28930:

Customizer: Support textarea and commonly-used input types as control type in WP_Customize_Control.
Add input_attrs property to support custom input attributes.

(Demo plugin attached to ticket.)

props celloexpressions.
fixes #28477.

#13 in reply to: ↑ 8 ; follow-up: @ocean90
10 years ago

Replying to celloexpressions:

Only outstanding issue here is whether (or to what extent) core should style different possible input types.

That should go to another ticket.

#14 in reply to: ↑ 13 @iseulde
10 years ago

Replying to ocean90:

That should go to another ticket.

#28262

This ticket was mentioned in Slack in #core-fields by celloexpressions. View the logs.


8 years ago

#16 @westonruter
7 years 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.