[wp-trac] [WordPress Trac] #37974: Add multi-panel feature to pages through add_theme_support

[WordPress Trac]

#37974: Add multi-panel feature to pages through add_theme_support
-----------------------------------------+------------------
 Reporter:  karmatosed                   |       Owner:
     Type:  task (blessed)               |      Status:  new
 Priority:  normal                       |   Milestone:  4.7
Component:  Themes                       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-ux-feedback needs-patch  |     Focuses:  ui
-----------------------------------------+------------------
Changes (by celloexpressions):

 * keywords:  has-ux-feedback has-patch => has-ux-feedback needs-patch


Comment:

 For the customizer integration there are two primary things we need to
 work on. The first is the control (and possibly section) structure and
 hierarchy. The second is the JS, which is structured differently from
 (most of) the rest of the customize API in using Backbone.js. There are
 many ways to go about addressing these, but I'll offer a couple of
 specific options to speed up the process.

 Possible (distinct) options for control/section structure:
 - Look into extending the dropdown pages control to create a sortable
 multi-selector. This would probably (but not necessarily) require
 different UI, but is probably the simplest option in terms of the API. The
 dropdown-pages control will gain the ability to create new pages from any
 control instance in #38164, so that's another major advantage here.
 - Split this into two controls: one for the sortable and deletion UI, and
 one for the slide-out addition UI. These are distinct UI controls that
 belong as separate control objects to facilitate re-usability.
 - Split this into a control for sortable objects, a section that slides
 out, and a control in the slide-out section that displays objects to add.
 This is one of the more modular ways to approach it, and would bring major
 improvements for themes and plugins to use.
 - Keep everything in one control, but make it more generic.
 `WP_Customize_Sorted_Multi_Select_Control` or something. Simplify it to
 use the `choices` attribute inherited from the base customizer control to
 define the objects that can be added and sorted, as `key => value` pairs
 in an array. Use a `labels` attribute for the button, search, etc. labels,
 allowing control indexes to adapt the UI text easily (the media controls
 do this to an extent). Then, the front page sections control can be added
 as an instance of this generic control with its relevant sections. If
 necessary, a child control can be made to override specific aspects of the
 functionality as needed, but I don't think that would be needed here,
 since pages can be passed in as `choices` and the labels can be defined
 when registering the control instance, and future functionality changes
 could make use of a child control if needed. The Site Icon control is a
 good example of this - it was introduced alongside the cropped image
 control, and nearly all of the functionality developed for icons was made
 available more generically as the cropped image control with only a small
 amount of functionality staying in the site icon control.

 As I mentioned previously, the Backbone approach doesn't jive well with
 the customizer API. As an example, the theme controls (currently and with
 the changes in #37661) were actually adapted from the Backbone-driven
 admin pages and refactored to be native to the customize API. I don't know
 if one way or the other is better from various perspectives, but because
 the customizer API is public, it's important that core controls are
 internally consistent and can be modularly extended. Some specific changes
 that will be required from the current JS structure:
 - All of the JS needs to be encapsulated into control (or section)
 objects. This allows child controls to override specific pieces of
 functionality in a modular way. The core media controls have some good
 examples of this.
 - The `content_template` for each control should probably be the only
 templates used. If templates are needed for various pieces they should
 each have their own function so that they can be modularly overwritten by
 subcontrols. However, templates can contain loops if needed, and the re-
 rendering approach that the media controls use works pretty well. Consider
 whether each customize object could use a single template.
 - Other parts of the API tend to use Underscore.js as needed, but not
 Backbone.js (with exceptions that need to eventually be updated
 accordingly). The Backbone views, models, and collections should be
 updated to use core customize API structure, with data stored within
 control and section objects that also handle UI and dynamic UI as needed.
 Using more customizer objects (such as a section for the slide-out and a
 control for each object that can be added with it) would provide a
 structure that could parallel the current approach more closely, but it's
 probably better to keep it simpler than that based on what's currently
 needed.

 Other things to note:
 - The JS (unfortunately) needs to go in `customize-controls.js`. Yes, this
 file is massive and ridiculous. It will be split up eventually, perhaps
 early in 4.8. But for now, that's where all core control, section, and
 panel JS belongs, with the exception of menus and widgets because of the
 sheer size of those files. This is another reason that it's important for
 all of the JS to be encapsulated in section and control objects.
 - The current patch still introduces more new CSS than I'd like, but most
 of it is probably necessary. We should simplify and combine selectors as
 much as possible.
 - Search probably shouldn't happen with Ajax. Instead, it should be
 implemented in JS similar to the widget filter, with all of the `choices`
 for the control instance being searched. Hover/focus styling should match
 available widget items, by the way. Ajax actions can get messy with
 controls that are intended to be used for a wide variety of things, and is
 unnecessary complexity since all of the data is available locally.
 - The convention for the slide-out UI is to maintain the width of the
 preview and slide it over (partially out of view), so that the preview
 doesn't go through responsive layout changes when opening and closing the
 slide-out.
 - Visibility toggles, if implemented in JS for consistency with the other
 places where core does that, should be placed alongside the other core
 visibility toggles. I think I'd prefer an `active_callback` set to `(
 is_front_page() && ! is_home() )`, but the JS approach also works.
 - Selective refresh is the core-recommended way to preview setting changes
 in the customizer. Therefore, all new core customize features should
 support selective refresh. It'll be tricky to do here, for sure, but we
 need to try to get a partial for the whole content area that refreshes, at
 least. This brings the potential for visible edit icons and is very
 important for usability. Themes may need to specify a selector for it in
 their add-theme-support call.

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