Description

• In Fatal errors due to infinite recursion with Full Site Editing #26923 I documented some scenarios where block rendering results in infinite recursion.
• The problems are easy to create in Full Site Editing using the core/template-part and/or core/post-content blocks.
• A very similar problem with Reusable blocks ( core/block ) was reported 500 error and 'Reusable' tab disappears when a reusable block is embedded into itself #18704.
• In Solve #18704 on front-end #26951 @carlomanf has developed a solution that checks for recursion for any block within WP_Block class.
• In my solution the recursion checking is only performed by block types which can go infinitely recursive.
  • core/post-content
• core/template-part
• core/block
• I believe it should be possible to cause core/post-excerpt to recurse.

Both solutions rely on a test to see if the block that's about to be rendered is already being processed.

The logic implemented in each solution is:

• Check if the block that's about to be rendered is already being rendered.

• If it isn't already being rendered. ie It's safe to render

  • add it to the stack of blocks being rendered.
  • render the block
  • pop it from the stack

• else don't render it

• In the WP_Block fix the recursive block is rendered as an empty string. Neither the end user nor the site administrator is made aware that there was a recursion problem.

• In this solution, there is an option to report the recursion error.

• The level of detail reported depends on the setting for WP_DEBUG

• This solution also supports extending the base solution for reporting recursion errors.

Regarding the reusable blocks issue ( #18704 )

• I've developed an extension class for the reusable block recursion problem that attempts to deal with the problem when encountered in a REST request.
• This error reporting extension for reusable blocks is not (yet) part of this PR.
• While it is able to deal with a self recursive reusable block
• It is unable to prevent the block editor from going recursive when a user inserts a reusable block that's been returned in the request to fetch reusable blocks.

How has this been tested?

Environment

• Tested with WordPress 5.6-beta3
• Active theme: Twenty Twenty-One Blocks, with some additional template parts, some template parts commented out and modified CSS.
• Active plugins: Gutenberg
• Plus, used to aid understanding of the post-content output:
• oik - for the [bw_list] shortcode
• And during development - oik-bwtrace - used to trace server events

Screenshots

Scenarios

Front end

• Tested recursion detection and reporting for template-parts using the 404.html template and a couple of recursive template parts.
• Tested recursion detection and reporting for post-content within the query / query loop in multiple pages
• Tested recursion detection for a self recursive reusable block.
  

Types of changes

• Fixes Fatal errors due to infinite recursion with Full Site Editing #26923
• Fixes Infinite recursion trying to edit a wp_template with revisions containing wp:post-content blocks #26593 - recently recreated then retested

These changes also include the fixes applied for:

• Fixes #26010 - Template Part Not Found message on Windows server #26772
• gutenberg_render_block_core_template_part() should not call wpautop() #26731

The solution introduces

• 4 new files included in load.php
• which implement 2 classes
  • WP_Block_Recursion_Control
  • WP_Block_Recursion_Error
• and 3 APIs:
  • gutenberg_process_this_content - performs the check for recursion
  • gutenberg_clear_processed_content - pops the last item processed
  • gutenberg_report_recursion_error

Checklist:

• My code is tested.

• My code follows the WordPress code style.

• My code follows the accessibility standards.

• My code has proper inline documentation.

• I've included developer documentation if appropriate.

• I've updated all React Native files affected by any refactorings/renamings in this PR.

• I've not delivered any automated tests.

• I imagine the new functions will need documenting so that they can be used by other block developers who may have had to develop their own recursion checking.