-
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 Hooks: Respect allowedBlocks
field and control for users
#53989
Comments
allowedBlock
field and control for users
allowedBlock
field and control for usersallowedBlock
field and control for users
I've approved #58262. However, maybe there's another problem before we can use it to implement a solution to this issue: If we'd like the Block Hooks mechanism -- which runs on the server side -- to respect the In practice, this could be a bit tricky: Core/GB blocks (like Comment Template) are registered before 3rd-party plugin blocks; so if the latter tries to extend the Comment Template block's I'm wondering if we need any additional filters, or if we'll simply need to un-register and re-register the block 🤔 |
The client-side blocks registration in JS has this covered with the It seems we need the same thing on the server, too, if it's already not there. |
In WordPress core all blocks get registered on |
allowedBlock
field and control for usersallowedBlocks
field and control for users
A block registration on the server, in a plugin PHP code, looks like this: add_action( 'init', function() {
register_block_type( /* my/block */ );
} );
add_action( 'register_block_metadata', function( $metadata ) {
if ( $metadata->name === 'core/navigation' ) {
/* add 'my/block' to $metadata->allowedBlocks */
}
return $metadata;
} ); When the block registrations run on |
Yes, it should work correctly. When we land WordPress/wordpress-develop#5988 then the changes from the server should also get correctly propagated to the client. |
Ah, thanks for clarifying that, folks! That'd be quite the relief 😄 BTW I've thought about this some more, and I'm starting to wonder if we should actually implement this behavior (i.e. Block Hooks respecting This is particularly clear with We could go as far as to "invert" this issue's idea: We could make Block Hooks extend a parent block's
Once again, this feels easier to answer for |
The only place where For example,
Similarly, |
Now that Jarda shared the context of how
I think we should consider One thing that might be actionable is respecting the |
from the tracking issue:
Originally touched upon Auto-inserting Blocks #39439 (comment). We might want to give a block some level of control what blocks it allows as its (auto-inserted) children.
There's an
allowedBlock
attribute that's currently used by a number of blocks; AFAICT, it's only handled on the client side, and basically passed through to the InnerBlocks component as a prop. I'm a bit hesitant to use something like this as it seems currently really up to each individual block, with no standardization, especially on the server (e.g. in the shape of block-supports).Implementing this later might amount to an API change: Blocks that were previously auto-inserted might cease to be if their parent disallows them 😕
full disclosure: I was reading through the tracking issue on my phone and must have fat-fingered it to create an issue of a to-do-item. Only noticed it today, when back at my computer.Tried to make the best of it by copy/pasting the content from the tracking issue.
The text was updated successfully, but these errors were encountered: