Restrict template part inserter support to the site editor using filters#37065
Restrict template part inserter support to the site editor using filters#37065
Conversation
| 'core/edit-site/block-register', | ||
| addInsertersupportForTemplatePartBlock | ||
| ); | ||
| registerCoreBlocks(); |
There was a problem hiding this comment.
If this approach sticks, I can see moving towards a declarative approach. E.g. imagine having an editor.json like:
{
"blockOverrides": {
"core/template-part": {
"supports": {
"inserter": true
}
}
}
}Or a call like
registerCoreBlocksWithOverrides([
setBlockSupport("core/template-part", "inserter", true)
])There was a problem hiding this comment.
I like this idea of different per editor context. I don't want to derail the conversation as this is worth a separate issue, but how would a 3rd-party block achieve the same functionality (working only the site editor) if they can only pack their block.json settings but don't have access to the editor.json one?
|
Size Change: +73 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
| 'core/edit-site/block-register', | ||
| addInsertersupportForTemplatePartBlock | ||
| ); | ||
| registerCoreBlocks(); |
There was a problem hiding this comment.
I like this idea of different per editor context. I don't want to derail the conversation as this is worth a separate issue, but how would a 3rd-party block achieve the same functionality (working only the site editor) if they can only pack their block.json settings but don't have access to the editor.json one?
|
Thanks for the PR Adam! This approach doesn't solve the problem now, as while we are in In general the new API that we need, will have to define what It seems that our current API I don't have a clear way forward but I think we will need involve |
|
Closing this PR, #37157 did the trick. |
Description TBD
Solves #30668