[wp-trac] [WordPress Trac] #32249: Create extendable base classes of WP_Customize_* so that the rest of WordPress can benefit for its API

[WordPress Trac]

#32249: Create extendable base classes of WP_Customize_* so that the rest of
WordPress can benefit for its API
-------------------------+-----------------------------
 Reporter:  paulwilde    |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:  4.2.1
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 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 [http://wptavern.com/redux-and-kirki-
 frameworks-join-forces-to-provide-better-support-for-the-wordpress-
 customizer 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32249>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform