[wp-trac] [WordPress Trac] #60120: Add cache group to block pattern cache

[WordPress Trac]

#60120: Add cache group to block pattern cache
--------------------------+--------------------------
 Reporter:  spacedmonkey  |       Owner:  joemcgill
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  6.5
Component:  Themes        |     Version:  6.4
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  performance
--------------------------+--------------------------

Comment (by joemcgill):

 Thanks @flixos90. Based on
 https://core.trac.wordpress.org/ticket/59719#comment:13, let's both add a
 new `theme_files` cache group and use this as an opportunity to explore
 the idea of backing these caches up with a transient when a persistent
 object cache is not present.

 A new PR should:

 1. Introduce a new `theme_files` cache group via
 `wp_cache_add_global_groups()`
 2. Apply the new cache group when setting the cached block pattern data in
 `WP_Theme::set_pattern_cache`
 3. Set the cache to a site transient, using `set_site_transient()` in
 `WP_Theme::set_pattern_cache` with an expiration time (e.g.
 `HOUR_IN_SECONDS`) if `wp_using_ext_object_cache()` returns false. In
 single sites, this will automatically fall back to a local transient.
 4. The expiration time should only be used for transients and not the
 persistent cache, and the value should be filterable. We should design the
 filter so the same hook can be extended to block templates and template
 parts, so the filter should pass additional context that identifies that
 the data the expiration applies to in this case is block patterns. Ex.
 `apply_filters( 'wp_block_theme_files_cache_ttl', HOUR_IN_SECONDS,
 'patterns' )` so that these TTL values can be independently controlled.
 4. Handle deleting the transient in `WP_Theme::delete_pattern_cache` when
 `wp_using_ext_object_cache()` returns false.

 Note that `WP_Theme::delete_pattern_cache` is already called from
 `WP_Theme::cache_delete` and during `switch_theme()`, but additional cache
 invalidation may need to be considered for things like editing theme files
 directly in the legacy theme editor (`/wp-admin/theme-editor.php`).
 Additionally, `WP_Theme::set_pattern_cache` is already only called if
 `WP_DEVELOPMENT_MODE` is not set to `theme` or `all`, and that should
 remain the responsibility of the code calling
 `WP_Theme::set_pattern_cache`, not in the implementation of that helper
 method.

 @flixos90 and @spacedmonkey, feel free to add anything that I missed.

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