wpautop not disabled when blocks are inserted dynamically

[jbeninger]

WP Version Tested on 6.1.1, but seems to still be present on the trunk.

Context

Our theme has multiple page-header styles. Users can insert any one of those as the first block of a page, or leave it out. If it's left out, we inject a default header block as the first block of the page using a customer WP_Block_Parser.

We've also imported a large number of pages from a previous pre-Gutenberg WP system, so not all posts have block content.

The Problem

On legacy posts that do not have block content, wpautop is enabled, even for the injected header block, resulting in extraneous <br> and <p> tags. If there's even a single block in the post content, the block renders normally.

The source of the issue is that do_blocks (https://core.trac.wordpress.org/browser/trunk/src/wp-includes/blocks.php#L1166) renders the blocks based on the results of the parser, but disables wpautop based on a call to has_blocks(), which uses the unparsed content to determine if there are any blocks in the post.

I recognize this is an edge case, as we're dealing with both legacy content and an (ab?)use of a custom block parser to inject blocks into blockless content, so it's not likely to be a high priority. But if the "block_parser_class" hook is going to allow us to override the parser, do_blocks should respect the blocks that are returned regardless of the original content string, and override wpautop accordingly.

Test Cases

Attached are:

• A single.php page template file that succinctly captures the problem
• The contents of two pages. One has no blocks and shows the wpautop problem. The other contains a single block and shows wpautop being disabled correctly. Use the Code Editor to enter this content into a page or post.