-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Skip redundant registration for Fonts API-registered fonts #48341
Skip redundant registration for Fonts API-registered fonts #48341
Conversation
When fonts are converted to theme.json format, origin is set to `gutenberg_wp_fonts_api`.
@@ -690,7 +690,7 @@ public function to_theme_json( $font_family_handle ) { | |||
} | |||
|
|||
$variation_obj = $this->registered[ $variation_handle ]; | |||
$variation_properties = array( 'origin' => 'gutenberg_wp_webfonts_api' ); | |||
$variation_properties = array( 'origin' => 'gutenberg_wp_fonts_api' ); |
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.
Is there risk of this impacting extenders who may be iterating through the registered fonts?
A search of the wporg plugin directory shows only Gutenberg using it https://wpdirectory.net/search/01GSZ95M6F3772YGWKZXG9A15P.
I suspect the risk to users is minimally low.
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.
If anything, this feature is in the experimental
folder so external developers should be aware that things might break 😅
Is it worth it to include a doing_it_wrong
call to announce that things changed, @hellofromtonya?
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.
If anything, this feature is in the experimental folder so external developers should be aware that things might break 😅
True, though the API now includes a temporary BC Layer which is intended to keep sites running while giving time for extenders to upgrade to the new API.
Is it worth it to include a doing_it_wrong call to announce that things changed, @hellofromtonya?
Good question @zaguiini! The origin is set internally within the API itself. So I think it's okay to not add a doing_it_wrong
here. But it does me think about: could it be set externally? If yes and set wrong, what happens? Hmm that's interesting as it may cause unexpected things. Thinking a new issue is needed to discuss and explore.
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.
tl;dr
This PR resolves the issue and is good for merge 👍
Reasoning:
- Before applying the PR, can reproduce the issue ✅
- After applying the PR, resolves the issue ✅
- The changes to the BC Layer have minimal risk of breakages: the
'origin'
is an internal flag and there are no instances of its usage in wporg plugin directory.
Needs tests to avoid this kind of regression, but thinking these tests can be added separately as more thought is needed for the coverage paths.
I can confirm the change fixes the problem and doesn't negatively impact Jetpack's or Blockbase's font stuff. |
@DaisyOlsen this patch is needed in 15.2.1 release (see #48263). |
* Update font origin to match updated API When fonts are converted to theme.json format, origin is set to `gutenberg_wp_fonts_api`. * Update font origin set in deprecated WP_Web_Fonts class --------- Co-authored-by: Tonya Mork <tonya.mork@automattic.com>
What?
This update synchronizes the origin name checked for fonts registered through the Fonts API. Those fonts are already registered, so can be skipped here.
Why?
Addresses #48263, where all fonts registered through a plugin are rendered on the front end, regardless of whether they are in use by global, template, or per-page style settings.
How?
Updates the origin name check to
gutenberg_wp_fonts_api
, to match where it's being set originally.Testing Instructions
If you have previously set custom fonts for global styles, templates/patterns through the editor, or on a per-post basis, please reset the typography to their defaults for the active template, otherwise test results may vary.
<head>
element, there should be a<style id="wp-fonts-local">
tag, but there should NOT be a<style id="wp-fonts-jetpack-google-fonts">
tag.<head>
element, there should now be a<style id="wp-fonts-jetpack-google-fonts">
tag, and the@font-face
declarations should match the custom font selected above. For instance, for Arvo there should be 4 declarations.<style id="wp-fonts-jetpack-google-fonts">
tag should include@font-face
declarations for both the custom font selected on the post, as well as the font set in the global styles above. For instance, for Arvo there should be 4 declarations, and Space Mono should have 12.Expected Results
<style id="wp-fonts-jetpack-google-fonts">
tag).@font-face
(s) should render on the site frontend in the<style id="wp-fonts-jetpack-google-fonts">
tag.@font-face
(s) should render on the site frontend's<style id="wp-fonts-jetpack-google-fonts">
tag, in addition to other custom fonts per template or page.Please note that logged deprecation notices for
wp_webfonts
andwp_enqueue_webfont
are expected.Testing Instructions for Keyboard
n/a
Screenshots or screencast
n/a
Additional Note
The test plugin provided for #48263 includes registration of fonts already present in TT3, and results in those fonts being doubly-rendered in the front end (first in
#wp-fonts-local
, and then#wp-fonts-jetpack-google-fonts
). The updated test plugin for this PR mitigates that issue by removing those fonts, as that bug should be tracked down separately.