I am currently using the allowed_block_type
filter to control the available blocks in my theme, similar to the following example:
function acf_allowed_blocks($allowed_blocks, $post)
{
// Register core blocks
$core_blocks = array(
'core/buttons',
'core/heading',
'core/image',
'core/list',
'core/paragraph',
);
// Register custom blocks
$custom_blocks = array(
'acf/test-block',
);
// Register plugin specific blocks
$plugin_blocks = array(
'gravityforms/form',
);
// Specify block groupings available on specific post types
switch ($post->post_type) {
case 'post_type_example':
$allowed_blocks = array_merge($core_blocks);
break;
default:
$allowed_blocks = array_merge($core_blocks, $custom_blocks, $plugin_blocks);
}
return $allowed_blocks;
}
add_filter('allowed_block_types', 'acf_allowed_blocks', 10, 2);
While this works perfectly, I am trying to determine whether or not it’s possible to remove the gravityforms/form
block, but allow it inside the acf/test-block
. Currently, if I remove the block from this function, it’s also becomes unavailable as an inner block in my ACF block markup, which looks like this:
$allowed_blocks = array( 'gravityforms/form' );
echo '<InnerBlocks allowedBlocks="' . esc_attr(wp_json_encode($allowed_blocks)) . '" />';
Does anyone have any idea on whether or not this is even possible with the current state of Gutenberg? I can just as easily live with it being available as both a main and an inner block, but it would be my preference to only use it as an inner block.
I am currently using the allowed_block_type filter to control the available blocks in my theme, similar to the following example:
function acf_allowed_blocks($allowed_blocks, $post)
{
// Register core blocks
$core_blocks = array(
'core/buttons',
'core/heading',
'core/image',
'core/list',
'core/paragraph',
);
// Register custom blocks
$custom_blocks = array(
'acf/test-block',
);
// Register plugin specific blocks
$plugin_blocks = array(
'gravityforms/form',
);
// Specify block groupings available on specific post types
switch ($post->post_type) {
case 'post_type_example':
$allowed_blocks = array_merge($core_blocks);
break;
default:
$allowed_blocks = array_merge($core_blocks, $custom_blocks, $plugin_blocks);
}
return $allowed_blocks;
}
add_filter('allowed_block_types', 'acf_allowed_blocks', 10, 2);
While this works perfectly, I am trying to determine whether or not it’s possible to remove the gravityforms/form block, but allow it inside the acf/test-block. Currently, if I remove the block from this function, it’s also becomes unavailable as an inner block in my ACF block markup, which looks like this:
$allowed_blocks = array( 'gravityforms/form' );
echo '<InnerBlocks allowedBlocks="' . esc_attr(wp_json_encode($allowed_blocks)) . '" />';
Does anyone have any idea on whether or not this is even possible with the current state of Gutenberg? I can just as easily live with it being available as both a main and an inner block, but it would be my preference to only use it as an inner block.
I was going to ask this exact same question, but then I used the search function and found this topic.
Did you ever find a solution to this? I want to create a block with a sidebar where editors can add some “cards”; a CTA, a related post etc. But I don’t want them to add these cards directly to the editor.
I was Googling this same question, and saw this: https://wordpress.org/support/topic/allowing-core-blocks-only-within-custom-inner-blocks/
which in turn links to this: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/#parent-optional
I haven’t tried it yet but it looks like it might help?
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
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 Privacy Policy. If you continue to use this site, you consent to our use of cookies.