[wp-trac] [WordPress Trac] #35926: Allow controls to be registered without any associated settings

[WordPress Trac]

#35926: Allow controls to be registered without any associated settings
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
     Type:  defect (bug)                         |  westonruter
 Priority:  normal                               |      Status:  reopened
Component:  Customize                            |   Milestone:  4.5
 Severity:  normal                               |     Version:  3.4
 Keywords:  has-patch has-unit-tests commit      |  Resolution:
  close                                          |     Focuses:
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests commit => has-patch has-unit-tests
     commit close


Comment:

 @dlh interesting. The JS constructor is definitely confusing. I checked
 out the state of Core before [36689] and I could replicate what you did. I
 think however your code wasn't quite right to begin with, however. If you
 look at:

 {{{#!js
 var control = wp.customize.control.create( 'baz', 'baz', {
     setting: setting,
 });
 }}}

 If you look at `control.deferred.embedded.state()` you'll see that it is
 "pending". Why? Because the `params.settings` were empty and so the
 deferred callback never fired, and so `control.embed()` was never called.
 This means your control's `ready()` callback was also never called, unless
 you were calling it manually. (Also, this `embedded` deferred won't
 resolve since no `section` param is provided.)

 The proper way to instantiate the control in the way that core does it
 when the Customizer boots up is like this (to adapt your example above):

 {{{#!js
 var control = wp.customize.control.create( 'baz', 'baz', {
     params: {
         settings: { 'default': setting.id },
     }
 });
 }}}

 Take these two other examples for how controls are instantiated
 dynamically in Core:
 https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-admin/js
 /customize-nav-menus.js#L2276
 https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-admin/js
 /customize-widgets.js#L1991

 It is not intuitive why there is an additional `params` property here but
 that's just how these JS constructors take their arguments.

 The reason why `control.setting` made its way through before was because
 of this line in the `Control`'s `initialize` method:

 {{{#!js
 $.extend( control, options || {} );
 }}}

 But this is not the way the control expects the setting to be passed in,
 as it needs to be part of the `params` object. With the most recent
 changes in [36689], the `setting` will get set explicitly to `null` if no
 `settings` are provided.

 So I ''think'' the resolution is to close this since the usage you were
 using, although intuitive, wasn't actually the way that Core constructs
 the controls.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35926#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform