[wp-trac] [WordPress Trac] #56975: Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a public function
WordPress Trac
noreply at wordpress.org
Wed Jan 18 22:19:07 UTC 2023
#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 needs-testing-info | Focuses:
gutenberg-merge | performance
-------------------------------------------------+-------------------------
Comment (by dmsnell):
To share more about the testing I provided, in case it helps someone
figure out what broke, I was running PHP 8.2.0, running WordPress from its
directory with `php -S 0.0.0.0`, on a fresh site install, on a fresh
database, with the `trunk` Gutenberg symlinked as a plugin.
Before the patch, with `WP_DEBUG` set (also with it unset too) I get no
CSS requests from `wp-admin` pages (except `wp-login`) and no errors on
the backend. as a fresh install the theme was twenty-twenty three, but
changing the theme didn't affect anything. page renders on the site
frontend were fine and enqueued and requested the appropriate CSS.
After the patch, everything works again.
Found this commit via `git bisect`.
I'm curious how this affects `wp-admin` CSS, maybe a bit unnerved that
theme-JSON related code can have this effect, but maybe I'm overlooking
something on the caching? or some error is being eaten up by a loose
try/catch somewhere? I initially assumed some hook/filter chain was broken
which stoped `enqueue_script`, but I didn't look far.
Thanks everyone for fixing this!
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56975#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list