Skip to content
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 Directory: Fix metadata of new innerBlocks of a installed block not propagated to the editor #69438

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 19 additions & 9 deletions packages/block-directory/src/store/actions.js
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,7 @@ export const installBlockType =

// Ensures that the block metadata is propagated to the editor when registered on the server.
const metadataFields = [
'name',
'api_version',
'title',
'category',
Expand All @@ -103,23 +104,32 @@ export const installBlockType =
'variations',
];
await apiFetch( {
path: addQueryArgs( `/wp/v2/block-types/${ name }`, {
path: addQueryArgs( `/wp/v2/block-types/`, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

_fields: metadataFields,
} ),
} )
// Ignore when the block is not registered on the server.
.catch( () => {} )
.then( ( response ) => {
if ( ! response ) {
if ( ! response && ! Array.isArray( response ) ) {
return;
}
unstable__bootstrapServerSideBlockDefinitions( {
[ name ]: Object.fromEntries(
Object.entries( response ).filter( ( [ key ] ) =>
metadataFields.includes( key )
)
),
} );
const blockDefinitions = Object.fromEntries(
response.map( ( blockItem ) => [
blockItem.name,
Object.fromEntries(
Object.entries( blockItem ).filter(
( [ key ] ) =>
metadataFields.includes( key )
)
),
] )
);

// Bootstrap all retrieved block definitions
unstable__bootstrapServerSideBlockDefinitions(
blockDefinitions
);
} );

await loadAssets();
Expand Down
Loading