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

Limit Block to Certain Post Type(s) #2685

Closed
timmyc opened this issue Sep 6, 2017 · 15 comments
Closed

Limit Block to Certain Post Type(s) #2685

timmyc opened this issue Sep 6, 2017 · 15 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience

Comments

@timmyc
Copy link
Contributor

timmyc commented Sep 6, 2017

During our local WordPress Meetup last night, a question was brought up around the ability to register a block type to only a certain Custom Post Type, or possibly multiple post types. I did not have the answer to that question off the top of my head so I did a bit of looking to see if this was part of the block API currently.

It appears that this functionality doesn't currently exist ( or I couldn't find it, which is very likely ) so I figured this issue would be a good place to track this question and discuss.

Somewhat related: #2457

@timmyc timmyc added [Feature] Block API API that allows to express the block paradigm. [Type] Question Questions about the design or development of the editor. labels Sep 6, 2017
@mtias
Copy link
Member

mtias commented Sep 6, 2017

See also #1654

@mtias mtias added [Feature] Extensibility The ability to extend blocks or the editing experience and removed [Type] Question Questions about the design or development of the editor. labels Nov 20, 2017
@johnbillion
Copy link
Member

This is definitely something I'd like to see. Post templates can be restricted by post type. It would be great to have the same functionality for blocks.

@youknowriad
Copy link
Contributor

The handbook shows how to whitelist/blacklist blocks, A script could be loaded for a specific CPT to achieve this. I think this addresses this issue. https://wordpress.org/gutenberg/handbook/extensibility/#removing-blocks

@johnbillion
Copy link
Member

That does technically address the issue, but native support would be a better developer experience.

@youknowriad
Copy link
Contributor

youknowriad commented Dec 22, 2017

@johnbillion Not against reopening if you think it's crucial. But maybe we could wait for more requests. I think the block-templates and locking will drastically reduce the need for this API.

@johnbillion
Copy link
Member

Let's re-open this for now and see if it picks up more interest.

@johnbillion johnbillion reopened this Dec 22, 2017
@greatislander
Copy link
Contributor

I think there’s a clear use case for this. If I register a custom post type and a block that must only be used within that post type, I shouldn’t have to load additional client-side JS to deregister that block in other places.

@youknowriad
Copy link
Contributor

I shouldn’t have to load additional client-side JS to deregister that block in other places.

I'm not denying the use-case but you can register this client-side JS only for this CPT instead.

@greatislander
Copy link
Contributor

To register the blocks but only for that post type? I hear you, but I still think it would be more intuitive to specify post types at the point of block registration rather than loading the block JS conditionally based on post type.

@bradyvercher
Copy link
Contributor

Count me in the 👍 camp. Currently, if I want to register multiple blocks meant for different CPTs, I need to build separate bundles for each CPT instead of having a single entry point.

@ericnicolaas
Copy link

Just wanted to add my voice here to say this would be a very helpful feature. I'm working on a handful of blocks that should be limited to a specific CPT.

Considering that blocks are designed to be a replacement for some meta boxes, and meta boxes can be limited by CPT easily, extending the same capacity to blocks will help adoption. As a developer making the switch, it's something I expect to be available.

@gziolo
Copy link
Member

gziolo commented Apr 16, 2018

#6208 adds functionality which allows to filter allowed block types based on the post type or other properties. This will still load JS and CSS for all blocks registered on the server, but they won't show up in the inserter.

There are other efforts which should fix the issue with obsolete JS and CSS tackled separately to limit the number of assets downloaded by end-users.

@alexsanford
Copy link
Contributor

@gziolo Could you demonstrate how this filter can be used to add a custom block type to a specific CPT? Since the value of $allowed_block_types is true, I'm struggling to conditionally add my block to the list based on $post->post_type.

Maybe I'm misunderstanding the intention of the filter? I believe my use case is the same as in the description of this issue.

@gziolo
Copy link
Member

gziolo commented Apr 30, 2018

true - means that all block types are allowed. Ideally, it should contain the list of all registered blocks, but blocks can be registered on the client which makes it impossible to control on the server. What we support at the moment is providing a whitelist with explicitly listed blocks that are allowed for a given post type. We will have to find a better way to control it before Gutenberg land in WordPress core.

@emfluenceindia
Copy link

I agree with @ericnicolaas . We should have the ability to limit blocks per CPTs upfront. In other words, we should be able to define blocks for a CPT which we only want to be associated with it.

This will not only make developers' life easier but also allow us to keep the code clean and easy to maintain.

Since I am a late comer to this thread, just curious whether it is already available by now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience
Projects
None yet
Development

No branches or pull requests

10 participants