[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