[wp-trac] [WordPress Trac] #55996: the get_the_block_template_html call all the same functions as the the_conent filter so they are run twice

[WordPress Trac]

#55996: the get_the_block_template_html call all the same functions as the
the_conent filter so they are run twice
------------------------------------------+------------------------------
 Reporter:  pbearne                       |       Owner:  (none)
     Type:  defect (bug)                  |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Formatting                    |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  performance
------------------------------------------+------------------------------

Comment (by needle):

 Replying to [comment:8 manfcarlo]:
 > A patch for this is available at
 https://github.com/WordPress/gutenberg/pull/44995

 @manfcarlo Unfortunately your patch doesn't solve the first issue I
 mentioned, so let me restate the problem...

 Say you want to add something to the rendered post content that ''must
 not'' be run through the core default filters. In a plugin, this is
 traditionally done by hooking in to `the_content` with a priority greater
 than `20` (IOW after the final default filter `convert_smilies` has run).

 However, because `get_the_block_template_html()` applies `wptexturize()`
 (plus the other functions mentioned in this ticket) directly to the
 complete rendered markup of the page template, this mean that whatever
 you've added via `the_content` still gets run through those functions.

 Your patch removes those function callbacks from `the_content` filter in
 `render_block_core_post_content()`, but plugin and child theme authors
 would actually ''expect'' those filters to be applied to post content
 unless they had already explicitly removed them.

 In my view, the issue here lies not in `render_block_core_post_content()`
 but in `get_the_block_template_html()` which, in principle, should do
 little (if anything) beyond running the template through `do_blocks()`. (I
 assume that `render_block_core_template_part()` should also delegate
 rendering to the blocks nested inside it and that it, too, should not call
 `wptexturize()` etc etc either.)

 Any renderable content in a block theme template should presumably be
 wrapped in the appropriate block identifier code and its parsing should
 therefore be handled by the block itself.  As it stands,
 `get_the_block_template_html()` breaks that contract.

 > The solution I propose is to move certain functions (`wptexturize`,
 `do_shortcode` and possibly others) out of `the_content` filter and into
 the block callback of certain blocks (paragraph block, classic block,
 heading block etc.) This will prevent them from ever being run twice on
 the same content.

 This is (kind of) why I raised the example of the HTML block. My point was
 about encapsulation of rendering responsibilities within blocks themselves
 and the apparent conflict with `get_the_block_template_html()` applying
 those functions outside the scope of the blocks themselves.

 Excluding the content of an HTML block from ''any rendering at all'' (as
 would be expected by the name of the block) seems problematic as long as
 `get_the_block_template_html()` applies the functions that it does.

 The larger issue here is whether `the_content` filter is actually an
 appropriate filter to invoke in a block theme context at all.

 > I tested your example and it appears that `&&` is produced
 even when `wptexturize` is only applied once. While I agree that it is
 unwanted, it looks to be outside the scope of this ticket.

 Thanks - yes, on review this does seem to be a bug in `wptexturize()`
 itself.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55996#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform