[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:  ux-feedback     |     Focuses:  ui
----------------------------+------------------

Comment (by celloexpressions):

 I stand by my significant concerns with the size of the patch and the lack
 of thorough integration with the customizer API. Especially considering
 that it is only for the UI in the customizer currently. If we want this
 UI, some additional specific technical guidelines for doing it in core are
 below.

 As I have stated previously, I do not have time to work on this patch, but
 I will provide feedback to make sure that we get to something that's
 appropriate for core. Once it's ready, I'll do a line-by-line code review,
 but we're not there yet.

 The UX feels pretty good. There is a significant lack of consensus on what
 problem we're trying to solve and whether this is the right solution, but
 this approach has been selected as the solution for now. The code needs
 work.

 ----

 Large self-contained control objects work against the principles of the
 API. In the API, complex UI is structured with multiple control, section,
 and panel objects and each object provides (the ability for) a hierarchy
 of children objects than can extend base functionality to do more specific
 things. This approach results in much less code being required to build
 things with the API, whether they're in core or in themes and plugins. For
 this feature, it might actually mean more code initially, but it would
 provide functionality that can be built on much more easily.

 The current patch reminds me of the header image control implementation,
 which has proven extremely difficult to maintain and has a completely
 separate codebase from the other media controls (for historical reasons),
 with a lot of the logic existing outside of the control object. If this
 can't be properly maintained moving forward within the structure of the
 customize API, we should not add it to core.

 The customize JS API integrates a lot of backbone functionality
 internally. It shouldn't (but might) be necessary to use Backbone directly
 (menus and widgets kind of do, but not really, and need to be updated to
 remove that). All of the Backbone pieces, and really all of the JS, needs
 to be contained within section or control objects at a minimum.

 Menus and widgets ''introduced'' the flyout panel UI and due to the
 massive scope of those projects, it was infeasible to abstract it in a
 meaningful way. Here, though, there is no reason to build yet another copy
 of it in a siloed way. And in fact, building it in a reusable way would
 drastically improve the overall quality of the solution to the API as a
 good chunk of the code will go toward something that is reusable in
 plugins. It should not be particularly difficult to extract that in the
 current patch as either a distinct control or a section, with a child
 control or a control within the section adding the pages UI to it.

 One UI adjustment that would provide a bit of simplification - since it's
 only up and down and the items aren't expandable, the reorder toggle
 should be removed in favor of showing the up/down icons directly. Users
 almost never notice the reorder button in testing, so it's better for
 discoverability and accessibility for that to always be on since there's
 room for the buttons here.

 A tight deadline isn't an excuse for rushing something into core that is
 not ready. Especially for a (theoretically) smaller feature in terms of
 UI, that is asking for trouble down the line. I'd love to see this happen,
 but it does take time to get it right. Deadlines are not arbitrary.

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