[wp-trac] [WordPress Trac] #58872: wpautop not disabled when blocks are inserted dynamically

[WordPress Trac]

#58872: wpautop not disabled when blocks are inserted dynamically
--------------------------+-----------------------------
 Reporter:  jbeninger     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Formatting    |    Version:  6.1.1
 Severity:  minor         |   Keywords:
  Focuses:  template      |
--------------------------+-----------------------------
 **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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58872>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform