[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 manfcarlo):

 Replying to [comment:9 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.

 The problem you describe is not mentioned in the ticket description at
 all. The ticket description only identifies the problem of the filters
 being run twice on the same content, which, to my knowledge, the patch
 solves.

 In other words, with the patch, none of the filters identified in the
 ticket description should ever run more than once on the same content.
 Unwanted effects such as #54614 and #56295 are believed to be directly
 caused by the double filters, so the patch should solve them.

 If the problem you describe still remains after eliminating the double
 filters, then it can be concluded that it's not caused by the double
 filters and is therefore outside the scope of this ticket.

 Plenty of independent bugs will still remain after applying the patch, and
 they can be worked on later, but it should not delay #54614 and #56295
 from being solved if there is a patch to solve them.

 > 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 argument here is rather fallacious and reminds me of people
 complaining that free speech is threatened because someone spoke out to
 disagree with them. If you want "encapsulation of rendering
 responsibilities within blocks themselves" then you must concede that any
 wrapper block that contains inner blocks can run something like:

 {{{#!php
 <?php
 return wptexturize( do_blocks( $inner_blocks ) );
 }}}

 It's not really fair to blame `get_the_block_template_html` for doing the
 same, simply because it's not a block. It could be argued that
 `get_the_block_template_html` actually does function much like a wrapper
 block, and there was [https://github.com/WordPress/gutenberg/issues/16998
 an abandoned exploration] to make the idea more explicit.

 The only way to stop blocks like Custom HTML from being filtered by a core
 wrapper block is to delegate the filters to micro-level blocks such as
 Paragraph, which I would imagine is inefficient and not how the filters
 were originally intended to be used.

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

 I'm not exactly sure of what you're hinting at here, but block themes have
 been available for 2–3 core release cycles now and I would not expect the
 core committers to agree to anything that breaks the pre-existing
 behaviour.

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