Skip to content
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

Font Library doesn’t work with style variations (WordPress 6.5 RC2) #59818

Closed
YanCol opened this issue Mar 13, 2024 · 9 comments
Closed

Font Library doesn’t work with style variations (WordPress 6.5 RC2) #59818

YanCol opened this issue Mar 13, 2024 · 9 comments
Labels
[Feature] Font Library [Type] Bug An existing feature does not function as intended

Comments

@YanCol
Copy link

YanCol commented Mar 13, 2024

Description

When attempting to use the Font Library with style variations, the new fonts included in the chosen style variation do not appear in the Font Library. Additionally, font settings get mixed up, combining variants from both the selected style variation and the default style variation.

Step-by-step reproduction instructions

  1. Activate the Twenty Twenty-Four theme.
  2. Select the Ember style variation, which includes "Instrument Sans" and "Jost" fonts.
  3. Navigate to the Font Library to manage fonts.
  4. Observe that “Instrument Sans” and “Jost” don’t appear while the “Cardo” and “Inter” fonts from the default style variation are present. When attempting to edit the fonts, the settings are completely mixed up.

Screenshots, screen recording, code snippet

googlefonts.mp4

Environment info

WordPress 6.5 RC 2. Or WordPress 6.4.3 with Gutenberg 17.9.0

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

@YanCol YanCol added the [Type] Bug An existing feature does not function as intended label Mar 13, 2024
@getdave
Copy link
Contributor

getdave commented Mar 14, 2024

cc @mikachan @matiasbenedetto

@justintadlock
Copy link
Contributor

justintadlock commented Mar 15, 2024

In my tests, it's not just the Font Library modal. The fonts loaded in the iframe don't correctly switch when choosing the Ember style variation:

tt4-fonts-not-loaded

If you have these fonts on your system, you probably don't even notice it, so it's best to check the source. You can also see the Headings in the above screenshot are not Jost, which has sharper points (I don't have Jost installed on my computer).

@YanCol
Copy link
Author

YanCol commented Mar 15, 2024

@justintadlock Yes, you’re right. I've forgotten that I have a lot of fonts installed (including Jost) on my pc. I can confirm “that it's not just the Font Library modal. The fonts loaded in the iframe don't correctly switch when choosing the Ember style variation”

@pbking
Copy link
Contributor

pbking commented Mar 15, 2024

This seems to have more to do with TwentyTwentyFour theme's usage of semantic slugs for the themes (body and header rather than jost or inter).

I'll tinker with this, but I'm... not sure how to address it.

@justintadlock
Copy link
Contributor

This seems to have more to do with TwentyTwentyFour theme's usage of semantic slugs for the themes (body and header rather than jost or inter).

Noting that this is the recommended practice and is also documented in the Theme Handbook: https://developer.wordpress.org/themes/global-settings-and-styles/settings/typography/#custom-font-families

If it's the root issue, it's going to be in wide use and should be accounted for.

@matiasbenedetto
Copy link
Contributor

Here's a potential and partial fix for this issue: #59921

There's still another PR needed to fix the font selection issue (font selected in the sidebar is different to the one displayed in the modal).

@MaggieCabrera
Copy link
Contributor

This seems to have more to do with TwentyTwentyFour theme's usage of semantic slugs for the themes (body and header rather than jost or inter).

Noting that this is the recommended practice and is also documented in the Theme Handbook: https://developer.wordpress.org/themes/global-settings-and-styles/settings/typography/#custom-font-families

If it's the root issue, it's going to be in wide use and should be accounted for.

The reason why a semantic name is preferred for default themes (and many others) is because of patterns. If a pattern needs to define a different font-family, using the descriptive name would break the pattern on style variations. This is the case for TT4.

@matiasbenedetto
Copy link
Contributor

There's still another PR needed to fix the font selection issue (font selected in the sidebar is different to the one displayed in the modal).

Here's the potential fix for this part of the issue: #59959

@getdave
Copy link
Contributor

getdave commented Mar 25, 2024

For the purposes of WP 6.5 I consider this Issue to be resolved with the merging of #59959.

This fixes the primary issue with the wrong fonts being shown in the Fonts Library modal when clicking on the Font in the right hand sidebar.

There is a wider Issue relating to usage of semantic slugs for the themes. I think this should have it's own Issue and be worked on during the next (6.6) cycle.

cc'ing Editor release leads @annezazu @fabiankaegy @youknowriad for confirmation and confidence check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Font Library [Type] Bug An existing feature does not function as intended
Projects
Status: Done
Development

No branches or pull requests

7 participants