[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
-------------------------+--------------------------
Changes (by flixos90):

 * owner:  flixos90 => joemcgill


Comment:

 We had a long discussion about this today
 [https://wordpress.slack.com/archives/C02KGN5K076/p1704214267233539 on
 Slack], involving mostly @joemcgill, @spacedmonkey and myself.

 Some context summary:
 * We cannot use the `themes` group as it is non-persistent by default.
 * We cannot use the `theme_json` group as it is non-persistent and also
 includes site-specific considerations (e.g. it cannot be globally cached).
 * We need to consider the differences between:
     * Sites with vs without persistent object cache
     * Multisite networks vs regular sites
 * We need to consider that people may edit theme files (specifically of
 custom themes) in ways WordPress cannot detect.

 Taking into account the ideas and perspectives shared in that discussion,
 here's what I would propose:
 * For sites that don't use a persistent object cache (see
 `wp_using_ext_object_cache()`), cache theme files in network transients
 (`*_site_transient()`).
     * On non-multisite, this automatically falls back to storing them in
 the `options` table.
     * Regardless of multisite or not, these transients are never
 autoloaded.
 * For sites that use a persistent object cache, introduce a new global
 cache group `theme_files`.
 * Use the transients / the cache group to cache theme files across all
 themes (i.e. transient/cache keys would include the theme's slug).
 * If using transients, provide an expiration (time TBD, likely anything
 between 30 minutes to 1 day).
     * This means when someone edits theme files in unsupported ways, at
 least they don't have to wait too long for the changes to become active.
     * For those that need changes to be reflected immediately, they need
 to either use `WP_DEVELOPMENT_MODE` or flush the transient with a plugin.
     * This is similar for sites using an object cache, though the
 difference in reality is that flushing the object cache is a commonly
 supported functionality in plugins, so it's a more intuitive workflow than
 having to flush transients (which isn't something that WordPress has
 historically required or encouraged anywhere).
 * If not using multisite, delete the previous theme's cached data since
 there's only that one site with the one active theme anyway (maybe
 regardless of whether object cache or transient, but certainly at least
 when using object cache).

 @joemcgill @spacedmonkey Please feel free to add anything I missed, and
 let me know if this proposal is in line with what you're thinking.

 Open questions if we go with the above:
 * What should be the expiration time?
 * How would we deal with theme versioning? Could be either part of the
 cache key, or stored within the transient/cache (in which case a cache
 value with outdated version would be considered stale and thus ignored).
 The latter is already used for the theme pattern caches today.

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