How rendering works.

From request to HTML

Five steps turn a request into a response:

1. Resolve the site and its mode. The request host, its domain, cname or one of its alternate domains, identifies which site is being asked for, and the site's render mode is read at the same time.
2. Find the template. An exact permalink match wins. Failing that, a post whose path matches is rendered through the layout template for its type.
3. Build the context. FleekSite assembles the variables your template can read, site, page, env, bits and the rest, from the database and the request.
4. Render the Liquid, tolerantly. The body is parsed and rendered against that context. Rendering is forgiving by design, as the next section explains.
5. Inject meta and serve. SEO and social meta are written into the head, and the page is served with a short-lived cache in front of it.

That is the outline. The render pipeline walks every step in order, with the exact resolution priorities, the meta it injects, and how caching and purging behave.

Tolerant rendering

Step four is deliberately forgiving. The renderer's aim is to always return a readable page, never a server error or a blank screen, so a small mistake in a template degrades quietly instead of failing loudly. Three behaviours make that concrete:

• An undefined variable renders as nothing. Reading a name that was never set produces an empty string, not an error, and the rest of the template renders around it. A typo like {{ site.naem }} simply leaves a blank.
• An unknown filter passes the value through. Applying a filter that is not registered emits the input unchanged rather than raising, so a mistyped filter name degrades to a no-op.
• One broken tag never takes down the whole page. A tag that cannot be parsed, or that throws while rendering, does not crash the response. FleekSite serves the page rather than a server error; how the broken tag itself appears depends on the render mode, covered below.

A blank where you expected text is the everyday sign that a variable name is wrong, which is why the objects reference is worth keeping to hand.

Where render mode fits

Render mode changes one thing at this stage: what happens to a tag the engine cannot parse. Both modes still serve the page.

• Standard leaves the unparsed source in place and logs it, so the mistake is visible on the page and points you straight at it.
• Compat strips the unknown tag out before rendering, so it disappears silently and leaves an empty space instead.

New sites render in standard. Everything else about the pipeline, host resolution, template lookup, context building and caching, is identical in both modes. Render modes is the full account of what each mode changes and why.