Summary
Cause
In the save handler (dist/main-*.js), the Google Fonts lookup runs unconditionally, including for category === "custom-font", and its result replaces the file that was just imported:
const b = await Grt(g.family, c), // fetch https://fonts.googleapis.com/css2?family=<family>:<variants>&display=swap
w = { ...g, files: b }, // overwrites files{} from the custom upload
...
await d(w)
Any failure there is caught and reported as "Could not download the selected Google Font", which is misleading in the custom-font flow.
The downstream uploader is already custom-font aware — d() skips the remote fetch via if (g.category !== "custom-font") — and the REST endpoint AllPoints.php::handle_font_upload accepts woff, woff2, ttf, otf, eot and writes the decoded file correctly. It's simply never reached: during a failed attempt, no request to upload-fonts appears in the server access log, so the whole thing fails client-side before any save.
Two smaller points about that lookup:
css2 rejects the family=<name>:400 variant syntax with HTTP 400 — including for Google families such as Roboto. Only :wght@400 returns 200.
- CORS is not involved:
fonts.gstatic.com returns Access-Control-Allow-Origin: *, and the server can reach both fonts.googleapis.com and fonts.gstatic.com (verified 200).
Suggested fix: skip Grt() when category === "custom-font" and pass the imported files straight through to d(), as the uploader already expects. A more accurate error message for genuine Google failures would help too.
Workaround: upload the .woff2 manually into uploads/core-framework/fonts/ and declare the @font-face by hand.
Affected surface
Web app
Steps to reproduce
- Fonts → Import Custom Font.
- Upload a font file whose family is not on Google Fonts (mine is Century Gothic, a licensed Monotype face). The preview loads correctly in the panel.
- Click Save.
Expected behavior
The uploaded file is saved to uploads/core-framework/fonts/ and an @font-face is generated for it.
Actual behavior
An error toast, "Could not download the selected Google Font", and nothing is saved. It happens with both WOFF and WOFF2.
Core Framework version or commit
2.0.2
Environment
WordPress 7.1.2 · PHP 8.4.25 · Chrome 152
Logs or screenshots
No response
Summary
Cause
In the save handler (
dist/main-*.js), the Google Fonts lookup runs unconditionally, including forcategory === "custom-font", and its result replaces the file that was just imported:Any failure there is caught and reported as "Could not download the selected Google Font", which is misleading in the custom-font flow.
The downstream uploader is already custom-font aware —
d()skips the remote fetch viaif (g.category !== "custom-font")— and the REST endpointAllPoints.php::handle_font_uploadacceptswoff, woff2, ttf, otf, eotand writes the decoded file correctly. It's simply never reached: during a failed attempt, no request toupload-fontsappears in the server access log, so the whole thing fails client-side before any save.Two smaller points about that lookup:
css2rejects thefamily=<name>:400variant syntax with HTTP 400 — including for Google families such as Roboto. Only:wght@400returns 200.fonts.gstatic.comreturnsAccess-Control-Allow-Origin: *, and the server can reach bothfonts.googleapis.comandfonts.gstatic.com(verified 200).Suggested fix: skip
Grt()whencategory === "custom-font"and pass the importedfilesstraight through tod(), as the uploader already expects. A more accurate error message for genuine Google failures would help too.Workaround: upload the
.woff2manually intouploads/core-framework/fonts/and declare the@font-faceby hand.Affected surface
Web app
Steps to reproduce
Expected behavior
The uploaded file is saved to uploads/core-framework/fonts/ and an @font-face is generated for it.
Actual behavior
An error toast, "Could not download the selected Google Font", and nothing is saved. It happens with both WOFF and WOFF2.
Core Framework version or commit
2.0.2
Environment
WordPress 7.1.2 · PHP 8.4.25 · Chrome 152
Logs or screenshots
No response