[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:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Themes           |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by westonruter):

 It seems like the initial implementation on WordPress.com is limited to
 only configuring a single multi-panel page, and specifically here it is
 the homepage (I see the `is_front_page` in there as the
 `active_callback`). Is that right?

 If the intention is for there to be multiple pages that have this kind of
 multi-panel configuration, then rather than introducing a new `multipanel-
 page` theme support flag, this could instead be indicated at the template
 level itself (template support?). For example, say there is a `multi-
 panel.php` page template file which has a header:

 {{{
 <?php
 /*
  * Template Name: Multi-Panel Page
  */

 add_template_support( 'multi-panel', array(
     /* define panels here */
 ) );
 }}}

 In this way, different page templates could have different panel
 configurations. When such a page is loaded in the customizer, the preview
 could then communicate up to the pane that it is previewing a multi-panel
 template and then dynamically create the required panel/section/controls
 as required to manage the content for that page.

 As for how the data gets stored, to me it seems @NateWr's suggestion to
 store the structured content in shortcodes embedded in the content is the
 most practical and it also aligns with what @jeremyfelt described. Having
 the panel (content block content) stored in `post_content` will ensure it
 is searchable. If the content is encoded as shortcodes in `post_content`
 then shortcodes can in fact be represented visually in the visual editor
 using TinyMCE views and could even adopt some of Shortcake. Since TinyMCE
 views can be drag and dropped now in core, these actually are content
 blocks. If there is then a lightbox that opens when clicking a TinyMCE
 view's toolbar (like the `gallery` shortcodes) the  could then display
 controls for manipulating the shortcode's fields, and these controls could
 be the same controls that are displayed in the customizer sections (I have
 some [https://github.com/xwp/standalone-customizer-controls proof of
 concept code] showing customizer controls being used outside the
 customizer entirely). As much as I would love to guide more users into the
 customizer to edit such multi-panel configurations (er, content) it seems
 that this could be implemented in the edit post screen as well via TinyMCE
 views representing shortcodes.

 Challenges I see with using shortcodes in this way is maybe they actually
 shouldn't be movable. The multi-panel idea is described here as though the
 content in each panel is displayed where the template defines, not where
 the user defines. So even if someone were to drag a shortcode up to the
 top of the content, maybe the template would still display it in the
 footer. So perhaps these multi-panel configurations that get encoded in
 shortcodes could have no visual representation at all? In an edit post
 screen context, maybe the interfaces for editing the panels would look
 like metaboxes that have the controls that read/write data from the
 content.

 Another problem with what I described here is that if the panel editing
 should also be doable from the edit post screen, a
 `add_template_support()` wouldn't really work because the configurations
 would need to be declared in a way that doesn't require the template to be
 run. Consider switching out a page template in the edit post screen and
 how switching the page template there could cause the metaboxes available
 to change according to what panels the template supports.

 Last note: the [https://wordpress.org/plugins/customize-posts/ Customize
 Posts] plugin has a feature whereby the Preview button on the edit post
 screen will open the customizer to preview that post's preview URL. The
 customizer section that contains the fields for that post (title, content,
 author, etc) is autofocused and changes made to those fields are synced
 back to the edit post screen so that when you close the customizer you can
 then Update/Publish the post and at that point the changes go live. This
 kind of setup could bridge the gap between exposing the editing of the
 panel configurations in the customizer but providing a way to easily
 access them from the edit post screen. In this way, the editing
 experiences wouldn't have to be duplicated between the edit post screen
 and the customizer, and changing the page template on the edit post screen
 wouldn't then have to load up a different UI based on what the selected
 template supports (since the selected page template would be known up-
 front when the customizer loads).

 Sorry for the long comment.

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