@aslotta If you do anything that would potentially change the state of the page in your step #8 and then save. It will delete changes you made to the page. This is the same behavior if you have 2 tabs open. If you work on the page in one tab and then open the page in the builder in another tab and edit it. If you save again in first tab, it will not revert your changes, but if you do anything in the first tab to potential change the state (toggle a setting on and off) and then save, it will delete any changes you made in the second tab. This is good behavior unless you forget and start editing again in the first tab and save.
@aslotta Also, if you turn of autosave and make changes to a page in one tab, then change it in a second tab, save in second tab and close the tab. Later if you view the first tab and forget what you did and hit the save button, it will wipe out all the changes you made in the first tab.
Hey @macksix & @aslotta ,
Thanks for providing the steps, but isn’t this a different issue? This report is about losing all classes, not losing a section or elements on the canvas when going back and forth
Of course, I will go through the steps, but I can’t expect all my classes to be deleted, can I?
@macksix You have already mentioned the same steps here, where they are more appropriate than in this thread, I think.
@timmse This is about losing all custom classes on a page that I am describing. I am not sure I understand what losing all classes mean. Losing classes auto assigned by Bricks?
“Of course, I will go through the steps, but I can’t expect all my classes to be deleted, can I?”
All classes no, but you can lose all custom classes on a page for sure if you leave a tab open with the page in state that has no custom classes and then in second tab you add all of your custom classes, save, close tab and then later hit the save button the first tab. It will wipe them all out.
Same if you use back button to go to editor and load a page with no classes, add any setting or toggle a button on and off, then save. All your custom classes for that page disappears.
It could be out of place for the trouble described, but I thought is might give a hint for all classes disappearing. So far I can’t figure out a way to make all classes disappear.
All good, maybe I’m mixing other reports about “losing classes”… there are some of them where classes were removed from an element (as you described), and others where all classes are completely deleted from the class list.
At least with your steps, we have a point to start with
So, when I follow your steps (@macksix@aslotta ), I lose the elements - not the classes on the elements. This is the problem that was described here and that I can reproduce thanks to your steps.:
It is quite possible that the same problem removes classes of elements, but as I said, I still cannot reproduce it. We are trying to fix the other problem as soon as possible, and with a bit of luck, this problem will be solved as well. If you have any other tips that could contribute to the solution, please let us know
We ran last week into this problem too.
Added custom classes. A hour later they were gone.
I will try to check my server too (nginx). Maybe there is a caching problem.
But behaviour itself ist very strange and extremly bad for the trust in daily use.
We added custom classes now in wpcodebox. That saves the classes but don’t solve that the element in the builder lose the added class.
I am also surprised that there is no feedback from the Bricks team for such a long time and though it’s an extremely urgent and important issue. But I’m even more surprised that Bricks team doesn’t just start to roughly narrow down the reason(s) by simply asking us users and trying to identify patterns that way. Oxygen for example did a survey in their Facebook group to find the reasons why the builder has been loading so slowly.
Concerning the loss of classes, these (and a ton of other similar questions) could be asked to narrow down the reasons:
On which hosting environments were the websites running where class loss occurred (exact info needed for detailed analysis)?
Which actions have been performed inside/outside the Bricks Editor before the class loss?
Is displaying dynamic data enabled/disabled in the builder?
What has the DOM size of pages been which have been worked before the class loss?
Which plugins are installed?
… and several other similar questions …
Can common culprits (or group of culprits) be identified based on analysis of above given answers?
We are running into this issue constantly on NGINX on one specific site.
We create a page all with custom classes on elements. The original author of the page can close the builder and re-open it and the classes are still there. As soon as a separate user edits the page, all classes either disappear or become “.undefined”.
Big thanks to everyone for the additional details & reports in regard to this issue. Especially the videos
We could finally reproduce the “browser back button” issue that wiped out the custom classes for @macksix and @aslotta, and the global class @digitalgravy added in his video above around the 20min mark.
After adjusting the Cache-Control HTTP header inside the builder, the issue no longer occurs for us locally. We’ll ship this fix in 1.6.2 in a few days (performing a few more tests in the meantime).
If anyone still encounters this issue in 1.6.2+ please reply to this post incl. a screenshot that shows your Response Headers inside the builder (as illustrated in the following screenshot).
Please also mention if you are referring to the loss of your global classes (the ones you can access via the dropdown) or the CSS classes under “STYLE > CSS > CSS classes”.
great to hear. Thanks for your update on this important issue.
I am experiencing another issue which could also be related to class loss for a few people. Please let me explain.
I do have a woo site and on my product single I am using tons of ACF fields (approx. 70/80 … didn’t count them). Often when saving (not every time, but very often), the save icon is
(1) either spinning and spinning forever (until I hit the save button a second time)
(2) or lasts about 1 - 2 minutes to finish the saving procedure
If (2) happens, my own managed hosting server, where all client websites are located, is being completely overloaded for this 1 - 2 minutes and no website on this server can be accessed or worked with both in frontend and backend. I am getting all greens in Bricks system info though and I am using a GOOD german server from a well known german hosting company (Mittwald). Even all cron jobs on OTHER projects are interrupted during this saving process. I have also been experiencing this on another site before with smaller cpt and acf templates , but couldn’t assign Bricks saving behavior as the culprit. Now I know that it’s reproducible behavior. And I am quite sure that it’s not a hosting server, cause I have built even larger templates with Oxygen too where this has never happened.
Why could this be (potentially) important concerning this class loss issue (no technician here, only guessing):
(a) If the save-icon/save-procedure is taking looooooong, I can well imagine, that (some) users are not patient enough to wait until the saving procedure has fully ended and are e.g. leaving the site, are continuing working on the site without edits being really saved.
(b) It seems that Bricks (?sometimes?) needs heavy server resources (when saving). Maybe this could be an issue on the server side too …
(c) Maybe this could also be this culprit for the editor lag … as I said: just guessing. Funny enough I am not experiencing this huge server lag (a bit yes, but not really a big problem. I am just reloading Bricks and editor lag is gone for a while. Running a Mac Pro here, if it’s important).
If you want to analyze this reproducible behavior I can create a staging site for you … we can also do a short screen sharing if you like …
Hi @beziehungsweise, i had a similar issue when using CPT’s on Bricks and tracked the issue on my Dev VPS via NetData and my finding was that the issue may be related to one of the experimental options in settings>builder>render dynamic data text on canvas.
Once this was deactivated the issue was resolved although I have noticed, in general, Bricks is resource heavy on servers, especially processor utilisation in comparison to other page builders and Gutenberg. Server spec is a Vultr HF 2 core (Intel Skylake) with 2Gb of RAM, OLS stack. Should be more than capable of running a WP dev site with no traffic. Hope this may be of some help.