Heading Font Weight Not Applying in Adventurer

[cat-og]

Quick summary

When using the theme Adventurer, changes made to the font weight to the Heading block in the Editor do not apply to the live site.

Multiple users also reached out to indicate that the font weight had abruptly changed to the default Black font weight, despite their custom settings. p1701120577309219-slack-C03TY6J1A

I also tested this on the theme Verve, but the Heading block updated as expected.

Steps to reproduce

1. Update site theme to Adventurer
2. Open any template in the Editor, and update the Appearance of any Heading block to a different font weight.
3. Save the change, and compare the Editor to the live site.

What you expected to happen

I expected that the font weight would update on the live site, matching the view in the Editor. font-weight

What actually happened

The view in the Editor updated, but the live site kept the same font weight as the theme default.

I made a video example here showing first the live site, then the change in the font weight in the Editor. For this example, I updated both the Heading and the paragraph Appearance from Black to Extra Light. Once the change was saved, you can see on the live site that the paragraph block updated correctly, but the Heading font remains the same.

AdventurerHeading.mp4

This example site is a Simple site, but I was able to replicate this on my Atomic site as well.

Impact

Some (< 50%)

Available workarounds?

No but the platform is still usable

Platform (Simple and/or Atomic)

Simple, Atomic

Logs or notes

No response

[liviopv]

Possibly related #84611 (comment)

[arthur791004]

The theme provides the Rubik font but it only supports font-weight: 900, so that's the reason why the font-weight: 300 (light) cannot be displayed correctly on frontend.

[cat-og]

Thanks, that makes sense! How can we make sure that is correctly displayed in the Editor? If the Rubrik font can only support font-weight: 900, is there a way to update the Preview in the Editor so that no matter which font-weight is selected, it will always display as font-weight: 900

Other fonts also don't have an option for each of the font weights, but usually the unsupported Appearance will just default to the closest equivalent. Using DM Mono as an example, there is no distinction between Thin, Extra Light, and Light, and so the preview for each of those is the same in the Editor

[radtechgh]

7369942-zen

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 7369942-zen
• 7382535-zen
• 7467369-zen
• 7369110-zen

[cat-og]

It's also worth nothing that the users reporting this have each mentioned that this was a recent change. If this was a limit of the Rubik font, why would that have worked in the past?

[arthur791004]

The Jetpack Google Fonts module used to print the font definitions on the frontend page when the fonts were in use. Now it also checks whether the font being used is included in the theme JSON file. If it is, the module won't print that font definition so the font weights not provided by the theme JSON file won't work.

[liviopv]

Now it also checks whether the font being used is included in the theme JSON file. If it is, the module won't print that font definition so the font weights not provided by the theme JSON file won't work.

@arthur791004 So, with the new implementation, theme designers would need to bundle all font variations in the theme JSON file to fix this?

[arthur791004]

YES!

[liviopv]

📌 REPRODUCTION RESULTS

• Tested on Simple – Replicated
• Tested on Atomic – Replicated

📌 FINDINGS/SCREENSHOTS/VIDEO

CleanShot.2023-12-08.at.09.52.43.mp4

📌 ACTIONS

• Triaged

[mreishus]

7382535-zen

[mreishus]

This is a very tricky issue caused at the intersection of a changing font library and API in Guternberg, WordPress.org releases, and the Google Fonts feature provided by Jetpack.

When the Fonts Library feature is finished and shipped, this should no longer be an issue, but we are in interim period where things don't quite work out right.

Possible solutions:

• I don't think it's feasible to change all the various themes to include all the weights we need - although - maybe if there are only a few popular themes being hit the most, we could change those.
• Idea 1: Could we do a hybrid solution where we still look at the intersection of WP_Font_Face_Resolver::get_fonts_from_theme_json(); and $this->fonts_in_use to determine which fonts are in use, but instead of relying on the theme to provide the resources, use the old style wp_register_fonts( $fonts ); across 100-900 to get them from google fonts?
  • I tried this, but couldn't get them to print out. I think the remove_actions() in Jetpack_Google_Font_Face() is also stopping this mechanism from working.
• Idea 2: Could we detect if any block at all has a ['attrs']['style']['typography']['fontWeight'] override, and if so, don't unhook the noisy printers, allowing all of the CSS to be printed? This might strike a balance between allowing customizations while not printing excessive css for un-customized sites.

[jp-imagines]

Came across this issue in 7382535-zd-a8c with the Creatio theme as well. That theme only bundles font weights 400-700 for the Inter font, so other weights aren't being rendered on the live site as they are in the editor.

@mreishus Do we happen to have any estimate for when the Fonts Library feature will be shipped (at least to Simple sites)? This user's particularly upset about this sudden change and that we have no workaround or ETA for a fix.

[mreishus]

There's some info on p7DVsv-jvg-p2. However, in my testing this doesn't fix the issue with the client site I was looking at ( 32da2-pb ). There's another patch floating around ( D131894-code / Automattic/jetpack#34608 ) which doesn't fix it either in my testing.
@arthur791004 , do you know if we have anything that will fix this case? ( 32da2-pb )

[mreishus]

It doesn't look like any of the fixes coming up in the short-term will address this. We will make the editor consistent with the front-end (that is, if we can't display Thin as Thin on the front-end, it will be greyed out in the editor drop-down, and any previously-saved-as-thin text will display as medium in the editor).

That's better than nothing, but it isn't ideal, since we would like to be able to make all of the options available to users. I think what's supposed to happen is the next version of WordPress will provide google fonts options built into the editor. There may be a workaround for .com possible, but I've been trying very hard with not much luck so far.

[liviopv]

• 7467369-zd-a8c - TT4 user looking to use Joost extra-light (100), but the font goes up to only Light (300)

[liviopv]

We will make the editor consistent with the front-end (that is, if we can't display Thin as Thin on the front-end, it will be greyed out in the editor drop-down, and any previously-saved-as-thin text will display as medium in the editor).

@mreishus displaying unavailable font styles as greyed-out would still be confusing to customers, as they might think there's a problem with their site, or that they need to upgrade to unlock those font styles. I'd be clearer if we simply don't offer them as an option at all.

[taipeicoder]

Not much of a follow-up, but the issue was highlighted in this thread: p1706201774599919-slack-CRWCHQGUB

[arthur791004]

It's related to WordPress/gutenberg#58764 (comment), and it should be resolved by WordPress/gutenberg#59119 when the PR gets merged 🙂

[druesome]

Just for posterity, the user in 7369110-zd is also affected. Let's get back to them once the PR is merged. Thanks!

[arthur791004]

The issue has been fixed by Core, WordPress/wordpress-develop#6161, and it's included in WP 6.5 RC1.

I assume we can close this issue after the official release of WP 6.5 🙂