Font faces defined in variations aren't loaded in the browser until the variation switch is saved and the page is refreshed

[mmaattiiaass]

Description
When switching style variations, the font faces defined in those variations are not loaded in the editor but after the page is reloaded.

Step-by-step reproduction instructions
Switch to a theme style variation with custom font faces defined.
Check that the fonts are not loaded in the editor until the page is refreshed (browser reload).

Originally reported in GitHub repo: ​https://github.com/WordPress/gutenberg/issues/59965

Resolve theme relative font faces URIs in theme.json and style variations.
Porting this change from Gutenberg repo: ​https://github.com/WordPress/gutenberg/pull/65019

Trac ticket: [](https://core.trac.wordpress.org/ticket/62231)

Load fonts from style variations only in the editor and admin, not in the public frontend.

This is an alternative and probably simpler alternative to the Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/65019 and it core port PR: ​https://github.com/WordPress/wordpress-develop/pull/7570

Trac ticket: https://core.trac.wordpress.org/ticket/62231

[ironprogrammer]

Thanks for the patch and convenient test theme, @mmaattiiaass! This PR works as advertised in my testing, and I've moved this ticket to the 6.7 milestone for visibility (it's already on the ​6.7 editor board). (Note that the ​first PR did not work for me.)

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7581 (second, "simpler alternative" PR)

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.6.1
• Browser: Safari 17.6
• Server: nginx/1.27.1
• PHP: 8.3.12
• MySQL: 8.0.27
• WordPress: 6.7-beta3-59237-src
• Theme: font-variants (​zip from PR description)

Actual Results

• ✅ Custom fonts in style variations are immediately and accurately reflected in the style thumbnails and editor preview. No page refresh is needed to show the custom fonts.

Supplemental Artifacts

Click an image for a large version.

Left Styles browser	Right Styles browser

Prefer videos? See these ​before patch and ​after patch recordings.

[peterwilsoncc]

In 59260:

Editor: Load all style variation fonts within the editors.

Loads the font family files from style variations defined within a theme for user in the site and post editors. This is to ensure the fonts are shown while editing without the need for a reload after switching styles.

Props ironprogrammer, mmaattiiaass.
Fixes #62231.

Merged r59260 / ​https://github.com/WordPress/wordpress-develop/commit/ba472085a05c837e42ab38f16aa06d90c3759994

Thanks Matias.

[ugyensupport]

Font faces defined in variations aren't loaded in the browser until the variation switch is saved and the page is refreshed

Description

When switching style variations, the font faces defined in those variations are not loaded in the editor but after the page is reloaded.

Steps

Switch to a theme style variation with custom font faces defined.
Check that the fonts are not loaded in the editor until the page is refreshed (browser reload).

Patch tested:
​https://github.com/WordPress/wordpress-develop/pull/7581/files
​https://github.com/WordPress/wordpress-develop/pull/7570/files

Environment

• WordPress: 6.7-beta3
• PHP: 8.3.10
• Server: nginx/1.21.4
• Database: mysqli (Server: 5.7.44-log / Client: mysqlnd 8.3.10)
• Browser: Chrome 129.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Akismet Anti-spam: Spam Protection 5.3.3
  • Gutenberg 19.4.0
  • Test Reports 1.1.0
  • WordPress Beta Tester 3.6.0

Actual Results

1. ✅ Issue resolved with patch.

As mentioned by @ironprogrammer
Custom fonts in style variations are immediately and accurately reflected in the style
thumbnails and editor preview. No page refresh is needed to show the custom fonts.

Supplemental Artifacts

Before: ​https://vioo.cc/v/1x0

After : ​https://vioo.cc/v/Yh7

Should we close this since ​https://github.com/WordPress/gutenberg/pull/65019 was closed?

Should we close this since ​https://github.com/WordPress/gutenberg/pull/65019 was closed?

Yes, let's close this. An alternative approach has been already merged.