GeneratePress CSS Not Updating: Inline, File or Cache?

The preview is right, and that is the clue

The pattern repeats on GeneratePress sites. The Customizer preview shows the new heading size. The block editor shows the new container padding. The live page, opened in a fresh tab, shows last week. Owners assume the save failed and change the setting three more times, which makes the eventual diagnosis harder.

The preview being right is useful information. In the theme's source, the Customizer preview skips the stored CSS and builds it fresh from your settings. GenerateBlocks does the same in post previews, printing its styles inline instead of using its file. So a correct preview proves the setting saved. What visitors receive is a stored copy, and the work is finding which one.

• Customizer changes missing live: suspect the External File, an optimizer's combined CSS or the page cache.
• Block styles missing live: suspect a GenerateBlocks file that has not been rebuilt.
• Child theme edits ignored: suspect the way the child theme loads stylesheets.
• Changes visible to you but not to a colleague: suspect a CDN or browser cache.

Six places a GeneratePress style can live

GeneratePress spreads its CSS across fewer places than most themes, but more than one. Before purging anything, find which row your missing change belongs to.

Everything in that table then passes through whatever caching and optimization sits in front of WordPress. A page cache stores the HTML that names these files, and a CDN stores the files themselves. The general guide to theme CSS that will not load covers those outer layers for any theme.

Inline Embedding or External File: which one is holding the old copy

GP Premium's General module adds a setting called Dynamic CSS Print Method in Appearance > Customize > General. Inline Embedding, the default, prints the Customizer CSS inside each page's head. External File writes it to a stylesheet in your uploads folder that browsers can keep between page views. Each fails differently when a change does not appear.

Optimizers make the External File trickier. In one thread on the vendor's forum, Customizer changes stopped appearing because Autoptimize, by default, treated the uploads folder differently from the theme's own files; removing that exclusion fixed it. Staff also describe the external file as only slightly better when an optimization plugin merges CSS anyway. If you run one, switching back to Inline Embedding is a fair test and often a fair permanent choice. The GeneratePress speed guide weighs both methods.

Edits the theme's CSS cache never hears about

Cache dynamic CSS, on by default under Customize > General, stores the Customizer's output in the database. Reading the 3.6.1 source, that copy is rebuilt in exactly two situations: when you publish in the Customizer, and when the theme's version number changes. A setting changed any other way leaves the old copy in place. That includes a database search and replace after a migration, settings written by a script, and child theme code that changes options or adds CSS through the generate_dynamic_css filter.

The test is quick. Untick Cache dynamic CSS, publish, and reload the live page with caches purged. If the change appears, the stored copy was stale. Tick the box again and publish; that publish rebuilds it with current settings. Leave caching on afterward, because the vendor describes it as a real speed gain.

Two more GeneratePress specifics catch people. Additional CSS is a WordPress feature, not part of the theme's dynamic CSS, so it never appears in the External File. And the vendor's troubleshooting guide warns that child themes which load the parent stylesheet a second time, through an @import line or their own enqueue function, stop some Customizer options from working. Remove that duplicate load; GeneratePress already loads the parent styles for you.

GenerateBlocks writes a file per page

Most GeneratePress layouts are built with GenerateBlocks, which keeps its styles apart from the theme. Its CSS Print Method defaults to External File, one stylesheet per page in uploads/generateblocks, named with the page ID. Saving the page marks that file for rebuilding, and the next visit writes it. The plugin throttles this to one file every five seconds, and falls back to inline CSS when it cannot write to the folder.

When block styles look right in the editor and wrong live, open GenerateBlocks > Settings and use Regenerate CSS Files, which forces each file to rebuild the next time its page loads. Then purge caches so visitors request the page again. If the folder is not writable after a move to a new host, fix the permissions rather than living on the inline fallback. When the trouble began with a plugin update, the cause is often markup rather than caching; GenerateBlocks layout broken after update covers that case, and the GeneratePress and Gutenberg guide explains how the two products divide the work.

Forcing fresh GeneratePress CSS, in order

1. 1

   Name the missing change

   Write down which row of the table it belongs to: Customizer, Additional CSS, child theme or block. The fix depends on the row.

2. 2

   Confirm it in a clean browser

   Open the live page in a private window with developer tools set to disable the browser cache. If it appears there, only your own browser was stale.

3. 3

   Rebuild the theme's copy

   For Customizer changes, make a small edit and publish, or untick and re-tick Cache dynamic CSS. With External File, use the regenerate option in Customize > General if it is showing.

4. 4

   Rebuild block files

   For GenerateBlocks styles, use Regenerate CSS Files under GenerateBlocks > Settings, then load the affected page once.

5. 5

   Clear the optimizer

   Purge your optimization plugin's combined and minified files, and check it is not excluding or rewriting files in wp-content/uploads.

6. 6

   Purge the outer caches

   Clear the page cache, the host's server cache and the CDN, in that order, so each layer refills from a fresh source.

7. 7

   Check the cascade

   If the new rule is in the CSS but not applied, inspect the element. Theme dynamic CSS prints after the main stylesheet, so a weaker selector loses even when it loads.

A purge order everyone on the team can follow

Stale CSS on GeneratePress is almost always a process problem: the person who changed a color does not know which of four caches holds it. Write the order down once and pin it where editors work. Rebuild the source (Customizer publish or GenerateBlocks regenerate), then the optimizer, then the page cache, then the host, then the CDN.

• Pick one print method per product and record it, so nobody regenerates a file that does not exist.
• Keep custom CSS in the child theme or Additional CSS, never both, so there is one place to look.
• After a migration, publish once in the Customizer and regenerate GenerateBlocks files before testing anything else.
• Never test design changes while logged in to a cached site; use a private window.

If that list reads like a job description, it is one. Our hosting and maintenance plans run it for you, and our theme repair team fixes sites where the layers have already tangled. Other GeneratePress quirks live in the GeneratePress repair hub.

When every color change needs a cache ritual

GeneratePress did nothing wrong in most of these cases. It stores CSS sensibly and rebuilds it when told. The trouble is the number of independent layers between a setting and a visitor, each with its own idea of freshness. On a lean blog that is a small tax. On a site where marketing edits pages daily, it becomes a weekly support call, and CSS changes not showing becomes a bookmark.

A Next.js build compiles styles at build time and gives every stylesheet a new name when its contents change, so a deploy cannot serve last week's CSS. It costs more up front and needs a developer for layout changes. GeneratePress vs Next.js lays out the trade honestly, and migrating from GeneratePress to Next.js shows what the move involves. More fixes for other problems sit in the troubleshooting section.