Make WordPress Core

Opened 10 years ago

Closed 7 years ago

#30740 closed enhancement (maybelater)

WP_Customize_Manager::register_control_type should also address registering JS subclasses

Reported by: celloexpressions's profile celloexpressions Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description (last modified by westonruter)

There are a couple of steps required to leverage JS for custom Customizer controls. In addition to declaring the object, which is basically like subclassing in PHP, you have to extend the Customizer's controlConstructor with the subclass.

It seems like register_control_type() could also take care of this (in addition to printing JS templates for controls), if we added an optional second argument for the JS class name. This would lower the barrier to creating new JS-heavy Customizer controls, and also make the somewhat annoying step of registering the control type more useful.

Essentially, we would be introducing a mechanism to do this automatically:

 * Extends wp.customizer.controlConstructor with control constructors for
 * menu_item, nav_menu, and new_menu.
$.extend( api.controlConstructor, {
        menu_item: api.Menus.MenuItemControl,
        nav_menu: api.Menus.MenuControl,
        new_menu: api.Menus.NewMenuControl

Change History (5)

#1 @westonruter
10 years ago

  • Description modified (diff)

Good idea.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.

9 years ago

#3 @celloexpressions
9 years ago

Noting that we should also do the same for custom panel and section types, which currently have the JS API part and will get register_panel|section_type() in #30737.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.

7 years ago

#5 @westonruter
7 years ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from new to closed

I'm not sure of the need for this now. Basically what I think this would look like is adding some JS identifier in the call to register_control_type, for example given a My_Custom_Control PHP class that has a $type of my_custom this ticket would entail doing something like this:

$wp_customize->register_control_type( 'My_Custom_Control', 'MyCustomPlugin.Control' );

Which would then translate into PHP generating this JS:

wp.customize.controlConstructor[ "my_custom" ] = MyCustomPlugin.Control;

However, we have to enqueue the JS for MyCustomPlugin.Control anyway, so it is just as easy to handle that in the JS file where that is defined to begin with, for example:

wp.customize.controlConstructor.my_custom = ( function() {
    var MyCustomPlugin = wp.customize.Control.extend({ /*...*/ });
    return MyCustomPlugin;
} )();

This is what I've been doing for the past couple years and it works great.

Note: See TracTickets for help on using tickets.