[wp-trac] [WordPress Trac] #29071: Make it easier to include an instance of the Customizer outside of customize.php

[WordPress Trac]

#29071: Make it easier to include an instance of the Customizer outside of
customize.php
-------------------------+-----------------------------
 Reporter:  ericlewis    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Customize    |     Version:  3.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+-----------------------------

Comment (by westonruter):

 Replying to [comment:8 ericlewis]:
 > In attachment:29071.3.diff, wrap bootstrapping code for the default
 customizer experience into a function, and return early if its not the
 default customizer instance (customize.php).

 There's an awful lot of code that is going to be unreusable if we go this
 route. The majority of the code in `bootstrapDefaultCustomizerInstance`
 would only be usable on the main Customizer page.

 Should `bootstrapDefaultCustomizerInstance()` perhaps instead be replaced
 with something like `wp.customize.init()`? The `customizer.php` page could
 then manually invoke it at the end after all scripts are printed,
 something like:

 {{{
 <script type="text/javascript">
 var _wpCustomizeSettings = <?php echo json_encode( $settings ); ?>;
 </script>
 <script>
 $(function () {
     wp.customize.init({
         settings: window._wpCustomizeSettings, // or 'config' instead
         l10n: window._wpCustomizeControlsL10n // not 100% sure on this one
     }); // or window._wpCustomizeSettings could be the only argument
 passed into init
 });
 </script>
 }}}

 This would keep `customize-controls.js` from attempting to bootstrap
 itself, which would improve reusability.

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