[wp-trac] [WordPress Trac] #61455: wp_kses & block parser being used on pre_term_name hook

[WordPress Trac]

#61455: wp_kses & block parser being used on pre_term_name hook
--------------------------+-----------------------------
 Reporter:  brumack       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.5.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 While I was experimenting with a custom parser, I noticed that the very
 first time the parser is called it's not being passed anything close to
 post content, or serialized block content.

 During a page's initial load, the block parser runs, and if you dump its
 output the very first result will be the theme's name.

 This is some example code I was running from a theme's functions file:
 {{{#!php
 <?php
 // this should run before template-canvas is required
 add_filter('template_include', function($template) {
         global $fndry_ran;
         $fndry_ran = false;
         return $template;
 });

 class TestParser extends WP_Block_Parser {

         public function parse($document) {
                 var_dump("document to parse",$document);

                 return parent::parse($document);
         }
 }

 add_filter('block_parser_class', function() {
         global $fndry_ran;
         if (!$fndry_ran) {
                 $fndry_ran = true;
                 return "TestParser";
         }

         return 'WP_Block_Parser';
 });

 }}}


 The resulting messages for me were:

 {{{
 string(17) "document to parse" string(13) "foundry-blank" string(17)
 "document to parse" string(233) " " // this contains the serialized post
 content
 }}}

 ''(Despite the code above this output was dumped twice because the parser
 is being called before template_include, which helped me figure out where
 it was coming from)''
 I managed to track down the culprit, and it appears as though during the
 main query construction, a term query is prepared and it results with
 wp_kses_hook sanitizing the term's name field, which at this point is just
 a string, as this is the query prepared for the wp_theme object. Weird
 that it's treating it as a potential source of block content though?

 Tracking it down:

 {{{
 blocks.php:1413 filter_block_content => parse_blocks
 formatting.php:5221 wp_pre_kses_block_attributes => filter_block_content
 default-filters.php:296 => add_filter( 'pre_kses',
 'wp_pre_kses_block_attributes', 10, 3 );
 kses.php:95 function wp_kses_hook => apply_filters 'pre_kses' hook
 kses.php:747 function wp_kses => wp_kses_hook
 kses.php:2104 function wp_filter_kses => wp_kses
 default-filters.php:23 => add_filter( $filter, 'wp_filter_kses' ); // part
 of array, $filter === 'pre_term_name'
 taxonomy.php:1808 sanitize_term_field => apply_filters(
 "pre_term_{$field}", $value, $taxonomy )
 class-wp-term-query.php:562 get_terms => $_name = stripslashes(
 sanitize_term_field( 'name', $_name, 0, reset( $taxonomies ), 'db' ) );
 class-wp-term-query.php:310 query => $this->get_terms
 // getting tired writing this out..
 class-wp-term-query.php:247 get_sql => get_sql_clauses =>
 get_sql_for_query => get_sql_for_clause => transform_query => $term_list =
 $term_query->query( $args )
 class-wp-query.php:2246 get_posts => $clauses = $this->tax_query->get_sql(
 $wpdb->posts, 'ID' );
 block-template-utils.php:1032 get_block_templates => $template_query = new
 WP_Query( $wp_query_args ); // yadda yadda eventually we get to get_posts
 template.php:500 get_page_template => get_query_template =>
 locate_block_template => resolve_block_template => get_block_templates
 template-loader.php:82 => $template = call_user_func( $template_getter );
 // in this case it was get_page_template

 }}}


 Exhausting lol.
 Anyway, it just strikes me as odd that the parse block func is being
 called on something that by rights should (probably?) never contain block
 content. Seems like it could be streamlined, maybe providing a flag that
 kses functions should not treat the field like block content? idk. Either
 way its workaround-able for the time being, just a little inefficient.

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