Updating the Font Library resets the colors and layout settings of the front-end and back-end

[YanCol]

Description

When updating the Font Library, it resets the color palette and layout settings (width of the main content area) to their default values and breaks the design of the live website.

For example, if a user tries a font, does not like it, and doesn’t save the editor, the design of the site will be reset without their knowledge. Additionally, every user that updates the Font Library will inadvertently reset the style (colors and layout widths) of their live websites until they save the editor.

Step-by-step reproduction instructions

1. Activate the Twenty Twenty-Four theme.
2. Open the Site Editor.
3. Select the Onyx style variation and save the changes.
4. Visit the live website to confirm that your website appears dark.
5. Open the Font Library and make any changes (e.g., remove Cardo Normal Italic).
6. Update the Font Library.
7. DO NOT SAVE the editor.
8. Check your live website, and observe that your website is not dark anymore and has been reverted to the default colors.
9. Reload the editor, and observe that your website in the editor is not dark anymore and has been reverted to the default colors.

Screenshots, screen recording, code snippet

font-library-issue.mp4

Environment info

WordPress 6.5 RC4 or Gutenberg 18.0.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

[desrosj]

Thanks for this report, @YanCol!

I've tested and I am able to reproduce. While this is frustrating, I don't think it warrants a delay in 6.5, can be addressed ASAP in the Gutenberg plugin itself, and after the fact in 6.5.1. Some additional findings:

• It only resets predefined styles applied from the theme. Custom selected colors do not seem to be reset.
• There is a revision within global styles that has all of the previously configured options saved. Reverting successfully fixes the problem. Because of this, there does not seem to be any actual data loss.

[matiasbenedetto]

Hi, thanks for testing.

This is not a typography or Font Library-specific problem but something related to global styles + theme style variations. The same issue can be reproduced with colors:

2024-04-02.12-14-02.mp4

[estelaris]

I can replicate the issue but I don't see it as a problem. Users are supposed to save changes in the editor in order to keep them.

Revisions as proposed by @desrosj should be sufficient to correct this.

[YanCol]

@matiasbenedetto

What you showcase in your video is indeed not an issue, as you don’t save the editor; therefore, the front-end should not change.

What I’ve recorded is different and not related to variation. (I’ve taken a shortcut by using a variation in my example to make it easier to reproduce). You can reproduce the same issue by simply changing the color palette and layout width, then saving the changes. You’ll see that the changes are applied on the front-end. Then, make a change with the font library and update it. Without saving the editor, you’ll notice that the color palette and layout widths that you have previously saved have been reset.

The issue occurs the moment the user clicks on the ‘Update’ button in the Font Library modal.

[YanCol]

I can replicate the issue but I don't see it as a problem. Users are supposed to save changes in the editor in order to keep them.

Revisions as proposed by @desrosj should be sufficient to correct this.

@estelaris This bug alters the appearance of live websites without the user's knowledge. If the user doesn't save the editor, the live website should not change.

[creativecoder]

Investigating this now, I see that clicking "Update" or "Install" in the Font Library modal saves user Global Styles with only settings.typography.fontFamilies values submitted the wp/v2/global-styles/<id> endpoint.

This overwrites any other custom styles until the "Save" button is used to save all the custom Global Styles settings/styles active in the editor and restore them.

So the cause here seems to be because

1. Updating the global-styles endpoint overwrites all user styles and settings, even if those keys aren't provided in the update
2. The Font Library updates the global-styles endpoint with only fontFamilies settings, outside the normal save flow

---

The only immediate solution I can think of is to update how activating fonts works so that we don't immediately persist using the wp/v2/global-styles endpoint within the modal.

Instead, settings changes in the modal would stage the changes in the editor preview, which could then be persisted using the editor "Save" button, like other styles/settings.

But this will need some design consideration. Just removing the primary button from the Font Library modal would be confusing, as it wouldn't be immediately clear how the selections made in the font modal are persisted.

[matiasbenedetto]

I investigated a little bit further after my previous comment, and this seems to be related to how we are saving the changes to the active global styles post.

I submitted a potential fix for this: #60390

I'll add more testing details there shortly.

[matiasbenedetto]

#60438 is an alternative approach to the previous PR #60390