Make WordPress Core

Opened 8 years ago

Closed 7 years ago

Last modified 6 years ago

#36167 closed enhancement (fixed)

Improve alignment between settings params between Customizer Controls and Partials

Reported by: westonruter's profile westonruter Owned by: westonruter's profile westonruter
Milestone: 4.9 Priority: low
Severity: normal Version: 4.6
Component: Customize Keywords: has-dev-note
Focuses: Cc:


In #27355, the concept of a Partial was introduced and is analogous to a Control in many ways, particularly in that it an object associated with one or more settings. A control is instantiated in JS like:

var control = new wp.customize.Control( 'foo', {
    params: {
        setting: 'default',
        settings: { 'default': 'foo', 'bar': 'bar' },

Whereas a partial is instantiated like:

var control = new wp.customize.Partial( 'foo', {
    params: {
        settings: [ 'foo', 'bar' ],
        primarySetting: 'foo'

Note the difference in how a partial uses primarySetting to designate the main setting for a control, whereas a control has a secondary “setting key” which is used identify which of the settings in the object passed should be the main setting.

Personally, the way settings are passed to Controls is not very intuitive to me, but to improve the parity in the API, perhaps both styles should be accepted by the partial.

Attachments (1)

36167.untested.diff (4.1 KB) - added by westonruter 8 years ago.

Download all attachments as: .zip

Change History (8)

#1 @chriscct7
8 years ago

  • Version trunk deleted

#2 @celloexpressions
8 years ago

  • Keywords 2nd-opinion added
  • Version set to trunk

This is specifically introduced in 4.5/trunk.

I think it could be nice to have parity here, but on the other hand with it not being in 4.5, not sure that it's worth changing later, particularly given the relative complexity of the patch. If anything, since the partial approach is clearer, we may want to update controls to accept that so that we're moving toward a clearer API.

#3 @westonruter
7 years ago

  • Milestone changed from Awaiting Review to 4.9
  • Owner set to westonruter
  • Status changed from new to accepted

#4 @westonruter
7 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 41750:

Customize: Allow controls to be created with pre-instantiated Setting object(s), or even with plain Value object(s).

  • Allow passing settings in keyed object (e.g. settings: { default: 'id' } ), or as an array (e.g. settings: [ 'id' ]) with first being default; again, Setting/Value` objects may be supplied instead of IDs.
  • Allow a single setting to be supplied with just a single setting param, either a string or a Setting/Value object.
  • Update changeset_status and scheduled_changeset_date to be added dynamically with JS and simply passing of api.state() instances as setting.
  • Introduce a data-customize-setting-key-link attribute which, unlike data-customize-setting-link, allows passing the setting key (e.g. default) as opposed to the setting ID.
  • Allow WP_Customize_Control::get_link() to return data-customize-setting-key-link when setting is not registered.
  • Eliminate default_value from WP_Customize_Date_Time_Control since now comes from supplied Value.
  • Export status choices as wp.customize.settings.changeset.statusChoices.
  • Export date and time formats as wp.customize.settings.dateFormat and wp.customize.settings.timeFormat respectively.

Props westonruter, sayedwp.
See #39896, #30738, #30741, #42083.
Fixes #37964, #36167.

#5 @westonruter
7 years ago

  • Keywords needs-dev-note added; 2nd-opinion removed

#6 @westonruter
6 years ago

In 42031:

Customize: Improve Media control accessibility and compatibility for settings passed as arrays or as solitary setting.

  • Eliminate Media control template from having dependency on params.settings.default for element ID, to fix compat with params.settings array or single params.setting. See #36167.
  • Move description out of label and add aria-describedby to Media control's Select button. See #30738, #33085.
  • Obtain notification container whenever content is (re-)rendered (such as for Media control). See #38794.
  • Re-render notifications after control content is re-rendered, if control is in expanded section. See #38794.

Amends [41390].
See #36167, #38794, #33085, #30738.

Note: See TracTickets for help on using tickets.