Get the MOST

Nachdem zwischen den Jahren der komplette Unterbau von Zikula 3 auf Stand gebracht worden ist, hat sich der nächste Sprint dem Übersetzungssystem gewidmet. In diesem Beitrag wird kurz dargestellt, welche neuen Funktionen eingebracht worden sind:

• Es gibt eine verbesserte Unterstützung für Regionen und Sprachvarianten (z. B. de_DE und de_CH neben de).
• Die automatische Erkennung zusätzlich vorhandener Sprachpakete wurde verbessert.
• Die Konfiguration für die Übersetzung von Modulen und Themes wird automatisch auf Stand gehalten.
• Mit der Funktion “Edit in Place” können Übersetzungen direkt auf einer Seite via Mausklick bearbeitet und gespeichert werden.
• Eine direkt im System verfügbare Weboberfläche erlaubt das Anlegen, Bearbeiten und Entfernen von Übersetzungen für das Kernsystem sowie vorhandene Module und Themes.
• Auch für Entwickler gibt es neue Vorteile: viele Dinge werden nun automatisch übersetzt, wie etwa Labels, Auswahloptionen und Hilfetexte für Formularfelder, Flash-Nachrichten oder Labels und Linktitel für Einträge in Knp-Menüs. Es muß kein Translator-Objekt mehr injiziert und verwendet werden. Auch beim Extrahieren der Übersetzungskataloge werden diese Nachrichten automatisch mit übernommen.

Im Rahmen des letzten Sprints wurde der Unterbau von Zikula 3 auf den neuesten technischen Stand gebracht. Im Folgenden wird kurz zusammengefasst, was hierbei genau passiert ist.

Twig 3

Als erstes sollte die Template-Engine Twig auf die Version 3 gebracht werden. Dies versprach anfangs eine sehr übersichtliche Sache zu werden. Allerdings gab es dann doch noch einige weitere Aspekte zu beachten:

• Da die templating-Komponente in Symfony 5 entfernt wird, müssen Pfade zu Templates nun der Namespace-Notation folgen. Aus z. B. Bundle:Controller:Action.html.twig wird damit @Bundle/Controller/Action.html.twig.
• Bedingungen in Schleifen sollten zur neuen filter-Syntax umgeschrieben werden.
• Die früheren Twig Extensions werden durch neue Twig Core Extra Extensions abgelöst.

Alle wichtigen Änderungen haben wir in einem Dokument zusammengefasst.

Zwischen den Jahren konnte ich etwas Zeit erübrigen und in den ModuleStudio Generator investieren, um eine größere Umstellung durchzuführen: bei Anwendungen für Zikula 1.4.x wird nun Twig an Stelle von Smarty verwendet. Anwendungen für 1.3.x verwenden weiter Smarty wie bisher.

Im Wesentlichen lief die Umstellung ziemlich geradlinig, da die meisten Konzepte aus Smarty analog auch mit Twig implementiert werden können.

Eine Besonderheit betrifft die Behandlung von Assets, also CSS-, JS- und Bilddateien: statt direkt die Asset-Komponente von Symfony zu verwenden, wird in Zikula eine darauf aufbauende zasset-Funktion eingesetzt, welche einige Besonderheiten des Zikula-Frameworks beachtet. Außerdem werden CSS- und JS-Dateien auf Grund der Modularität von Zikula-Systemen nicht einfach in einem Twig-Block eingebunden, sondern nach wie vor über PageVars zentral registriert. Beides zusammen sieht dann in etwa so aus:

Mit dem Multisites-Modul lassen sich beliebig viele Seiten mit einem einzigen Zikula-System betreiben. Mit Vorlagen, die im Prinzip SQL-Dumps repräsentieren, können neue Seiten auf Knopfdruck erstellt werden. Jede Seitenvorlage beinhaltet damit die vorab definierten Strukturen und -daten out of the box.

Jede Internetseite verfügt (aus Gründen der Architektur und der Skalierbarkeit) über eine eigene Datenbank. Es ist auch möglich, dass mehrere Internetseiten mit der gleichen Datenbank arbeiten. Dies erfordert jedoch entsprechende Anpassungen in den verwendeten Themes.

Im Gegensatz zu älteren Versionen empfangen Controller-Aktionen ab Zikula 1.3.x keine Argumente mehr. Bei der Umstellung bestehender Module kann man darüber stolpern, zum Beispiel wenn Controller-Funktionen mit dem modfunc-Plugin in Smarty-Templates eingebettet wurden.

Worum geht es?

Früher wurde in Zikula nicht unterschieden zwischen Controller-Aktionen und API-Methoden. Beides konnte beliebig aufgerufen und integriert werden, sowohl in PHP als auch in Smarty-Templates. Seitdem Symfony unter der Haube die Behandlung von Requests steuert, erfolgt hier eine striktere Trennung: während API-Methoden immer noch mit Argumenten aufgerufen werden, werden bei Controller-Aufrufen ausschließlich die Request-Parameter injiziert. Dies folgt der Konvention, dass ein Controller immer eine Response für einen gegebenen Request zurückliefern sollte.