[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:  ux-feedback      |     Focuses:  ui
-----------------------------+------------------
Changes (by westonruter):

 * keywords:   => ux-feedback


Comment:

 Replying to [comment:16 brentjett@…]:
 > Love to see this concept getting some traction. Not to complicate the
 issue but one thing to keep in mind for a true component system is css/js
 dependencies. Ideally you want to declare the stylesheets or scripts that
 a component requires and have it be enqueued for a page only when that
 component will be used in that page. That allows you to start creating
 modular components that aren't tied to their theme or plugin's main
 stylesheet. It'd be great to have that logic built into the foundation of
 a future-looking API.

 Widgets account for this currently to a degree. A widget can enqueue it's
 assets conditionally based on `is_widget_active()`, though it should also
 enqueue them if `is_customize_preview()` to account for new widgets added
 via selective refresh.

 Here's how this has been normalized in JS Widgets:

 https://github.com/xwp/wp-js-
 widgets/blob/efcfd5c7e8dd4e679a81660d90e99cead6309c7b/php/class-js-
 widgets-plugin.php#L255-L268
 https://github.com/xwp/wp-js-
 widgets/blob/efcfd5c7e8dd4e679a81660d90e99cead6309c7b/php/widgets/class-
 wp-js-widget-text.php#L44-L64

 Shortcodes can do this as well by iterating over the posts in the (main)
 query to see if they are referenced in any of the posts' `post_content`.
 There could be a helper function like `is_content_block_type_active()` or
 something, but it gets tricky since there could very well be subqueries
 made after `wp_head` has already happened which reference a given
 shortcode and it would then be too late to enqueue those assets.

 Replying to [comment:17 Stagger Lee]:
 > Can you all guys close to core circle push a bit for Shortcake Shortcode
 UI into core ?
 >
 > As I see it, but will leave space to be wrong, other third party plugin
 developers wait to be sure before they implement it on mass scale. And
 when Shortcake is in core their Github page will literally explode with
 new ideas and new contributors.
 >
 > To make it short, not much happenning in Shortcake development. As it is
 stalled somehow.

 Shortcake is a great project that I think provides excellent prototypes
 for what will eventually go into core. Shortcake as it exists right now
 isn't going into core, not at least before the design team gives it a
 thorough UX evaluation. Also, Shortcake is specifically focused on
 shortcodes. We need to abstract it to be about content blocks. I should
 hope that the discussions we have in this ticket will make their way back
 into Shortcake as the feature plugin that can be used to test the concepts
 in the community, and thus activity in Shortcake I expect will pick up
 again. But we can't put the cart before the horse.

 By all means we should develop prototypes for how to implement things
 technically (e.g. Shortcake, JS Widgets), but again, if the next release
 is going to be design-led, then we need to wait for design before we start
 any development that is expected to be merged into core.

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