Browser: Chrome 110
OS: Windows 11
URL: Link to a page that illustrates this issue
Video: Sign in to your account
[Please describe this bug in as much detail as possible so we can replicate & debug this bug]
I email firstname.lastname@example.org but did not get a response.
See the attached video. Looking further after recording this. If I have any fonts registered in Bricks->Custom fonts the number of queries significantly increases. The more fonts, the more queries, even if the fonts aren’t being used anywhere.
I had 15 font families registered and was getting over 800 queries. Moving the 13 unused fonts to trash the queries dropped to 200.
Very strange! Could you try going to the performance tab in Bricks settings and disable ‘Cache query loops’?
Cache query loops was not enabled at all.
I got a response from the support email. I’ll let them take a look.
I just replied to your email.
We can replicate this issue and will enhance the way Bricks retrieve the custom fonts before generating the CSS style.
You can still use the Custom fonts on the production site as usual although the number of queries seems high, the load time added is below 0.1s
Appreciate your time in reporting this issue to us. Thank you.
Yes, I forgot to put a note on the forum comments. My performance issue was that PHP Opcache disabled. When I was troubleshooting and saw 800 queries, it led me down the wrong path
I love Bricks, it is awesome.
We’ve fixed the issue in Bricks 1.7.2, now available as a one-click update in your WordPress Dashboard.
Please let us know if you are still experiencing issues.
Hey guys, it looks like it 1,7,2 update has caused an issue.
All of my custom fonts are being output as inline CSS in the Browser. I even tried trashing them, and then completely deleted them. They still get output as Inline CSS.
I have no caching enabled and tried incognito.
Checking the DB. The options table for ‘bricks_font_face_rules’ still has all the deleted fonts
See this video.
I haven’t updated yet, but Bricks has an issue with fonts, or at least that’s what happened to me when I migrated a website (all-in-one wp migration).
The solution I found is to go to a template, then to Settings > Theme Styles > Typography, delete the font and save it. After that, add the font again and it should work. At least, that’s what worked for me with migrations, maybe it could work for you too.
I’m still not sure if it worked by chance or if there’s a bug in the system.
I had a similar issue after cloning my bricks blueprint. Font URLs were still pointing to the old domain and Cors wasn’t enabled on my server so it couldn’t retrieve them. Re-generating external css files fixed it though. Maybe give that a try next time u migrate cause that’s a lot easier than resaving them in the typo settings.
First of all, the fact that the font-face rules are added inline is not a bug: Changelog – Bricks
Currently, you can force the rules to regenerate the font-face rules and get rid of the unused ones by adding a new custom font. We will try to improve this in the future so that the rules are also regenerated when a font is deleted.
However, the font-face rules have no influence on your page performance because the fonts are not loaded unless they are requested somewhere. This means that if you do not use the font, the font file will not be loaded.
The inline font-face rules only ensure that the path to the file is available everywhere. This allows you, for example, to use the font in custom CSS, which was previously only possible in a cumbersome way (by manually adding the font-face rule).
Ah OK, that makes sense.
I assumed a bug because even when you trash or even completely delete a custom font, Bricks still outputs the @font-face declarations for them.
With Bricks 1.7.3, now available as a one-click update in your WordPress Dashboard, the font-face rules will update as soon as you enter the “custom fonts” screen, so there shouldn’t be no more issues.
Thanks mate. Looks good now.