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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38464 602fd350-edb4-49c9-b593-d223f7449a82
f9feaf1778