Wer lange genug mit gewachsenem PHP-Code gearbeitet hat, kennt diese Dateien auswendig. Oben ein Datenbankabfrage, darunter ein paar Berechnungen, dann irgendwo ein echo "<table>", und zwischendrin ein if-Block, der entscheidet, ob eine Zeile rot oder grün wird. Alles in einer Datei. Alles vermischt. Das System läuft – aber niemand will es anfassen.

Warum das ein echtes Problem ist

Solche Dateien sind nicht nur unschön, sie sind ein Wartungsproblem. Wer die Datenbanklogik ändern will, kämpft durch HTML. Wer das Layout anpassen will, stolpert über SQL-Queries. Und Tests schreiben? Vergiss es – du kannst die Logik nicht isolieren, ohne das ganze HTML mit in den Test zu ziehen. Dazu kommt: Wenn ein Projektbeteiligter ohne PHP-Kenntnisse eine Vorlage anpassen soll, hat er keine Chance. Er kann den Code nicht lesen, ohne Dinge zu zerstören, die er gar nicht sehen sollte.

Twig installieren

Twig lässt sich mit Composer in wenigen Sekunden hinzufügen. Wer noch kein Composer im Projekt hat, sollte das als erstes nachholen – das ist ohnehin ein sinnvoller Schritt für sich. 

composer require twig/twig

Danach braucht man einen zentralen Einstiegspunkt für Twig – eine kleine Hilfsfunktion oder Klasse, die den Loader und die Environment konfiguriert. Das muss nicht perfekt sein, es muss nur funktionieren.

Schrittweise Migration: eine Seite nach der anderen

Der wichtigste Grundsatz bei dieser Arbeit: nicht alles auf einmal umbauen. Ich fange immer mit einer Seite an, die wenig Logik hat und oft aufgerufen wird – zum Beispiel eine einfache Übersichtsseite. Die Logik bleibt in der PHP-Datei, aber das HTML wandert in ein Twig-Template. Die alte PHP-Datei bleibt parallel bestehen und wird erst entfernt, wenn die neue Variante stabil läuft.

Vorher – alles in einer PHP-Datei: 

<?php
$result = $pdo->query("SELECT * FROM kunden WHERE aktiv = 1");
$anzahl = $result->rowCount();
echo "<h1>Aktive Kunden: " . $anzahl . "</h1>";
echo "<ul>";
foreach ($result as $row) {
    echo "<li>" . htmlspecialchars($row['name']) . "</li>";
}
echo "</ul>";

Nachher – Logik und Darstellung getrennt: 

<?php
// kunden.php – nur Logik
$result = $pdo->query("SELECT * FROM kunden WHERE aktiv = 1");
$kunden = $result->fetchAll();
echo $twig->render('kunden.html.twig', [
    'kunden' => $kunden,
    'anzahl' => count($kunden),
]);
{# kunden.html.twig – nur Darstellung #}
<h1>Aktive Kunden: {{ anzahl }}</h1>
<ul>
  {% for kunde in kunden %}
    <li>{{ kunde.name }}</li>
  {% endfor %}
</ul>

Was Twig erzwingt – und warum das gut ist

Twig-Templates können keine Datenbankabfragen machen. Das ist kein Bug, das ist das Feature. Wer ein Twig-Template schreibt, kann nur das darstellen, was ihm übergeben wird. Das zwingt dazu, die Daten vorher aufzubereiten – und genau das macht den Code testbar. Die Logik lässt sich testen, ohne einen Browser zu brauchen. Das Template lässt sich anschauen, ohne PHP verstehen zu müssen.

Twig macht die Trennung von Logik und Darstellung nicht einfacher – es macht sie zwingend. Das ist der Unterschied zwischen einer Konvention und einer Struktur.

Fazit

Die Migration zu Twig ist kein großes Projekt. Es ist eine Reihe kleiner Schritte, von denen jeder einzelne das System ein bisschen wartbarer macht. Anfangen mit einer Seite, die alte Datei parallel stehen lassen, und erst nach dem nächsten Deployment entscheiden, ob man weitermacht. Meistens will man dann weitermachen.