Repository navigation
Conversation
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
…uild. WP_Theme_JSON_Resolver::get_core_data(), get_block_data(), get_theme_data() and get_user_data() tested the cached object for null before calling has_same_registered_blocks(). On the first call the object is null, so the check never ran and never recorded the registered blocks. The second call ran the check, found nothing recorded, and rebuilt the origin's data. Call has_same_registered_blocks() first, so the first build records the registered blocks and the second call reuses the data. A block type registered between calls still rebuilds it. The test data provider case "When both caches are not empty" left the blocks cache empty and expected a rebuild; it now fills the cache and expects none.
205c3da to
c80fcb0
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
The performance numbers in the description are probably all much lower, to the point that this change is almost certainly negligible in terms of performance, since #14071 landed. |
1 participant
Avoid rebuilding
WP_Theme_JSON_Resolverdata on the second call to each origin getter. The first call skipshas_same_registered_blocks()because the data cache is empty, leaving the block registry cache unset. The next call treats that as a registry change and rebuilds the data.Check the registered blocks before the data cache in all four getters. This records the registry on the first call so the second reuses the data. Registering a new block still triggers a rebuild;
get_theme_data()still applies theme supports on each call by default.Filters added after the first build now need
wp_clean_theme_json_cache()to take effect unless a new block is registered. The redundant rebuild previously picked them up on the second call. Automatic invalidation on filter changes remains unresolved in Trac #62249.In measurements from 2026-10-07, this change reduced origin builds from eight to four per request, saving 0.5–1.2 ms in the getters. Total request time was too variable to establish an improvement. Getter times in milliseconds, from three rounds of 20 requests each (medians after warm-up):
wp/v2/posts?context=editRuns alternated trunk and branch in Docker with PHP 8.3.33, WordPress 7.2-alpha-63166-src,
WP_DEBUGoff, and Twenty Twenty-Four with ten block-content posts. These measurements predate the merged-data cache added in r64354.Validation at
d52f8b9a38: 44 resolver tests (177 assertions) and thethemesandblocksgroups (1,297 tests, 10,679 assertions, 15 skips) passed, as did PHPCS for both files. The four new regression cases cover cache reuse and invalidation; all fail against the pre-fix resolver. The existing core-data test now sets both caches as its data provider specifies.Trac ticket: https://core.trac.wordpress.org/ticket/62249
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code, Codex
Model(s): Claude Fable 5.1, GPT-6
Used for: Implementation, tests, measurement, review and description editing.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.