Block Library: Register all block with "block.json" on the server' #22491
Conversation
|
Size Change: 0 B Total Size: 1.12 MB ℹ️ View Unchanged
|
gziolo
force-pushed
the
update/server-side-register-blocks
branch
from
272ae3e to
d3b0211
Compare
gziolo
added
[Package] Block library
|
This is the list of blocks
|
gziolo
force-pushed
the
update/server-side-register-blocks
branch
from
d3b0211 to
446d52c
Compare
|
I discussed Widgets Area block with @jorgefilipecosta and it seems like it doesn't have to be loaded in every context. I'm sure the same applies to many other blocks added recently. @youknowriad and @mtias do you have some strategy planned moving forward in terms of whether to limit what types of blocks are loaded depending on the edit page type? @aduth, while working on updates to |
The short answer for me would be "no". But I do grant that there's an interesting problem here in if and how a block should assume for context to have been provided. Part of the reason that From the block's perspective, it's still an open question if it should assume the context value is available or not, which could be affected by the prior handling. Currently, they do handle this, though in a way that's not especially graceful (example, returning empty string). It might be something to observe over time:
Finally, it's worth clarifying: Context doesn't necessarily come from the direct parent. It can come anywhere from the ancestry. So |
|
To make it clear for all observers, all that discussion I started with @aduth isn't a blocker to this particular PR. @aduth, thank you for your detailed answer. It looks like there are many ways to work with a context in the case when it's not provided in the upper scope of the tree where block lives.
I was aware of this limited usage of One more question, do you envision any issues on the frontend caused by the block registration process happening on the server knowing that we don't run the same logic that hooks operating on |
Regrettably no, what little work I had remained in a local branch and I had to deprioritise that task. |
I don't really imagine there should be. For the most part, if a block type doesn't have an associated |
| return; | ||
| } | ||
|
|
||
| $block_folders = array( |
There was a problem hiding this comment.
Instead of an explicit array, can we just loop through the folder?
There was a problem hiding this comment.
In the ideal world, I would do it, but some blocks are behind the flag and other call register_block_from_metadata in PHP file. Well, we could detect the latter, and blacklist the former. Hmmm, I might open a follow-up. I guess I could use glob right?
There was a problem hiding this comment.
There is also this proposed addition to WordPress core from @aduth in https://core.trac.wordpress.org/ticket/49615:
register_block_type_args filter
With that, we could find all block.json file to register blocks and use this hook to set render_callback separately.
youknowriad
left a comment
youknowriad
left a comment
There was a problem hiding this comment.
Do you think we should create a trac ticket to backport the API and this change?
There is still some work going on in #22491 but I agree that we should at least have a tracking ticker in Trac 👍 |
|
Filed a follow-up #22660 for the only remaining block – Embed. |
|
Trac ticket created as well: https://core.trac.wordpress.org/ticket/50263. |
gziolo
added
the
Backport to WP 6.9 Beta/RC
gziolo
removed
the
Backport to WP 6.9 Beta/RC
Description
This PR registers on the server all core blocks that have
block.jsondefined when they don't contain PHP files that would take care of it. This way soon we should be able to get a few benefits like:https://github.com/WordPress/wordpress-develop/blob/437ac63d7652b08095dc7f77b6ba4ef52db44dbb/src/wp-admin/edit-form-blocks.php#L111-L115
How has this been tested?
I checked in the source code that included blocks are listed in the
wp.blocks.unstable__bootstrapServerSideBlockDefinitionscall:Types of changes
New feature (non-breaking change which adds functionality).
Checklist: