[wp-trac] [WordPress Trac] #37270: Improve handling of active state for dynamically-created controls/sections/panels

[WordPress Trac]

#37270: Improve handling of active state for dynamically-created
controls/sections/panels
--------------------------+-----------------------------
 Reporter:  westonruter   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Customize     |     Version:  4.0
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  javascript
--------------------------+-----------------------------
Changes (by westonruter):

 * keywords:   => needs-patch
 * version:   => 4.0


Old description:

> When a control, section, or panel is dynamically created in JS and
> doesn't have a corresponding construct that gets created in PHP, then
> when the preview refreshes the construct won't be included among the
> `activeControls`, `activeSections`, or `activePanels` and so it will get
> its `active` state set to `false`. A workaround as used for nav menu
> items is to define `control.active.validate` to override whatever is
> being sent from the preview:
>
> {{{#!js
> control.active.validate = function() {
>         var value, section = api.section( control.section() );
>         if ( section ) {
>                 value = section.active();
>         } else {
>                 value = false;
>         }
>         return value;
> };
> }}}
>
> The problematic code in Core is:
>
> {{{#!js
> var active = !! ( activeConstructs && activeConstructs[ id ] );
> }}}
>
> This is not ideal, and it means that a plugin cannot programmatically do
> `control.active.set( false )`.
>
> As suggested in an [https://github.com/xwp/wp-customize-
> posts/issues/157#issuecomment-223343369 issue on Customize Posts], we
> could improve the situation by discontinuing from considering constructs
> that are absent in the preview when determining whether to change the
> `active` state, which would specifically be for any constructs that are
> dynamically created:
>
> {{{#!js
> var active, isDynamicallyCreated;
> if ( ! _.isUndefined( activeConstructs[ id ] ) {
>     active = _.isUndefined( activeConstructs[ id ];
> } else {
>     isDynamicallyCreated = ! _.isUndefined( wp.customize.settings[ type +
> 's' ][ id ] );
>     active = isDynamicallyCreated ? null : false;
> }
> if ( _.isBoolean( active ) ) {
> ...
> }}}

New description:

 When a control, section, or panel is dynamically created in JS and doesn't
 have a corresponding construct that gets created in PHP, then when the
 preview refreshes the construct won't be included among the
 `activeControls`, `activeSections`, or `activePanels` and so it will get
 its `active` state set to `false`. A workaround as used for nav menu items
 is to define `control.active.validate` to override whatever is being sent
 from the preview:

 {{{#!js
 control.active.validate = function() {
         var value, section = api.section( control.section() );
         if ( section ) {
                 value = section.active();
         } else {
                 value = false;
         }
         return value;
 };
 }}}

 The problematic code in Core is:

 {{{#!js
 var active = !! ( activeConstructs && activeConstructs[ id ] );
 }}}

 This is not ideal, and it means that a plugin cannot programmatically do
 `control.active.set( false )`.

 As suggested in an [https://github.com/xwp/wp-customize-
 posts/issues/157#issuecomment-223343369 issue on Customize Posts], we
 could improve the situation by discontinuing from considering constructs
 that are absent in the preview when determining whether to change the
 `active` state, which would specifically be for any constructs that are
 dynamically created:

 {{{#!js
 var active, isDynamicallyCreated;
 if ( ! _.isUndefined( activeConstructs[ id ] ) {
     active = _.isUndefined( activeConstructs[ id ];
 } else {
     isDynamicallyCreated = ! _.isUndefined( wp.customize.settings[ type +
 's' ][ id ] );
     active = isDynamicallyCreated ? null : false;
 }
 if ( _.isBoolean( active ) ) {
 ...
 }}}

 Contextual controls were introduced in #27993 with contextual
 sections/panels in #29758.

--

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