Customize: Improve handling of active state for dynamically-created controls/sections/panels.
When a customizer construct (panel, section, control) is not added in PHP, the JS has interpreted this to mean that a given construct should be deactivated (because it is gone). This is problematic for dynamically-created constructs in JS, as it has meant that the construct would also have to be created in PHP to ensure the `active` callback is called, or else a hack would be required to add a `construct.active.validate = function() { return true };` to forcibly prevent the construct from getting deactivated. These workarounds can be eliminated by treating constructs differently when they are created dynamically in JS (after page load) as opposed to being created statically in PHP (on the server). Namely, if a construct is dynamically-created then its absence in a preview refresh should not signal that the construct should be deactivated. Rather, a dynamic construct should only have its activation state toggled if it has a corresponding construct created in PHP when the preview refreshes to explicitly indicate its `active` state. Otherwise, the management of the `active` state for a construct created in JS should also be the responsibility of client-side code. Props westonruter, sayedwp. Fixes #37270. Built from https://develop.svn.wordpress.org/trunk@38464 git-svn-id: http://core.svn.wordpress.org/trunk@38405 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit is contained in:
parent
153ba4a832
commit
9546303342
|
@ -2966,11 +2966,24 @@
|
|||
};
|
||||
_( constructs ).each( function ( activeConstructs, type ) {
|
||||
api[ type ].each( function ( construct, id ) {
|
||||
var active = !! ( activeConstructs && activeConstructs[ id ] );
|
||||
if ( active ) {
|
||||
construct.activate();
|
||||
} else {
|
||||
construct.deactivate();
|
||||
var isDynamicallyCreated = _.isUndefined( api.settings[ type + 's' ][ id ] );
|
||||
|
||||
/*
|
||||
* If the construct was created statically in PHP (not dynamically in JS)
|
||||
* then consider a missing (undefined) value in the activeConstructs to
|
||||
* mean it should be deactivated (since it is gone). But if it is
|
||||
* dynamically created then only toggle activation if the value is defined,
|
||||
* as this means that the construct was also then correspondingly
|
||||
* created statically in PHP and the active callback is available.
|
||||
* Otherwise, dynamically-created constructs should normally have
|
||||
* their active states toggled in JS rather than from PHP.
|
||||
*/
|
||||
if ( ! isDynamicallyCreated || ! _.isUndefined( activeConstructs[ id ] ) ) {
|
||||
if ( activeConstructs[ id ] ) {
|
||||
construct.activate();
|
||||
} else {
|
||||
construct.deactivate();
|
||||
}
|
||||
}
|
||||
} );
|
||||
} );
|
||||
|
|
File diff suppressed because one or more lines are too long
|
@ -4,7 +4,7 @@
|
|||
*
|
||||
* @global string $wp_version
|
||||
*/
|
||||
$wp_version = '4.7-alpha-38463';
|
||||
$wp_version = '4.7-alpha-38464';
|
||||
|
||||
/**
|
||||
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
|
||||
|
|
Loading…
Reference in New Issue