The WP Rig team is thrilled to announce WP Rig v3.5.0 — the largest release since v3.0. This is the release where the framework’s three-paradigm foundation becomes real: design tokens reach version 2, the Site Editor gets a full bake-and-sync round-trip, classic themes get a true-classic guarantee, and WP 7.1’s theme.json v3 and Icon API are supported natively. Here is everything that landed.
Design token system v2 (SPEC-017)
config/tokens.json is now layered — primitives → semantic light/dark → component — with a JSON Schema for editor autocomplete. Dark mode is generated from semantic.*.dark, fixing the long-standing gap where token colors never flipped in dark schemes. Config-driven theme.designTokens.colorBinding (independent vs wp-preset) is paradigm-aware: classic themes never emit --wp--preset-- references. New commands: rig:tokens:setup (v1→v2 upgrade with backups), rig:tokens:import / rig:tokens:export for W3C DTCG / Figma round-trips. Tailwind remains fully optional — nothing is added unless theme.designTokens.emit.tailwind is enabled. A WCAG contrast gate (currently at warn) audits your palette as you work.
npm run rig:tokens:setupSite Editor bake & sync (rig:bake)
Site Editor work — custom templates, template parts, patterns, Global Styles, Font Library fonts — lives in the database, not in git. v3.5.0 ships rig:bake, a Node port of bacoords/wp-theme-control, that moves that work into your theme’s files so it can be diffed, reviewed, and committed. Every write is recorded in a manifest with sha256 checksums; cleanup deletes only records whose files still match. Runtime URLs in baked patterns are patternized to patterns/hidden-*.php. Paradigm-gated to universal and block-based themes — classic gets a graceful refusal.
git status # must be clean — a bake is reviewed as a diff
npm run rig:bake:plan # read-only inventory + collisions
npm run rig:bake # writes files; does NOT clean the DB
npm run lint:patterns && npm run lint:blocks
git add -p && git commit # review the diff
npm run rig:bake:clean -- .wp-theme-control/runs/<run>/manifest.tsvThe true-classic guarantee
Choosing classic during rig-init now enforces itself. A stale config.local.json override no longer silently wins the merge chain — init strips theme.themeType and theme.enableBlocks on every run so your interactive choice is authoritative. Selecting classic also moves leftover templates/ and parts/ FSE artifacts into a timestamped .rig-backup/ folder (never deleted) — a stray templates/index.html made WordPress core detect a block theme and surface the Site Editor regardless of config. theme.json is intentionally kept: it is hybrid-legitimate and never triggers the Site Editor.
Navigation that looks right out of the box
The starter template no longer ships a bare <!-- wp:navigation /--> — the markup that caused WordPress to lazily create an unstyled fallback nav post. The starter now ships inline wp:home-link + wp:page-list inner blocks with a styled baseline in _blocks-based.css, so the default state renders like real navigation immediately. A new opt-in npm run seed:navigation seeds an editable wprig-primary-nav post for Site Editor workflows.
npm run seed:navigationWordPress 7.1 alignment
- theme.json v3: added
settings.viewport(mobile 480px / tablet 782px), explicitsettings.blockVisibility, and token-derived layout sizes. Pseudo-state styling (hover/focus/active) is enabled. - Viewport-driven breakpoints: all 7
@custom-mediaaliases derive fromsettings.viewport— one breakpoint scale for every paradigm, and the editor preview and frontend finally agree. - Block Visibility alignment: the responsive nav shares the same scale as core’s
wp-block-hidden-*classes — hamburger hides at 481px, nav collapses at 782px. Guidance documented to avoid double-toggling. - Native Icon API: every SVG in
assets/icons/registers withwp_register_icon()in every paradigm — classic included. Incompatible icons are skipped with a log note instead of registering blank.
The paradigm foundation
The single-source-of-truth paradigm system ships complete: config/paradigms.json, JS/PHP helpers, generic component gating via Paradigm_Component_Trait and PARADIGM constants, and fail-fast validation with jest + PHPUnit coverage. Block features are strictly gated out of the classic core. Changing your theme type is a one-line config edit — every gate follows automatically.
Block-based CSS surface & pattern registry
A new assets/css/src/_blocks-based.css (gated to universal/block-based) ships a starter baseline for FSE core blocks: Navigation desktop + mobile-toggle alignment, theme part spacing, and Query Loop defaults — it never loads in classic themes. The new inc/Block_Patterns component provides config-seeded, filterable pattern categories and registers installed components’ bundled patterns. Companion tooling: rig:pattern scaffolding with i18n-aware headers and a lint:patterns validator now part of ai:check.
Framework vs theme version separation
WP Rig’s own version now lives in config/framework.json and is stripped by childify — a built theme never carries it. The theme version lives in config and is stamped into style.css and readme.txt at bundle time, fixing a leak where the framework version could reach production themes.
npm run rig version:framework 3.5.0 # bump framework version
npm run rig version 1.0.0 # bump theme version
npm run rig version # print bothUser-styles overlay (SPEC-016)
Baked Global Styles and font activations land in git-tracked config/user-styles.json — not theme.json. The token pipeline merges the overlay last (deep-merge objects, arrays replace wholesale, custom font definitions win on duplicate slugs); SSOT keys never merge. rig:tokens regeneration is deterministic after a bake, and the PHP runtime is overlay-blind with a PHPUnit parity guard.
Upgrading
Update your WP Rig checkout and re-run init:
npm run rig-initComing from token-system v1? Run rig:tokens:setup — it upgrades config/tokens.json to the layered v2 format with a collapse-aware legacy-name codemod and backups. Full release notes are in the changelog.
Thanks
This release was driven by @robruiz with the WP Rig maintainer team. Found a bug? Open an issue on GitHub — and if WP Rig saves you time, consider sponsoring the project.