Page Builder
At a glance
A drag-and-drop page builder lets editors compose CmsPages from typed content blocks — text, gallery, calendar, news, contact form, dynamic widgets — with reusable templates, a draft/review/publish workflow, future-date scheduling and SEO-friendly URLs, all rendered server-side by Next.js with ISR for sub-minute publish-to-visible latency. Reusable block components let federations propagate footer or call-to-action edits across dozens of pages with one save.
How it works
Every page in the CMS is a CmsPage document containing an ordered array of typed blocks. Each block has a discriminated type (`hero`, `text`, `image`, `gallery`, `video`, `map`, `embed`, `form`, `columns`, plus the dynamic data blocks from F18.11) and a JSON config that the renderer maps to a React component. The admin page builder presents these as draggable cards in a left-rail palette; editors drop them onto a stacked canvas, reorder by drag, and edit inline.
Page templates jump-start common layouts — homepage, about, contact page, competition landing, news listing — by hydrating a fresh CmsPage with a curated block sequence that the editor can then mutate. URLs are derived from a slug field (validated for SEO friendliness — lowercase, hyphenated, no stop-words enforced) and combined with the page's parent path to form `/<parent>/<slug>`. The publish workflow uses a state machine: draft → review → published, with optional schedule_at timestamps that the publisher job picks up every minute and flips to published when due.
Versioning snapshots the entire block array on every publish, so editors can diff or roll back. Reusable block components — typically headers, footers, sponsor strips and call-to-action banners — are stored as standalone CmsBlock documents and referenced by id from any page; editing the source block updates every page that includes it. The Next.js renderer revalidates each page on a 60-second ISR window, so a publish is visible within a minute without a full rebuild.
Key capabilities
- Drag-and-drop block-based composition
- Static blocks (text, image, gallery, video, map, embed, form, columns) and dynamic data blocks
- Page template library for common archetypes (homepage, about, contact, competition, news)
- SEO-friendly URL slugs with parent-path inheritance
- Draft/review/publish state machine with versioned snapshots
- Future-date scheduling with per-minute publisher job
- Reusable block components shared across pages
In practice
Marc, the federation's communication officer, opens the CMS to publish a tournament recap. He clicks 'New page', picks the news-article template, and the canvas loads with hero, lede paragraph, gallery and related-events blocks pre-arranged. He drags the gallery up under the hero, drops in twelve photos from the media library, and the auto-WebP variants generate in the background.
He picks the reusable 'Federation footer' block — already used on 40 pages — so any future change propagates everywhere. He saves as draft, sends to his colleague for review, then schedules publish for Sunday 18:00 when the awards ceremony ends. Sunday evening the publisher job flips the state, ISR revalidates, and the page goes live exactly on time.
Features in this subsystem
8| ID | Status | Features |
|---|---|---|
| F18.02.01 | Shipped | Drag-and-drop page builder with content blocks ✅ PL-F1802a |
| F18.02.02 | Shipped | Block types: text, image, gallery, video, map, embed, form, columns ✅ PL-F1802a |
| F18.02.03 | Shipped | Dynamic data blocks: ranking table, results, calendar, club directory, venue map ✅ PL-F1802a |
| F18.02.04 | Shipped | Page templates library (homepage, about, contact, competition, news) ✅ PL-F1802a |
| F18.02.05 | Shipped | Custom page creation with SEO-friendly URLs — PL-F1802b ✅ PL-F1802b |
| F18.02.06 | Shipped | Page versioning and draft/publish workflow — PL-F1802b ✅ PL-F1802b |
| F18.02.07 | Shipped | Page scheduling (publish at future date) — PL-F1802b ✅ PL-F1802b |
| F18.02.08 | Shipped | Reusable block components (header, footer, sidebar) — PL-F1802b ✅ PL-F1802b |
Stakeholders who need this subsystem
Surfaces in 1 stakeholder analyses