[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 noreply at wordpress.org
Fri Oct 14 17:39:09 UTC 2022


#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:6 ocean90]:
 > > Removing both `wp_filter_content_tags()` calls still adds the loading
 attribute so there's indeed something that still runs the `the_content`
 filter on the output.
 >
 > That's actually because of the post content block which
 [https://core.trac.wordpress.org/browser/tags/6.0.1/src/wp-includes/blocks
 /post-content.php?marks=55#L54 calls the filter in the render callback].

 Yes, this is exactly what I've just run into. It's easily verified that
 `wptexturize()` is called twice by Block Themes when rendering post/page
 content.

 This becomes more than just a display problem when the content has text
 that should not be texturised (e.g. inline Javascript) even if it's added
 via `the_content` filter with a priority greater than 11, i.e. after all
 default core filters have run.

 It seems to me that `get_the_block_template_html()` definitely shouldn't
 be calling the functions that are more usually hooked in to `the_content`
 (especially directly as it does) but that also implies that each block
 should be solely responsible for the parsing of its own content and I'm
 not sure that's the case.

 An HTML block in post/page content, for example, shouldn't run its content
 through any filters at all, given that the content is "raw" and therefore
 the responsibility of someone knowledgeable to insert. Yet try adding one
 to a page in Twenty Twenty-Three and making its content:

 {{{
 <script>
 function foo() {
   for( i=0; i < document.Main.elements.length; i++ ) {
     if (1 && 0) {
     }
   }
 }
 </script>
 }}}

 You'd expect this to output as-is in the page, but since it's run through
 `wptexturize()` by both `render_block_core_post_content()` and
 `get_the_block_template_html()`, the `&&` ends up encoded as
 `&&` and the Javascript fails.

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


More information about the wp-trac mailing list