Flatsome CSS Not Updating: Theme Options, Custom CSS and the Cache in Between

Five versions of the same stale-style complaint

The symptoms vary more than people expect, and each one narrows the search. Note which of these you see, logged in and logged out, before purging anything. Purging first destroys the evidence.

• Customizer preview right, live site wrong for everyone. A page cache, host cache or CDN is serving pages built before the change.
• Right for you, wrong for visitors. You are logged in, and most caches skip logged-in users. Visitors get the cached page.
• Right on desktop, wrong on phones, or the reverse. The rule sits in a screen-size field or media query that does not match the device.
• Child theme edits ignored entirely. The browser or CDN is holding the old style.css because its address never changed.
• One page stubborn, the rest fine. A UX Builder element setting, or a page-level cache entry, is overruling the global style.

If styles are missing altogether rather than out of date, you have a different fault: a stylesheet that fails to load. That one is covered in WordPress theme CSS not loading, and the plain-language version for any site is CSS changes not showing.

Where Flatsome writes each kind of style

On the vendor's own demo store, Theme Options output arrives as an inline style block with the id custom-css, printed in the page head. It holds the color palette as CSS variables such as --fs-color-primary, header heights, font choices and, near the end, whatever you typed into the Custom CSS fields. The theme's main stylesheets, flatsome.css and flatsome-shop.css, are separate files tagged with the theme version.

UX-Themes says the two Custom CSS fields work the same way, so use one. It also says never to put CSS in the parent theme's style.css, because the next update replaces that file. Even the vendor's demo serves its theme CSS through a cache plugin's minify folder, which tells you how normal this layering is.

Five reasons a Flatsome style refuses to change

1. A cached page still carries the old inline block

Because Theme Options styles travel inside the HTML, a page cache built yesterday holds yesterday's colors, no matter how many times you press Publish. Hosts often run their own cache in front of your plugin, and a CDN may hold a third copy. Check: view the page source logged out and search for custom-css. If the old value is there, a cache is the problem, not Flatsome.

2. The optimizer rebuilt the files and kept the old result

Minify, combine and remove-unused-CSS features write their own versions of Flatsome's stylesheets and store them. Some regenerate on every save; some wait for a manual purge. Remove-unused-CSS tools also build a list per page, so a new class used in a fresh rule can be stripped as unused. Check: switch the optimizer's CSS features off, purge, and compare.

3. The child theme file kept its old address

The vendor's custom CSS article notes that you may need to raise the child theme's version number to see changes. The reason: the version is part of the file's address, and browsers and CDNs keep a file with an unchanged address for a long time. Check: open the page source, find the child stylesheet's link and see whether its ?ver= value changed after your edit.

4. The rule is live but loses

Flatsome's own rules, UX Builder element settings and CSS variables can outrank a rule that is technically present. Breakpoints trip people too. Flatsome's stylesheet switches layouts at 849 and 549 pixels. In Classic builds we checked, the Custom Tablet CSS and Custom Mobile CSS fields are wrapped at those widths, while the starter child theme's mobile block uses 48em, or 768 pixels. A rule written for one range misses the gap between them. Check: inspect the element in the browser and look for your rule crossed out.

5. The Customizer saved a draft

WordPress lets the Customizer's Publish button switch to Save Draft or Schedule. A colleague who chose either leaves the change waiting. Check: open the Customizer and read the button's label and any scheduled date.

Getting new styles onto the live store

1. 1

   Confirm the save

   Open the Customizer, confirm the button reads Publish and that the preview shows the change. Re-publish if it was a draft.

2. 2

   Read the source, logged out

   In a private window, view source and find the custom-css block. Old values mean caching; new values mean the rule is losing.

3. 3

   Purge from the server outward

   Clear the optimizer's CSS files, the page cache, the host's cache and the CDN, in that order, so no layer refills from a stale one.

4. 4

   Version the child theme

   Raise the Version line in flatsome-child/style.css after each edit, so the stylesheet's address changes and caches fetch it fresh.

5. 5

   Settle the rule

   Inspect the element. If your rule is crossed out, match Flatsome's selector or move the change into the UX Builder element that controls it, rather than forcing it with an important flag.

6. 6

   Match the breakpoint

   Put phone rules where Flatsome's mobile layout starts, at 549 pixels, and tablet rules at 849, or write your own media queries to those numbers.

7. 7

   Retest the store templates

   Check the homepage, a category, a product page and the cart, logged out, on desktop and a phone.

A workflow that makes the next change show up first time

• Choose one home for custom CSS. One Custom CSS field or the child theme, not both, so nobody edits a rule that something else overrides.
• Comment every rule with the date and the reason. Six months later, that note is the difference between editing and guessing.
• Make purging part of publishing. Most cache plugins add a purge button to the admin bar. Use it after every design change.
• Exclude the Customizer preview from optimization. Many optimizers already do; confirm yours does, or previews will mislead you.
• Test on staging before the busy season. A color change that breaks the add-to-cart button is cheaper to find in March.

Cache and optimizer choices also decide store speed. Our Flatsome speed guide sets out one cache and one optimizer as the safe arrangement, and Flatsome slow website is the repair checklist when speed has already slipped. If a header element is the thing that will not change, Flatsome header not showing covers the settings behind it.

Fonts and icons that look like a CSS problem

A typeface change that does not appear can be a cache, but it can also be the font file failing to arrive. Since version 3.16.0, Flatsome downloads the fonts you pick to /wp-content/fonts/ and serves them from your server. If that folder cannot be written, the CSS names your new font and the browser shows a fallback. The checks are in Flatsome fonts not loading.

Likewise, a phone menu that stopped opening after a CSS cleanup is often a remove-unused-CSS tool stripping the sidebar's overlay styles. That case has its own guide: Flatsome mobile menu not working.

When every color change needs a purge ritual

Count the copies of one button color on a typical Flatsome store: the Theme Options value in the database, the inline block in every cached page, the optimizer's rewritten files, the host's cache, the CDN and each visitor's browser. Changing the color means making all of them agree. Plugins exist to manage that, which is a fair summary of the WordPress theme stack.

Next.js builds styles into files whose names change whenever their contents change, so a new color ships with a new file name and no cache can hold the old one. The cost is a developer and a deploy for design changes. Flatsome vs Next.js sets the two side by side, and Flatsome to Next.js covers the move. Sites we build run on Athena CMS, with a real preview that matches what visitors see.

If you would rather keep Flatsome, our theme customization service cleans up scattered rules and sets a workflow, and the Flatsome repair hub collects our other fixes. The Flatsome review covers where Classic is heading now that Site Builder is in beta.