Deleted Webfont Font Families remain available in Global Styles following theme switches

[peterwilsoncc]

Description

Deleted webfonts remain available and is use by a theme following a theme switch:

• The fonts are defined as the default on the front end of the site
• The fonts appear in the typography sidebar for global styles
• The fonts appear as available in block settings

This results in broken styles and the display of affected elements falling back to the default system font.

In such circumstances, I suggest the following:

• Ensure font-family post type remains before displaying in site/post editor
• To allow for deleted font faces, fall back to the theme default in the font family CSS attributes, eg --wp--preset--font-family--just-another-hand: "Web Font Name", "Theme Font Default", system-default;

Step-by-step reproduction instructions

Convenience steps

1. Configure a fresh environment (either via a reinstall or by deleting all the posts). This isn't necessary but makes it easier.
2. Activate 2024 theme
3. Open the site editor
4. In the Font Library Modal install the Just Another Hand font via Google.
5. In the global typography settings, set all items to use the Just Another Hand font (this will make the bug obvious)
6. Save the site, this will include a prompt to save the global styles
7. Visit the front end of the site, the font will load.
8. Via WP CLI run the command wp post delete $(wp post list --post_type='wp_font_face,wp_font_family' --format=ids) --force
9. Visit and reload the site's front end with the cache disabled (either via network tools or a shift+refresh in Chrome/Firefox)
10. Observe the font falls back to the default system font, cursive

Long form steps

Replace the WP CLI command with:

1. Exit the site editor
2. Switch the theme to 2023
3. Open the site editor
4. In the Font Library modal delete the Just Another Hand font
5. Exit the site editor (as the global styles are unchanged, you probably won't get a save prompt)
6. Switch the theme back to 2024
7. Open the site editor
8. Go to the global typography settings
9. Observe the deleted font is still listed
10. Continue steps above that follow the WP CLI step

Following the reproduction steps you may be able to reinstall the Google Font and everything will look nice again. In production this is unlikely to work as Google frequently renames the font files which will be reflected as the wordpress.org API endpoint is updated.

Screenshots, screen recording, code snippet

Site prior to WPCLI command/long form steps

Site following WPCLI command/long form steps

Typography sidebar following WPCLI command/long form steps

Environment info

• Gutenberg trunk
• WordPress 6.4.x

AND

• WordPress trunk

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

[getdave]

This Issue was triaged by Editor release leads and contributors in WP Slack as part of the final WordPress 6.5 process.

See https://wordpress.slack.com/archives/C02QB2JS7/p1711372016096219 (requires registration).

The criteria used was:

• Was this bug identified during the RC cycle for WP 6.5?
• Is this bug directly related to one of the blessed features in this release?
• Would this bug cause existing website’s to break/fail upon upgrade to WP 6.5?
• What is the approximate scope of the impact? Scale: (Minimal) 1 - 5 (Severe).
• Is the fix introducing any new features or changes? n/a

Conclusion: we propose that any fix for this Issue is not included in WP 6.5 and is punted to 6.5.1.

Contributors recognised that the UX is far from ideal, but without a PR and with the other work required for 6.5 there was no clear route for a shipping a fix in time for the major release. However we should strive to have a robust solution in place for 6.5.1.

[peterwilsoncc]

I did some quick investigation of the font-family post types.

While testing matiasbenedetto/modern-fonts-stacks-for-font-library and in discussion with @creativecoder via Slack, I confirmed that System font font-families do not have any font-face post types created as they're not required. This is because @font-face rules aren't required.

So when the final font-face child of a font-family post type is removed, it's safe to assume that the font-family is a webfont and can be dropped as well. Some additional logic may be helpful and can be the subject of further discussion. (Circular logic warning: deleting a font-family deletes the font-faces so it will need to be checked for infinite loops.)

What I haven't been able to figure out is how to handle the global and block styles that make use of a since removed font-family. Clearly updating all the post objects when a font-family is removed is out of the question so it probably needs some logic on render to confirm the font family is still defined. Once a post object is opened in the site/block editor it could be updated in a fashion similar to deprecation migrations.

All the discussion for this can wait, I'm just logging this while I remember some of the testing I did and the gotchas I discovered while doing so.

[afercia]

See related issue: #58375
Font Library: Fonts still listed as installed after they are manually deleted via FTP or by other means

[aaronjorbin]

I think what would be beneficial here is if there is notice of some sort, likely in the site editor as a whole but possibly just in the global styles that the expected font is not installed and ideally a one click fix.

It should hopefully be clear to a person who expects one font that the site isn't using that font, but I don't think that is 100% certain so I think a notice of some sort is necessary.

While it is a bug, I also think it might be rare to encounter this until the font library have been in place for longer, so I wonder if this might be a better fit for 6.6 than 6.5.x

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.