[wp-trac] [WordPress Trac] #28093: Add REST API endpoints for widgets and sidebars

[WordPress Trac]

#28093: Add REST API endpoints for widgets and sidebars
-------------------------+-----------------------------------
 Reporter:  westonruter  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Widgets      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  javascript, rest-api
-------------------------+-----------------------------------

Comment (by westonruter):

 Agreed. The scope of this ticket should be limited to REST API endpoints.

 There are some prototype endpoints for widgets in the
 [https://github.com/xwp/wp-js-widgets JS Widgets] plugin. However, it
 depends on widgets implementing the `JS_Widgets` interface so that there
 is a schema available for each widget. See #35574. To me it seems for
 widget endpoints to really be usable in JS they should expose the instance
 props not just the PHP-rendered `WP_Widget::widget()` output. In this way
 the widgets could be rendered using JS instead (e.g. React). However,
 since schemas aren't available for each widget yet, we don't have a way to
 manage the visibility of the properties. We could just output the
 `rendered` widgets if they have no schema defined, but we should provide a
 schema in core to make that an option. Schemas //have// been implemented
 for media widget instances.

 One other gotcha for widget endpoints: a widget may render differently
 depending on the page it appears. For example, a Text widget with a
 `[gallery]` shortcode in it will render differently depending on which
 post is the current queried object. Likewise, a Navigation Menu widget
 will apply different classes to menu items based on what the current URL
 is.

 There is an existing WP-API GitHub repo for developing widget and menu
 endpoints here: https://github.com/WP-API/wp-api-menus-widgets-endpoints

 Lastly, I haven't been wanting to push to hard on adding widget endpoints
 yet while the work on blocks is underway in Gutenberg. Blocks in Gutenberg
 actually have their own dedicated `wp_block` post type (which I've wanted
 to do for widgets in #35669), and the data model for blocks is being
 architected in the way that widgets should have been done in the first
 place. I personally think that widget endpoints in core will make the most
 sense //after// we go through the work of migrating from widgets to blocks
 in sidebars. The data model of widgets is a mess and trying to expose
 endpoints to manage the mess will be messy. Also, nav menu items are
 similar in concept to widgets (of a specific type) but their data model
 and API are wildly different. The endpoints for both widgets and nav menus
 should be closely aligned in interface, but that's painful now because
 they are so different architecturally.

 So once we have blocks then I think we'd be in a better place to work on
 the endpoints for widgets and nav menus, because at that point we'll be
 working on migration anyway. It may end up being that we actually don't
 implement endpoints for `WP_Widget` at all, but rather only endpoints for
 //widget blocks//. Since all widgets will be ported over to blocks, the
 need to interface with classic `WP_Widget` will lessen and eventually
 could be deprecated altogether.

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