SOLVED: Bricks classes lost

This Preview → Back Button behavior looks strange indeed. Not sure though if this is related to classes getting lost. But maybe you wanna have a look what’s going wrong here, @timmse:

  1. Create an element (e.g. a section)
  2. Apply a class to the section for better visibility via Style > CSS > CSS classes (I created this class via Bricks > Settings > Custom code)
  3. Add a heading to have some context
  4. Save the page
  5. Click the Bricks button to go to the preview (it is set to not open in a new tab)
  6. Check the page in the frontend → looks correct!
  7. Use the browser’s back button to get back into Bricks builder
  8. Check the builder → the section that was added before is missing
  9. BUT: Using the browser’s reload button at this point reloads the builder and brings back the section that was added before

Demo: Video uploaded to CleanShot Cloud

1 Like

@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.

Additionally, if you are editing a page in the builder:

  1. Click the Preview Button on the right
  2. Click View On Frontend and a new tab opens with a preview.
  3. Click Edit With Bricks on the WP Admin Toolbar.
  4. Now, in the new tab, make a change to the page.
  5. Click the Preview Button in the new tab.
  6. Click View On Frontend in the new tab. Notice that the preview opens up in the same tab and not in a new tab.
  7. Click the Browser Back button.

The change you made is now missing, just like if you used the logo button for preview as described in WAIT: Bricks classes lost - #21 by macksix

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 :thinking:

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. :slight_smile:

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 :+1:

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 :slight_smile:

1 Like

Hi all

Thanks for continuing this discussion. When I had the original issue I can confirm no other tab was open in my browser in any other state.

Due to how catastrophic this bug could be to a build I’ve suspended all use of Bricks until resolved but am following the topic.

4 Likes

I can confirm that after reloading the css reappeared. I am on the version 1.6

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.

(Using 1.5.7)

4 Likes

I just lost all my custom classes as well! I did have the preview mode window open. Trying to retrieve the classes in revisions does not help. Is there any way to retrieve them?

2 Likes

@m910 I helped someone with this issue the other day so I might be able to help you get the classes back.

Could you go into your wp_options table and search for the option_key “bricks_global_classes” and paste the option_value onto unserialize.com? Then click the unserialize button and post the url here.

2 Likes

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 …

Goal:
Can common culprits (or group of culprits) be identified based on analysis of above given answers?

2 Likes

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”.

Very frustrating.

4 Likes

Oh … sorry to hear that. From my point of view solving this huge issue is the most important one at the moment Bricks team should work on!

No one wants to lose work. This is the first real killer criteria! If they don’t solve this VERY soon I doubt that Bricks will be used for serious work by serious agencies or devs‘

Come on by Bricks team, it’s about time to officially get in contact with us users to solve this issue in common anytime soon!

1 Like

Big thanks to everyone for the additional details & reports in regard to this issue. Especially the videos :ok_hand:

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”.

4 Likes

Hi @thomas,

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 …

Best Regards
Michael

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.

1 Like

Hi guys,
We’ve fixed this issue in Bricks 1.6.2, now available as a one-click update within your WordPress Dashboard.

Please let us know if you are still experiencing issues.

Best regards,
timmse

4 Likes