[wp-trac] [WordPress Trac] #56975: Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a public function

[WordPress Trac]

#56975: Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a
public function
-------------------------------------------------+-------------------------
 Reporter:  oandregal                            |       Owner:
                                                 |  hellofromTonya
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.2
Component:  Themes                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gutenberg-merge has-patch has-unit-  |     Focuses:
  tests has-testing-info                         |  performance
-------------------------------------------------+-------------------------

Comment (by hellofromTonya):

 Replying to [comment:92 spacedmonkey]:
 > I am not 100% sure about static variable. I don't like the DUX of cache
 clearing with a param on a function. That feels ugly.

 The `$can_use_cache` is removed, i.e. due to BC concerns and unknowns if
 it's truly needed

 {{{#!php
 wp_theme_has_theme_json( $can_use_cache = true ) {
 }}}


 >I could get behind any solution that makes the internals changable later.
 We need a `wp_theme_has_theme_json` function and a
 `wp_theme_has_theme_json_cache_clear` function ( named however you want).
 If developers call, `wp_theme_has_theme_json_cache_clear` if clears that
 cache. That way we can change it however we want later. Any solution where
 we forcing ourselves to use a param, is just making bad DUX IMO.

 @spacedmonkey I think [https://github.com/WordPress/wordpress-
 develop/pull/3887 PR 3887] fits your request of what is known today and
 what can be done in time for WP 6.2.

 * There's no reset param.
 * Cache is ignored when automated tests are running.
 * The internals are changeable without BC concerns.

 > All of which have their pros and cons. I think the end goal here is end
 up in a preseient cache across requests, but this has never been defined
 as the goal.

 If persistent caching is the goal, that will likely need to be in future,
 maybe 6.3. I doubt there's time to revamp all of the caching strategies
 being backported and get them committed in time for 6.2.

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