-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache wp_theme_has_theme_json
via static variable
#3887
Cache wp_theme_has_theme_json
via static variable
#3887
Conversation
Per discussions in the Trac ticket, f8d09bc removes the cache reset and However, a reset of some sort is still needed between automated tests. Else, tests will fail (as seen by the commit ❌ ). |
/* | ||
* Ignore cache when `WP_DEBUG` is enabled. Why? | ||
* - to avoid interfering with the theme developer's workflow. | ||
* - to reset between each automated test. | ||
* | ||
* @todo Replace `WP_DEBUG` once an "in development mode" check is available in Core. | ||
*/ | ||
if ( WP_DEBUG ) { | ||
$theme_has_support = null; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted in #3887 (comment), a static cache reset is needed to reset after each automated test. This can be accomplished in many ways:
- Checking constants like
WP_DEBUG
and/orWP_RUN_CORE_TESTS
- Adding a hard reset parameter to the function
- Filtering
- Global
There is precedence within Core for using the WP_DEBUG
and `WP_RUN_CORE_TESTS constants.
I'd suggest avoiding the approach of adding a reset param to the function. Why? (a) BC concerns for the future if the param is no longer needed and (b) performance concerns of exposing a hard reset in prod.
However if a hard reset option is needed, for example on theme switch or preview, then the param can be added and constant(s) removed.
cc @felixarntz @azaozz @oandregal What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also combine the check with early bail-out below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hellofromtonya +1 to avoid the function parameter, I'd be concerned about BC with that too.
IMO the WP_DEBUG
approach is the most suitable for now, since that's what we were going to go with at this point anyway (keeping in consideration the @todo
comment to iterate on it with a more appropriate solution). Later, once there is e.g. a filter for this too, we would be able to adjust the tests themselves to decide on whether or not the static variable cache should be used here or not. That's why I think WP_DEBUG
works best for this for now.
Nit-pick, can you move it from the extra if clause to the existing one below? IMO no need to have a clause to reset the static cache value when we could instead not use the static cache at all. Having WP_DEBUG
in the existing clause below is also better in line with how we would like to adjust this code in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I think none of that is really great, but I think keeping the static and relying on WP_DEBUG
has the least impact on anything global that we wouldn't be able to change later, and it's relatively close to where we want this code to go eventually.
if ( WP_DEBUG ) { | ||
$theme_has_support = null; | ||
} | ||
|
||
if ( null !== $theme_has_support ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comment in https://github.com/WordPress/wordpress-develop/pull/3887/files#r1084500610:
if ( WP_DEBUG ) { | |
$theme_has_support = null; | |
} | |
if ( null !== $theme_has_support ) { | |
if ( ! WP_DEBUG && null !== $theme_has_support ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking more about the constants, I agree with @azaozz to also use WP_RUN_CORE_TESTS
specifically for the tests. In this way, it provides clarity on the purpose of both constants, especially for the future when a "development mode" is introduced into Core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- consolidates the
WP_DEBUG
check as requested - checks
WP_RUN_CORE_TESTS
per Cachewp_theme_has_theme_json
via static variable #3887 (comment) and Cachewp_theme_has_theme_json
via static variable #3887 (comment)
@azaozz and @felixarntz can you re-review please? Thanks!
+1 to using Regarding use of The only case that seems a bit unclear when using a static is whether invalidating the cache may be needed while PHP is running. Reading through the newer comments on https://core.trac.wordpress.org/ticket/56975, seems it will not be? |
Awesome! Thanks @spacedmonkey for running this before and after analysis #3887 (comment) 👏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This patch LTGM as it implements the lean performance approach discussed in the Trac ticket. There seems to be good consensus for it 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @oandregal!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using WP_DEBUG
(until better indication for "development mode" exists in core), and ! WP_RUN_CORE_TESTS
looks good imho.
Thank you everyone for your contributions to land on this solution. Committed via changeset https://core.trac.wordpress.org/changeset/55138. |
@spacedmonkey Sorry for not directly relevant question, but could you let me know which tool you used for this profiling? |
Trac https://core.trac.wordpress.org/ticket/56975
This PR implements caching to
wp_theme_has_theme_json
using a static variable.