Guide 00 · Developer docs

Core dna for site builders

Read this guide first. Core dna is hosted, so there is nothing to install; your repository holds only templates and front-end assets; and a new kind of page starts in the admin, with a layout. In half a day, from what the platform is to a page you built, deployed and rendered in Smarty or Twig.

L0
Unit 04 · From URL to rendered page

Hostname to site, prefix to abstraction

From URL to rendered page Page 21 of 28 Updated

The path from a URL to your HTML and its first steps: the hostname picks the environment, site and client, and the start of the path picks the API, the admin or the public site, where the page cache is checked before any template runs. Where to look when a hostname reaches the wrong site.

Who this is for. Theme developers, and anyone working out why a request reached the wrong site or the wrong part of one. This unit follows a request from its hostname to the rendered HTML, at the depth a site builder needs. The point to take away from it: the template is chosen by the record's layout, not by a route you write, which is why a template file on its own does nothing.

The journey in one picture

GET https://www.example.com/news/my-first-article

1  hostname     www.example.com        ->  environment  ->  site  ->  client and its database
2  path prefix  /news/...              ->  not a file, not /cdna-api, not /cdna-admin  ->  public site
3  page cache   a cached copy?         ->  if so, it is sent now and nothing below runs
4  module       no module prefix matches /news  ->  Pages
5  controller   Pages "show page"      ->  finds the page at news/my-first-article
6  layout       the page's live revision uses "Article"
7  template     pages/pages/article.html renders, with the platform's variables

This page covers steps 1 to 3. Module route to controller covers 4 and 5, The layout chooses the template covers 6 and 7, and the last two pages of the unit cover what a template receives and how to inspect it.

1. Hostname to site

The platform looks the request's hostname up among the hostnames it has registered. Each hostname belongs to exactly one environment, each environment to one site, and each site to one client, whose database serves the rest of the request. The site's folder of files, its settings and its content all follow from that one lookup.

A hostname the platform does not know is answered with HTTP 421 and a page headed Host name not configured: "The requested host name does not match any sites."

On Core dna's development servers, a hostname such as examplecom-<developer>.au.coredna.dev is read as the site's examplecom.coredna.site hostname before the lookup. That is how a developer's copy is matched to the right site.

When a hostname reaches the wrong site, or none

  • Check which environment the hostname belongs to: under System › Sites › Environments, the list shows each environment's primary hostname and its edit form shows all of them. The screen is visible to Super admin and Developer users only.
  • A 421 means the hostname is not registered at all. Hostnames are registered for the whole platform, and one cannot belong to two sites, so adding or moving one is a request to Core dna.
  • On a development hostname, everything before -<developer>.au.coredna.dev must be the first part of the site's .coredna.site hostname.

2. The start of the path picks the abstraction

Once the site is known, the path decides which side of the platform answers, checked in this order:

  1. A path that matches an allowed file in the site's folder, such as /dist/app.css, is sent as that file, before anything else.
  2. A path starting /cdna-api goes to the API.
  3. A path starting /cdna-admin goes to the backend, the admin.
  4. Everything else is the frontend, the public site.

The MCP server at /cdna-mcp is a separate service on the same hostname, which calls the site's API on your behalf. The URL surfaces of a site shows a request to each.

3. The page cache comes first

On the public site, the page cache is checked before any of the site's code runs. If it holds a copy of the page, that copy is sent as it is: no controller, no layout, no template. Two consequences follow:

  • Whatever a template prints is the same for every visitor who receives the cached copy. Something that depends on who is looking has to come from the browser, or be kept out of the cache: The caching tiers explains how.
  • A development environment caches no pages, so a template that looks right there can still behave differently on production, where the cache is on.
Go deeper
GuideThe caching tiers GuideSeveral hostnames on one site, or several sites GuideThe URL surfaces of a site FAQA page shows on dev but 404s on production

Was this page helpful?

Your answer goes to the docs team.