Closed ndiego closed 1 year ago
This issue will be resolved with Font Face, which is replacing the Fonts API.
I'm closing this issue.
Why? No further work will happen on the Fonts API.
Why? It is being replaced by Font Face and will be removed when Font Library is merged.
I'm not seeing where this issue was directly introduced within the Fonts API itself. @ndiego reported the issue still exists with the new Font Face generator and printer. Since it exists in both the Fonts API and new Font Face, I suspect the root cause is not within either.
I'm reopening this issue to capture the discussion, investigation, and separate resolving PR.
Thanks @hellofromtonya. I just know that this is going to impact a LOT of people, given the popularity of tools like Yoast and ACF (both of which use metaboxes). My guess is something related to the relatively recent work on iframing the Post Editor is the culprit. Any ideas @ellatrix?
More context to help:
@ndiego noted here
fonts registed in theme.json do not load when metaboxes are present in Gutenberg 16.1 or WordPress 6.3 Beta 2 (i.e. the Editor is iframed)....
In WordPress 6.2.2, without Gutenberg active, if you enable the Yoast plugin, the fonts in TT3 will load as expected. Yoast includes a metabox and the post Editor in 6.2.2 is not iframed.
Now if you update to 6.3 Beta 2, the fonts are not loaded when a metabox is present (the Editor is no longer iframed).
Nick notes the metabox regression was introduced during WordPress 6.3 beta cycle.
Neither the Fonts API nor the new Font Face have been merged into WordPress 6.3. Rather, WordPress Core is still using the stopgap code from WP 6.0.0 (i.e. _wp_theme_json_webfonts_handler()
).
Something else is the culprit / root cause, some other backport to Core introduced during the 6.3 cycle is causing this regression.
Note: If the fix for the root cause also requires a change to be made in the @font-face
handling, it'll need to be done in _wp_theme_json_webfonts_handler()
within WordPress Core.
What's the next step?
Identify the PR(s) merged into Gutenberg or the backport in WordPress Core that introduced the regression. This step will take some testing and investigation.
@anton-vlasenko @ellatrix
Applying the approach described in https://github.com/WordPress/gutenberg/pull/51770#issuecomment-1620867701 should fix this issue. I've just tested that it works.
WordPress 6.3-beta3-56130-src, no meta boxes: font faces are loaded;
WordPress 6.3-beta3-56130-src, meta boxes enabled: font faces are loaded;
WordPress 6.3-beta3-56130-src, Gutenberg trunk (16.1.0), no meta boxes: font faces are loaded;
WordPress 6.3-beta3-56130-src, Gutenberg trunk (16.1.0), meta boxes enabled: font faces are NOT loaded;
trunk
(i.e. 6.3-beta3-56130-src
)Note: the Gutenberg plugin is deactivated in this test report.
Here is what the font looks like on Google Fonts:
IBM Plex Mono font:
IBM Plex Mono font:
WordPress Core's current trunk via 6.3-beta3-56130-src
works as expected with no regression ✅
I can confirm with 6.3-beta3-56140
. Activating Gutenberg causes the issue to come back. But looks like we are good in Core :raised_hands:
Next, this test report repeats my above tests but with the Gutenberg plugin activated.
Here is what the font looks like on Google Fonts:
IBM Plex Mono font:
IBM Plex Mono font:
With metaboxes (such as from Yoast SEO plugin):
The regression is in Gutenberg, but not in WordPress Core 6.3 Beta 3.
Why are the @font-face
styles are not being generated?
tl;dr Printing is limited to the iframe for block themes.
I was wrong. The regression is in the Fonts API.
The change that introduced the regression in Gutenberg:
The hook to print them into the main doc's <head>
was guarded to only work for classic themes:
This was done for performance to avoid printing the @font-face
styles more than once, i.e. in the main doc and in the iframe. But consideration was not given to when metabox is present, causing the editor no longer be in an iframe.
Commenting out the if
guard wrapping around the add_action()
resolves the regression in the Fonts API.
The new Font Face implementation replacing the Fonts API also resolves the regression.
As the Font Face is not yet merged into Gutenberg, I'll create a quick fix PR to remove the guarding in wp_fonts()
. This way, the regression is resolved and not dependent upon the new Font Face.
PR https://github.com/WordPress/gutenberg/pull/52343 should resolve this regression in Gutenberg. @ndiego @anton-vlasenko can you test the PR please to confirm it does resolve it for you?
Description
https://github.com/WordPress/gutenberg/pull/51178 fixed a bug in 15.9 that prevented fonts included in themes to be loaded in the Editor, both post and Site Editor. This was due to a change in https://github.com/WordPress/gutenberg/pull/50875.
While https://github.com/WordPress/gutenberg/pull/51178 fixed the issue when the Editor is iframed, if a plugin registers metaboxes, the Editor is no longer iframed. As a result, the fonts are no longer loaded.
cc @hellofromtonya @ellatrix
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
Environment info
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes