[Bug]: Local fonts with a space in the family name 404 on the front end

[DavidBabinec]

Summary

In Core Framework 2.0.1, a local font whose family name contains a space (for example Source Sans 3) never applies on the front end. The generated CSS references /wp-content/uploads/core-framework/fonts/Source Sans 3-400.woff2, but the file written to disk is Source-Sans-3-400.woff2. The referenced URL returns 404, and because a font face with a 404 src is discarded silently, nothing shows up in the console.

Affected surface

WordPress plugin (front end and builders)

Steps to reproduce

1. WordPress 7.1, PHP 8.4, Bricks 2.4 beta 3, Core Framework 2.0.1.
2. Import Source Sans 3 via Import Google Font, enable 400, 600, 700.
3. Load a page that uses the font on the front end.

Expected behavior

The font applies on the front end.

Actual behavior

The font never loads. The referenced woff2 URL returns 404; the real file on disk uses dashes.

Root cause

The upload endpoint in packages/wp/wp/App/Rest/AllPoints.php stores the file through sanitize_file_name(), which turns spaces into dashes. The @font-face src is built separately from the raw family name and keeps the spaces, so the two never match. Re-saving does not help because the path is derived from the family name each time.

Core Framework version or commit

2.0.1