“Why does my design look different in Breakdance than it does when I visit it on the front-end?”
“The site looks fine to me, but it’s broken when a client visits it.”
“None of my changes are showing up.”
Do any of these sound familiar? If so, you’re in the right place.
One of the most common issues users encounter with Breakdance and other visual site builders is a difference between what they see in the builder and what they see on the front-end. Sometimes this difference is only on different devices, e.g. it looks different on phones than on a desktop. Sometimes it’s on the same device.
Luckily, this common issue has some very easy to solve common causes.
According to Cloudflare, caching is…
…the process of storing copies of files in a cache, or temporary storage location, so that they can be accessed more quickly.
Caching is super important for delivering modern web experiences to website visitors quickly. Without it, many websites would be unbearably slow, so we’re thankful for caching. But it does cause some problems when using visual site builders.
Caching comes in a few different flavors, too.
Some hosts offer something called a “web application accelerator”, also known as a “caching HTTP reverse proxy.”
This solution is positioned between the website visitor and your server. When the visitor requests a resource, the web application accelerator checks its cache and tries to serve it to the visitor without having to make a request to your server. If the resource isn’t available from the cache, it’s loaded from the server and then cached by the web application accelerator for future requests.
The most prominent example of this type of caching is Varnish by Cloudways.
Because this type of caching is so effective at not requesting cached resources from your server, it can often be overly aggressive when making rapid visual changes to your site via a visual builder such as Breakdance.
CDN (Content Delivery Network) caching is a lot like a web application accelerator.
The difference is that CDNs are built around networks of geographically positioned hardware that can deliver content faster to users in the same region.
While this type of caching isn’t as troublesome for Breakdance as web application accelerators, it can certainly cause issues if a cached version of your site or resource is being delivered to visitors instead of the version you expect to see.
Browser caching is built-in to all modern browsers.
When a visitor visits a website for the first time, the resources from the website may be downloaded directly to the user’s hard-drive. This local cache of resources can then be used to serve subsequent requests, rather than having to re-download the resources from the server every time.
This type of caching is very often responsible for seeing differences between the builder preview and the front-end.
The first step when you notice a difference between the builder preview and the front-end is to clear your caches!
It’s easy to do, but the process depends on the type of cache.
Wep Application Accelerator (Varnish, etc..): To clear this type of cache, you usually need to use a special control panel from the WordPress admin area. Look for the words “flush”, “purge”, or “purge all.” This type of caching can also be temporarily disabled for your site or server from your web hosting control panel. We recommend this if a site is under active development, but it’s a good idea to turn it back on once the site is live and undergoing less frequent changes.
CDN Caching: It’s fairly rare that you’ll need to do anything about your CDN caching. When you do, you may have a control in the WordPress admin area to flush, purge, or clear your CDN cache. This will depend on your provider. If you’re not sure how to clear your CDN cache, please reach out to your CDN provider for more assistance.
If clearing all of the necessary caches doesn’t resolve the issue, you’re ready to move on to cause #2.
Breakdance is a powerful, modern visual site builder. Because it allows you to write custom CSS in various places in the builder, it’s quite common to run into issues related to styling because of a typo or mistake in custom CSS.
The most common causes for broken CSS are incorrectly nested selectors & missing braces. You can find both of these by running your custom CSS code through a CSS formatter such as this one.
There are two main places that we commonly find bad CSS that breaks styles.
In Breakdance, if you select an element and go to Settings > Advanced in the Properties panel, you’ll find an area where you can write CSS code on a per-element basis. Because of the way Breakdance’s CSS is compiled, if you notice that the styles work up to a specific element and then break after that element, you should check the last working element for broken custom CSS. Common problems in CSS are incorrectly nested selectors & missing brackets.
If you find an error in this code, make sure it’s corrected, then save. Once you’ve done that, if the corrected code was the only problem, the styles should start working as expected on the front-end.
Under Settings > Global Settings > Code in Breakdance, you’re able to add your own custom stylesheets. This is the next place to check for bad CSS if the per-element search didn’t yield any results.
Just like before, make sure the CSS is all properly formatted by running it through a formatter or visually inspecting it. It’s usually best to do both to ensure you don’t miss any mistakes.
Because of the way CSS works, bad CSS in either of these areas can cause all styles that come after them to be broken or behave unexpectedly.
If the above steps didn’t help you resolve the issue, our expert support staff is happy to investigate further. Please submit a ticket via our support portal with the following details: