Block Directory: Fix metadata of new innerBlocks of a installed block not propagated to the editor #69438
Conversation
…blocks of newly installed Block
github-actions
bot
added
the
First-time Contributor
|
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @karthikeya-io! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
karthikeya-io
changed the title
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Mamaduka
added
[Type] Bug
| @@ -103,23 +104,32 @@ export const installBlockType = | |||
| 'variations', | |||
| ]; | |||
| await apiFetch( { | |||
| path: addQueryArgs( `/wp/v2/block-types/${ name }`, { | |||
| path: addQueryArgs( `/wp/v2/block-types/`, { | |||
There was a problem hiding this comment.
This would fetch all registered block types and bootstrap them again. We need to find a solution that only targets the installed block and its dependencies (inner blocks).
Maybe this could use the allowedBlocks metadata, clearly defining parent/child relation. cc @Lovor01
P.S. As far as I know, the block directory currently doesn't allow block bundle plugins; it only allows single surpose or parent/child blocks. See: https://developer.wordpress.org/plugins/wordpress-org/block-specific-plugin-guidelines/#:~:text=Block%20plugins%20may%20contain%20more%20than%20one%20block%20where%20a%20clearly%20necessary%20parent/child%20or%20container/content%20dependency%20exists%3B%20for%20example%20a%20list%20block%20that%20contains%20list%20item%20blocks.
There was a problem hiding this comment.
This would fetch all registered block types and bootstrap them again. We need to find a solution that only targets the installed block and its dependencies (inner blocks).
Maybe this could use the
allowedBlocksmetadata, clearly defining parent/child relation. cc @Lovor01P.S. As far as I know, the block directory currently doesn't allow block bundle plugins; it only allows single surpose or parent/child blocks. See: https://developer.wordpress.org/plugins/wordpress-org/block-specific-plugin-guidelines/#:~:text=Block%20plugins%20may%20contain%20more%20than%20one%20block%20where%20a%20clearly%20necessary%20parent/child%20or%20container/content%20dependency%20exists%3B%20for%20example%20a%20list%20block%20that%20contains%20list%20item%20blocks.
True; Make IT Easy slider provides two blocks, parent slider and child slide. Slide block has parent setting, see:
https://github.com/Lovor01/makeiteasy-slider/blob/main/src/slide/block.json
|
@karthikeya-io thanks for this PR! |
What?
Closes #69315
Why?
PR fixes the Block Directory installation bug which causes failing registration of innerBlocks of newly installed block until the page is refreshed.
How?
When a new block is installed propagating all registered blocks metadata to the editor instead of just newly installed block.
The ideal case would be propagating only new block and innerBlocks used in that block, but I am unable to achieve it.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast