Alle Objekte, die eine Vorlage bekommt

Der Kontext ist eine feste Liste. Ein Schlüssel, der hier fehlt, ist im Template still leer — und weil unbekannte Variablen nicht bemängelt werden, merkt man es erst am fehlenden Text.

Überall verfügbar: `restaurant`, `settings`, `brand`, `widget`, `analytics`, `page_title`, `page_meta`, `locale`, `locales`, `now`, `menus`, `menus_by_id`, `opening_hours_sets`, `opening_hours_sets_by_id`, `navigation_menus`, `navigation_menus_by_id`, `navigation_menus_by_handle`, `products`, `products_by_id` und `tt_vorschau`. Letzteres ist `true` in jeder sitzungsgebundenen Vorschau — im Theme-Studio wie hinter dem Knopf „Vorschau“ (`/preview/<id>`) — und `false` für signierte Aufrufer (Vorschaubild, Dashboard-Kachel) und die öffentliche Website. Code, der nur auf der veröffentlichten Website laufen darf, gehört in `{%- unless tt_vorschau -%} … {%- endunless -%}`; so hält es das Layout eines gespiegelten Themes mit den Skripten der Originalseite, die sonst unter der Herkunft der angemeldeten Sitzung liefen. Dieselbe Vorschau entschärft der Renderer auch am fertigen Dokument: geparkte Einbettungen werden durch einen sichtbaren Platzhalter ersetzt, Tracking wird weder geparkt noch nach Zustimmung geladen, und der Kopf trägt `<meta name="tt-vorschau" content="1">` — daran erkennt `assets/tt-consent.js` die Vorschau und schaltet nichts frei; gelesen wird dafür nur der `<head>`, ein gleichnamiges Meta im Rumpf zählt nicht. Der Zustimmungsbanner bleibt sichtbar und bedienbar.

Die Engine maskiert von sich aus nichts. Werte in Attributen und im `<title>` deshalb immer mit `| escape` ausgeben — `restaurant.name`, `page_meta.description`, `restaurant.description`, `restaurant.icon_url` und jede Einstellung —, Adressen mit `safe_url` (src, url()) beziehungsweise `safe_href` (Linkziele). So halten es das Basis-Layout, Kopf- und Fuss-Section des Basis-Themes und das Layout gespiegelter Themes; die html- und body-Attribute einer geklonten Originalseite kommen maskiert und ohne `data-tt-*` ins Layout. Einstellungswerte in `templates/*.json` werden beim Rendern als Liquid interpoliert — ein Vorgabewert mit Betriebsdaten trägt den Filter deshalb selbst (`{{ restaurant.name | escape }}`). Ein Theme, das `{% section 'cookie-banner' %}` selbst im Layout aufruft, bekommt die Zustimmungs-Laufzeit immer — auch ohne Tracking und in der Vorschau: der Renderer zählt, was `{% section %}` wirklich gerendert hat (auch in `{% render %}`-Teilstücken), nicht ob die Marke im Dokument vorkommt.

Nur im Layout dazu: `content_for_layout`, `sections` und `template` — der Name der Vorlage ohne `.json`, etwa `index` oder `password`; das Layout eines gespiegelten Themes wählt daran Rahmen und Body-Klassen je Seite.

Nur innerhalb eines Abschnitts dazu: `section` und `sections`.

Beim Rendern einer Asset-Datei mit der Endung `.liquid` steht NUR die allgemeine Liste bereit — kein `section`, kein `sections`, kein `content_for_layout`. Eine `theme.css.liquid` kommt also an die Theme-Einstellungen heran, nicht aber an einen einzelnen Abschnitt.

Diese Objekte gibt es hier NICHT, auch wenn andere Liquid-Welten sie kennen: `page`, `product`, `collection`, `cart`, `customer`, `shop`, `request`, `routes` und `linklists`; `template` kennt nur das Layout, in Abschnitten und Teilstücken bleibt es leer. Die Entsprechungen heissen `page_title` und `page_meta`, `products`, `navigation_menus` sowie `restaurant`.

Für die Buchung gibt es keine eigene Variable: Der Link zur Buchungsstrecke steht als `restaurant.booking_url`, die einzubettende Adresse als `widget.embed_url`.