[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
-----------------------------------------+------------------

Comment (by celloexpressions):

 Replying to [comment:154 westonruter]:

 The current approach generally works in themes and plugins but I largely
 disagree in the core context - see specific comments below:

 > * I don't think we should discourage the use of Backbone for developing
 controls. As long as a control adheres to the general interface and its UI
 is encapsulated in the control, it shouldn't matter if the control's logic
 is handled by another library, whether that be the Customizer's own
 `Element` logic, the Iris color picker, Backbone views, or even React.

 For core controls, they become less modularly extensible if large amounts
 of the JS logic is implemented outside of the control object. If over time
 in a feature plugin the Backbone approach can be iterated on to work
 within the control object and be modularly extensible, I'm open to
 exploring the options there if it comes into core later. @bradyvercher
 this may, for example, mean that all of the backbone views are within the
 control object.

 The header image control uses a similar approach and has been quite
 difficult to maintain and extend, to the point that all of the other media
 controls have been implemented and improved entirely separately from the
 header image control, which now needs to be updated to go back and use the
 base functionality of the other media controls. I want to avoid a repeat
 of that situation here.

 > * For keeping everything in `customize-controls.js`, just because it is
 so big right now this doesn't mean it has to get bigger. There is already
 precedent for splitting out JS into separate files with `customize-nav-
 menus.js` and `customize-widgets.js`. It makes sense for the post
 collection logic to be in a separate file as well if it is only active
 when theme support is added.

 If this feature were equivalent to menus or widgets I'd agree. But since
 it's a generic control in the public API that's intended to be reused in
 plugins and themes, it should live in the same conventions as the other
 core controls that fit that model. Hopefully if this goes into a plugin
 we'll have a different structure in core by the time it comes back.

 > * Selective refresh is a nice-to-have. Really it's up to the theme to
 add support. I don't think that it's something that necessarily needs to
 be supported in core. Themes register these partials themselves for
 `blogname` and `blogdescription` now with the appropriate selectors.
 Given the importance of selective refresh moving forward, and the
 potential difficulty of adding it to existing core functionality later
 (header images, for example, see notes in #38172), we should build it into
 new core features where it can be included.

 > * Actually I think that Ajax should be used as opposed to filtering. If
 the data being searched/filtered is all posts/pages then thus is is
 unbounded and it is not scalable to include all of them statically in the
 page. (This isn't needed for widgets because they're a limited fixed set.)
 The `dropdown-pages` control needs to eliminate the entire pages tree from
 being exported for each control instance as well.

 If it's posts, perhaps. But my other suggestions lead to a more generic
 control that uses `choices` by default, which could behave like widgets
 do. Then, a child control could add the Ajax part if needed, such as a
 control for showing posts of a given type (which would presumably also add
 lazy-loading/infinite scroll for the data).

 I also do not think this is ready for 4.7 currently.

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