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

Comment (by NateWr):

 Replying to [comment:21 ThemeZee]:
 > If a Core solution only allows to select some featured pages as multi-
 panel then I think we don't need it.

 I tend to agree with this. The multi-panel concept as initially outlined
 doesn't need core support and probably shouldn't have it. A custom
 customizer control will do the trick. I suppose that could be built into
 core but it doesn't seem particularly valuable unless it really addresses
 the data storage issue as well.

 Replying to [comment:22 melchoyce]:
 > How do existing themes handle interfaces like this? I know many are
 around that have rolled their own solution. What do those solutions look
 like? Can any themers chime in?

 I've seen a lot of attempts to nail this which try to focus on either the
 UX or the data storage problems. Solving them both is the really difficult
 thing. Even if an individual solution nails the UX component, in the
 broader WordPress ecosystem this quickly leads to more generalized UX
 problems such as performance issues and headaches migrating between
 solutions. These problems may not be as apparent in a controlled ecosystem
 like WordPress.com. But they represent some of the most critical UX issues
 for the rest of us.

 I have made my own attempt to solve this problem as well, though I can't
 recommend it wholesale for core. I'll outline how it works technically,
 link to video/code showing it in action, and then describe a few of the
 pitfalls it encounters.

 The code is a small library which is included in a theme, which creates a
 new customizer control. This control basically recreates the widget
 interface, but instead of using widgets the themer must create components
 specifically for this control (eg - whitelisted components rather than any
 widget). These components are added and edited in the Customizer, and when
 saved this data is rendered and saved into the page's `post_content`.

 A short video showing it in-action (this is a marketing video so apologies
 for the obnoxious music):
 https://www.youtube.com/watch?v=jAEyQHQsDGE

 The library on GitHub:
 https://github.com/NateWr/content-layout-control

 A very basic demo theme:
 https://github.com/NateWr/clc-demo-theme

 The theme from the video which shows a complete implementation with theme-
 specific components (use the Releases to get compiled code):
 https://github.com/NateWr/luigi

 In building this, my goals were to ensure that users were carefully
 limited in the content they could add, that they could add it very easily
 and see a live preview of it, and that the data was saved into
 `post_content` to ensure it was sort-of portable between themes and that
 it was available in search without creating new pages with their own URLs.
 Broadly, I achieved this, but ran into a number of other issues:

 1. It's common to want dynamic content in components, such as a list of
 recent posts, an event calendar, etc. For these things I had to fall back
 on shortcodes under-the-hood. Without a proper solution to saved content
 blocks this solution still relies heavily on shortcodes, even though the
 user never sees them.

 2. If there's any kind of content relationship - eg, including one post as
 part of a component in another - there's no way to signal when the saved
 `post_content` is out-of-date and needs to be rebuilt. Again, a core
 system for content blocks would help.

 3. Although saving the rendered output into `post_content` means the
 content will travel with themes, it's likely to lose much of it's visual
 meaning moving to a theme that doesn't support the same components.

 4. This is a lot of bespoke code for what essentially recreates widgets.
 For my purposes, I deliberately didn't want all widgets to be part of the
 process, so it made sense to build a separate system. But a similarly
 interactive experience tailored to content blocks on a homepage could be
 created on top of the widget customizer code if desired.

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