[wp-trac] [WordPress Trac] #53804: Bug: `wp_cache_themes_persistently` only used for setting, not getting

[WordPress Trac]

#53804: Bug: `wp_cache_themes_persistently` only used for setting, not getting
----------------------------+-----------------------------
 Reporter:  mattwiebe       |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Themes          |    Version:
 Severity:  normal          |   Keywords:  needs-patch
  Focuses:  administration  |
----------------------------+-----------------------------
 The `WP_Theme` class sets its own `$persisently_cache` static property on
 `__construct`, via the `wp_cache_themes_persistently` filter. The class
 checks this property throughout before setting cache values, but cache
 values are fetched via the `cache_get` method without ever first checking
 `self::$persisently_cache`, leading to a condition where, once caching is
 active, it is difficult to test changes to a theme that involves cached
 pieces.

 For instance, on WordPress.com, we return `150` on the
 `wp_cache_themes_persistently` filter to leverage our memcached backend
 for caching theme data. We recently wanted to remove the `full-site-
 editing` theme tags from a few themes because they were causing problems
 with theme activation under WP 5.8's `validate_theme_requirements`
 function, which won't activate a theme with that tag and the Gutenberg
 plugin inactive. (This was from an earlier, pre-Gutenberg FSE project we
 ran internally on wpcom.)

 Nor could we simply call the `cache_delete` method for the affected
 themes, since our development environment shares the `memcache` pool with
 production servers, which would lead to cache pollution. Nor was simply
 deploying the fix and hoping for resolution after cache expiry a valid
 approach in this case.

 The simple fix would be to check for `self::$persistently_cache` in the
 `cache_get` method, always returning `false` in that case. I can try to
 make a patch for that tomorrow, as I don't currently have a working core
 environment to make a patch against and need to log off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53804>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform