Skip to main content

Regenerating the site

Sometimes a single publish isn't enough — settings change, the theme switches, a plugin gets enabled. The Themes → Regenerate site menu rebuilds whatever is needed without you having to click Publish on every post.

Where to find it

ThemesRegenerate site dropdown (top right of the page).

The dropdown shows several targets:

TargetWhat it does
All HTML pagesRe-renders every published post + page + home + every category archive
Home page onlyRe-renders just /index.html
Theme assetsRe-uploads theme-assets/<id>.css + -menu.js + -posts.js for every loaded theme (alias for the Sync theme assets button)
Sitemaps (when flexweg-sitemaps is enabled)Re-uploads stylesheets + every yearly sitemap + index + News + robots.txt
RSS feeds (when flexweg-rss is enabled)Re-uploads every enabled feed + the XSL stylesheet
Search (when flexweg-search is enabled)Re-uploads /search.js + /search-index.json
Archives (when flexweg-archives is enabled)Wipes /archives/ + rebuilds every period page + index
Favicon manifest (when flexweg-favicon has icons uploaded)Re-uploads site.webmanifest
(any third-party plugin's regeneration target)Per the plugin
EverythingRuns every target above, in priority order

When to use which

After editing a post

You don't need to. Publishing the post itself triggers the cascade automatically (home + listings + sitemaps + RSS + search + archives all update via lifecycle hooks).

After changing site settings (title, baseUrl, language)

All HTML pages. Settings appear on every page (titles, og:url, lang attribute), so all pages need a fresh render.

After enabling / disabling a plugin that contributes head or body markup

All HTML pages. Without this, already-rendered pages keep the old plugin output until they're re-rendered.

After switching themes

Everything — the new theme has different templates, different CSS, different blocks. Theme assets must be uploaded too. See Theme switch flow for details.

After updating the admin

Theme assets + All HTML pages if the new admin version changed templates. Often the admin update notes mention which targets to run.

After editing a category slug

All HTML pages — every post in that category has its URL change, plus every other category archive that mentioned it. The publisher handles single-post slug changes automatically; bulk slug edits aren't a real workflow but if you do one manually in Firestore, regenerate everything.

How long does it take?

Roughly:

Site sizeAll HTMLEverything
50 posts5-15 s30-60 s
500 posts1-3 min3-5 min
5 000 posts10-15 min20-30 min

The throttle is 75 ms between uploads (hardcoded in regenerateAll). At 1 upload per 75 ms, 5 000 posts plus listings plus plugin outputs is ~7-10 minutes.

The admin tab needs to stay open during the regeneration. Switch tabs, but don't close the browser.

Progress + resumability

The Regenerate dropdown shows a progress bar with per-file status. Errors are listed at the end with the failed paths.

A failed regeneration doesn't roll back successful uploads. So if the network drops at file 1 200 of 5 000, files 1 201-5 000 are unchanged and files 1-1 200 reflect the new state. Re-running All HTML pages picks up where the previous run left off (every file is re-rendered against the same source, so re-running is idempotent).

Hash optimisation

regenerateAll hashes every rendered HTML and skips uploads where hash === lastPublishedHash. So if 4 800 of 5 000 posts didn't actually change (e.g. a settings tweak only affected 200 pages), only 200 uploads happen.

The hash includes:

  • The full HTML (after sentinel replacement, post-plugin-filters)
  • Implicit: anything that affects the HTML — settings, plugin configs, theme code, the post's content

So changes that don't affect rendered output (e.g. updating a seo.description field that the active theme doesn't use) skip the upload. This is the main reason a "Everything" pass on a stable site can complete in seconds even on large sites.

Why "Everything" exists

For times when you're not sure what changed and want to be safe. It's idempotent — running it multiple times produces the same result. Slower for large sites but never breaks anything.

If unsure, Everything is always the right answer. The hash optimisation means you're not paying full price.

Continue