[wp-trac] [WordPress Trac] #47620: REST API: Expose blocks registered on the server

[WordPress Trac]

#47620: REST API: Expose blocks registered on the server
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:
                                                 |  spacedmonkey
     Type:  feature request                      |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  REST API                             |     Version:  5.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:  rest-api
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by gziolo):

 Replying to [comment:10 spacedmonkey]:
 > Current my patch uses `edit_posts` cap. This api should be available to
 everyone that can edit a post, if it is to be used in the mobile app.
 `install_plugins` cap is very limiting as by default only administrators
 have this cap.

 It's a different use case for the Block Directory, my point was that it
 doesn't use any other permission check there. This is something that
 should be addressed in both places.

 > As for the missing fields @gziolo , I wasn't sure of the state of the
 RFC, so didn't review it. Can we use this a design for the API?

 It's based on the actual implementation in Gutenberg for core blocks and
 the Block Directory also follows the same API.

 > The classes doesn't allow for other fields. So these would have to be
 added to the class. This is not a small change, as it would require the
 updating of the docs / unit tests / implementation of the
 [https://developer.wordpress.org/reference/functions/register_block_type/
 register_block_type] function. This should likely happen in another
 ticket, as this is a sizale change.

 It's a fair point. You can split work into two parts, whatever other
 reviewers feel is the best. To make it functional though, we need to have
 all those additional fields covered because we won't be able to integrate
 this new endpoint with the block editor on the client-side.

 > But I would also recommend adding
 > - supports

 We plan to deprecate this field. In the long run, we want to provide a
 more robust API to achieve the same goal. It would be nice to skip this
 field from the REST API. We keep this field on the client for all core
 blocks.

 > I would also look at the newly added
 > - example

 Yes, this one might be a good fit as well. We should double-check first
 whether the format provided can be encoded in JSON files.

 > Also where is the URL for translations defined?

 Can you explain what is this about? Maybe @swissspidy will know :)

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