Template-Engines in PHP: Übersicht

Die häufigste Kritik lautet: PHP ist selbst eine Template-Sprache, wozu also eine zweite? Das stimmt technisch und geht am Punkt vorbei. Der Nutzen einer Engine liegt nicht darin, mehr zu können, sondern weniger zu erlauben.

Was eine Engine tatsächlich bringt

Trennung durchsetzen. In einer .php-Datei kann jederzeit eine Datenbankabfrage stehen. In einem Template mit eigener Syntax ist das nicht möglich – die Engine kennt keine Datenbank. Das ist eine Einschränkung, und genau darin liegt der Wert.

Automatisches Escaping. Der praktisch wichtigste Punkt. In purem PHP muss jede Ausgabe einzeln durch htmlspecialchars, und ein vergessener Aufruf ist eine XSS-Lücke. Twig escapet standardmässig, ohne dass jemand daran denken muss.

Templates für Nicht-Entwickler. Eine Designerin kann ein Template mit Platzhaltern bearbeiten, ohne PHP zu verstehen. Bei TinyButStrong bleibt die Datei sogar valides HTML und lässt sich in einem visuellen Editor öffnen.

Vererbung und Bausteine. Ein Basistemplate mit definierten Blöcken, das die Einzelseiten überschreiben – das lässt sich in purem PHP nachbauen, aber selten so sauber.

Die drei Ansätze

Eigene Syntax. Smarty und Twig bringen eine eigene Sprache mit geschweiften Klammern mit:

{% for produkt in produkte %}
  <li>{{ produkt.name }} – {{ produkt.preis|number_format(2, ',', '.') }} €</li>
{% endfor %}

Ausdrucksstark, mit Filtern und Vererbung. Der Preis ist eine zweite Sprache, die jeder im Team lernen muss.

Platzhalter mit Blöcken. vlibTemplate arbeitet mit einfachen Platzhaltern und Kommentar-artigen Steuerelementen:

<!-- BEGIN produkte -->
  <li>{NAME} – {PREIS} €</li>
<!-- END produkte -->

Weniger mächtig, dafür in zehn Minuten erklärt. Logik ist bewusst nicht möglich, was die Trennung erzwingt.

Unverändertes HTML. TinyButStrong benutzt HTML-Kommentare und Attribute, sodass die Datei valides HTML bleibt:

<li>[produkte.name] – [produkte.preis] €</li>

Der Vorteil zeigt sich, wenn die Templates von jemandem gepflegt werden, der mit einem visuellen Editor arbeitet.

Entscheidungshilfe

Der letzte Fall wird oft übersehen. Für eine Handvoll Seiten ist das hier vollkommen ausreichend:

<ul>
<?php foreach ($produkte as $p): ?>
  <li><?= htmlspecialchars($p['name'], ENT_QUOTES, 'UTF-8') ?></li>
<?php endforeach; ?>
</ul>

Die alternative Syntax mit : und endforeach bleibt zwischen HTML lesbar. Was fehlt, ist das automatische Escaping – jeder <?= ohne htmlspecialchars ist ein potenzielles Loch.

Wenn du eine alte Engine übernimmst

Bestandsprojekte mit vlibTemplate, Smarty 2 oder TinyButStrong laufen häufig seit vielen Jahren. Vor jeder Migrationsentscheidung lohnt sich die nüchterne Prüfung:

1. Läuft die Engine auf der Ziel-PHP-Version? Das ist die einzige Frage, die eine Migration wirklich erzwingt. Alter Code mit ereg, each oder Konstruktoren im PHP-4-Stil bricht spätestens ab PHP 8.
2. Gibt es offene Sicherheitslücken? Besonders relevant bei Engines, die PHP-Code im Template zulassen.
3. Wie oft werden die Templates tatsächlich angefasst? Wer im Jahr drei Änderungen macht, gewinnt durch eine Migration nichts.

Ist die Antwort auf 1 und 2 unkritisch, ist die richtige Entscheidung fast immer: verstehen, dokumentieren, weiterlaufen lassen. Die ausführlichen Anleitungen zu den einzelnen Engines findest du in diesem Bereich – sie sind für genau diesen Fall geschrieben.