REST API: Apply allowed_block_types filter to Block Types endpoint #24076
Conversation
ockham
added
the
[Type] Question
|
Size Change: 0 B Total Size: 1.15 MB ℹ️ View Unchanged
|
|
In my opinion, the block types endpoint should return the full list of registered blocks. We could add a So I would implement this as a property on the posts endpoint that would be the list of allowed block names. It would only be available in the |
I don't have a strong preference for either option, but a point can be made that the only place were blocks are currently made available in the editor does apply that filter (which is contextual). This is my main reason for wondering if the same pattern might make sense to carry over to the endpoint.
Right. By comparison, what would be a typical use case for the block types endpoint? 🤔
Ah, thanks for the link, wasn't aware of that conversation! |
Yeah that's definitely true. For me though, I think that list could grow so it wouldn't be the most forward compatible interface.
As a developer, I want to be able to limit the blocks that can be used in the widgets screen, navigation screen, and full site editing. I think those would be different filtering contexts. For those, they could perhaps be done with the same arguments because they are each backed by posts. But what about term descriptions or author archives? |
Hmm, what would it mean to insert a block in an author archive? Wouldn't one just be editing the corresponding template? And for term descriptions, those are currently plain text, AFAICT 🤔 Not trying to hair-split, but it seems like a post object based filter might give us pretty good coverage of most of the use cases you're listing, and it'd be nice if
|
|
I'll add that in contexts like the Site Editor, it's possible to switch between the currently edited template (i.e. |
The template would, but the users themselves also have a description field that often is shown in the archive. Also plain text, but I think in an ideal world it'd be a block editor. So that belongs to the user object.
Yeah those are currently a plain text input, I thought the idea was that we'd be able to edit those with the block editor at some point?
That seems like a strong argument for making it a property of the post being edited :) Then you wouldn't need to refetch the block types definition, you'd just be getting the list of block names from the post object you've selected. |
|
Some related discussion (about we should filter by context rather than post object): #24006 (comment) |
|
Closing. We might opt to make allowed blocks a property of the post object (as returned by the posts/pages/post types endpoint), see discussion above. |
ockham
deleted the
update/apply-allowed-block-types-filter-to-rest-api
branch
Description
This is more of an RFC -- this code would currently produce an error.
In #21065, a new endpoint was introduced to return registered blocks:
By comparison, there's an
allowed_block_typeshook in Core that's applied upon loading the Block Editor, allowing filtering of the blocks that are available to the user in the inserter.I think it would make sense to apply that same filter to the
block-typesendpoint. However, that is not straight-forward, as the filter currently accepts a second argument: the current post object (which is, of course, readily available in a Block Editor context).Somewhat related: WordPress/wordpress-develop#419
Questions
wp_templateCPTs) vs Post Editor.)cc/ @spacedmonkey @TimothyBJacobs for opinions 🙂
How has this been tested?
Hasn't yet 😬
Types of changes
RFC
Checklist: