Fatal error: Memory exhausted loading recursive reusable blocks

[bobbingwide]

In Gutenberg there have been at least 3 issues associated with Reusable blocks causing infinite recursion.

WordPress/gutenberg#18704
WordPress/gutenberg#21117
WordPress/gutenberg#22131

The first of these 3 is still open.

I wanted to see if my fix for #27 and #30 could also be applied to issue 18704.

I created a scenario with three reusable blocks named after these issues.

Name	Post ID	Embeds reusable block
Issue 18704	1134	1133
Issue 21117	1135	1134
Issue 22131	1133	1135

These are in a recursive loop. 1133 -> 1135 -> 1134 -> 1133

I added a reusable block to the 404.html template and achieved the fatal error.
I then overrode the gutenberg_render_block_core_block render_callback
with fizzie_render_block_core_block

function fizzie_render_block_core_block( $attributes, $content, $block ) {
    if ( empty( $attributes['ref'] ) ) {
        return '';
    }
    if ( fizzie_process_this_content( $attributes['ref'] ) ) {
        $html = gutenberg_render_block_core_block( $attributes, $content, $block );
        fizzie_clear_processed_content( $attributes['ref'] );
    } else {
        $html = fizzie_report_recursion_error( $attributes['ref'], 'block' );
    }
    return $html;
}

[bobbingwide]

Note: This solution does not fix the problem when any of these reusable blocks are inserted into the Visual editor.
Here's what happened when I switched from Code editor to Visual editor while editing reusable block Issue 21117.

[bobbingwide]

I found a problem that didn't detect recursion.

• Trash Issue 21117 ( ID 1135 )
• Recover from bin - it goes into Draft status
• Attempt to edit the Draft post.
• The REST requests all work....but
  • On rendering we don't realise that post 1135 is where we started
  • Is this because it's a draft?
  • So recursion isn't detected.
• Visual editor enters cyclical loop

That's a good edge case!

[bobbingwide]

I revealed my proposed solution in the Gutenberg issue.
Here's what I wrote:
WordPress/gutenberg#26923 (comment)

[bobbingwide]

I'm not sure I can believe my eyes. I hooked into rest_prepare_wp_block and traced the $response.
The data field doesn't contain the rendered content.

[data] => Array
                (
                    [id] => 1135
                    [date] => 2020-11-12T21:10:08
                    [date_gmt] => 2020-11-12T21:10:08
                    [guid] => Array
                        (
                            [rendered] => https://s.b/wp56/?post_type=wp_block&p=1135
                            [raw] => https://s.b/wp56/?post_type=wp_block&p=1135
                        )

                    [modified] => 2020-11-13T00:25:43
                    [modified_gmt] => 2020-11-13T00:25:43
                    [password] => 
                    [slug] => issue-21117
                    [status] => publish
                    [type] => wp_block
                    [link] => https://s.b/wp56/?wp_block=issue-21117
                    [title] => Array
                        (
                            [raw] => Issue 21117
                        )

                    [content] => Array
                        (
                            [raw] => <!-- wp:paragraph -->
<p>This is reusable block 21117</p>
<!-- /wp:paragraph -->

<!-- wp:block {"ref":1134} /-->
                            [protected] => 
                            [block_version] => 1
                        )

                    [template] => 
                )

So why (the f) was it being rendered in the first place?
... other than the fact that we'll need to do this in order to know that recursion will occur.

[bobbingwide]

OK. So I've temporarily prevented the recursion in the editor by breaking the block.
It appears as an empty Classic block.
How do I improve on this?

[bobbingwide]

How do I improve on this?

It would be nice if there were a core/error block.
This is a work in progress.
The second block is a paragraph block that's replaced the core block.

I think there's a problem here.
What if the recursion is detected in an embedded reusable block, not the starting block.
Do we need to change all wp:block entries? Or will it work at the right level?

[bobbingwide]

Bugger. There's your answer.
Is this the same as when I was editing a Draft. The recursion was not detected since it was a recursion of the top level object, which wasn't in the $processed

[bobbingwide]

This is a different problem from that which I had editing a reusable block which was a Draft.
I believe it is because the editor has copies of the reusable blocks that it loaded up right at the start and it's trying to resolve them itself.

[bobbingwide]

While working on fizzie_process_this_content() I added some logic to automatically add the global post ID to the array, hoping this would cater for the Draft reusable block. This prevented the single pages from working.

[bobbingwide]

I'm going to close this now everything's moved on. Fizzie has its own recursion detection logic over and above what's provided in core/Gutenberg.