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

[WordPress Trac]

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

 * focuses:  template =>
 * component:  Themes => Widgets
 * milestone:  Awaiting Review => Future Release


Comment:

 +1

 I just opened an issue on the Shortcake project a few days ago to discuss
 this very thing. (In shortcake, content blocks are called “post
 elements”.) [https://twitter.com/danielbachhuber/status/709502403729428481
 According] to @danielbachhuber, this is the “Grand Unification Theory of
 WordPress”.

 It should be trivial for a widget and shortcode to be used interchangeably
 as content blocks in post content or sidebars. the UI for manipulating a
 content block could be accessed via the Shortcake UI, a widget form, or
 Customizer control. The form UI should be managed by the Fields API. A
 content block could be inserted into post content via shortcode, into a
 sidebar via a widget, or into another context via a dedicated tag template
 (like `the_content_block()` with a hat tip to `the_widget()` and
 `do_shortcode()`).

 > == [https://github.com/wp-shortcake/shortcake/issues/585 Content Blocks:
 Shortcodes & Widgets] ==
 > I recall talking a conversation at some point with @mattheu regarding
 how shortcodes (as enhanced by shortcake) are a great candidate for the
 much-mused “content blocks”. I believe in this conversation it was also
 suggested that widgets (and nav menu items to a limited extent) are just
 another side of the same coin. I've been wanting to tackle a rewrite of
 widgets for awhile now to make them JS-driven (#33507). This now has a
 dependency on adding JSON schema information to widgets to allow their
 PHP-serialized instance data to be reliably represented as JSON (#35574),
 and this in-turn now seems to have a dependency on the Fields API which
 can be used to specify the schema and also dynamically build the form
 control via JS.
 >
 > All of this to say, and forgive me if this all been hashed out
 previously, to me it seems that the Shortcake project has a lot of overlap
 with Widgets and the Fields API. Shortcodes could even be implemented as
 widgets, where the shortcode name is an alias for the widget type (class
 or `id_base`), and the shortcode attributes can be passed in directly to
 `the_widget` as instance data.
 >
 > I wanted to open an issue to start a conversation and dump some ideas
 I've had for awhile, if at least to direct me to where I can join an
 existing conversation.
 >
 > Some related Trac tickets:
 >
 > * #33507: Allow widget controls to be JS-driven
 > * #35574: Add REST API JSON schema information to WP_Widget
 > * #28580: Speed up customizer by lazy-loading controls and settings as
 needed

 See also:
 * https://make.wordpress.org/design/2013/08/08/proposal-improving-the-
 content-editing-experience/
 * http://wptavern.com/revamping-the-content-creation-experience-in-
 wordpress

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