[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 westonruter):

 Sorry I haven't been able to follow development here more.

 Replying to [comment:114 celloexpressions]:
 > …

 A few points:

 * 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. The
 most important thing is ensuring that there is bidirectional sync between
 the control's `setting` and the UI state for the control. So this means
 there should be a: `control.setting.bind( function( value ){ ui.setState(
 _.clone( value ) ); } )` and `ui.onChange( function( value ) {
 control.setting.set( _.clone( value ) ); } )`. I don't see this in the
 patch, so it needs to be added.
 * 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.
 * 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.
 * 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.

 I think I agree with @NateWr that we could just bundle this functionality
 in Twenty Seventeen itself for 4.7. It seems we're rushing to try to get a
 generic solution that will satisfy any theme but if we're hasty then we
 could end up adding something we have to support with backwards-
 compatibility that we may not be fully satisfied with or haven't given
 enough time to bake. If it is part of Twenty Seventeen then it can be
 better iterated on for that theme, other themes can also iterate on their
 own forks, and then in 4.8 we can come back together to assemble a core
 patch that handles the use cases that come to light after enough
 rumination time.

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