Create extendable base classes of WP_Customize_* so that the rest of WordPress can benefit for its API

[paulwilde]

This is a grand plan ticket so bare with me here, but I think it has the potential of changing a lot of WordPress for the better.

The Customiser holds a lot of logic for handling form fields that the rest of WordPress could take advantage of. I propose we abstract out these classes so that there's a base class that other parts of WordPress could extend. This would basically be the first step in order to create a consistent API for creating meta box fields (See #), and (eventually) a front-facing API for adding custom fields to taxonomy pages once term meta is in core.

This could also be used to update all of the Setting screens away from tables and having all of those fields registered in the same consistent way as well adding/removing widget & user fields and because the base classes would be a public API plugin developers could extend it and use it for front-end forms and such.

Here's a breakdown of the current structure, and what I'd suggest for abstracting things out:

• WP_Customize_Control holds a lot of logic for rendering form controls that could be used elsewhere inside WordPress for outputting fields by creating a WP_Form_Control class which WP_Customize_Control would extend.

• WP_Customize_Setting holds the logic for saving the values of these controls, so this could be abstracted into WP_Form_Setting and then WP_Customize_Setting extends this base class and holds customiser specific logic (mainly just adding theme_mod as an option).

• WP_Customize_Manager handles the bulk of the front-facing API of adding/getting/removing sections, panels, controls and registering the default controls associated with the customizer. This could extend a WP_Form_Manager class that would handle the majority of this code. WP_Customize_Manager would then simply handle customizer specific things such as panels and creating all of the default objects.

• WP_Customize_Panel and WP_Customize_Section seem to repeat the same code twice except for how each renders the HTML. A separate WP_Form_Group class would be created that moves most of this repetitive code away.

Once the abstraction has happened separate classes could be created that handles object specific areas of the admin (post types, taxonomies, settings, etc).

Advantages:

• As people begin to learn how the customiser API works, once the other parts of WordPress move over to use the same API everything is consistent and easy to pick up. Once you understand how to add fields to the customiser, you automatically know how to do the same everywhere else in WordPress. That currently isn't the case as everything is different.
• Once a control type is added to WordPress core (say for example a WYSIWYG editor) all of WordPress could take advantage of that control. There already seems to be some interest in adding several more control types into the customiser (See ​here).
• This would give the opportunity to update all of the Setting screens away from tables (See #16413).
• This would pave the way to an API to add fields to post meta boxes, one of the most wanted features by the majority of developers.
• The customiser is moving forward faster than the rest of WordPress. If everything else shared the same API then everything would benefit.
• Although I haven't really digged into the Javascript side of the Customiser I'm going to assume that if everything were to use this API then some of the Customiser code could also be abstracted out so things like conditional display logic could be possible elsewhere inside the admin.

Disadvantages:

• This could potentially create a lot of classes in the long run. I'm not sure if this is a disadvantage as such, but it's at least noteworthy.

If there's any interest in taking things in this direction (oh please let there be), I'd be interesting in helping drive this thing forward. It would be nice to get the base classes complete in 4.3 (maybe its too late now?) so that 4.4 could then begin to take advantage by beginning to move each part of WordPress (release by release) over to the new API whilst adjusting the existing API to still work for backwards compatibility.

[paulwilde]

This ticket can be closed.

It appears there's ​already an effort I wasn't aware of that is looking at bringing the same sort of abstraction into core.