Prevent stale Font Library saves from reactivating theme fonts

[Copilot]

WordCamp sites using the Font Library could get stuck in a loop where deactivating one theme font caused another to become active again, making it impossible to fully deactivate both. This change adds a server-side guard for wp_global_styles saves so stale theme-font payloads do not reintroduce fonts that were just turned off.

Props @copilot

• Normalization on wp_global_styles saves

  • Intercept Font Library saves in wc-fonts.
  • Compare the incoming settings.typography.fontFamilies.theme payload with the currently saved theme-font set.
  • When Gutenberg submits an incomparable stale set (neither a pure add nor pure remove), keep only the shared fonts so prior deactivations persist.

• Scope

  • Applies only to wp_global_styles updates.
  • Leaves normal subset/superset saves unchanged.

• Regression coverage

  • Adds focused tests for:
    • incomparable saves collapsing to the shared intersection
    • subset saves remaining unchanged
    • superset saves remaining unchanged
    • identical saves remaining unchanged
    • multiple shared-font intersections

$incoming_not_saved = array_diff( $incoming_slugs, $saved_slugs );
$saved_not_incoming = array_diff( $saved_slugs, $incoming_slugs );

if ( ! empty( $incoming_not_saved ) && ! empty( $saved_not_incoming ) ) {
	// Stale save: keep only fonts present in both sets.
}

Screenshots

N/A — admin behavior fix in the Font Library save flow.

How to test the changes in this Pull Request:

1. On a WordCamp site using the Font Library, activate at least two theme fonts (for example, the reported Fira Code and Manrope case).
2. Deactivate one font, click Update, return to Appearance → Fonts, then deactivate the other and click Update again.
3. Confirm the previously deactivated font does not become active again, and both fonts can remain deactivated across reloads.

[dd32]

@copilot Is this a bug in Gutenberg font handling? Is this a bug in the wc-fonts plugin? Why is this needed other than fixing the bug.

[Copilot]

@copilot Is this a bug in Gutenberg font handling? Is this a bug in the wc-fonts plugin? Why is this needed other than fixing the bug.

This looks like a stale wp_global_styles payload coming from the Gutenberg Font Library save flow, not wc-fonts intentionally reactivating fonts. The reason it lives here is that wc-fonts is currently the WordCamp.org integration point for theme fonts (inject_fonts_theme_json() is still a temporary shim), so this is the safest place to add a server-side guard against that stale payload.

In other words: the underlying bug appears to be upstream/editor-side, but wc-fonts owns the WordCamp.org-side workaround until the native/core path is fully usable here. Once that upstream behavior is fixed and this shim is no longer needed, this guard should be removable too.