-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Library: Register all block with "block.json" on the server' #22491
Conversation
Size Change: 0 B Total Size: 1.12 MB ℹ️ View Unchanged
|
272ae3e
to
d3b0211
Compare
This is the list of blocks
|
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 |
@@ -16,6 +16,41 @@ function gutenberg_reregister_core_block_types() { | |||
return; | |||
} | |||
|
|||
$block_folders = array( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of an explicit array, can we just loop through the folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Description
This PR registers on the server all core blocks that have
block.json
defined 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__bootstrapServerSideBlockDefinitions
call:Types of changes
New feature (non-breaking change which adds functionality).
Checklist: