Step 3: Use the theme's own CSS

A block theme's look lives in its global styles: the stylesheet WordPress computes from theme.json, block styles and the site's customisations. Flx reuses it instead of re-creating it.

How it flows

1. The plugin publishes the computed CSS at /wp-json/flx-modernize/v1/global-styles?v=<hash> and the theme's @font-face CSS at /wp-json/flx-modernize/v1/theme-assets/fonts?v=<hash>. The hash changes whenever the styles change, so URLs are safe to cache.
2. Each payload carries those two links (global_styles, theme_assets.fonts), not the CSS itself.
3. The renderer fetches them (src/lib/globalStyles.ts: 2-second timeout, 24-hour cache per URL, failures retried after 30 seconds) and inlines them right after its own stylesheet (src/lib/layout.ts).

On Twenty Twenty-Five this is about 175 KB of CSS per page, which is exactly what makes the theme's markup look native.

The trap: your CDN may block the renderer

The renderer fetches the CSS from a cloud server. Cloudflare's Bot Fight Mode answered every such request with a challenge page (HTTP 403, cf-mitigated: challenge). The renderer logged flx_render_css_asset: fetch failed … unexpected status 403 and rendered without the theme CSS: a plain, unstyled page.

To diagnose it, request the CSS URL from a cloud machine (a GitHub Actions runner works) rather than from your own server, which the CDN may trust. Then fix it in the CDN: turn off bot challenges for the site, or skip them for /wp-json/flx-modernize/v1/.

Check: a rendered page contains a <style> block of roughly the size of the global-styles endpoint's response. On Twenty Twenty-Five that's 175,073 bytes: 174,571 of global styles plus 502 of font faces.