In the latest version of Bricks (1.7.3), adding custom fonts does not work correctly, they are duplicated many times, here is a video:
Hi Jacek,
Thanks so much for your report!
Unfortunately, I cannot reproduce the issue.
Can you please deactivate all plugins (incl. Litespeed caching) and test it again?
I assume that you also cache the backend for logged-in users?
Best regards,
timmse
I will check it tomorrow. I was reminded of one other weird thing I did. At one point, I wanted to see if it would work on a font from google (because I had this font from google plugged in before I uploaded it) and I changed the name to “Titllium Webu”:
Then update and after some time back to “Titllium Web” and update again. Perhaps this broke something.
After disabling the plug-ins, it’s even worse, everything has fallen apart.
Oh oh, that doesn’t look good. But I assume that it is a local problem for you, otherwise we would certainly have received more reports than just yours.
Would you be so kind as to send temporary login credentials and a link to this thread to help@bricksbuilder.io using the email address you used during the purchase?
I sent it and am waiting for the results
Hi Jacek,
I have no idea how you managed that, but please don’t do it again 
It seems that the font files were responsible or your renaming actions because at least one of them was corrupt/broken and ultimately broke the WordPress dashboard. I deleted the files, downloaded them again from here, and recreated the family: Problem solved.
Best regards,
timmse
Sorry, but… the problem unfortunately still exists 
Log in again and try to add some font thicknesses. They multiply and multiply.
Ok, at first glance/attempt it worked for me, but yes, the problem is back. Let’s see if our developers have an idea 
So I am waiting for the developer to intervene, I hope to contribute with my discovery to improve Bricks Builder 
Hi Jacek,
The problem seems to be related to your server (Litespeed), possibly only to a single setting. Unfortunately, we can’t make any more detailed statements about this.
Would you please contact your hoster? They might have an idea, apart from the fact that this is their specialty anyway.
But imho this started happening after the Bricks update to 1.7.3, previously I didn’t notice it.
The second… What should I ask the provider? I have no idea how to ask the question, especially since after disabling litespeed the problem does not disappear.
We already had a similar report two months ago (well before 1.7.3) and also asked the user to contact his hoster. Unfortunately, we never received an answer. I have tested it in your installation with both 1.7.2 and 1.7, and the problem persists with them.
The interesting thing is that as soon as the LiteSpeed Cache plugin is activated, the interface is at least no longer completely shot up. The only problem that remains is the duplicated fonts.
Show and explain to him what the problem is and give him access data so that he can also look at it in detail. As I said, it is probably due to a specific server setting.
The hosting provider is unfortunately still silent.
I did some more reasearch.
First, I defined one custom font:
and:
Then I poked around a bit in the database, checked how many custom fonts are defined in the posts table (by SQL):
SELECT * FROM `qvaposts`
where post_type='bricks_fonts'
ORDER BY `ID` ASC
results:
As expected, there is one custom font named Titllium.
Then I checked how many font definitions there are in the post_meta table:
SELECT * FROM `qvapostmeta`
where meta_key='bricks_font_faces'
ORDER BY `post_id` DESC
And this is where things start to go wrong.
Why are there 3 definitions of fonts metadata? Only one is associated with the actual defined font (see red arrow, ID = 1898), the other two “hang in the air”.
Perhaps it is these other two definitions that are responsible for the bizarre behavior of the custom fonts editor?
Before I delete these other two metadefinitions I present you with my observations for your consideration and reflection, because for some reason these records have been left in the database, even though Bricks should delete them along with the custom font being deleted, right?
The test account is still active, if anyone would like to take a look I invite you to do so.
Hey Jacek,
have you had any luck with contacting your hoster?
Three of us have independently looked into your setup and also into your database, but none of us has a concrete explanation for the things that are going on.
Your database (the entry selected in blue is your custom font, the others are already deleted entries - e.g. post_id 1900 is still in the trash, and the other two no longer exist):
Test on our dev server
I had three custom fonts on our test server until just now, I deleted one of them and emptied the recycle bin as well. All I can still see are the two fonts that are still installed (as they should be). The deleted font is no longer part of the database.
Please talk to your hoster and let us know as soon as you know more.
Best regards,
timmse
My hoster wrote now:
“Did the developers perhaps indicate what kind of issue regarding Litespeed? Guessing it will be hard to come to a solution for this issue, have you tried using debug mode in wordpress? Does it log any errors related to the described anomaly?”
I don’t know what to write back to him…?
If we had a starting point or a clue, we would let you know. The fact is that you and another user (two in total) had or have this problem, and you both use a Litespeed server. Unfortunately, we do not have any more information about this.
What you see is a notice, not an error. There are huge differences between Notices, Warnings, and Errors. I also get this notice on my server, but I have neither duplicated fonts in the interface nor old, already deleted entries in the database.
Is it possible that your database is getting cached as well (redis or something similar)?
No, db is not cached.
Yes, you are right, it is a notice. However, it is strongly puzzling that it shows just where there is a problem with the duplicate font (the second 700 bold), coincidence?
In the help for ob_get_clean() I read:
“The output buffer must be started by ob_start() with PHP_OUTPUT_HANDLER_CLEANABLE and PHP_OUTPUT_HANDLER_REMOVABLE flags. Otherwise ob_get_clean() will not work.”
But I don’t see anywhere calling ob_start()
I discovered (by reading on SO about this error) that the cause could be gzip, I disabled it:
and the problem disappeared:
But I don’t want to have compression disabled. I hope this will suggest something to someone smarter than me.
maybe this will be helpful:
and next useful link about ob_ and gzip: