Development
This is the developer’s reading path. Foundations explained why CTXR is shaped the way it is; this chapter is what you do with it — and it builds in the same direction, from meaning outward.
It opens with the part the whole platform reads but nobody hand-codes: the semantics of your schema. From there it moves to the data those semantics describe — a node on its own, then nodes wired to each other — and then to the engine that compiles, derives and cascades by reading all of it. Only once that’s in place does the chapter get hands-on: the build/ folder and the templates, styles and helpers you write there.
Where the hands-on work lives
The platform ships a complete, working space: defaults for everything, a sensible theme, a full editor. You don’t start from an empty directory — you start from something that already runs, and you extend it.
Your entire workbench is one folder: build/. It holds the PHP templates that turn nodes into HTML, the CSS that styles the public site, and the JavaScript that runs in the browser. Everything else — the compiler, the API, the editor chrome, the storage layer — is platform machinery you call into but never edit.
build/ ← your work lives here
pages/ blocks/ menus/ forms/ assets/
email/ i18n/ pwa/ ← optional overrides of platform defaults
(platform internals) ← you call these, never touch them
the compiler · the API · the editor · the registry
The boundary is the whole point. Code-pushes never touch live content; runtime edits never touch code. A lint-gate keeps that promise safe.
The chapters
| Page | What it covers |
|---|---|
| Use of semantics | What a property means — range, inverse, kind, cardinality; schema as hint, contract as law |
| Nodes & types | A node on its own: the Bare Four, Schema.org types, custom properties, the Thing fallback |
| Nodes & Relations | The three relation kinds, order and pagination, derived values, projection |
| The mechanical engine | The executor: how compile, derive and cascade read the semantics |
| The build folder | Your folder structure, the push/pull workflow, and the lint-gate boundary |
| Theming & assets | Free site CSS, fixed editor chrome, importmaps, the module grammar |
| Template helpers | The helper API — the only bridge between a template and editability (definitive list in Reference) |
| The editing experience | How your templates become editable — the three-layer contract |
| Automation & connectors | Operations, connectors, the wizard, webhooks |
| Internationalisation | One language per node, and the four-rung translation ladder |
| The API | One endpoint, two auth modes, JSON-LD output |
Read top to bottom for the full picture, or jump to the page that matches the problem in front of you.