Sydney CSS Not Updating: The Theme Cache, the Child Stylesheet and the Rest

Sydney 2.70 added a cache most owners have never heard of

The 2.70 changelog, from July 2026, says it plainly: dynamic CSS output is now cached in a transient to stop regenerating it on every request. That is a sensible speed change. Before it, Sydney rebuilt the CSS for your colors, fonts, buttons and header on every page view. Now it builds it once and stores the result, keyed to the active theme folder and the text direction, for up to a week.

The code is careful about clearing that copy. It flushes on a Customizer publish, a theme switch, plugin activation or deactivation, any update, media library edits and any write to the theme's settings option. It also stores a signature built from the theme version, the active child theme and whether the Header Builder module is on, and rebuilds when any of those change. The Customizer preview never uses the cache at all, which is why the preview is always right.

What the code cannot hear is a change that bypasses WordPress. Its own comment names raw database edits of theme settings as the case the one-week expiry exists to backstop. In practice that means a database pushed from staging with an import tool, a restored backup, or a search-and-replace run straight on the database. A persistent object cache such as Redis can also keep the old copy after a database restore, because transients live there instead of in the database.

The preview is built fresh every time. Your visitors get whatever copy is nearest to hand.

Tracing a Sydney style back to its source

Right-click the element that looks wrong, choose Inspect, and read the winning rule in the Styles panel. Its source tells you which layer owns it, and therefore which layer to clear.

One renaming catches people out. Version 2.70 merged the separate Colors, Typography and Buttons panels into a single Global Styles panel. If a tutorial sends you looking for a Colors panel that no longer exists, the setting has moved, not vanished.

Suspects for stale Sydney styles, server side first

A page cache holding yesterday's HTML

Because Sydney prints its Customizer CSS inline, the styles travel inside each cached page. View the source logged out and search for sydney-style-min-inline-css, the id WordPress gives that block. If it holds the old hex code, a page cache, host cache or CDN is serving stored HTML. Most caching plugins skip logged-in users, which is why you see the change and customers do not.

The theme's own transient

If the inline block is old even on an uncached request, Sydney's transient is the next suspect, especially after a database import or restore. Make any small change in the Customizer and publish it, which writes the theme settings and triggers the flush. If your host runs Redis or Memcached, flush the object cache too.

An optimizer that captured the inline block

Plugins that aggregate inline CSS can lift Sydney's block into a combined file that only changes when the optimizer's own cache is cleared. Look for stylesheet addresses under a cache folder with hashed names. Purge the optimizer separately from the page cache.

Elementor styles winning on Elementor pages

On activation Sydney switches off Elementor's global color and typography schemes so the Customizer stays in charge. If someone switched them back on, or styled widgets with fixed colors, Elementor's rules win on those pages however often you change the Customizer. Elementor also writes CSS files of its own; regenerate them under Elementor, Tools, Clear Files & Data. Builder conflicts are covered under Elementor repair and in Elementor theme conflicts.

A Performance toggle doing its job

Under General, Performance, Defer block styles removes the block library stylesheet from the head on single pages without blocks and loads it later with a load-swap trick. If block widgets in a footer look unstyled on Elementor pages, or an optimizer rewrites that trick, switch the toggle off and compare. Load Google Fonts Locally serves the theme's fonts from your server, but fonts chosen only in Elementor stay on Google's, which can look like a typography change that half worked.

The child stylesheet stuck at version 20230821

This one is easy to miss and permanent until fixed. In 2.71, Sydney's functions.php enqueues the active theme's style.css under the handle sydney-style with a hardcoded version string, 20230821. When a child theme is active, that file is the child's stylesheet. Edit it as often as you like: the address stays exactly the same, so browsers and CDNs are entitled to keep the copy they already have.

The fix belongs in the child theme's functions.php: dequeue sydney-style and enqueue the same file again with a version that changes when the file does, such as its modification time, or move your rules into a separate stylesheet you version yourself. Until then, every child theme edit needs a CDN purge and a hard refresh, and real visitors may see the old styles for days. The general pattern is covered in CSS changes not showing on a website.

Clearing old Sydney styles in a fixed order

1. 1

   Confirm the save

   Reopen the Customizer and check the setting holds its new value. If it reverts, you have a saving problem, not a caching one; publishing failed errors are a likely cousin.

2. 2

   Find the winning rule

   Inspect the element and note the source of the rule that wins: inline Sydney block, Additional CSS, child stylesheet or Elementor file.

3. 3

   Refresh Sydney's own copy

   Publish a small Customizer change, then flush the object cache if your host runs one. This forces the transient to rebuild.

4. 4

   Purge the optimizer

   Clear the CSS optimizer's files, then its page cache.

5. 5

   Purge host and CDN

   Use the host's purge button and purge everything at the CDN, not single files.

6. 6

   Regenerate Elementor files

   On Elementor sites, Elementor, Tools, Clear Files & Data, then purge the page cache again.

7. 7

   Fix the child theme version

   If the old rule comes from the child stylesheet, re-enqueue it with a changing version, then purge the CDN.

8. 8

   Check logged out

   Load the page in a private window on a phone and a desktop. Search the source for your new value.

House rules for anyone who edits Sydney's styles

• Make style changes in one place per kind of change: Global Styles for theme colors and fonts, the child theme for structural CSS, Elementor only for Elementor content.
• After any database import or restore, publish a Customizer change and flush the object cache before judging the result.
• Run one page cache. A plugin cache stacked on a host cache doubles the places old HTML can hide.
• Version the child stylesheet properly once, and the browser cache problem goes away for good.
• Test style changes on staging and look at the header afterward, since header colors have shifted after updates before, as our Sydney header guide records.

If a cache plugin also broke the phone menu, Sydney mobile menu not working covers the script side, and the Sydney speed guide explains what each Performance toggle is for. The cross-theme mechanics are in WordPress theme CSS not loading.

Why a button color should not need a purge list

Count the layers between a color picker and a customer on a typical Sydney site: the theme settings, the theme's transient, Elementor's files, a CSS optimizer, a page cache, a host cache, a CDN and the browser. Each exists for a good reason. Together they turn a two-second change into a routine someone has to remember.

A Next.js build compiles styles into files whose names change whenever their contents do, and a deploy replaces them all at once, so there is no stale copy to chase. It costs more up front and needs a developer for structural changes. Sydney vs Next.js lays out the trade, and Sydney to Next.js covers the move. Prefer to stay? Our theme troubleshooting team untangles stuck styles on staging, and the Sydney review helps decide whether the theme still fits. Other fixes live in the troubleshooting section.