© istockphoto.com/lanarepnikova, © istockphoto.com/ysunnie
Make PHP Template Rendering Great Again

Frisch serviert


Mit Plates steht für PHP ein vergleichsweise neues Paket zum Verarbeiten von Templates bereit. Es arbeitet mit nativen PHP-Templates und steht als performante Alternative zu den etablierten Templatesystemen bereit. Sie erfahren in diesem Artikel, wie Sie Plates installieren können, was es kann und wie Sie es in einige PHP-Frameworks integrieren können.

Das native PHP-Renderingsystem Plates [1] ist noch vergleichsweise jung: Plates wird seit 2013 unter Federführung von Jonathan Reinink entwickelt. Plates gehört der „League of Extraordinary Packages“ an [2], einem Zusammenschluss von Entwicklern, die moderne, stabile und gut ausgetestete Packages für PHP bereitstellen. Alle Pakete der „Liga“ richten sich nach den Standards der PHP Framework Interop Group (PHP-FIG) [3] und den Best Practices der Initiative „PHP: The Right Way“ [4]. Zudem können alle Pakete per Packagist [5] und Composer [6] installiert werden. In dieser Liga sind auch weitere interessante Komponenten vertreten, z. B.:

  • Csv – eine Bibliothek zum Verarbeiten von CSV-Dateien

  • Event – ein Tool zum Verarbeiten von Events in einer Applikation oder der Domänenschicht einer Anwendung

  • Glide – eine Library für die Bildmanipulation auf Anfrage, deren API per HTTP angesteuert werden kann

  • Omnipay – eine Bibliothek für die Zahlungsabwicklung verschiedener Gateways wie PayPal oder Wirecard

Doch genug des Namedroppings an dieser Stelle, wenden wir uns nun Plates zu. Anders als reine Template-Engines wie Twig [7] oder Smarty [8] verwendet Plates keine eigene Templatesprache oder Templatesyntax und arbeitet auch nicht mit vorkompilierten Templates. Die Templates werden in reinem PHP geschrieben – mit allen Vor- und Nachteilen, die dieser Ansatz mit sich bringt. Am ehesten ist Plates noch mit Zend\View vergleichbar [9], der Komponente zum Verarbeiten von Templates aus dem Zend Framework.

Warum native PHP-Templates?

Es gibt viele Gründe, eine „richtige“ Template-Engine wie Twig oder Smarty mit eigener Syntax zu verwenden:

  • Die templateorientierte Syntax macht es Webdesignern ohne tiefer gehende PHP-Kenntnisse leichter, die Templates einer Anwendung zu erstellen.

  • Die Syntax dieser Templatesprachen hat ihren Fokus auf der Ausgabe von Daten.

  • Durch Templatevererbungen wird die Wiederverwendbarkeit von Templates erhöht.

  • Durch den sogenannten Sandbox-Modus kann niemand in dem Template groben Unfug, wie das Manipulieren von Sessiondaten oder das Schreiben von Daten in eine Datenbank, treiben. Die Syntax erlaubt eben nur Kontrollstrukturen, die Ausgabe von Daten sowie vordefinierte Funktionen.

  • Durch automatisches Escaping der ausgegebenen Templatevariablen sind diese Templates weitestgehend vor XSS-Attacken („Cross-site Scripting“) gefeit.

Es gibt sicherlich noch weitere Vorteile, die die Liste ergänzen können. Erkauft werden diese Vorteile jedoch durch die Notwendigkeit, dass die geschriebenen Templates erst einmal kompiliert und somit in natives PHP übersetzt werden müssen. Das bedeutet auch trotz des Cachings der kompilierten Templates einen gewissen Overhead. Templatesysteme wie Plates oder Zend\View, die mit nativem PHP Templates bauen, bieten im Gegensatz dazu jedoch auch ihre Vorteile:

  • Die Entwickler können die Tem­plates in ihrer Sprache schreiben – also in PHP – und müssen keine zusätzliche Templatesprache lernen und anwenden.

  • Webdesigner ohne PHP-Kenntnisse können in der Regel auch auf die alternative PHP-Syntax für die Kontrollstrukturen geschult werden. Die Unterschiede sind da nicht so groß.

  • Das Kompilieren der Templates in natives PHP entfällt völlig.

  • Das Escaping der Templatevariablen kann durch eigene Methoden innerhalb der Templates erreicht werden.

Auch diese Liste der Vorteile ließe sich sicher noch erweitern. Das schlagende Argument für die „richtigen“ Template-Engines bleibt am Ende doch der fehlende Sandbox-Modus bei Templatesystemen mit nativen PHP-Templates. Da die Templates aus reinem PHP-Code bestehen, könnten bauernschlaue Entwickler direkt schreibend auf die Datenbank zugreifen, lustig Dateien erstellen, Verzeichnisse löschen oder anderen Schabernack treiben, der nichts in einem Template zu suchen hat.

Dennoch ist dieses Argument nur ein Scheinargument. Ja, das ist theoretisch möglich. Doch ein Team, das zulässt, dass es solche Templates in ein Repository oder gar auf den Produktionsserver schaffen, hat ein ganz anderes Problem. Nur eine Mischung aus unsauberen oder nicht definierten Codierrichtlinien, fehlender Code-Review, falschem Verständnis von Qualitätskontrolle und purem Leichtsinn sollte dazu führen, dass grober Codeunfug in Templates unentd...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang