#30738 closed task (blessed) (fixed)
JS content templates for base WP_Customize_Control
Reported by: | celloexpressions | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.9 | Priority: | high |
Severity: | normal | Version: | 4.1 |
Component: | Customize | Keywords: | needs-unit-tests has-patch needs-testing has-dev-note |
Focuses: | accessibility, javascript, rest-api | Cc: |
Description
This will make it possible to create all of the base Customizer control types directly in JS, and will allow them to share a single template passed from the server on Customizer init for all controls with the basic types (following up on #28709).
I think we may need to explore adjusting how register_content_type works since this control handles multiple types and all fallback types. But more likely we'll just do something a bit different, probably adding fallback handling on the other side and hard-coding these types into the Customizer Manager somewhere.
Follow-up to #29572. Related to several tickets I'm currently creating.
Attachments (6)
Change History (77)
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core by westonruter. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
#8
@
10 years ago
- Focuses javascript added
- Keywords has-patch added; needs-patch removed
- Milestone changed from Future Release to 4.3
@westonruter 30738.wip-2.diff should be most of what we need but there's a syntax error in the big template, and I'm not finding it, do you see it? I think it should be a quick fix and that this should be a relatively easy/painless improvement, but we'll have to see how it goes.
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
9 years ago
#13
follow-up:
↓ 14
@
9 years ago
Patch is not yet functional - we need someone to pick this up or we're going to have to punt probably.
Note that Menus in the Customizer are currently using several custom controls that really shouldn't be custom controls to step around this and use a common setting, which I believe the settings
control param can handle.
#14
in reply to:
↑ 13
@
9 years ago
Replying to celloexpressions:
Patch is not yet functional - we need someone to pick this up or we're going to have to punt probably.
Yes, unless you and @westonruter find time to make a decision on it this weekend, this is probably going to get punted.
#15
@
9 years ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from 4.3 to Future Release
This should definitely happen, but no longer a priority for 4.3. Need a functional patch first.
#16
@
8 years ago
There is a partial implementation of this in the Customize Posts plugin (see also #37275):
https://github.com/xwp/wp-customize-posts/blob/develop/php/class-wp-customize-dynamic-control.php
https://github.com/xwp/wp-customize-posts/blob/develop/js/customize-dynamic-control.js
Something implemented here, which I think has been discussed previously, is that the label
element doesn't wrap the title and description anymore (for non-checkboxes at least), by introducing a random id
for the input to be used with the label[for]
attribute. This is turning out to be important now with the introduction of the new notifications in 4.6 which have a container that gets injected right after the site title. This means that if there is a button inside of a notification, it won't work as expected because it is wrapped in a label
. Also related here is that notifications should support a template allowing them to allow arbitrary markup as opposed to an escaped message. This was noted by @celloexpressions in https://wordpress.slack.com/archives/core-customize/p1469851496000101
#17
@
8 years ago
This might go in another ticket, but we also should allow for a content_template
param to be passed in when instantiating a widget in JS. When this is supplied, it should use that template instead of the template selected via the type
param as output from the PHP WP_Customize_Control::content_template()
method. This would allow for custom control templates to be easily used without having to define an entirely new WP_Customize_Control
or hack around with the type
parameter to get it to use something else.
#18
@
8 years ago
Here's an implementation of content_template
param which can be incorporated into Control#renderContent()
: https://github.com/xwp/wp-customize-posts/pull/225/commits/495b1fcb0c2286305b9e38f3c868f6ae3e970c83
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
8 years ago
#20
@
8 years ago
- Milestone changed from Future Release to 4.7
- Owner set to westonruter
- Status changed from new to accepted
Adding to 4.7 due to the existing code in Customize Posts which can be lifted.
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by chriscct7. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#26
@
8 years ago
- Milestone changed from 4.7 to Future Release
Removing from the 4.7 milestone due to lack of traction.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#31
@
8 years ago
The dropdown-pages
control type actually _should_ be included among the types that have content template, and the list of pages that appears in the select
field should be fetched via the REST API and populate it dynamically. See also #39908.
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
8 years ago
#34
@
8 years ago
- Focuses accessibility added
Couple of considerations:
Labels
As per the Accessibility coding standards, all new code must use an explicitly associated label, that is the ones that don't wrap the associated element and use for/id attributes.
get_input_attrs()
It would be great to make this a general utility to be re-used in other places too, with an option to get or echo or two separate functions for that. See for example something very similar planned to be used for the Settings API revamping ongoing effort on GitHub: https://github.com/wpaccessibility/settings-api-enhanced/blob/50a91ffba9ef857f9b40010b1d8b3684ef645ae4/wp-admin/includes/template.php#L635
/cc @flixos90
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#38
@
8 years ago
Just realized that the default
param from WP_Customize_Setting
is not getting exported from PHP to JS. Sometimes, as in the case of the color control, the default value from the setting is needed by the control. The color control currently copies the setting's default value into the control when the control is exported to the client, but this isn't going to facilitate controls that are added dynamically on the client. So I think something like export-setting-defaults.diff should also be done.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#42
@
7 years ago
I have no objections to export-setting-defaults.diff as a first step toward making this happen.
Also, +1 to including the dropdown-pages control and making use of the Rest API there, although perhaps the options should be included with the control params?
#43
@
7 years ago
- Keywords has-patch needs-testing added; needs-patch removed
I refreshed the patches into 30738.2.diff with PR for review and amending: https://github.com/xwp/wordpress-develop/pull/261
#44
@
7 years ago
Header image control is currently broken (at least).
Also should incorporate the label fixes from #33085.
@
7 years ago
Use settingless-control for display_header_text to avoid element unsyncing https://github.com/xwp/wordpress-develop/pull/261/commits/09e8afd
#45
@
7 years ago
- Priority changed from normal to high
Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.
#46
@
7 years ago
For the approach on how we should handle input_attrs
we should output just the raw key/value pairs and then loop over them in the template to output. This is what I just added in https://core.trac.wordpress.org/attachment/ticket/41872/41872.5.diff
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#48
@
7 years ago
Two examples where this would be coming in handy:
- https://github.com/xwp/wordpress-develop/blob/346e07f0ae26bd8623cba9fe0d609c1205d55859/src/wp-admin/js/customize-controls.js#L6308-L6334
- https://github.com/xwp/wordpress-develop/blob/5a39ca3f5e6e58c797ac7f6d4957f3ec322604e0/src/wp-admin/js/customize-controls.js#L5251-L5261
The templateSelector
, or rather templateId
, or even template
should be a parameter when constructing the control as was recently done for Notifications in r41374.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
7 years ago
#54
@
7 years ago
Here is a demo plugin showing how the new control default template can be used: https://gist.github.com/westonruter/fa261e53208a17a890960b015e5ad4bd
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by melchoyce. View the logs.
7 years ago
#60
@
7 years ago
Another stab at this: https://github.com/xwp/wordpress-develop/pull/289
#62
@
7 years ago
- Resolution set to fixed
- Status changed from accepted to closed
We'll pick this up again in 5.0 via #42272. We'll leave server-registered base controls rendering their content on the server. For controls registered on the client, however, the new base JS templates can be freely used.
#64
@
7 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
There is a problem with JS templates overriding any server-side content supplied for default types. The client-side template should only be used if the control's container is empty.
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
7 years ago
#68
@
7 years ago
Changes look good for 4.9. We should remove empty render_content()
methods from other core controls as well as removing the base PHP templates in the future.
Basically need to convert
WP_Customize_Control::render_content()
into a JS/Underscore template, then hook up the necessary pieces to address this control applying to multiple types.