[wp-trac] [WordPress Trac] #63062: Parent theme incorrectly not getting resolved in WordPress 6.8-beta1
WordPress Trac
noreply at wordpress.org
Wed Mar 12 11:42:27 UTC 2025
#63062: Parent theme incorrectly not getting resolved in WordPress 6.8-beta1
-------------------------------------------------+-------------------------
Reporter: fabiankaegy | Owner: joemcgill
Type: defect (bug) | Status: closed
Priority: high | Milestone: 6.8
Component: Themes | Version: trunk
Severity: normal | Resolution: fixed
Keywords: has-patch needs-unit-tests needs- | Focuses:
testing has-testing-info has-screenshots |
-------------------------------------------------+-------------------------
Comment (by gigitux):
Thanks, @wildworks, for the initial exploration. As mentioned in [63086],
this change causes regressions in plugins relying on
`wp_is_block_theme()`, such as WooCommerce.
Based on the discussion, this change seems necessary because
`wp_is_block_theme()` may return an incorrect value due to inaccurate
parent theme resolution before `after_setup_theme`. A potential solution
could be addressing the parent theme resolution issue.
After some investigation (cc @nerrad), we found:
* `wp_is_block_theme()` calls `wp_get_theme()` to retrieve the theme and
invokes the `is_block_theme()` method.
* `wp_get_theme()` instantiates `WP_Theme`, which sets a cache on the
first run. If executed before `after_setup_theme`,
[https://github.com/WordPress/wordpress-
develop/blob/7475126055ddf7b9fd6c303d2468676926b762f0/src/wp-
settings.php#L689-L705 the theme's functions.php] will not have been
processed, resulting in an incorrect cache.
A possible solution could be to only set the cache on `WP_Theme` if
instantiated after `after_setup_theme`; otherwise, avoid caching.
It is essential to take careful consideration of performance implications.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/63062#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list