[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:  dev-feedback gutenberg-merge has-    |     Focuses:
  patch has-unit-tests has-testing-info          |  performance
-------------------------------------------------+-------------------------

Comment (by flixos90):

 @oandregal I agree with @Otto42 here. It is a non-persistent cache, no
 need to clear it. I did a quick follow up test for a static variable cache
 and in that, the total `wp_theme_has_theme_json()` time was cut in half. I
 would need to look a bit more to get a better assessment, but it is safe
 to say that the static variable cache ''does'' bring a notable
 improvement.

 I would suggest to go with that. Also a lot simpler as it does not involve
 the cache clearing code. And given the WP cache API usage doesn't bring a
 benefit here, at least for this function we don't even need to consider
 using a persistent cache later - no notable benefits. We can create a new
 PR where we introduce a static variable, and keep the WP cache API
 (including the non-persistent cache group) out of it. For the other
 related tickets where we have been considering using the API, we need to
 separately consider and measure whether it's worth it.

 @spacedmonkey I agree with you mostly, however I don't think we should use
 the existing caching from `WP_Theme` in `WP_Theme::has_theme_json()`.
 Doing so would bring just as little benefit as using the WP cache API does
 here, since it is effectively similar logic. This is a good lesson for us
 that using WP cache API is not ''always'' solution (though it often is).

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