[wp-trac] [WordPress Trac] #59719: Revise caching approach for theme files

[WordPress Trac]

#59719: Revise caching approach for theme files
-------------------------+--------------------------
 Reporter:  flixos90     |       Owner:  joemcgill
     Type:  enhancement  |      Status:  assigned
 Priority:  high         |   Milestone:  6.5
Component:  Themes       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |     Focuses:  performance
-------------------------+--------------------------

Comment (by joemcgill):

 Thanks for adding your thoughts, @spacedmonkey. I agree that invalidation
 is one of the bigger challenges to consider when caching theme files due
 to the various non-standard ways that theme files can be edited. This is
 one of the reasons that I feel pretty strongly that any caching needs to
 include a TTL expiration so that sites don't get stuck in a broken state
 due to a stale cache indefinitely.

 In addition, it's helpful to list the cases where we ''can'' assume that
 files have been updated and explicitly clear caches in those cases as
 well. Off the top of my head, those include:

 1. When the theme version number has changed
 2. When someone has edited the theme from the Theme File Editor

 If we can find additional indicators that the files have been modified in
 order to invalidate caches, I think we should do so, but that shouldn't
 block us from implementing the strategy that @flixos90 [comment:13
 outlined above], IMO.

 I also agree that it is good to think about designing the caching strategy
 so that it is easy for external tools like WP CLI to make use of it, but
 those ideas should be discussed and handled separately from this
 particular ticket.

 Lastly, I want to offer a slight modification to the cache groups you've
 defined above:

 * **Theme data** (`themes`): Theme data that has traditionally been cached
 by Core, non-persistent by default.
 * **Theme JSON data** (`theme_json`): Expensive data that is derived from
 the theme.json structure, which includes loading and parsing options and
 settings across core, themes, blocks, and user data (e.g.,
 `wp_get_global_settings()`).
 * **Block theme template files** (`theme_files`): This currently includes
 block patterns (#60120), and potentially block templates/template-parts
 (#59600).

 The reason the last ones are worth handling differently than the prior two
 is that there is extra overhead involved in loading and parsing these
 types of files when compared with traditional PHP template parts, which
 are loaded an included at runtime. For patterns specifically, it's even
 more sever due to the fact that all of the patterns get registered on
 every request (as you've previously identified). Since this data is
 generally only used only once per request, we want to avoid this cost to
 each request. These files rarely change between requests so putting some
 persistence in place makes sense. If we find better ways of reducing the
 overhead of these types of files (e.g., lazily loading block patterns),
 the new `theme_files` cache group may become unnecessary entirely, and
 these could all move to the default `themes` cache, where a site could
 opt-in to persistence for the whole group.

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