WordPress.org

Make WordPress Core

Opened 15 months ago

Closed 6 weeks ago

Last modified 2 weeks ago

#37964 closed enhancement (fixed)

Allow customizer controls to be encapsulated by accepting pre-instantiated settings

Reported by: westonruter Owned by: westonruter
Milestone: 4.9 Priority: high
Severity: normal Version: 3.4
Component: Customize Keywords: has-patch needs-unit-tests has-dev-note
Focuses: javascript Cc:

Description (last modified by westonruter)

In #35926 the ability to add setting-less controls was made possible. The work here only went halfway, however. Consider wanting to re-use a control in a standalone context (see #29071), where the settings used in the control are just plain wp.customize.Value instances. Controls should allow pre-instantiated Value (Setting) objects to be passed in as params.settings. And when this is done, there would be no api( settingId... ) deferrals.

So one should be able to create a new control like this:

var control = new wp.customize.Control( 'product_name', {
    // ...
    settings: {
        'default': new wp.customize.Value( 'Something' )
    }
} );

Instead of having to do:

wp.customize.create( 'product_name', 'product_name', 'Something', {} );
control = new wp.customize.Control( 'product_name', {
    // ...
    settings: {
        'default': 'product_name'
    }
} );

The goal is to allow controls to be encapsulated and to be able to use them in standalone contexts or embedded inside of other controls.

Related:

Attachments (2)

37964.0.diff (5.2 KB) - added by westonruter 15 months ago.
37964.1.diff (8.8 KB) - added by westonruter 13 months ago.

Download all attachments as: .zip

Change History (37)

#1 @westonruter
15 months ago

  • Description modified (diff)
  • Keywords has-patch added

#2 @westonruter
14 months ago

Related: #38077 (Facilitating embedding customizer controls outside of sections)

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


14 months ago

#4 @celloexpressions
14 months ago

The patch looks like an improvement to me, although I haven't dug into this code before.

#5 @westonruter
14 months ago

  • Owner set to westonruter
  • Status changed from new to accepted

The patch for this is being tested and improved by @sayedwp.

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


14 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


13 months ago

#8 @westonruter
13 months ago

As part of this, we should also defer adding the elements with the input/setting links until the setting is actually ready, even if the settings all exist up front. This will ensure that delay embedding their contents (or use content template) until ready will also also work as expected with data-customize-setting-link.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


13 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


13 months ago

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


13 months ago

#12 @westonruter
13 months ago

  • Keywords needs-unit-tests needs-testing added

@sayedwp Would you give the latest patch a try?

#13 @sayedwp
13 months ago

Sure I will test it today

Last edited 13 months ago by sayedwp (previous) (diff)

#14 @sayedwp
13 months ago

@westonruter Since the setting less control would not have notifications set by default its throwing error that setting.notifications is undefined, so we probably want to add a condition for control.setupNotifications() ?

I am able to create control using api.DynamicControl using wp-customize-posts plugin without any errors however when I try to add a setting less control in other sections, the control is created and I can see that in console but it does not append/render in the section.

Here is the code I tried

(function( api ) {

	api.section.bind( 'add', function( section ) {
		if ( 'colors' === section.id ) {

			var addSettingLessControl = function addSettingLessControl() {
				var control, id = 'product_color';

				control = new api.Control( id, {
					type: 'color',
					params: {
						section: section.id,
						label: "Test Control",
						active: true,
						type: 'color',
						input_attrs: {
							'data-customize-setting-link': id
						},
						settings: {
							'default': new api.Value( '#000000' )
						}
					}
				} );

				api.control.add( control.id, control );
			};

			section.expanded.bind( function( expanded ) {
				if ( expanded ) {
					addSettingLessControl();
				}
			} );
		}
	} );

})( wp.customize );

Am I doing something wrong here?

Tested with "'4.7-alpha-38934'" and twenty-sixteen theme.

This ticket was mentioned in Slack in #core by stevenkword. View the logs.


13 months ago

#16 @westonruter
13 months ago

  • Milestone changed from 4.7 to Future Release

Sorry I ran out of time. 😞 We'll have to hit this in 4.8.

@sayedwp Any 4.7 checks you have in feature plugins should be bumped to 4.8.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


13 months ago

#18 @westonruter
10 months ago

  • Milestone changed from Future Release to 4.8

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 months ago

#20 @jbpaul17
7 months ago

  • Milestone changed from 4.8 to 4.8.1

Per yesterday's bug scrub, we're going to punt this to 4.8.1.

#21 @westonruter
5 months ago

  • Milestone changed from 4.8.1 to 4.9

This ticket was mentioned in Slack in #core-customize by jeffpaul. View the logs.


2 months ago

#23 @westonruter
2 months 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.

#24 @jbpaul17
2 months ago

  • Owner changed from westonruter to sayedwp
  • Status changed from accepted to assigned

This ticket was mentioned in Slack in #core-customize by jeffpaul. View the logs.


8 weeks ago

#26 @westonruter
7 weeks ago

The changeset date and status are two examples of controls that would benefit from this.

This should be a follow-up on https://github.com/xwp/wordpress-develop/pull/267

#28 @westonruter
7 weeks ago

  • Owner changed from sayedwp to westonruter
  • Status changed from assigned to accepted

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


6 weeks ago

#30 @westonruter
6 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.

#31 @westonruter
6 weeks ago

  • Keywords needs-dev-note added; needs-testing removed

#32 @westonruter
6 weeks ago

  • Description modified (diff)

#33 @westonruter
6 weeks ago

  • Description modified (diff)

#34 @westonruter
3 weeks ago

In 42024:

Customize: Link elements prior to embedding to prevent possible errors when a control is associated with a non-existent section.

Fixes issue specifically with attempting to access an orphaned control's elements immediately after it has been added. Normally this would not happen because a control would not be registered without a section, and also a control should only be interacted with once its embedded deferred has been resolved.

Also harden logic for gathering list of deferred setting IDs.

See #37964.
Fixes #42330.

Note: See TracTickets for help on using tickets.