The template editor.
Templates are written in the admin, in a browser editor backed by the same Liquid engine that renders your site. This page covers the fields on a template record, the server-side validation that checks your syntax before you save, and the manifest the editor is built on.
The template record
A template is a database row, not a file. These are the fields you set in the editor:
| Field | What it is |
|---|---|
title | The template's name, and how other templates address it. {% partial 'header' %} resolves by title in either mode; native {% include 'header' %} does so in Standard mode. |
permalink | The path the template answers. A template with permalink about serves /about; an exact permalink match is the first thing the renderer looks for. |
type | A numeric classification. For a layout template it maps a content type to the page that wraps it, so a product post renders through the :product template. |
label | A free-text grouping used to organise and filter templates in the editor's file tree and search. |
identifier | A stable handle for the template. Layouts are referenced by identifier rather than permalink, so a page names its wrapper through this field. |
body | The Liquid and HTML source. Everything the reference documents is written here. |
Templates compose: one template can pull another in by title, and a post is wrapped by a layout chosen from its type. Templates covers composition in full.
Validating before you save
The editor checks your Liquid on the server, against the real engine, so the errors you see are the ones the renderer would hit. Send the template body to POST /api/v1/templates/validate. It takes a JSON body with one field, body, holding the template source, and requires a signed-in user with an editor-level role on the site (membership role above 2); other callers get a 403.
The check is parse-only: it never renders the source, so side-effecting tags such as {% fetch %}, {% prefetch %} and {% collection %} never fire during validation. A clean body returns an empty error list:
{
"state": "ok",
"data": { "ok": true, "errors": [] }
}When parsing fails, ok is false and errors holds a single entry shaped { message, line }, where line is the 1-based line the parser points at, or null when it cannot locate one. The parser stops at the first syntax error, so at most one problem comes back per call: fix it, validate again, and repeat until the list is empty. An empty or whitespace-only body is treated as valid.
The runtime manifest
The editor does not keep its own copy of which tags, filters and objects exist. It reads them from a public, read-only endpoint, GET /api/v1/runtime/manifest. The manifest is generated from the live engine's own registrations, so it cannot drift from what the renderer and the validator actually accept.
It lists the registered tags and filters, the FleekSite-specific customTags, the collectionSources the {% collection %} tag understands, and the contextVariables available at the root of every render. The editor drives its autocomplete and its problem list from exactly these arrays.
If you are building tooling of your own, fetch the manifest rather than hard-coding the tag and filter names. It is public, site-independent and cached, so one request gives you the authoritative list. The runtime manifest reference documents every key.
Saving and going live
Saving writes the row. There is no build and nothing to deploy. The change is live within about a minute: FleekSite holds a template body in a short-lived cache for up to sixty seconds, with a similar cache in front of rendered pages, so a fresh save can take that long to appear on the site. Reload after a minute and you will see the new output.