Enterprise FSE Publishing Platform
WORDPRESS · FSE PLATFORM
Organisations need editors to publish complex pages fast, but unrestricted blocks, copied layouts and theme-owned business logic produce defects and slow reviews. This platform separates durable content rules from presentation so the editorial surface stays governed instead of rigid or chaotic.
- Maintainer
- Pixy Puala
- Vertical
- Enterprise publishing · Editorial CMS
- Year
- 2026
- Role
- Open source
- Stack
- WordPress block theme
- Status
- ● Public repo
- Verified
- Source on GitHub
Problem
When business logic lives inside a theme, a redesign becomes a data migration and every editor gets either a locked-down template or an unbounded block canvas. Both produce defects: copied layouts drift, capability checks get skipped, and editor output stops matching the frontend. The fix is architectural — durable content rules and capability enforcement belong in a plugin that survives the theme.
Constraints
Decisions
Plugin owns the rules, theme owns the look
Content model, capability matrix and migrations sit in the site-core plugin. The block theme carries theme.json, templates and patterns only. Swapping the theme cannot lose data or drop a permission check.
Capability checks are server-authoritative
The editor UI hides what a role cannot do, but the server decides. The capability matrix is unit-tested so a privilege boundary cannot regress silently behind a hidden button.
Migrations are a versioned, idempotent ledger
Schema changes run through a recorded migration ledger rather than ad-hoc upgrade routines, so a half-finished deploy can be re-run safely instead of leaving the database in an unknown state.
Build
Stack
- ▸ WordPress block theme · theme.json · patterns
- ▸ Site-core plugin · PHP 8.2+ · PSR-4 · Composer
- ▸ Server-rendered dynamic block · Interactivity API
- ▸ TypeScript · React editor UI · wp-scripts
- ▸ Schema.org JSON-LD renderer (XSS-hardened)
- ▸ Privacy export / erase shapers
- ▸ PHPUnit · PHPStan · PHPCS/WPCS · ESLint
- ▸ WordPress Playground blueprint
Tooling
- ✓ kept Composer · wp-env · Playground blueprint · GitHub Actions
Results · Measured
Evidence is committed alongside the code: docs/audit/BASELINE-AUDIT.md, THREAT-MODEL.md, FINAL-AUDIT.md and RELEASE-EVIDENCE.md. No production traffic figures are claimed — this is a reference implementation, not a launched client site.
Tradeoffs
One dynamic block (program-list) is shipped and Interactivity-API tested; tabs, accordions and stats blocks are specified but not built. Playwright editorial journeys and a full WCAG 2.2 AA audit are documented as the next milestone, not claimed as done. The optional AI seam is present but disabled by default and guarded — it is a boundary, not a feature.