{"id":30786,"date":"2020-05-15T23:06:54","date_gmt":"2020-05-15T23:06:54","guid":{"rendered":"https:\/\/www.designbombs.com\/?p=30786"},"modified":"2020-05-17T08:52:05","modified_gmt":"2020-05-17T08:52:05","slug":"registering-gutenberg-blocks-for-custom-post-type","status":"publish","type":"post","link":"https:\/\/www.designbombs.com\/registering-gutenberg-blocks-for-custom-post-type\/","title":{"rendered":"How to Register Gutenberg Blocks for Some Custom Post Type only, using PHP (not JS!)"},"content":{"rendered":"

When creating a WordPress site<\/a>, we may need to create a custom post type and have it reference other entities from the database. For instance, a Product<\/code> custom post, which displays how many stars it has been rated by the users, needs to reference a list of users or a list of ProductReview<\/code> custom posts.<\/p>\n

WordPress provides custom meta fields, which enable to add any arbitrary piece of data to posts, users, comments, categories and tags, such as references to any other entity from the database. However, WordPress doesn’t provide a built-in solution to create the relationships across entities in the admin panel in a user-friendly way.<\/p>\n

This void has been filled by plugin Advanced Custom Fields<\/a>. Whenever we can control the environment where the site runs (such as when building a website for a client), we can install ACF and depend on it for creating all the relationships across entities.<\/p>\n

However, that is not the case when submitting a theme or plugin to the WordPress directory. Since we don’t know in advance if the user installing the theme or plugin will also have ACF installed, we must then find a different way to solve the problem.<\/p>\n

Luckily, Gutenberg<\/a> can replace ACF (even though is not as simple, since it requires plenty of coding) by attaching custom blocks to the editor to let the user define the relationships across entities. For instance, the custom block can fetch the list of database entities that can be referenced using the WP REST API, display them on a select input, and save the selected entries through a block attribute.<\/p>\n

\"\"<\/p>\n

Gutenberg will store the data within the post content, and we can retrieve it using function parse_blocks<\/code><\/a>, as we explained on article Exposing WordPress site data for mobile apps<\/a>.<\/p>\n

This custom Gutenberg block makes sense only when editing the intended custom post type, so we need to remove it everywhere else. In this article, we will explore how to achieve this. We will first analyze the official solution, which is based on JavaScript, and then an alternative (and better) approach using PHP.<\/p>\n

The official (unsatisfying) solution: Unregistering blocks through JavaScript code<\/h2>\n

The official solution<\/a> to this problem is to unregister the block by executing JavaScript function wp.blocks.unregisterBlockType<\/code>:<\/p>\n

wp.domReady( function() {\r\n  wp.blocks.unregisterBlockType( 'my-namespace\/my-custom-block' );\r\n} );\r\n<\/code><\/pre>\n
Please notice that there is also an alternative proposed approach, which is to use a whitelist<\/a>:<\/p>\n
var allowedBlocks = [\r\n  'core\/paragraph',\r\n  'core\/image',\r\n  'core\/html',\r\n  'core\/freeform'\r\n];\r\n \r\nwp.blocks.getBlockTypes().forEach( function( blockType ) {\r\n  if ( allowedBlocks.indexOf( blockType.name ) === -1 ) {\r\n    wp.blocks.unregisterBlockType( blockType.name );\r\n  }\r\n} );\r\n<\/code><\/pre>\n
However, this approach will not work for our situation, because we only know which is the block type that is forbidden from all other custom post types, instead of knowing which are all the allowed block types. Sure, we could calculate the whitelist by removing the blacklisted block type from the list of all block types, but then we’d rather already use the simpler blacklisting approach.<\/p>\n
The blacklisting approach works, however I find this solution quite unsatisfactory, because of several reasons:<\/p>\n