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

Comment (by bradyvercher):

 @karmatosed Yes, it should include the Customizer UI. You need to add
 support to your theme with this snippet:

 {{{
 add_action( 'after_setup_theme', function() {
         add_theme_support( 'front-page-sections' );
 } );
 }}}

 Once you've added that, it works like the mockup. The UI will show in the
 Static Front Page section when a page is set to show on front.

 @celloexpressions I'm not really sure where to start and it's a bit
 disappointing, but there's a lot of misinformation in your comment.

 This is implemented as a self-contained Customizer control, so it doesn't
 need embedded sections or a fly-out panel API. It integrates with the
 Customizer API where necessary and uses Backbone.js views to manage the
 UI, which I would argue is better understood by more developers and
 prevalent throughout the WordPress codebase. This part is pretty
 straightforward and is hardly unmaintainable.

 > As a general rule, we need to try to improve on existing API
 functionality when introducing new functionality rather than working
 around it.

 This doesn't work around the Customizer API. It integrates with the API
 where necessary and takes advantage of the structure Backbone.js provides
 to implement the UI. New features require new code. I'm all for improving
 existing APIs, but that's outside the scope at the moment. Menus and
 widgets both use Backbone.js, but weren't built in such a way that their
 functionality could be reused and the code in the patch is closer to
 creating reusable components than what's currently available.

 > The dropdown-pages control is the current way to add post object
 selector UI...

 I don't really think that control is even close to being usable for this
 feature in any meaningful way.

 > Building out a solution to #36733 would be a requirement if we want to
 use that UI here, with the option to update widgets and menus to use it
 later.

 That wasn't a requirement for getting widgets or menus into core and
 shouldn't be a requirement here.

 > If we can get something similar to what is mocked up here with less
 extreme technical debt...

 It's a little concerning that a new control can't be introduced to core
 without adding "extreme technical debt" to a feature that's already 40K+
 lines of code. If you'd like to take more than a "glance" and make
 actionable suggestions that actually reduce the amount of code, I'm happy
 to iterate, but I'm disinclined to spend any more effort with this kind of
 feedback.

 It may be worth reducing the public surface by making much of the
 JavaScript in the patch private so that it could be refactored in the
 future. The AJAX callback could also be removed if the REST API endpoints
 make it into core this cycle -- at the moment it's modeled on
 `wp_ajax_find_posts()`.

 Like I mentioned in my initial comment, this is a solid start. It's not
 perfect and needs some iteration, but I'm confident in the approach.

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