-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Allow/deny block use based on post-type or template context #41062
Comments
For woocommerce/woocommerce-blocks#5193 we are trying the solution with a |
When designing the Regarding a deny list, there was a proposal about allowing you to pass an object to Maybe can revisit some of this 😀 |
allow block use by post and template type
Good point. I know about a similar discussion when This issue is related to #46900, which proposes adding a way to register a block only in a specific editor. In some cases, providing a post type would be equivalent to limiting access to the post editor, and providing a template would be equivalent to limiting access to the site/template editor. |
It would be very interesting to have this setting for the variations too. Regarding the variations, I created an issue about the support for the ancestor/parent #48424 |
@gigitux @boonebgorges What do you think about the approach to handling this on a post type level, as @mtias suggests in his comment.
|
We have use cases where we need to limit the available blocks within a specific Block Template. Something like this could deregister blocks based on template, but then there is no good way to restore the block types once the user switches to another template or view.
Ideally we'd like some additional context passed to |
Thanks for this additional context @mikejolley. Dynamically restricting blocks in the Site/Template Editor is definitely more complicated than the Post Editor and we currently lack the tools to do so. Also, not sure why I removed the "Blocks Adoption" tag in the past 🤦♂️, but added it back. |
What problem does this address?
It's sometimes desirable to limit blocks to certain post-type contexts (or, in a parallel fashion, to prevent a specific block from being used in a given context). As far as I can see, the current recommendation is to use
unregisterBlockType()
to unregister a given block based ongetCurrentPostType()
, etc. See eg #27607.While the semantics of this technique are not entirely straightforward ("unregister" rather than "hide", or better still, "prevent from showing in this context"), it pretty much works in the post editor. However, it's not workable in the Site Editor. It's possible to fetch the currently edited template using
wp.data.select( 'core/edit-site' ).getEditedPostId()
, and tounregisterBlockType()
based on this. But it's possible to switch the currently-edited template without a page reload, meaning that you'd have to re-registerBlockType()
. Moreover, setting up asubscribe()
callback forgetEditedPostId()
to determine the current context is pretty clumsy.What is your proposed solution?
I propose that, as part of their registration metadata, a block can specify
allow
ordeny
contexts. Maybe something like:postTypes
would specify the contexts for the post editor, whiletemplates
would be for the site editor. Or it might be better to have a single declaration that covers both cases, depending on the overall strategy for merging the editing experience.Similarly, it might be nice to have
deny
declarations that work similarly (though of course there are problems with allowing both).Apologies in advance if this idea's already in circulation - I searched but couldn't find anything.
The text was updated successfully, but these errors were encountered: