Bis zum heutigen Tag habe ich diese Seite mit dem Theme Tikva betrieben. Tikva war mein Einstieg in die Thematik der Erstellung von WordPress-Themes.
Als ich diese Site vor einigen Jahren von einer eigenen, Django- und somit Python-basierten Software auf WordPress migriert habe, habe ich ein schlichtes Theme gesucht, das auf der damals aktuellen Version 3 des Bootstrap CSS-Frameworks basiert. Mit Bootstrap hatte ich gute Erfahrungen gemacht, mit den Komponenten kannte ich mich insofern aus, darüber hinaus gefiel mir das schlichte Design.
Im Dschungel der WordPress-Themes
Das Theme sollte weitestgehend die Standard-Elemente von Bootstrap unterstützen, sich noch ein wenig anpassen lassen, etwa bei der Farbwahl, aber viel mehr benötigte ich wiederum nicht. Natürlich gab es bereits gefühlt Myriaden von WordPress-Themes, darunter fanden sich auch einige hervorragende, vielseitig anpassbare und noch dazu kostenlose Themes. Doch vielfach brachten diese Themes weitaus mehr Funktionen, als ich benötigte, was die Inbetriebnahme letztlich verkompliziert hätte. Zudem existieren zwar Unmengen kostenlose Themes, häufig gibt es jedoch eine „Pro“-Version, die dann nicht mehr kostenlos ist und noch dazu relativ prominent in der Admin-Oberfläche dafür wirbt. Das ist alles absolut verständlich und legitim, und während die einfachen, Bootstrap-basierenden Themes mir zu wenig Funktionalität angeboten haben, waren die Light-Versionen von „professionellen“ Varianten ebenfalls mitunter zu eingeschränkt.
Ein schlichtes WordPress-Theme: Tikva
Das führte insgesamt dazu, dass ich ein einfaches, auf Bootstrap 3 basierendes Theme entwickelt habe, es Tikva nannte und selbstverständlich im WordPress-Theme-Directory veröffentlichte. Mit der Zeit kamen auch weitere Funktionen hinzu, entweder für den Eigenbedarf oder auf Wunsch von Anwendern, falls dies realisierbar war. Tikva wird auch weiterhin gepflegt, d.h. für Hinweise, Fehlerberichte etc. bin ich nach wie vor dankbar und werde versuchen, etwaige Probleme zeitnah zu lösen.
Bootstrap-Rewrite und Folgen
Irgendwann stand Bootstrap in der neuen Version 4 vor der Tür, nach der langen alpha-Phase erfolgte schließlich die Freigabe der Release-Version. In der Zwischenzeit hatte ich Tikva für das Grav CMS adaptiert, und zwar bereits auf Basis von Bootstrap 4, wenngleich noch in einer alpha-Fassung. Insofern lag zunächst der Gedanke nahe, Tikva zu überarbeiten und mit der neuen Version von Bootstrap auszurüsten.
Doch mit der neuen Version sind auch einige Änderungen ins Bootstrap-Framework eingezogen. Letztlich war es weniger ein Update als ein Rewrite von Bootstrap, entsprechend umfangreich ist der Migrationsleitfaden. Neben der geänderten internen Struktur wurde auch das visuelle Erscheinungsbild wesentlich überarbeitet, so dass bei einem Update des Tikva-Themes sämtliche darauf basierende Sites ebenfalls anders ausgesehen hätten, was nicht unbedingt im Sinne der Website-Autoren gewesen wäre.
Nicht zuletzt war Tikva das erste WordPress-Theme, was ich entwickelt hatte, die Anfänge lagen mehr als vier Jahre zurück, so dass der Code an einigen Stellen auch inzwischen in die Jahre gekommen war. Darüber hinaus war durch das Hinzufügen neuer Features die Struktur der bei WordPress „Templates“ genannten PHP-Dateien, die jeweils Seitenabschnitte und deren Inhalte darstellen, nicht gerade übersichtlicher geworden.
Templates in WordPress vs. Templates in PHP-Frameworks
Noch dazu beinhalten jene „Templates“ sowohl HTML- als auch PHP-Code, evtl. noch ein wenig JavaScript, je nach Bedarf. WordPress bietet zwar ein „Backend“, nutzt aber für das „Frontend“ denselben Code, dieselben Funktionen, es ist keine klare Trennung zwischen Template, Controller und sonstigen Komponenten vorhanden, bzw. zumindest lässt WordPress es zu, dabei sehr frei zu agieren. Natürlich wollte ich WordPress nicht umschreiben, um eine Art von „Separation of Concerns“ (Trennung der Zuständigkeiten) zu erreichen, aber wenigstens auf der Ebene der Templates sollte Derartiges doch möglich sein. Von PHP-Frameworks wie Symfony oder Laravel, aber auch bereits zu Zeiten vor derartigen Entwicklungen war ich es gewohnt, dass HTML-Inhalte mittels einer Template-Engine gerendert werden. Zwar gibt es darüber (immer noch? immer wieder?) rege Diskussionen, weil PHP doch eigentlich bereits eine „in HTML eingebettete Skriptsprache“ – so die Definition zu Zeiten von PHP 3 – sei, aber aus meiner Sicht überwiegen klar die Vorteile von dedizierten Template-Engines wie z.B: Twig. Die Templates werden im Vergleich zu mit PHP-Code gespickten Dateien übersichtlicher, kürzer, damit leichter verständlich, darüber hinaus weniger mächtig als wenn der komplette PHP-Sprachumfang zur Verfügung steht, was ein Sicherheitsvorteil sein kann. Demgegenüber stehen Möglichkeiten wie Vererbung von Templates, die Nutzung von Makos, ein einfaches Filtern der Ausgabe usw..
Eine Template-Engine für WordPress?
Aus all diesen Gründen habe ich zunächst ein Experiment gestartet: Wie hoch wäre der Aufwand, und würde es überhaupt ohne größere Probleme funktionieren, die Template-Library Twig in einem WordPress-Theme einzusetzen? Composer war schnell angeworfen, Twig und notwendige Abhängigkeiten im vendor-Verzeichnis installiert. Mittels einer kleinen Wrapper-Klasse war die Einbindung in die bisherigen „Template“-Dateien auch schnell erledigt. Die ersten Umstellungen der „Templates“ verliefen ebenso recht vielversprechend. Insofern – grundsätzlich funktionierte es!
Da Twig einen Template-Cache vorsieht, war die Performance auf den ersten Blick ebenfalls in Ordnung. Damit waren die ersten Schritte erledigt, und die Hürden waren nicht allzu hoch. Ein gewisses Umdenken war jedoch notwendig – im Detail problematisch waren es vor allem die bei WordPress mitunter versteckten Ausgaben, d.h. eine Funktion wird aufgerufen, die sofort für eine Ausgabe sorgt, anstatt die Inhalte erstmal zu speichern und – zur Not als HTML – zurück zu geben. Insofern war in den ersten Experimenten noch viel Code fürs Output-Buffering vorhanden. Teilweise lässt sich das auch nicht vermeiden, an anderen Stellen konnte dieser Umweg inzwischen umgeschrieben werden.
Aus dem anfänglichen Experiment wurde somit ein völlig neues WordPress-Theme, was zudem auf Bootstrap 4 basiert. Genau dieses Theme, genannt Azbalac, kommt ab sofort auf diesem Blog zum Einsatz. Das Design ist ein wenig anders, auch sind noch nicht alle Unzulänglichkeiten behoben, das wird jedoch in der nächsten Zeit passieren. Noch ist Azbalac nicht im WordPress-Theme-Directory veröffentlicht, wer also daran Interesse haben sollte, möge mich einfach kontaktieren. Einzige Voraussetzung ist die Nutzung von PHP 7.0 oder höher, da Twig diese Version als Abhängigkeit besitzt.
Neben der Umstellung auf Bootstrap 4 und die Nutzung der Twig-Engine sind auch noch wenige neue Features und etliche Korrekturen in das neue Theme mit eingeflossen. Insofern kann es tatsächlich als neues Theme bezeichnet werden, und nicht als weitere Version von Tikva.
Fazit
Noch ist die Entwicklung nicht abgeschlossen, die Todo-Liste nicht vollständig abgearbeitet, aber bereits jetzt macht mir persönlich die Arbeit am Theme durch die Trennung von HTML- und PHP-Code in den Templates wesentlich mehr Spaß!
