Support

Account

Home Forums Bug Reports acf_register_block and filter block_categories issue with 5.8.0

Solving

acf_register_block and filter block_categories issue with 5.8.0

    • kyfr4n

    • May 9, 2019 at 8:38 pm

    I’ve created a custom block category for pages and use the core categories in posts.

    function ff_block_category( $categories, $post ) {
    
    	if (get_post_type($post) == 'page') { 
    
    		$welcoop_blocks = array(
    
    				array(
    					'slug' => 'headers',
    					'title' => __( 'WELCOOP Headers', 'mlp-admin' ),
    				)
    
    			);
    
    		return $welcoop_blocks;
    
    	}
    
    	return $categories;
    }
    add_filter( 'block_categories', 'ff_block_category', 10, 2);

    Since I’ve updated to ACF 5.8.0 (I used the 5.8.0-RC2) this code don’t work.

    function mlp_welcoop_register_blocks() {
    
    	if( ! function_exists('acf_register_block') )
    		return;
    
    	acf_register_block( array(
    		'name'			=> 'header-default',
    		'title'			=> __( 'Header Défaut', 'mlp-admin' ),
    		'render_template'	=> 'blocks/headers/header-default.php',
    		'category'		=> 'headers',
    		'icon'			=> 'format-image',
    		'mode'			=> 'edit',
    		'supports' => array( 'mode' => false, 'align' => false ),
    		'keywords'		=> array( 'header' )
    	));
    
    	acf_register_block( array(
    		'name'				=> 'chapo',
    		'title'				=> __( 'Chapo', 'mlp-admin' ),
    		'render_template'	=> 'blocks/common/lead.php',
    		'category'			=> 'common',
    		'icon'				=> 'media-document',
    		'mode'				=> 'edit',
    		'supports' 			=> array( 'mode' => false, 'align' => false )
    	));
    
    	acf_register_block( array(
    		'name'			=> 'header-light',
    		'title'			=> __( 'Header Light', 'mlp-admin' ),
    		'render_template'	=> 'blocks/headers/header-light.php',
    		'category'		=> 'headers',
    		'icon'			=> 'format-image',
    		'mode'			=> 'edit',
    		'supports' => array( 'mode' => false, 'align' => false ),
    		'keywords'		=> array( 'header' )
    	));
    
    }
    
    add_action('acf/init', 'mlp_welcoop_register_blocks' );

    I only have header-default in pages and nothing in posts. Did I do something wrong or is it an issue?

    It was working fine before the update.

    Thanks for your help.

  • I’m having issues as well with multiple block categories and registering blocks to those categories. Whereas selecting multiple areas (CPT’s in this case), only one category is displaying at a time. And only one grouping of blocks will show (whichever is written first). The other I’m getting the Your site doesn't include support for 'acf/... block error. Not sure what the issue is there…

    At any rate, with your situation, you may want to attempt to merge the $categories and $welcoop_blocks arrays. Perhaps something like this may work for you:

    function ff_block_category( $categories, $post ) {
    
    	if ( $post->post_type == 'page' ) { 
    
    		$welcoop_blocks = array_merge(
    			$categories,
    			array(
    				array(
    					'slug' => 'headers',
    					'title' => __( 'WELCOOP Headers', 'mlp-admin' ),
    				)
    			)
    		);
    
    	} else {
    
    		return $categories;
    
    	}
    
    	return $welcoop_blocks;
    }
    add_filter( 'block_categories', 'ff_block_category', 10, 2);

    Hopefully that helps.

    • kyfr4n

    • May 14, 2019 at 5:13 pm

    Hi @captain_yar , thank you very much for your help.
    Effectively, when I merge all the block categories, it works.

    Unfortunately, my goal is to have different categories for pages and posts. I use Gutenberg for building full width sections in pages, but want to use standard blocks (with a few customs) for posts.

    Regarding your error, is it a javascript message?

    By my side i have this kind of javascript error when i’m editing a post:
    The block "core/quote" must have a registered category.

  • @kyfr4n, yea same for me…about merging the categories. I have several different custom post types that I want to have different categories display for each. But when I separate them out using conditionals, only one will show where the other won’t register (in this case, the first conditional won’t register), even though the conditional statement is working. Since only one is registering, the custom blocks using the acf_register_block_type() that are tied to the non-working category aren’t registered which leaves me with the error I stated in my previous post. If I put all the block categories together as one, like you said, it’ll work.

    Seems we’re having a similar issue. It worked great for me until the official 5.8.0 update. I was using 5.8.0 RC1, prior. Hopefully this will be addressed if more folks have the same issue.

  • Looking at the documentation again for acf_register_block_type(), there is an option for post_type restriction:

    'post_types' => array('post', 'page'),

    This seems to take care of the category issue, too. If the category is empty, it will not show.

    Potentially solved?

    • kyfr4n

    • May 15, 2019 at 4:11 am

    I’ve seen this option, thank you. But this way, I can’t remove the default block in pages.

    I’ve found this post which can be the solution:
    https://rudrastyh.com/gutenberg/remove-default-blocks.html

    But I have to list manually all of the block I want to use for each post type: can not exclude a whole category…

    add_filter( 'allowed_block_types', 'mlp_welcoop_allowed_block_types', 10, 2 );
     
    function mlp_welcoop_allowed_block_types( $allowed_blocks, $post ) {
     
    	if( $post->post_type === 'post' ) {
    		$allowed_blocks = array(
    			'core/shortcode'
    		);
    	} else {
    		$allowed_blocks = array(
    			'acf/header-default',
    			'acf/header-light'
    		);
    	}
     
    	return $allowed_blocks;
     
    }
Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.