“Enclosing” MFB shortcodes don’t seem to work

Hi @yankiara, thank you for your feedback. MFB does not support separating a shortcode into opening and closing tags as you’ve described . It only supports the normal way as follows:

[shortcodetag att1="value1" att2="value2"]Your content[/shortcodetag]

Anyway, I’m not clear on why you need to separate your shortcodes in this way. Could you please explain your use case? Perhaps I can suggest a workaround.”

Phi.

Hi,

Thanks for your reply ??

My use case is displaying a group of blocks with conditions, but it could be any processing on a group of blocks. For instance, if I’m on a single post template and post category is ABC, then display blocks.

So I use enclosing shortcodes to wrap a bunch of blocks, and shortcode evaluates the condition with PHP. But it is impossible to use inline enclosing like [shortcode]…[/shortcode] for this because content is not a string.

A possible workaround is to wrap my blocks in a pattern, then transmit pattern id as shortcode parameter, then recall the pattern in my shortcode, but I lose a bit of spontaneity ??

Hi?@yankiara, thank you for the details. Based on your use case, using MFB is not an efficient approach. I would recommend using the Content Blocks Builder plugin instead. It is also my plugin. Here is how you should do it with CBB:

1. Create a new block. You could name it anything you want. for example: your_project_condition
2. Put that block inside your Query Loop
3. Then insert all your required blocks inside that block
4. Add following code to display or hide it:

add_filter(
	'render_block_boldblocks/your_project_condition',
	function( $block_content, $block ) {
		$current_post_id = $block->context['postId'];

		// Do your condition here, use $current_post_id as the context parametter to calculate the condition.
		if ( false ) {
			// Don't display inner blocks.
			return '';
		}

		// Display all blocks.
		return $block_content;
	},
	10,
	2
);

Please let me know if you need further assistance.

Thank you!

I couldn’t get the post ID with $block->context['postId'] because I had a PHP error (and indeed, $block is an array, and it doesn’t have any context item anyway), but I could use get_the_ID() instead, so it is OK.

Maybe because I’m not in a query loop but just in single template content? I have to check CBB documentation for this context thing.

Anyway, this is exaclty what I needed, looks like CBB will soon be adopted ??

@yankiara, I’m glad to hear that you find it useful. Regarding the post_id in the context, I made a mistake. Here is the correct code:

add_filter(
	'render_block_boldblocks/your_block_name',
	function( $block_content, $block, $block_instance ) {
		$current_post_id = $block_instance->context['postId'];

		// Do your condition here, use $current_post_id as the context parametter to calculate the condition.
		if ( false ) {
			// Don't display inner blocks.
			return '';
		}

		// Display all blocks.
		return $block_content;
	},
	10,
	3
);

OK, awesome, I will have a deeper look a your plugins, they seem great!

Mmmmh, strangely, since I have created the block, I have this warning in the add plugins page:

Warning: Undefined property: stdClass::$plugin in?/home/xxxxxxxxxx/sites/xxxxxx/wp-includes/class-wp-list-util.php?on line?168

(Yes, my WP_DEBUG is to true.)

Even after having deactivated all plugins, the warning remains.

Also even with CBB deactivated, the block I created is still working and available in the editor!
So does it mean created blocks are persistent???
How can we permanently delete them?

@yankiara I believe the issue is not related to CBB. When you deactivate it, the block stops working in the editor. I have never encountered this issue, so I’m not sure about the problem. Can you try it in different installation?

Yes, created blocks can’t be added in the editor any longer, but they are still present in the editor as not supported block, and they still work on frontend.

I guess I’ll have to delete them from the post, anyway, and maybe purge the cache, if I need to remove the plugin.

As for the PHP warning, it disappeared after a few activations/deactivations of all plugins ??

This is how all blocks work. When they are unregistered, they turn into unsupported blocks. You have to remove that unsupported block from the post manually.