1.6.0 — Self-hosted font bundling

Fixes self-hosted fonts getting blocked by CORS on the deployed site.

A @font-face font whose src still points at your WordPress host is a cross-origin request once the page is served from *.pages.dev. Browsers fetch fonts in CORS mode, your origin sends no Access-Control-Allow-Origin header, so the font is blocked and the page drops to a system typeface. This is the blocked by CORS policy error you see in the console for things like Astra's local Google Fonts.

• Self-hosted fonts are now bundled automatically. Each rendered page is scanned for .woff2 / .woff / .ttf / .otf / .eot files served from your own host. They're shipped inside the deploy and their URLs rewritten to your Public Site URL, so they load same-origin and the CORS error disappears. Covers theme webfonts, icon fonts, and Astra's local fonts at wp-content/astra-local-fonts/. Third-party fonts (Google Fonts on fonts.gstatic.com, etc.) already send CORS headers and are left untouched. On by default via the new Bundle self-hosted fonts setting; ignored when Rewrite /wp-content/ URLs is on, since that already rewrites fonts.
• Extra paths now accept a wp-content/-relative entry. If an entry isn't found at the WordPress root, the plugin looks under wp-content/ before giving up, so astra-local-fonts resolves the same as wp-content/astra-local-fonts. This removes the most common reason a bundled asset kept pointing at the old domain: the URL rewrite hinges on the wp-content/ prefix, and a bare path used to silently miss it.

After updating, run one Full Rebuild + Deploy so every page picks up the rewritten font URLs, not just the ones you've edited recently.

Also on wordpress.org: https://wordpress.org/plugins/staticforge-for-cloudflare-pages/