Bricks CSS Not Updating: Why the Builder Shows Your Change and the Live Site Ignores It

Saved in the builder, missing on the page

Stale CSS on Bricks shows up in a handful of recognizable ways. Pin down which one you have before you clear anything, because clearing every cache at once destroys the evidence of which cache was guilty. The Bricks Builder review covers how Bricks generates its styles; this page is about when that output goes out of date.

• The change appears in the builder and when you are logged in, but not in a private window.
• One page shows the new style, while other pages using the same component or global class still show the old one.
• A breakpoint change, such as a new tablet width, applies in the builder but not on real devices.
• Everything looked right until a Bricks update or a migration, and now spacing or colors are off site-wide.
• A rule you typed in Custom CSS disappeared or moved after you clicked a style control.
• The CSS clearly loads (you can see it in the page source) but another rule wins.

The first four are delivery problems: the right CSS exists somewhere but the visitor gets an old copy. The last two are cascade problems: the browser has the current CSS and still prefers something else. Treat them differently.

Where Bricks keeps your styles decides where they go stale

Bricks offers two CSS loading methods under Bricks > Settings > Performance. The default, Inline styles, writes generated CSS into style tags inside each page's HTML. The Academy describes it as always current with no caching of its own. External files writes minified stylesheets to wp-content/uploads/bricks/css/ and links them, so browsers and CDNs can cache them. That option requires a writable uploads folder, and when it is selected Bricks shows a Regenerate CSS files button with the date and Bricks version of the last regeneration.

That last detail is your fastest diagnostic. If the date predates your most recent Bricks update or breakpoint change, the files on disk were built from old settings.

Our Bricks speed guide explains why External files is usually the faster choice. It is also the one with more moving parts, so most stale-style tickets come from it.

Five reasons Bricks hides a style you saved

1. A cache is serving an older page

The commonest cause on any WordPress site, and the reason the change shows when you are logged in: most page caches skip logged-in users. A CDN may also hold the HTML or the CSS file. Bricks has a developer hook, bricks/generate_css_file (since 1.9.5), that fires whenever it writes a CSS file, and the Academy suggests using it to tell a cache plugin to purge. Check: open the page in a private window, add a throwaway query string such as ?nocache=1 (many caches skip those), and compare. The cross-theme version is CSS changes not showing.

2. External files that were never rebuilt

Switching to External files does nothing visible until you click Regenerate CSS files, which is when Bricks creates the folder and files. Bricks regenerates after its own updates since version 1.8.1, but forum users reported the automatic pass not completing after some one-click updates, fixed by a manual regenerate. Changing custom breakpoints has its own Regenerate CSS files button under Bricks > Settings > General, because existing files were built for the old breakpoint widths. Check: the regeneration date, and that the uploads folder is writable.

3. WP-Cron is switched off

This one surprises developers. In a thread marked solved in June 2026, a component edit was not reaching other pages that used it, and the cause was DISABLE_WP_CRON set to true with no server cron job to replace it. Bricks staff explained that external CSS auto-generation relies on cron to avoid performance problems when saving, and Bricks added a settings notice for sites with External files and DISABLE_WP_CRON set to true. Check: wp-config.php for DISABLE_WP_CRON, and if it is set, confirm with the host that a real cron job calls wp-cron.php.

4. The style loads but loses

Three Bricks mechanisms decide which rule wins. Bricks puts its default styles in a CSS cascade layer called bricks, so any un-layered stylesheet, such as an old plugin's CSS, beats them regardless of selector. Theme styles default to a loading method of Most specific, which loads only the single best-matching theme style, so editing a broader one changes nothing on pages where a narrower one applies. And when two global classes set the same property, Bricks 2.4 added Output global class CSS in Class Manager order to make the winner predictable. Check: inspect the element and see which rule is crossed out.

5. CSS Sync rewrote your Custom CSS

Bricks 2.4 introduced CSS Sync, an experimental setting under Bricks > Settings > Builder that keeps Custom CSS and style controls in step. Forum reports after release described an edit to Custom CSS being deleted when a style control was clicked afterward, and descendant rules such as %root% a being copied into root controls; 2.4.1 fixed the second. Bricks notes that when both define the same property, Custom CSS takes precedence. Check: turn CSS Sync off on a staging copy and repeat the edit.

Forcing Bricks to print the styles you saved

1. 1

   Confirm the save

   Reload the builder. If your change is gone there too, the problem is saving, not CSS; see the builder troubleshooting guide linked below.

2. 2

   Note your CSS loading method

   Go to Bricks > Settings > Performance and read the CSS loading method. With External files, note the date and version shown beside Regenerate CSS files.

3. 3

   Regenerate the files

   Click Regenerate CSS files. If you changed breakpoints, also use the Regenerate CSS files button under Custom breakpoints in Bricks > Settings > General.

4. 4

   Purge caches from the inside out

   Clear the caching plugin, then the server cache, then the CDN, then test in a private window. Purging in that order stops an outer layer from refilling with stale content.

5. 5

   Test with Inline styles

   If styles still look wrong, switch the method to Inline styles. Bricks itself advises reverting to Inline styles and reporting the issue if external files conflict with your caching.

6. 6

   Check WP-Cron

   If component or global class edits lag behind page edits, confirm WP-Cron runs, either natively or through a server cron job.

7. 7

   Inspect the losing rule

   If the CSS is present but not applied, inspect the element, find the winning rule, and fix the theme style condition, class order or stray stylesheet that beats it.

Keeping Bricks styles and caches in agreement

Decide which cache owns the site and switch the rest off. A host cache, a caching plugin and a CDN each with its own rules is how a site ends up with three versions of the same stylesheet. If you use External files, wire the bricks/generate_css_file hook to your cache's purge function, or choose a host whose cache clears itself when files in uploads change. Leave WP-Cron running unless a server cron job replaces it.

Treat Bricks updates as style changes. Update on staging (staging sites do not count against the license), regenerate CSS files, check a few templates at each breakpoint, then go live and regenerate again. Keep experimental settings such as CSS Sync off on production until they leave experimental status. Our hosting and maintenance plans do exactly this with every update.

Bricks saved your change. A cache decided you did not need to see it.

If the page looks broken rather than merely out of date, the cross-theme checks in theme layout broken and theme CSS not loading apply. If the editor itself will not open, start with Bricks builder not loading, and for a menu that misbehaves on phones see Bricks mobile menu not working.

Three copies of one stylesheet is an architecture, not a bug

Each layer on a Bricks site is reasonable on its own. The builder generates CSS, a plugin caches pages, a CDN caches files, and WordPress cron finishes the work later. Together they create four places a style can be out of date, and the owner has to remember the order in which to clear them. That is the cost of assembling a site from parts that update on their own schedules.

In a Next.js build, CSS is compiled when the site is built and ships with that deploy, so new pages and their styles arrive together and the CDN serves both. There is no regenerate button because there is nothing to regenerate. The trade is a higher build cost and a developer for layout changes. Compare the two in Bricks vs Next.js, read the plan in Bricks to Next.js, and see how editors work in Athena CMS, where Argus flags slow or failing pages.

Most Bricks sites should stay on Bricks and simply get their caching straightened out. Our theme troubleshooting service does that on a staging copy, our theme repair team handles sites an update has scrambled, and our Bricks developers take on ongoing template work. The WordPress troubleshooting library covers the rest of the stack.