WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 2 weeks ago

Last modified 2 weeks ago

#36167 closed enhancement (fixed)

Improve alignment between settings params between Customizer Controls and Partials

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

Description

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 20 months ago.

Download all attachments as: .zip

Change History (6)

#1 @chriscct7
19 months ago

  • Version trunk deleted

#2 @celloexpressions
19 months 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
2 weeks ago

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

#4 @westonruter
2 weeks 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
2 weeks ago

  • Keywords needs-dev-note added; 2nd-opinion removed
Note: See TracTickets for help on using tickets.