Blocksy CSS Not Updating: Find the Old global.css Before You Clear Anything

Right in the preview, wrong on the website

The pattern is familiar. A new accent color looks perfect in the Customizer, the Publish button greys out to confirm the save, and the public site carries on in the old color. Sometimes it is worse: the change shows for you and not for a customer, or it shows on the home page and not on the blog. Before you clear anything, note which of these you are seeing, because each points at a different layer.

• Changed in the preview, unchanged everywhere live. The stylesheet was not rebuilt, or every page is cached.
• Changed for you, unchanged for visitors. Logged-in users usually skip the page cache. Visitors are getting stored HTML.
• Changed on some pages only. Those pages were purged; the rest were not. Or the setting is a per-page one stored with that page.
• Changes vanished after a child theme went live. WordPress keeps separate Customizer settings for a parent and a child theme. Nothing is stale; the child theme simply has its own configuration.
• Your own CSS edits do nothing. The rules are losing on specificity, or a child stylesheet is loaded with a version number that never changes.

Where Blocksy writes the styles you design

The relevant switch is Dynamic CSS Output, under Customizer > General Options > Performance. The option itself comes from the free Blocksy Companion plugin, and the vendor recommends File. In File mode, Companion writes the global styles to wp-content/uploads/blocksy/css/global.css and loads it as a normal stylesheet with the ID blocksy-dynamic-global-css. Its version number is the last five digits of the file's modification time, so each rebuild gives it a new address. In Inline mode, the same CSS is printed inside a style tag with the ID ct-main-styles-inline-css in every page's head.

Three details in the 2.1.58 code matter for debugging. The Customizer preview never uses the file; it renders styles inline so changes sync instantly, which is why the preview is always right. Styles from the per-page Blocksy Page Settings panel are saved with that page and always printed inline. And if Companion cannot write to the uploads folder directly, or the file is missing, the theme falls back to inline output without telling you.

The usual hiding places, ranked for Blocksy

1. Cached HTML still pointing at the previous file

Publishing rebuilds global.css, but on a routine Publish Blocksy does not ask your caching plugin to purge pages. The theme only runs its own purge of known caching plugins when the theme version changes or when options are imported. Some caching plugins purge on Customizer saves by themselves; many do not. Check: view source as a logged-out visitor and find blocksy-dynamic-global-css. If its ver number differs from the one you see logged in, the HTML is cached.

2. A CDN or browser holding the old stylesheet

If a CDN caches CSS by full address, the old version stays served to anyone whose cached HTML still asks for it. Check by opening the global.css address from the page source directly and searching for your new color value.

3. An optimizer that bundled yesterday's styles

Combine CSS and remove unused CSS features copy global.css into their own files. Your regenerated file is ignored until their cache is cleared. CreativeThemes advises against combining CSS and removing unused CSS on Blocksy, because the theme loads many styles only when a feature appears on the page. Check by finding your color in the optimizer's file rather than in global.css.

4. The file could not be written

On hosts where WordPress needs FTP credentials to write files, or where the uploads folder is not writable, Companion cannot save global.css. Check the page source: if you expected File mode and see ct-main-styles-inline-css carrying your global styles, the write failed. Fix the folder permissions and regenerate.

5. The wrong configuration, or a losing rule

After switching to a child theme, use Customizer > General Options > Manage Options > Copy Options to bring the parent's settings across. If custom CSS is the issue, inspect the element and see which rule wins. That is a specificity question, not a cache, and the general guide to theme CSS not loading walks through it.

Rebuild the stylesheet, then clear from server to browser

1. 1

   Confirm the output mode

   Open Customizer > General Options > Performance and note whether Dynamic CSS Output is File or Inline. If the option is missing, Companion is inactive or out of step with the theme, and the theme prints styles inline.

2. 2

   Force a rebuild

   Make a small change, Publish, change it back and Publish again. That runs Blocksy's refresh. With shell access, wp blocksy tool run regenerate_dynamic_css, a command Companion registers, does the same.

3. 3

   Check the file itself

   Load uploads/blocksy/css/global.css in a browser and search for the new value. If it is missing, the write failed; check folder permissions and the filesystem method before going further.

4. 4

   Clear the optimizer

   Purge your optimization plugin's minified and combined files, and switch off Combine CSS and Remove Unused CSS while you test.

5. 5

   Purge the page cache, then the CDN

   Clear every page, not one URL, so all HTML points at the new version. Then purge the CDN, including CSS files.

6. 6

   Test as a stranger

   Open a private window on another device or network. Confirm the new ver number in the source and the new color on the page.

Still stale? Switch Dynamic CSS Output to Inline, Publish, and purge. If the change appears, the problem is in the file layer: permissions, a CDN rule or an optimizer. Switch back to File once fixed, since the vendor's documentation favors it for caching. Our Blocksy speed guide explains the trade.

Moves, restores and imports leave old CSS behind

A site migration copies global.css along with every other upload, and with it any absolute addresses written into the file, such as a Customizer background image on the old domain. Companion listens for the finish of an All-in-One WP Migration import and rebuilds automatically. Other migration tools, a manual database search and replace, or a restored backup do not trigger that rebuild. Publish once in the Customizer after any move. The same applies after restoring a backup, and the general CSS changes not showing fix covers hosts that cache aggressively.

Importing settings through Manage Options, or importing a starter site, does trigger a rebuild and a purge of the caching plugins Blocksy knows about. A theme update does too, because the theme runs its database checks and refreshes the CSS when the version number changes. If an update looks wrong rather than stale, Blocksy update broke my site is the better page.

A cache routine your whole team can follow

• Pick one caching plugin and one CDN. Two caching layers that each think they own the CSS are the most common reason a fix needs four purges.
• Set the caching plugin to purge everything on Customizer saves, if it offers that, and write down where the setting lives.
• Leave Combine CSS and Remove Unused CSS off on Blocksy. The theme already splits its styles and loads them on demand.
• Give your child stylesheet a version number that changes with the file, so browsers fetch the new copy.
• After any migration or restore, Publish once in the Customizer and purge all caches before telling anyone the site is ready.

Our hosting and maintenance plans include a single caching layer configured for the theme, so a published change is a published change. If styles break in other ways, such as a Blocksy mobile menu that will not open after an optimizer change, the same layers are usually involved.

When a color change needs four purges, the stack is the problem

None of the parts here is badly made. Blocksy writes a clean file. The caching plugin stores pages correctly. The CDN serves files quickly. The trouble is that each keeps its own copy and none of them is told when another one changes. Every Customizer edit becomes a small ritual, and a new team member who skips a step publishes a site that looks half updated.

A Publish button that needs a checklist is not really a Publish button.

In a Next.js build, styles are compiled with the page during a build and published together, with new file names, so there is no old stylesheet to purge. The trade is a higher build cost and a developer for structural changes. Compare honestly in Blocksy vs Next.js, read the move plan in Blocksy to Next.js, and see how Athena CMS handles edits with a real preview. Prefer to stay on Blocksy? Our theme troubleshooting service maps your cache layers, and theme repair fixes what it finds. More fixes by theme are in the troubleshooting section, and the full Blocksy review covers the rest of the theme.