NO BUG: Karla Custom font not loading when registered under its correct name — falls back to serif

Browser: Chrome 110
OS: macOS
URL: https://sunshinecoastroofingandguttering.com.au/

Hi all, hoping someone has run into this before.

I’m self-hosting Rubik and Karla via Bricks → Settings → Custom Fonts, with Google Fonts disabled under Performance settings. Rubik is working perfectly. Karla is not loading at all — the browser falls back to a serif font (Times New Roman style).

What I’ve tried:

  • Uploaded the correct Karla woff2 file via the media library — file is accessible via direct URL
  • Registered it under Custom Fonts with the family name “Karla” — no result
  • Renamed the custom font entry to “KarlaLocal” to rule out a naming conflict with Google Fonts — still falls back to serif
  • Uploaded a completely different font file (Rubik 700) under the Karla entry as a test — a different font rendered, confirming Bricks is reading the file reference but something is wrong with the Karla file or how it’s being served
  • Leaving the font name field empty or entering a single character (e.g. a period) causes the correct Karla to show in the variation preview — suggesting the file itself is fine, but something about the name triggers a conflict
  • Renaming the entry to “Rubik” causes the preview to immediately switch to Rubik — which suggests Bricks may be doing an internal lookup against known Google Font names and overriding the custom registration

Environment:

  • Bricks Builder (latest version)
  • Hosted on SiteGround
  • Google Fonts disabled in Bricks Performance settings
  • Font applied via Theme Styles → Typography

Has anyone seen a conflict between Bricks’ internal Google Fonts handling and custom font registrations sharing the same name? And is there a known workaround beyond aliasing the font family name?

Thanks in advance.

(FYI I have reverted to using Google Fonts for the time being)

Hi Hamish,
Thanks so much for your report!

Unfortunately, I cannot reproduce the problem. Would you please provide a screencast (jam.dev) showing the whole process?

What I have noticed, however, are mixed content warnings that appear when certain resources are served via HTTP, even though the page actually uses HTTPS. This can be particularly problematic with custom fonts, leading to the issue. So please check WordPress » Settings » General to see if both URLs are set to https, save and re-save your permalinks. Then, try again.

Best regards,
timmse

Hey Timmse,

Thank you for the suggestion of resolving conflicts between HTTP and HTTPS. After configuring settings and re-uploading as custom fonts, I can confirm this is now resolved. Appreciate your support on the matter.

1 Like