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

WordPress Trac noreply at wordpress.org
Mon May 10 18:57:48 UTC 2021


#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 desrosj):

 Was just thinking this through a bit, and I have a few concerns.

 First, I think that if caching is added for block parsing, it should be on
 by default, and WordPress should manage cache keys automatically.

 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 also wondering if it's better to delegate the caching responsibility
 to the parsing classes (`WP_Block_Parser` by default). Different parsing
 classes may want to cache blocks more or less aggressively. Are there any
 good examples of custom block parsing classes in the wild? I think it may
 help to review those.

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


More information about the wp-trac mailing list