[wp-trac] [WordPress Trac] #45471: Allow caching of parse_blocks results

[WordPress Trac]

#45471: Allow caching of parse_blocks results
----------------------------------------------+----------------------------
 Reporter:  joostdevalk                       |       Owner:  francina
     Type:  enhancement                       |      Status:  assigned
 Priority:  normal                            |   Milestone:  Future
                                              |  Release
Component:  Cache API                         |     Version:
 Severity:  normal                            |  Resolution:
 Keywords:  dev-feedback early needs-refresh  |     Focuses:  performance
----------------------------------------------+----------------------------

Comment (by dmsnell):

 > Second, I think we have to work under the assumption that the parser
 changes the output. I lean towards @dmsnell's example above, but it
 doesn't tell us if the parsing will change the block. One potential option
 around this is to use the content before parsing to create the md5() hash,
 and the content after parsing for the stored cache value. As long as the
 pre-parsed content is unchanged, and the parsing class remains the same,
 the output content should be the same.

 I'm confused on what you are saying @desrosj - I think what you list as a
 "potential option" is what I proposed in my comment earlier, though
 "doesn't tell us if the parsing with change the block" is still unclear.
 Just to be clear, we're not looking at rendered output in this function
 but //only// a transformation from the serialized HTML into the block
 objects that are fed into the renderer. `$content` in this case //is//
 "the pre-parsed content."

 > a cached empty string would not be returned and would always trigger
 parsing

 Good catch! Type errors strike again. Practically speaking though this
 wouldn't really matter since it probably takes about as much time to parse
 an empty document as it does to pull it from cache. Caching empty
 documents also seems wrong; we could early-abort if the input document is
 blank.

 > I'm also wondering if it's better to delegate the caching responsibility
 to the parsing classes

 This is a great idea and one of the reasons we added in the filterable
 parser. That being said, caching the parse generally seems like a fair
 option to stick in as the default. This would break behaviors if a custom
 parser class introduced non-determinism in its parse, possibly through
 something like random ids or time-based parsing, or *gasp* through
 database lookups. This //isn't// the place to perform those side-effects
 but someone will probably do it.

 If we want to demonstrate a custom caching parser class we could wrap the
 default behavior and it might serve as an example of how to wrap the
 parser.

 {{{#!php
 <?php
 class WP_Caching_Block_Parser {
     public function construct( $parser_class = 'WP_Block_Parser' ) {
        $this->parser_class = $parser_class;
     }

     public function parse( $content ) {
         if ( ! $content ) {
             return [];
         }

         $cache_key    = sprintf( 'block_%s_%s', md5( $content ),
 $this->parser_class );

         $cached = wp_cache_get( $cache_key, 'parsed_blocks' );
         if ( $cached ) {
                 return $cached;
         }

         $parser = new ($this->parser_class)();
         $parsed = $parser->parse( $content );
     }
 }

 function parse_blocks( $content ) {
     $parser_class = apply_filters( 'block_parser_class',
 'WP_Caching_Block_Parser' );
     $parser = new $parser_class();
     return $parser->parse( $content );
 }
 }}}


 Well I don't like what I just wrote in a permanent sense but the idea at
 least is close to what I want - default behavior is to cache all posts and
 use the default parser. If you have special needs then you can replace the
 whole thing, and if you want to keep the caching behavior around you can
 wrap your own class in this one.

 > Are there any good examples of custom block parsing classes in the wild?
 I think it may help to review those.

 I haven't come across any.

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