Die Template-Engine und die Design-Kette #

Diese Seite richtet sich an Ingenieure, die verstehen müssen, wie eine Seite gerendert wird, wie ein Template gewählt wird und was dabei schiefgehen kann. Die Template-Sprache ist die eigene von Exponential; sie ist weder Twig noch Smarty, auch wenn ihre Syntax mit geschweiften Klammern ähnlich aussieht. Die maßgeblichen Regeln stehen in Kernel-Architektur.

Inhalt #

1. Die Engine
2. Datenzugriff aus Templates
3. Die Design-Kette
4. Overrides
5. Caching innerhalb von Templates
6. Fehlersuche beim Rendern
7. Prüfregeln

Die Engine #

eZTemplate (lib/eztemplate/classes/eztemplate.php) kompiliert .tpl-Dateien zu PHP und führt die kompilierten Dateien aus (mitgeliefert site.ini [TemplateSettings] TemplateCompile=enabled). Operatoren (|wash, ezurl, i18n) und Funktionen ({def}, {foreach}, {include}, {cache-block}) sind PHP-Klassen, die in eztemplateautoload.php- Dateien als Einträge von $eZTemplateOperatorArray und $eZTemplateFunctionArray registriert sind. Die Engine lädt sie aus [TemplateSettings] AutoloadPathList[] und aus den in ExtensionAutoloadPath[] aufgeführten Erweiterungen.

Die Sprachreferenz steht in der Hilfe: Template-Sprache und Template-Operatoren.

Datenzugriff aus Templates #

Templates fragen die Datenbank nicht ab: Die Sprache hat kein SQL-Konstrukt. Daten kommen aus:

• den Variablen der View, die die Modul-View vor dem Rendern setzt;
• Fetch-Funktionen: fetch( 'content', 'list', hash( ... ) ), zugeordnet in kernel/<module>/function_definition.php und von eZFunctionHandler ausgeführt. Ein Fetch, der Inhalte zurückgibt, wendet die Berechtigungen des Benutzers an;
• Template-Operatoren, die PHP sind und alles tun können; sie werden daher wie Views geprüft.

Die Design-Kette #

Ein Design ist ein Verzeichnis mit Templates, Stylesheets und Bildern. Designs werden gestapelt, sodass eine Website nur enthält, was sich von der Basis unterscheidet: site.ini [DesignSettings] SiteDesign, AdditionalSiteDesignList[] und StandardDesign (standard). Erweiterungen fügen Design-Verzeichnisse über design.ini [ExtensionSettings] DesignExtensions[] hinzu. eZTemplateDesignResource baut die Kette: zuerst die Design-Verzeichnisse der Erweiterungen, dann design/<design>/.

Overrides #

Blöcke in override.ini wählen für eine View ein anderes Template, wenn Bedingungen passen: Source, MatchFile, Subdir und Match[...] (zum Beispiel der Klassenbezeichner oder der Knoten). Seit Juli 2026 werden Overrides nach Priority geordnet, niedrigere zuerst (Reihenfolge der Template-Overrides). Die Administrationsseite Design > Templates schreibt nur settings/siteaccess/<sa>/override.ini.append.php.

Eine Website oder Erweiterung überschreibt ein Kernel-Template über override.ini oder ihr eigenes Design-Verzeichnis; sie darf keine Dateien in design/standard/ oder design/admin*/ ändern.

Caching innerhalb von Templates #

Siehe Cache-Invalidierung und Leeren.

Fehlersuche beim Rendern #

• Kommentare mit Template-Pfaden umschließen jedes gerenderte Template mit HTML-Kommentaren, die seine Datei nennen (Kommentare mit Template-Pfaden).
• Die Debug-Leiste listet die Templates, die eine Seite verwendet (Die Exp-Debug-Leiste).
• ./console exp:eztemplatecheck (bin/php/eztemplatecheck.php) prüft Templates auf Syntaxfehler.

Prüfregeln #

• Jede Variable aus Inhalten oder Eingaben wird mit |wash ausgegeben oder über einen Operator, der maskiert.
• Ein Operator, der HTML in PHP baut, maskiert es dort.
• Kein SQL in Templates, und kein rohes Datenbank-Handle wird an eines übergeben.
• In den Administrationsdesigns: kein <style>-Block und kein style=""-Attribut und kein Inline-Skriptcode; das prüfen Tests in tests/tests/design/ (Gestaltung der Administration).
• Skripte, die inline bleiben müssen, tragen die Nonce der Content Security Policy: <script nonce="{csp_nonce()}">.

Verwandte Seiten #

• Templates und Design
• View-Ergebnisse und das Pagelayout
• Die Design-Kette
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.