Conflict with LearnDash

This was brought up to LearnDash support. We are looking into it. Should be patched soon. Thanks.

Thank you @theinnographer and @pmenard.

If anyone comes across this, we’ve been communicating using email conversations. The issues should be resolved soon.

• This reply was modified 4 years, 3 months ago by Morgan Hvidt.

Just some observations about how the Conditional Blocks plugin works and possibly way to minimize the effect you are having on other plugins.

First, within the Conditional Blocks plugin code, in file methods/core/core-render-blocks.php the filter priority for ‘render_block’ seems to too high a priority ‘999’.

add_filter( 'render_block', 'conditional_blocks_render_html', 999, 2 );

Since the purpose of the Conditional Blocks plugin is meant to filter all blocks it should call the filter function conditional_blocks_render_html before the normal plugin handler function is called. Otherwise, the other plugins render functions get called then ends up not getting displayed by the Conditional Blocks plugin logic. I would suggest changing the 999 to 1. OR maybe consider using the two other filters below.

In the WP core in wp-includes/blocks.php within the function render_block()is the start for the ‘render_block’ filter call. Before that point, there are two other filters you should consider using.

/**
  * Allows render_block() to be shortcircuited, by returning a non-null value.
  *
  * @since 5.1.0
  *
  * @param string|null $pre_render The pre-rendered content. Default null.
  * @param array       $block      The block being rendered.
  */
  $pre_render = apply_filters( 'pre_render_block', null, $block );

Seem this would be a better filter to hook into since it lets you abort the normal block rendering logic.

/**
  * Filters the block being rendered in render_block(), before it's processed.
  *
  * @since 5.1.0
  *
  * @param array $block        The block being rendered.
  * @param array $source_block An un-modified copy of $block, as it appeared in the source content.
  */
  $block = apply_filters( 'render_block_data', $block, $source_block );

This filter would let you remove your own block attributes so they don’t get passed down to the real plugin render logic where they are causing issues.

Thank you very much for bringing up those suggestions @pmenard ??

The render_block_data filter is excellent. I’m exploring isolating the attributes, as you said.

function conditional_blocks_isolate_attribute_data( $parsed_block, $source_block ) {

	if ( isset( $parsed_block['attrs'] ) && isset( $parsed_block['attrs']['conditionalBlocksAttributes'] ) ) {
		// Move conditional blocks attributes to the first level.
		$parsed_block['conditionalBlocksAttributes'] = $parsed_block['attrs']['conditionalBlocksAttributes'];
		// Remove the original condition attributes.
		// This way third-party plugins won't pick up conditions along with thier expected attributes.
		unset( $parsed_block['attrs']['conditionalBlocksAttributes'] );
	}
	return $parsed_block;
}

add_filter( 'render_block_data', 'conditional_blocks_isolate_attribute_data', 10, 2 );

I think this will provide a nice solution going forward. It means I can still use the full flexibility of the render_block filter and make sure our attributes aren’t handled together with the block’s expected attributes.

The ‘999’ priority is more of a catch-all choice. Some blocks may add additional HTML earlier. Conditional Block may need to add a wrapper around the entire block to function.

@pmenard I’ve been looking deeper into this and my above idea of isolating the attributes doesn’t work with LearnDash blocks.

It seems that LearnDash blocks don’t pass any attributes ['attrs'] to any of the 3 filters in render_block().

That would because LearnDash Blocks handles attributes and generates shortcodes earlier than the render_block() function.

The only way that I can prevent the Fatal error: Uncaught Error: Object of class stdClass could not be converted to string in LearnDash from occurring is by removing condition attributes using the LearnDash filter learndash_block_markers_shortcode_atts. I’m happy to do so, to prevent errors for our users. Though it would be better to handle objects in the first case to prevent issues with other third-party integrations.

Would it be possible for LearnDash blocks to pass along the original attributes to render_block() as well? That’s the last thing that’s preventing me from adding conditions.

The current output looks like this:

Array
(
    [blockName] => 
    [attrs] => Array
        (
        )

    [innerBlocks] => Array
        (
        )

    [innerHTML] => [learndash_login login_label="custom label" type="registered,course,quiz"]
    [innerContent] => Array
        (
            [0] => [learndash_login login_label="custom label" type="registered,course,quiz"]
        )

)

What are your thoughts?

@morganhvidt

We are in the process of reviewing the changes needed. So no need for you to patch the LearnDash code. But thanks.

Anyone having issues with LearnDash core can contact our support and reference our tracking ID LEARNDASH-5145.

Hi @morganhvidt and @pmenard,

I know I’m connected by email with you and your teams too.

Just wanted to thank you here also for the quick and deep responses to this.

It’s great to feel so well supported.

Very much appreciated.

Alex.

Phew! Been a busy week, but I wanted to write again to thank you both @pmenard and @morganhvidt for your help on this. Thanks too to LearnDash’s Jarett.

For those following along, the current version of Conditional Blocks + the next version of LearnDash to be released should fix this one for you.

Thanks all!

Alex.

• This reply was modified 4 years, 3 months ago by theinnographer.