WordPress.org

Make WordPress Core

Opened 2 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#42083 closed enhancement (fixed)

Customize: Clean up longstanding annoyances in JS API

Reported by: westonruter Owned by: westonruter
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Customize Keywords: commit
Focuses: Cc:

Description

There are some annoyances when working with the JS API which aren't present when working with the PHP API. In particular:

  • Manually crafting the content param for the <li> container.
  • Lack of default params for active=true and priority=10.
  • Having to create panels, sections, and controls with an options object that contains a single params key with the actual object that has the options in it. Why not just pass params directly?
  • Inability to specify the templateId via param.
  • Redundantly having to supply an id in addition to an instance when add'ing a Panel, Control, Notification, or any other such object that is added to Values instances.

This is a subset of #30741.
Initially #28709 and #29572 .

Attachments (1)

30741.0.diff (42.9 KB) - added by westonruter 2 weeks ago.
https://github.com/xwp/wordpress-develop/pull/274

Download all attachments as: .zip

Change History (5)

#1 @westonruter
2 weeks ago

  • Keywords commit added
  • Owner set to westonruter
  • Status changed from new to accepted

#2 @westonruter
2 weeks ago

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

In 41726:

Customize: Improve usability of Customize JS API.

  • Eliminate need to pass both ID and instance in calls to Values#add() for panels, sections, controls, settings, partials, and notifications.
  • Eliminate need to supply content param when constructing a Control.
  • Unwrap the options.params object passed in constructors to just pass a flat options. (Back-compat is maintained.)
  • Add support for templateId param for Control to override which template is used for the content.
  • Remove unused previewer being supplied in Control instances.
  • Rename classes to containerClasses on Notification.
  • Automatically supply instanceNumber to improve stable sorting.
  • Use api.Notifications for notifications in settings instead of api.Value.

See #30741.
Fixes #42083.

#3 @westonruter
2 weeks ago

In 41739:

Customize: Fix theme details modal by updating logic in getPreviousTheme and getNextTheme to not rely on DOM traversal and manually constructing control IDs.

Amends [41726].
See #42083, #37661.

#4 @westonruter
2 weeks ago

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.

Note: See TracTickets for help on using tickets.