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

 In [attachment:37974.18.diff] the JS is refactored to:

 * Remove the drawer Backbone model and collection in favor of a drawer
 object extending `wp.customize.Class` (similar to sections and panels)
 * Move search-related logic into a `PostSearchDrawer`
 * Encapsulate views in related objects

 Replying to [comment:159 celloexpressions]:

 > 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.

 A temporary container can be injected in the preview using `loop_start`
 and `loop_end`, which should allow the edit icon to work. Beyond that,
 registering a partial callback isn't really possible since the output is
 controlled by the theme. It might be possible to use JS to move or remove
 the sections instantly, but a full refresh needs to happen any time a new
 section is inserted to ensure any new styles and scripts are loaded and
 initialized.

 > 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).

 Selected posts for this control have always been exported to JS for the
 initial load, with AJAX being used to search for additional posts. Using
 AJAX this way is used in multiple places throughout WordPress, including
 when searching for menu items in the Customizer and is pretty critical to
 ensure this scales.

 Replying to [comment:163 pento]:

 I looked into using the REST API last night, but reverted due to the lack
 of an endpoint for fetching any post type. I've used the Backbone.js
 client for single post types before and really liked the way it works. I'm
 already pretty familiar with `rest_do_request()`, but your thoughts on
 other aspects of the REST API echo my own.

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