Developing a build

Your space runs, but it still looks like the example it was cloned from. Turning it into your site means two things: deciding what your content actually is, and building the templates that present it. The platform already handles data, logins, compilation and the editing experience — the build is the one part that’s hand-crafted, and it’s where a developer comes in.

You don’t necessarily need to hire someone: if you’re comfortable with HTML and a little PHP, you can do it yourself. Either way, this page is the map of what the work involves and where to read more.

First, plan your content

Before any template is written, it helps to know what kind of content your site holds. CTXR uses Schema.org types, so you’re not inventing a structure from scratch — you’re picking from an existing vocabulary. A walking-route site, for example, might use Place for locations, TouristTrip for routes, Review for visitor reviews, and WebPage for overview pages.

Two questions shape the plan:

  • Is it a page or a block? A page gets its own web address and a full template (a Place at /fikkie). A block has no address — it only appears inside other content, like a review card on a place page. The same type can be both, depending on context.
  • How does it connect? Some content curates other content (an overview page listing places); some content relates to other content (a review pointing at a place). These references are what the platform resolves into a ready-to-serve graph.

You don’t declare any of this in advance — the platform stores whatever properties you save. But sketching your types, deciding what’s a page versus a block, and noting how they connect gives a developer everything they need to start. The full treatment is in Nodes and types and Nodes & Relations.

If your content connects to an outside system, plan your identifiers early — giving a node an external id makes it findable by that id from day one. See Nodes and types.

Then, build the templates

A developer works in one folder — build/ — and nowhere else. They don’t need editor access to your space; they need access to the files (via Git, SSH or however you deploy). There’s no framework to learn: templates are PHP files that receive a ready-made $data array and produce HTML, with helper functions for reading values, marking elements editable, and embedding blocks. Someone comfortable with HTML and basic PHP can build a complete site in a day.

A typical cycle looks like this: build a template per page type, build the reusable blocks (cards, snippets), add navigation, style it with CSS in build/assets/, then log in as an editor and check that editing, image upload and list reordering all work. Once templates are in place, editors can create and publish immediately — the editing layer switches on automatically through the helper functions.

Point your developer at these, in order:

  • Foundations — why the platform works the way it does, so the rest makes sense.
  • The build folder — a walkthrough that builds a complete page template from scratch.
  • Template helpers — the functions templates use to read data and turn elements editable.
  • The editing experience — how the draft/live workflow appears to editors, for free.

When you need exact signatures and lists, the Reference section has the template helpers, the API actions, and the editor attributes laid out concretely.

That’s the quick start

Account, space, build — that’s the path from nothing to a live, editable site. From here, the Development journey goes deeper on everything above.