StaticForge 1.3.0

Version 1.3.0 — archived release. Installable zip attached (code from the wordpress.org tag).

StaticForge 1.2.1

Version 1.2.1 — archived release. Installable zip attached (code from the wordpress.org tag).

StaticForge 1.2.0

Version 1.2.0 — archived release. Installable zip attached (code from the wordpress.org tag).

StaticForge 1.1.1

Version 1.1.1 — archived release. Installable zip attached (code from the wordpress.org tag).

StaticForge 1.1.0

Version 1.1.0 — archived release. Installable zip attached (code from the wordpress.org tag).

1.7.0 — Translation-ready + smarter URL rewriting

Two things in this release: the plugin is now translation-ready, and the URL rewriter catches more of your in-post links.

Translation-ready

The admin UI, the Setup Guide, and the contextual Help tabs are wrapped in WordPress i18n functions against the staticforge-for-cloudflare-pages text domain, with a languages/staticforge-for-cloudflare-pages.pot template (314 strings) shipped in the plugin. Translations can be contributed at translate.wordpress.org. Activity-log messages stay in English on purpose so they still match the troubleshooting reference. Nothing changes for English installs.

More in-post links get rewritten

The rewriter used to match only your site's exact home URL, so a link an editor had pasted as http:// when the site is https://, or with a stray www. (or missing one), or as a protocol-relative //your-site/..., kept pointing at the WordPress origin instead of the Public Site URL. Those near-miss spellings of your own host are now folded onto the canonical form before the rewrite, so they get swapped along with everything else.

• Only your origin's own host and its www/non-www counterpart are touched — third-party links are left alone.
• /wp-content/ assets still follow the bundle / keep-on-origin rules as before.
• New SFORGE_Renderer::normalize_origin_aliases().

Run one Full Rebuild + Deploy after updating so every page picks up the change.

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

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/

1.5.0 — Extra paths to include

Adds a way to ship files and folders the crawler never sees in the rendered HTML.

A new Export Scope → Extra paths to include setting lets you bundle assets that don't show up as URLs on any page — a plugin's icon font (Elementor's Font Awesome at wp-content/plugins/elementor/assets/lib/font-awesome, say), a webfont directory, a downloadable PDF. List them one path per line, relative to your WordPress root, and the plugin copies them straight off local disk into the deploy.

• A whole folder is pulled in recursively, a single file is copied as-is, and a trailing wildcard (wp-content/uploads/2025/*.pdf) is expanded.
• Bundled files under /wp-content/ get their URLs pointed at the live host so the deployed page loads the bundled copy, while the rest of /wp-content/ stays on origin exactly as before.
• Because the files are read locally, there's no origin firewall in the way.
• Paths are confined to the WordPress root — anything escaping it via .. or a symlink is skipped and logged — and each rebuild is capped at 5,000 files / 200 MB.

New setting extra_paths, new class SFORGE_Extra_Assets. Optional; nothing changes unless you set it.

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

1.4.1 — Plugin Check fixes

Housekeeping release. No functional change — 1.4.0 is where the partial-rebuild work landed.

Running the official WordPress Plugin Check against 1.4.0 surfaced one error and three warnings, all introduced by that release.

• Fixed a phpcs suppression that named a sniff which does not exist (directory_rmdir instead of file_system_operations_rmdir). phpcs silently ignores suppressions for unknown sniffs, so the comment looked correct and did nothing.
• Annotated two read-only $_GET reads in the post-list Rebuild notice. The state change behind the redirect was already nonce-verified; the notice only renders text.
• Shortened the 1.4.0 upgrade notice, which was 1189 characters against a 300-character limit.

Plugin Check now reports 0 errors, 0 warnings.

1.4.0 — Partial rebuilds

Editing a post used to re-render the entire site. Each page costs one HTTP round-trip to the origin and they run one after another, so a 1,400-page site paid 1,400 sequential fetches to fix a typo — the main reason large sites saw rebuilds measured in hours.

What changed

• Partial rebuilds. Only the pages an edit actually invalidates get re-rendered: the post, its term archives, its author archive, its post type archive, the homepage and posts page, plus their translations. Everything else is reused from the export cache.
• The export directory is now the deploy source. Rendered pages were always written to wp-content/uploads/sforge-export/, but the deploy was built from an in-memory copy and that directory was never read back. Making it the source of truth is what makes partial rebuilds possible — a Cloudflare Pages deployment is a whole-site snapshot, so the manifest must list every file even when only a few changed.
• Memory no longer scales with site size. Files are streamed from disk for hashing and read back only for assets Cloudflare reports as new. Measured on a 400 MB export: 489 MB peak before, 73 MB after.
• Stale pages are pruned, so deleting a post removes it from the live site. Pruning is scoped to HTML and refuses to run when a partial rebuild's URL list looks implausibly short.
• Two rebuild buttons (changed vs full) and a per-post Rebuild row action.
• Uploads already mirrored are no longer re-fetched every rebuild.
• A failed render now keeps the previously exported page instead of dropping it from the deploy.

Upgrade note

Run one Full Rebuild after updating to populate the export cache.

Asset hashing is unchanged, so assets already cached at Cloudflare stay cached across the upgrade.