[wp-trac] [WordPress Trac] #33473: Shortcodes + Widgets + Nav Menus. Unified "component" API (aka Content Blocks)

[WordPress Trac]

#33473: Shortcodes + Widgets + Nav Menus. Unified "component" API (aka Content
Blocks)
-----------------------------+------------------
 Reporter:  brentjett@…      |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  4.8
Component:  Widgets          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  ui
-----------------------------+------------------

Comment (by westonruter):

 @folletto thanks for the summary. I think that's right.

 I'd say that a lot of what is being described here (in terms of the
 editor) is already largely implemented in the Shortcake plugin. I think
 that it will provide us with a great starting point to continue iterating
 on the UX and also on the technical details for how to extend the editor.
 Personally I'm especially keen on integrating widgets into the mix, and
 this is largely dependent on a modernization and JavaScriptification of
 widgets (per #33507).

 There is no unified API yet proposed for content blocks as far as I know,
 but we really do need to normalize the differences between widgets and nav
 menus and shortcodes. In addition to normalizing the difference between a
 given instance of a widget, nav menu item, or shortcode… we also have the
 need to normalize how we group these things into nav menus, widget
 sidebars, and post content. Widgets and nav menus have widely different
 methods for grouping, as you know, where nav menus have re-usable groups
 that can be assigned to locations whereas widgets do not (although
 #19912). I think we need `wp_nav_menu()` and `dynamic_sidebar()` and
 `the_content()` to all potentially be different ways to do the same thing:
 establish an area on the template where content blocks can appear. The
 specific function used could serve as a way to filter which kinds of
 content blocks can appear in the given region, such as nav menus could
 only be assigned to a region where `wp_nav_menu()` is used.

 I think we should consider introducing a `content_block` custom post type
 which can serve as next iteration on the `nav_menu_item` custom post type
 and also be where widgets are moved to instead of being stored in options
 (see #35669). Then we can decide how these `content_block` posts get
 organized into groups (and positionally related to each other), whether we
 have a `content_block_group` taxonomy or custom post type.

 In terms of the customizer then, the content blocks should be able to be
 managed inside of a post's content or in the nav menu locations or widget
 sidebar locations.

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