[wp-trac] [WordPress Trac] #33552: Facilitate plugins to override Customizer features

[WordPress Trac]

#33552: Facilitate plugins to override Customizer features
------------------------------------+------------------
 Reporter:  westonruter             |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  4.4
Component:  Customize               |     Version:  3.9
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------

Comment (by westonruter):

 @DrewAPicture first of all, the `$components` would need to be iterated
 over in a `foreach` loop, right?

 To me it seems the primary use case of this filter is to remove components
 from being added. For instance:

 {{{
 add_filter( 'customize_components_to_load', function( $components ) {
     return array_filter( $components, function ( $component ) {
          return 'nav_menus' !== $component;
     } );
 } );
 }}}

 But what about the other non-removal use cases, where new components might
 be added or existing ones replaced?

 If I want to introduce a new component for “posts” then it seems I would
 need to do basically hack the filter to serve as an action:

 {{{
 add_filter( 'customize_components_to_load', function( $components,
 $wp_customize ) {
     $wp_customize->posts = new My_Customize_Posts( $wp_customize );
     return $components;
 }, 10, 2 );
 }}}

 If I want to replace the current `widgets` implementation with a different
 one, I would have to do something like:

 {{{
 add_filter( 'customize_components_to_load', function( $components,
 $wp_customize ) {
     // First remove widgets entirely so that it won't get constructed.
     $components = array_filter( $components, function ( $component ) {
          return 'widgets' !== $component;
     } );

     // Now instantiate the the custom implementation now that the default
 widgets one won't be.
     $wp_customize->widgets = new My_Customize_Widgets( $wp_customize );
     return $components;
 }, 10, 2 );
 }}}

 So I'm not sure.

 Maybe it would work better if `customize_components_to_load` was filtering
 a mapping of component name to class name. For instance:

 {{{
 $components = array(
     'widgets' => 'WP_Customize_Widgets',
     'nav_menus' => 'WP_Customize_Nav_Menus',
 );
 $components = apply_filters( 'customize_components_to_load', $components,
 $this );
 }}}

 And then it could do:

 {{{
 foreach ( $components as $component => $class ) {
     $this->$component = new $class( $this );
 }
 }}}

 This would, however, not play nicely with the `require`ing of the class
 file, so those should `require_once` statements should remain where they
 are at the top, or else changed to be something lower down like:

 {{{
 if ( isset( $components['widgets'] ) ) {
     require_once( ABSPATH . WPINC . '/class-wp-customize-widgets.php' );
 }
 if ( isset( $components['nav_menus'] ) ) {
     require_once( ABSPATH . WPINC . '/class-wp-customize-nav-menus.php' );
 }
 }}}

 What this implies is that `\WP_Customize_Widgets` and
 `\WP_Customize_Nav_Menus` can never be pluggable to be replaced with any
 other classes. If you want to use a different class for managing menus,
 then you'd have to do:

 {{{
 add_filter( 'customize_components_to_load', function( $components) {
     require_once MY_PLUGIN_DIR . '/class-my-customize-nav-menus.php';
     $components['nav_menus'] = 'My_Customize_Nav_Menus';
     return $components;
 } );
 }}}

 But both of the `My_Customize_Nav_Menus` and `WP_Customize_Nav_Menus`
 would both be loaded regardless, even though the latter would never be
 used.

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