Font upload shows failure message but font is added to library

[369work]

Description:
When uploading a font from Appearance > Fonts, WordPress shows an upload failure error.
However, the uploaded font is actually added to the Font Library list.

Steps to reproduce:

1. Go to Appearance > Fonts.
2. Click upload/add new font.
3. Upload ShipporiMincho-Regular.woff2.
4. Upload MPLUSRounded1c-Regular.woff2.
5. Upload NotoSerifJP-VariableFont_wght.woff2.

Actual result:

• Upload failed error is shown in the UI on every upload.
• Browser console shows: Cannot read properties of undefined (reading 'styles').
• All uploaded fonts still appear in the Font Library list.

Uploaded files:

• ShipporiMincho-Regular.woff2
• MPLUSRounded1c-Regular.woff2
• NotoSerifJP-VariableFont_wght.woff2

Expected result:

• If the font is successfully stored and listed, no failure error should be shown.
• The UI result and backend result should be consistent.

Environment:

• WordPress version: 7.0 RC3
• Theme: TT5
• Active plugins: all plugins disabled
• Browser/OS: Edge

[amykamala]

Thanks for reporting this! The alert is citing that properties of styles can not be read. The font is a Japanese font, .woff2 file, while other .woff2 files were tested during the release party and did not get the same alert. Here is the slack thread for reference: ​https://wordpress.slack.com/archives/C02RQBWTW/p1778261887176439

[wildworks]

I tried using ​Noto Serif Japanese, but I couldn't reproduce the issue. Information like the following would be helpful in identifying the problem:

• Where did you download the font from?
• Does this issue occur with fonts other than Japanese fonts?
• Does this issue occur with WordPress versions 6.9 and below?
• Does the problem occur across all browsers?
• Does the same issue occur in the Site Editor and the Global Styles sidebar?

[369work]

Where did you download that font from?

Google

---

It also occurred with newsreader-v26-latin.
[Imgur](​https://imgur.com/jgEINhe)
[Imgur](​https://imgur.com/Vk5L18h)

---

1. It occurs in "Appearance" > "Fonts".

2. "Appearance" > "Editor" > "Style" > "Typography" > "Fonts" works fine.

(The banner says "Fonts were installed successfully.")
(I was surprised because I hadn't tried it.)
[Imgur](​https://imgur.com/IBnN2Tk)

---

Does this problem occur in all browsers?

It occurs in Edge.
Chrome works fine.

---

I deleted the font and uploaded the same font in Edge, and it worked fine.
This might be due to the success in Edge (step 2).
I can no longer reproduce the error no matter how many times I delete it.

---

Does this also occur in versions prior to 6.9?

1. I can't test it because "Appearance" > "Fonts" is not available.
2. "Appearance" > "Editor" > "Style" > "Typography" > "Fonts"

It worked correctly in Edge & Chrome.
(The banner says "Fonts were installed successfully.")

[wildworks]

Thanks for the information.

It also occurred with newsreader-v26-latin.

This indicates that the problem is not specific to Japanese fonts.

I can no longer reproduce the error no matter how many times I delete it.

It would be great if there were reliable steps to reproduce the issue. If not, we might be able to close this ticket.

[369work]

Thank you for your assistance.

I can reproduce this issue multiple times, so I will explain the steps.

1. Install WordPress Studio 7.0RC3.

2. Select Upload from Appearance > Fonts.

3. Upload the font.

4. Cannot read properties of undefined (reading styles)

Expected behavior:
Success banner

Windows 11

Edge

However, uploading via Appearance > Editor > Style > Typography > Fonts is successful.

After this, uploading via Appearance > Fonts is successful, and the error no longer occurs.

​https://youtu.be/CVrGBME3rxw

[sanayasir]

Tested this issue on WordPress 7.0 RC3 with TT5 theme and all plugins disabled.

Steps tested:

• Navigated to Appearance > Fonts
• Uploaded the provided font files:

• ShipporiMincho-Regular.woff2
• MPLUSRounded1c-Regular.woff2
• NotoSerifJP-VariableFont_wght.woff2

Result:

• Fonts uploaded successfully
• Uploaded fonts appeared correctly in the Font Library
• No upload failure message was displayed
• Browser console did not show the reported Cannot read properties of undefined (reading 'styles') error during testing

Additionally:

• Tested with multiple additional .woff2 font files
• Additional fonts were also uploaded and applied successfully
• No installation or UI errors appeared during repeated testing

The behavior is working as expected according to the ticket requirements.

Screenshots attached for reference.

[369work]

I want to clarify that this is not an environment-specific issue.

The browser console clearly shows:
Cannot read properties of undefined (reading 'styles')
This is a JavaScript error — meaning the code itself is crashing, not the environment misbehaving.

The key condition to reproduce is "first upload ever, via Appearance > Fonts, before any upload via the Editor".

Once a font has been uploaded via Appearance > Editor > Style > Typography > Fonts, the error disappears — even in Edge.

This strongly suggests that the two upload paths initialize state differently.
The Editor path hydrates some font family data into state first.
The Appearance > Fonts path does not — and when it tries to read .styles from that uninitialized data, it throws.

Testers who cannot reproduce this may already have font upload history in their environment, which means the state is already initialized before testing.

Additionally, Edge and Chrome are both Chromium-based, so the difference between them is unlikely to be a compatibility issue.

The observed difference may point to a timing issue in async/Promise execution order — but this is a hypothesis based on behavior, not a confirmed root cause.

What is clear is that the code reading .styles may not be guarding against an uninitialized state when Appearance > Fonts is used as the first upload entry point.

Could someone check whether .styles is safely handled in that specific code path?
This is a reproducible code-path bug, not a environment issue.

[wildworks]

Reproduction Report

This report validates that the issue can be reproduced.

Environment

• OS: Windows 11 Home
• Local environment: Studio 1.9.0 (Windows on Intel/AMD)
• Web Server: Server Name PHP.wasm
• PHP: 8.4.20 (Supports 64bit values)
• WordPress: 7.0 RC-3
• Browser: Edge 148.0.3967.54 (Official build) (64-bit)
• Theme: Twenty Twenty-Five
• Active Plugins: Beta Tester

Actual Results

❌ No errors occurred.

Test procedure

1. Create a new site
2. Update to 7.0 RC-3 via the Beta Tester plugin
3. Download the ​Noto Serif Japanese font.
4. Access Appearance > Font
5. Oopen the Upload tab
6. Unzip the downloaded zip file and upload hoge from within it.
7. No errors occurred.

[369work]

Thank you for your cooperation with the test. However, it's possible that the reproduction conditions I mentioned in my previous comment haven't been met.

Could you please confirm that you have never uploaded fonts via Appearance > Editor > Style > Typography > Fonts before testing?

This error seems to occur only during the initial upload attempt via Appearance > Fonts, i.e., when the font library hasn't been initialized via the editor. This matches a race condition, and the error disappears once initialization is complete in either way.

---

OS: Windows 11 Pro
Local Environment: Studio 1.8.0 (Intel/AMD Windows)
PHP: 8.4.20 (64-bit compatible)
WordPress: 7.0 RC-3
Browser: Edge 148.0.3967.54
Theme: TT5
Active Plugins: Beta Tester

---

Note that on our end, the same UI error occurs even when installing a fresh 7.0RC3. However, this error disappears once the upload via Style is successful.

The observed difference may point to a race condition in async/Promise execution order — but this is a hypothesis based on behavior, not a confirmed root cause.

P.S.
Just to confirm, you are using a Japanese language environment, right?
No one else experienced any problems during the release party, except for me.

[wildworks]

Could you please confirm that you have never uploaded fonts via Appearance > Editor > Style > Typography > Fonts before testing?

I have already confirmed it.

[369work]

Update: We tested on Local by Flywheel 10.0.0 with the same WordPress 7.0 RC-3 (updated via Beta Tester plugin), and the font upload was successful without any errors.
This suggests the issue may be specific to WordPress Studio, rather than WordPress core itself.

---

Environment Result
WordPress Studio 1.8.0 + 7.0 RC-3 ❌ UI error / race condition
Local by Flywheel 10.0.0 + 7.0 RC-3 ✅ Success

---

It may be worth investigating whether Studio handles the font library state initialization differently from other local environments.

Additional finding during testing on Local by Flywheel:
In Appearance > Fonts, the tab labels and their content are not translated.
This appears to be a separate issue discovered during the same testing process — please let us know if this should be filed as a separate ticket.

[Imgur](​https://imgur.com/u758uQV)
[Imgur](​https://imgur.com/5X2SgeH)

[369work]

This issue did not occur in 7.0RC4, so is it okay to wait and see until the 7.0 release?

[wildworks]

We are unable to identify which WordPress version this issue occurs in or the specific steps to reproduce it. Therefore, it is difficult to investigate this issue further. Let's close this for now.

[mymothersdaughter]

I was testing about an hour ago on a fresh WordPress install running the current 7.0 alpha/nightly build.

While testing custom font uploads in the new Fonts area, a custom font successfully uploaded and became usable inside the site, but WordPress still displayed the following error message: "A font face matching those settings already exists."

When I clicked the Library tab, the font was already there and available for use.

I tested this two additional times with the same result. The upload appears to succeed, but the UI still displays the error message afterward.

Is it possible the system is performing a secondary duplicate check after the font has already been successfully registered?

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[wildworks]

@mymothersdaughter, Does the problem occur with all fonts, or only with specific ones?

"A font face matching those settings already exists."

This message is different from the error message originally reported in this Issue, so your symptoms might indicate a different problem.

[mymothersdaughter]

Replying to wildworks:

@mymothersdaughter, Does the problem occur with all fonts, or only with specific ones?

"A font face matching those settings already exists."

This message is different from the error message originally reported in this Issue, so your symptoms might indicate a different problem.

It happens to any third party font (woff, woff2). Receive the error but then go to Library and the font is listed there.

[amykamala]

Edit: nevermind! The comment is totally unrelated, just mentions encoding

Hello hello - I don't have details on this but wanted to relay that a tester reported an upload/encoding error during the 7.0 release party ​https://wordpress.slack.com/archives/C02RQBWTW/p1779299327778579