NO BUG: CSS values attached to classes (custom CSS and builder set) randomly unset or go missing

Browser: Chrome 127
OS: macOS
URL: https://gpn.edynam.com/ (dev site)

I’ve been using Bricks with Brixies, Core Framework and Advanced Themer. Since updating to version 1.10 I’ve noticed custom CSS and CSS values set via the builder have been getting randomly undone.

It first started when I added custom CSS to elements inside the header. I selected the CSS class on the elements and then proceded to add custom css. I saved the page. I checked the outcome on both desktop and mobile. I went to bed (no one else had been touching the site). In the morning, all the CSS changed inside the header were gone. I needed to redo it. I also checked my history in the builder to check if there were saved states. There was nothing, the last save state said 4 days ago. It’s like it never happened. I checked with my hosting (Cloudways), there were no recoveries made during the night.

I decided to ignore it and keep on going. I remade my CSS changes, only to start noticing throughout the day other elements started losing their CSS value. This time I’m referring to values set in the builder and attached to a class (not custom CSS).

For example:
On the single blog template page - https://gpn.edynam.com/test-post-9/
The post wrapper’s width has gone back to 715px on several occasions. I keep setting it to 810px but it keeps reverting. The class being - blog-single__container , which is not used anywhere else. On occasion it also had its flex alignment revert to center. I say revert as this is a section we have copy / pasted from Brixies service which gives it the initial values. Then i select the class and update the vales and save. And I test the save. But then it randomly reverts later.

There have been other sections on the site which has had this happen. It’s driving me insane. What’s more worrying is that no one else has reported anything like this happening.

The project is on a tight deadline, and I will need to revert to Bricks 1.9.8 because we didn’t have any issues with that version. If it continues to happen with that version I will keep you posted.

Any ideas what might be happening?
I’ve checked external factors like:

  1. PHP memory - which is fine (256MB Wordpress / 512MB server)
  2. php_input_vars - 4500
  3. All caching is disabled (varnish disabled, no other cache should be present)
  4. PHP version 8.1

It feels like some sort of cron job processes something, and loses values set in CSS and the builder. But it feels random, sometimes the value sticks, sometimes it doesn’t.

Thanks, that’s all I can report.

** Update - I rolled back to Bricks 1.9.8 and the CSS reversions are still happening.

I tried to capture it on Loom by following the same steps which caused a reversion, but it did not happen whilst I was recording. I shall give it more time, as on occasion it reverts after time.

I made sure no other tabs with the page was open anywhere else to avoid any accidental overriding.

Here is the video where I was unable to successfully capture it happening - Support - GPN Vaccines | Loom

It’s driving me a bit crazy. I can’t figure out what’s causing it.

** Updates

Have noticed this is still happening across my site. I haven’t been able to find any particular reason that the CSS is not saving its values.

I have found define(‘WP_DEBUG’, true); was on. I have only just turned this off. Would this affect the saving of CSS in Bricks Builder?

Hi Michael,
Thanks so much for your report!

Unfortunately, I cannot reproduce the issue.

At first glance, it sounds like you have caching problems. Are you using a plugin or caching enabled by your hosting provider?

Finding a way to reproduce the problem consistently if it’s not caching would be really important. Otherwise, it’s the famous needle in the haystack…

Best regards,
timmse

Hi Timmse,

Thanks for your reply.

We are using Cloudways - Vultr server for hosting.
As this is a dev server, I have turned off all caching at application level.
It usually has Varnish. But Varnish is off.
Our hosting stack includes:

  • Apache
  • Memcached
  • NGINX
  • MySQL
  • phpfpm
  • Redis
  • Varnish

I have done the following, and haven’t had any further issues so far:

  • Turned WP_DEBUG to false in the wp-config.php file.
  • Instead of pressing command + S for saving a Bricks page, I am now manually clicking the save button (incase there is some kind of saving bug). As it seems the CSS changes stick more often than not when I press the button instead of command + S.
  • I removed the Advanced Themer PHP Filter that put Core Framework into the custom variable picker. It was inside the child theme function.php file:
    add_filter( ‘at/variable_picker/enable_core_framework’, ‘__return_true’ );

Fingers crossed that it won’t happen again.
It feels odd that WP_DEBUG could cause this?
Or potentially the Advnaced Themer PHP filter?

I currently do this thousands of times a day without a single problem. As far as I know, we don’t have any other reports on this. Accordingly, the problem does seem to be individual, which makes it even more difficult.

No, it can’t: Debugging in WordPress – Advanced Administration Handbook | Developer.WordPress.org

Enabling WP_DEBUG will cause all PHP errors, notices, and warnings to be displayed. This is likely to modify the default behavior of PHP, which only displays fatal errors or shows a white screen of death when errors are reached.

Let’s see :slight_smile:

*** Update:**
I’ve spend the whole day working on the site without issue. One of the mentioned things which I switched off must have been the cause.

Hey Michael,
Thanks for the feedback!

Ok, let’s assume for now that it’s not a general problem with Bricks.

If you can still attribute the problem to Bricks alone, please post again in this thread. Thank you!

Hi timmse,

I have been working on a new project. Which is a duplicate of our base WordPress / plugins stack (which is the same as our previous project which had issues).

Interestingly, I’ve had the same issue a previous specifically with the template I created as ‘default single post’ template, even though I’ve switch off the AT PHP filter.

The template contained elements with Global classes. I made structural changes, and also CSS changes via the builder / global classes. Interestingly, all the structural changes stayed in place, which included deleting elements and moving other elements in divs, etc.

But all the changes that were made to the global classes somehow disappeared. When I say disappeared. I made the changes, saved the template. Closed the template. Check frontend, saw the CSS changes missing, but the structural changes were present.

So to me it looks like this is only affect global classes. As I added and styled other elements on ID level, which worked.
And something to note, is that there are two of us working on the site simultaneously.

We both have seperate user accounts.

Would it be possible that somehow we are overwriting global classes on our saves?
My 2nd user didn’t report losing anything CSS styles, and I only noticed it on this particular template (not on any other pages).

And the ‘single blog post’ template is very specific with its global class naming, meaning there shouldn’t be any other instances of single blog post classes on the other pages. So I assumed this would mean it shouldn’t be getting overwritten.

But this time, I am not taking any further chances, and I am deleting this template and starting a fresh one.

Could you let me know how Bricks works for saving the global css data, and any implications of having two users saving it at the same time? Is this what the new “Global data sync” feature is for? How safe / reliable would it be to turn that feature on as it is marked as experiemental?

I would assume that if my 2nd user saves global classes, and the global classes are not the same as what I save on my page, then he shouldn’t be overwriting my data. But I’d like confirmation.

Hi @MichaelV,

Yes, you’re right, this is why it’s happening. The issue with global classes being lost is most likely because two of you are working on the site simultaneously. When both users have the builder open, changes made by one user can override the other’s when saved, leading to the loss of CSS values. This can also happen if you have multiple windows of the builder open on your end.

Here’s how this scenario typically plays out:

  • User A and User B both have the builder open, or you have the builder open in multiple windows.
  • User A makes changes to a global class and saves them.
  • User B, who still has the builder open, is unaware of User A’s changes. When User B saves their own work, it doesn’t include User A’s changes.
  • As a result, User A’s changes are overwritten, and only User B’s changes are saved in the database.

To answer your question:

Yes, exactly. The Global Data Sync feature is designed to automatically merge non-conflicting changes from other builder instances and notify you if there are conflicting changes (e.g. both users modifying the same class), allowing you to decide whether to keep your changes or the other user’s.

Although this feature is still experimental, we haven’t received any reported issues since introducing it in 1.9.9. However, I wouldn’t recommend using it in a production environment. If you’re working on a staging site, feel free to give it a try, but make sure to take frequent backups of your site in case anything goes wrong.

Please let us know if you have any other questions or if the problem persists after enabling “Sync global classes”.

Hi Charaf,

Thank you for your reply.

What about the following situation:

Person A and Person B are working on the site.

Person A makes changes to a template which contain global css variables. The global css variable are only used inside that template. Person A saves the template.

Person B makes changes on a page, not containing anything from Person A’s template. Person B saves the page (Bricks builder).

Person A notices that all the CSS changes to global class are now gone from their template.
Person B doesn’t notice anything gone.

Is a situation like this possible? Or is person B meant to be able to save without affecting person A (considering there would be no global css variables shared between that page and the template)?

Hi @MichaelV,

Yes, the situation you described is possible. Even if Person A and Person B are working on separate pages and modifying different parts of the site, if both make changes to global classes, there’s a risk of data being lost. Without the Global Data Sync feature enabled, when Person B saves their page, the entire set of global class data in the database is overwritten by what’s in Person B’s builder instance. This could result in Person A’s changes being lost, even if they’re working on a different template or page.

The “Sync global classes” feature prevents this from happening by automatically merging changes and checking for conflicts. If there’s a conflict—like both users modifying the same class—the builder will alert you and allow you to decide which changes to keep.

However, it’s important to note that this feature is still in the experimental stage and currently only affects global classes. In your scenario, if both users are modifying Bricks global variables rather than classes, the same issue could occur until we extend the data sync feature to include other global data like variables, color palettes, and theme styles.

Hi Charaf,

Thank you for this information. I will adjust our processes to avoid this potential issue.

1 Like