Reference: how it all works
The guides tell you where to click. This page tells you what the machinery is actually doing, system by system, and how the systems fit together. Nothing here is required reading; all of it is true.
The request pipeline
Every address on a Snazy site is a query: ?page=slug (the home page is ?page=home). When a request arrives:
- Snazy looks the slug up in your Pages first. A published Page renders through the Layout pipeline below.
- An unpublished Page renders only for signed-in admins (that's the preview); visitors fall through.
- If no Page claims the slug, built-in routes (sign-in, forum, account) get their chance.
- Anything else lands on the 404 page.
Because Pages are checked first, you can take over almost any address on your site just by publishing a Page with that slug.
The content model
Six kinds of thing, each with one job:
- Template: the field schema, what a kind of content is made of. References nothing.
- Content entry: one filled-in instance of a Template. References its Template.
- Block: picks content and renders it. References a Template and a source.
- Layout: the skeleton, named regions in a responsive grid. References nothing.
- Page: a URL. References a Layout and one Block per slot.
- Theme: the look, tokens plus styling plus advanced CSS. References nothing.
The references only point one way. Content never knows what pages show it; blocks never know what pages hold them. That one-way flow is why you can reuse everything everywhere without anything breaking.
How a page renders
The Page names a Layout; the Layout defines slots; the Page's slot assignments name a Block per slot. Each Block resolves its source:
- A single entry: always this one entry, by slug.
- The current page's entry: the entry whose slug matches the page's slug. This is what the Static layout uses, and why a page named
aboutfinds the entry namedabout. - A list: the newest entries of a template, with a limit.
- A datasource: a named feed, such as every published entry of one template, rendered as a set of cards through that template's own schema.
Lists and datasources serve published entries only. Single-entry sources honor your admin preview, so a draft page showing a draft entry previews fine.
Signals, precisely
Signals is a publish/subscribe wire protocol between blocks, visible in one place: the I/O bus in Admin.
- The bus is a rack of numbered jacks. A block field's Send names an input jack; a Receive listens on an output jack.
- Flow requires a cord patched between an input jack and an output jack. No cord, no delivery. This is deliberate: you can silence any interaction by unpatching one cord, and you can always see the whole wiring at a glance.
- Events that can send: a value change, a click, a key press (held keys repeat), a mouse button, and one element touching another (contact).
- Verbs a receive can run: set text, set an attribute, toggle a class (add, remove, pulse, or flash with an auto-timeout), count with min/max/reset, track and latch positions, nudge an element, show or hide by match, navigate, submit a form.
- Matching: a receive can limit itself to specific payload values, and list-rendered blocks can match per item (each card reacts only to its own slug). The wheel demo's cards work exactly this way.
- Guards: a receive can require the page to be in a state ("only if this selector matches") before its verb runs. All guards are checked before any verb fires, so multi-listener steps behave atomically.
Everything from a one-cord toggle to a playable arcade game is built from nothing but these pieces; Signals walks you in gently.
Themes and rendering hooks
A theme is tokens plus an advanced CSS layer. Tokens cover the wired-up basics (core colors, type, spacing); the Style editor writes targeted rules for everything else by letting you click the element you mean.
For hand-written CSS, the markup gives you stable hooks:
- Every block wrapper carries
phpew-section--<block-slug>. - Every rendered entry carries
phpew-content--<entry-slug>. - The page body carries
phpew-page--<page-slug>.
So "this exact block, on this exact page" is always one selector away, and your rules survive content edits because slugs are stable.
Drafts and publishing, exactly
- An unpublished Page: 404 for visitors, full preview for admins.
- An unpublished entry: skipped by lists and datasources, hidden from visitors everywhere, visible in your previews through single-entry sources.
- Nothing cascades on publish: publishing a page doesn't publish its entries, and vice versa. Each thing flips when you flip it.
The AI connector, underneath
The connector exposes the same machinery through MCP tools: reading tools (site overview, listing and fetching pages, blocks, content, templates, themes) and writing tools (saving content and blocks, patching the theme, patching cords on the I/O bus). There is one universal endpoint, connect.snazy.com/mcp; you authenticate with your account, pick a site, and the issued token is scoped to that site: the server routes each call to the site the token names, so one connection can never reach another. Access is granted per assistant by an administrator, revocable from your account’s Connected apps page or the site’s own admin, and everything it writes is ordinary content: the same drafts, the same blocks, the same wiring you’d author by hand. There is no second, hidden way into your site.
Portability
Everything above round-trips as a content bundle: templates, blocks, layouts, entries, pages, themes, and the Signals wiring that the exported blocks use. Your site's authored state is data, and it travels.
Back to all docs.