Best Practice: Arbeiten mit Zikula 1.3.0 und Modulestudio

Eingereicht von demoadmin am 21. Nov 2011 - 15:19 Uhr

Für ein aktuelles Kundenprojekt haben Axel [1] und ich [2] uns entschieden, Zikula 1.3 zu benutzen und mit Modulestudio ein neues Modul zu entwickeln. Der Kunde betreibt eine Sportmodel-Agentur [3]. Wer also jemanden für Film oder Fotos braucht, der eine Sportart beherrscht, kann sich bei ihm melden. Unsere Aufgabe war es, einen Teil seines Kataloges online zu bringen. Da es dafür kein passendes Modul gibt, haben wir selbst etwas entwickelt. Ich wollte hier mal einige der Erfahrungen aus diesem Prozess weitergeben.

Der Kunde hatte bereits eine Homepage, die auch recht chic war. Sie war nur leider gar nicht darauf eingestellt, dass jemand wirklich mit der Seite arbeitet. Er konnte seine Firma präsentieren und einen kleinen Ausschnitt aus seinem Modelkatalog zeigen. Dahinter stand aber nicht einmal ein CMS, das man leicht hätte erweitern können. Selbst für ein einfaches Kontaktformular mit Bildupload musste man selbst programmieren.

Es sollte also eine neue Lösung her, mit der er einen wesentlich größeren Teil seines Kataloges abbilden kann. Die Homepage bekommt dann die Funktion einer Applikation mit der die Kunden der Agentur Models recherchieren können. Wir mussten also eine Lösung finden, mit der ein paar hundert Models vernünftigt kategorisiert durchsuchbar werden. Ein Design- und Bedienvorschlag kam von stoehrmann.com [4], der auch für den Rest des Corporate Designs verantwortlich ist. Er wusste also, worauf es ankommt. Nach einigen Telefonaten hatten wir die meisten Frage zu dem Design geklärt .

Axel und ich haben dann überlegt, wie wir die Umsetzung machen. Auf jeden Fall wollten wir ein spezielles Modul und nicht die Funktionalität eines anderen Moduls umbiegen. Mit Modulestudio spielen ein paar Felder mehr oder weniger ohnehin keine Rolle. Wir hatten uns für Zikula 1.3 entschieden, weil das Release eigentlich schon länger draußen sein sollte. Nun gibt es mittlerweile zumindest ein Feature Freeze. Es wäre aber ungünstig gewesen noch für die 1.2er-Struktur ein neues Kundenmodul zu beginnen. Axel hatte auch mit der Umstellung der Generatoren in Modulestudio begonnen.

Modulestudio

Modulestudio [5] verändert die Arbeit radikal - weg vom Programmieren hin zum Konzeptionieren. Statt vorher haarklein zu klären, welche Felder es wie geben soll und wie genau was funktionieren soll, hat Axel einfach ein Modul modelliert und generiert nach den ersten Vorgaben. Mit der Zeit haben wir das dann weiterentwickelt. Ich habe die Templates angepasst und im Theme gelagert. Und immer, wenn ich auf ein Problem gestoßen bin, hat Axel das Modell geändert und mir eine neue Version geschickt. Durch die Templates ging nie eigenes Arbeit verloren, wir konnte einfach immer die neue Model-Schicht unter unseren View schieben.

Zwar sind die Module, die aus Modulestudio fallen so programmiert, dass Basisklassen immer durch eigene überschrieben werden können. Faktisch musste ich keine Zeile Code ändern. Alle speziellen Funktionen konnte ich in Plugins auslagern und auch so vor Änderungen im Modul sicher im Theme lagern.

Es hat sich aber auch gezeigt, dass Modulestudio eine Menge Funktionen aus dem neuen Zikula Core nutzbar macht und dass das dazu verleitet, die auch alle tatsächlich zu nutzen. Die Versionierung von Tabellen sind nur ein Häkchen in der Modellierung. Da haben wir unsgedacht: Das ist doch für die Models genau das richtige - wenn man sich dann mal verklickt, kann man den alten Stand einfach wiederherstellen. Das Problem: Das geht natürlich auf Kosten der Performance. Und bei hunderten von Models in der Übersicht, ging das gar nicht mehr. Also raus damit. Wir sind letztlich mit vielen Dingen gestartet, die dann nach und nach wieder rausfolgen - weil man sie nicht braucht, oder weil sie einen zu kleinen Gewinn gegenüber dem Performance-Vorteil bieten.

Damit will ich nicht sagen, dass die nie Sinn ergeben! Nur in unserem Szenario hat man wenig davon. Selbst wenn man aus versehen das falsche Model löscht, hat der Kunde die Daten ohnehin noch und kann die in Minuten wiederherstellen.

Der Arbeitsablauf mit dem Modulestudio war also viel offener und dynamischer als die klassische Modulentwicklung. Und Axel hat in seiner Arbeit am Modulestudio auch davon profitiert, weil er die Ergebnisse gleich testen konnte. Dabei sind viele, tolle Funktionen entstanden. Freut euch auf die nächste Version des Modulestudios…

Module

Neben dem eigenen Kartei-Modul kommen Pages, Formicula und Scribite zum Einsatz. Scribite und Pages sind kaum verändert. Einige Regeln für das Stylist-Plugin in Scribite sind da schon fast alles. Formicula musste ich natürlich für die beiden Formulare komplett anpassen. Die Durchnummerierung der Zusatzfelder stößt da ein wenig an seine Grenzen. Bei 5-6 Feldern ist das okay. Ich hab in dem Formular 32 davon gehabt und dann sollte ich doch noch Straße und Hausnummer trennen. Manuell musste ich dann alle folgenden 30 Felder umbenennen.

Ein Problem gab es zu Anfang mit den Uploads in dem Bewerbungsformular. Axel gab mir aber den entscheidenen Tipp: Das Form-Tag brauch einen bestimmten Enctype. Ich hab das im Handbuch inzwischen dokumentiert. Das mit den Uploads funktioniert hervorragend.

Performance

Die Website lief bei all-inkl.com zu Anfang auf einem Privat-Paket. Da reichte aber schon der Webspace nicht für die ganzen Fotos. Der Wechsel auf den Business-Tarif hat dann einiges auch an Performance gebracht. Allerdings hat es nicht gereicht einfach nur Server-Power auf die Seite zu schmeißen. Die Optimierungen liegen im Detail.

Das Modul an sich ist keine Raketentechnik: Eine Liste von Models mit X Feldern. Dazu eine Tabelle mit den Sportarten. Zu Anfang waren auch noch Tabellen für die Fotos und die Wohnorte der Models vorgesehen. Die Standorte sind dann aber aus praktischen Gründen rausgeflogen, die Fotos wegen der Performance. Außerdem war der Kunde viel mehr Arbeit gewöhnt: Auf seiner alten Seite musste er alle Bilder korrekt zurecht schneiden: Für die Übersicht, die Listenansicht und die Großansicht. Jetzt muss er nur noch per FTP die Bilder halbwegs im richtigen Format und nicht allzu groß auf den Server laden und richtig benennen.

Die Bilder werden vom Thumbnails-Modul zugeschnitten und verkleinert. Das Modul achtet selbst darauf, dass es vorhandene Thumbnails nur neu erzeugt, wenn das Originalbild geändert wurde. Sind die Bilder also alle einmal in jeder Größe aufgerufen worden, werden die nur noch direkt von der Festplatte gezogen.

Um in den langen Listen nicht den Effekt zu haben, dass die Bilder per Zufall mal hier mal da erscheinen, habe ich das JavaScript Lazierload [6] eingebaut. Das Script schaltet automatisch alle Bild-URLs, die außerhalb des sichtbaren Bereichs liegen, auf ein Dummybild. Erst wenn der Benutzer nach unten scrollt, werden nach und nach die URLs richtig geschaltet und die Bilder geladen. Das geht so schnell, dass man das nur sehen kann, wenn man bei einer langen Liste ganz schnell ans Ende scrollt. Und selbst dann kommen die Bilder flott nach.

Bei mehreren hundert Einträgen in einer HTML-Liste zählt jede HTML-Verschaltung und jedes Tag, das man sparen kann. Nachdem ich eine funktionsfähige Umsetzung des Designs fertigstellt hatte, musste ich noch einmal einige Zeit damit verbringen, das mit möglichst wenig Tags hinzubekommen.

Einen kleinen Performance Effekt bekommt man, wenn man in der config.php ausschaltet, dass die alten pnRender-Tags und Plugins beachtet werden. Dann muss man allerdings in allen Templates auf die neue Syntax umstellen. Das war nur bei den Zusatzmodulen nötig. Es reicht, die Klammer zu suchen und zu ersetzen und die Vorsilbe pn zu suchen und durch nichts zu ersetzen. Nur das JavaScript in Scribite braucht dann Nacharbeit. In Formicula und Pages ging es automatisch. Soweit ich gesehen habe, liegen in den Repositories von Pages und Scribite schon Versionen mit der neuen Syntax. Bei Formicula habe ich nicht geguckt.

Es lässt sich nicht verhindern, dass die längeren Listen auch länger dauern. Wir haben hier keine einfache News-Seite mit 10 Einträgen pro Seite. Jeder Benutzer hat Verständnis dafür, dass so eine Applikation etwas länger benötigt. Er muss nur wissen, dass es länger dauert und dass nichts schief gelaufen ist. Deswegen haben wir uns dafür entschieden, die Seite per Modalbox [7] beim Aufruf der Kartei auszublenden und den Ladevorgang anzuzeigen.

Richtig Speed hat aber nur das Caching gebracht. Seiten, die bereits einmal aufgerufen wurden, liegen als fertige HTML Seiten im Cache und werden ohne Verarbeitung einfach geschickt. Das ist dann fast so schnell wie statisches HTML. Wie ihr wisst, ist Caching allerdings immer schon auch schwierig gewesen. Ich hab zum Beispiel das Render-Caching ausgeschaltet und halte nur den Theme-Cache vor. Sonst schmeißt das System nicht-reproduzierbar Fehler, weil angeblich irgendwelche Funktionen fehlen. Außerdem sind alle Module, bis auf die Kartei von Caching ausgenommen. Für die anderen Module müssen wir jetzt nach und nach schauen, ob das Caching funktioniert und wenn nein, woran das liegt. Bei Pages werden zum Beispiel keine Editlinks angezeigt und Änderungen werde nicht angezeigt. Das Modul sorgt also nicht dafür, dass der Cache gelöscht wird…

Tricks

Auf der Startseite seht ihr eine Pages-Seite und darunter einen Menüblock mit den drei Buttons. Das heißt, dass die Buttons sehr leicht umzubelegen sind. Für Admins erscheint da ein Edit-Link und darüber kann man einfach die Beschriftung und den Link ändern. Der Kunde will damit gelegentlich auf bestimmte Aktionen verlinken statt auf die allgemeinen "Anfragen". Natürlich ist es durch das spezielle Design nicht einfach möglich weitere oder weniger Buttons anzuzeigen.

Bei den Referenzen seht ihr ein Template, das ich mit SimpleTemplates angelegt habe. Darin wird eine bestimmte Pages-Seite per API aufgerufen und 2 Blocks geladen. Sowohl die Liste mit den Kunden als auch die Liste mit den Agenturen sind ebenfalls einfache Menüblöcke. Dadurch kennt der Kunde bereits die Bedienung und kann leicht weitere Referenzen hinzufügen oder alte entfernen.

Auch die Hauptnavigation ist ein normaler Menüblock. Allerdings musste ich da im Template ein wenig tricksen, damit der Hintergrund bei aktiven Links auch aktiv bleibt, wenn man zum Beispiel in der Kartei herumklickt.

Seht ihr die Referenzseite für den Dachverband der Tischler und Schreiner [8]? Das ist ein Youtube-Video! Man kann es einfach mit dem normalen Embed-Code in Zikula 1.3 verwenden! Der neue HTML-Filter ist wesentlich schlauer und entfernt solche Sachen nicht mehr automatisch. Auch mit Vimeo [9] geht das zum Beispiel.

Fazit

Zikula ist immer noch ein tolles System. Mit der neuen Modulstruktur lässt sich noch professioneller arbeiten. Ich denke, es wird immer weniger Sinn ergeben, Module komplett von Hand zu schreiben. bei den vielen Verzeichnissen und Dateien, die man anlegen muss, ist das auch immer weniger möglich. Das Modulestudio ist da unersetzlich. Gerade beim Übergang von 1.2 zu 1.3 hat sich auch die Stärke modellgetriebener Entwicklung gezeigt: Das Modell für das Modul ist für beide Zikula-Versionen das gleiche. Der Generator im Modulstudio wirft dann neuen Code aus. Wenn jetzt 1.4 noch einmal größere Veränderungen bringt, kann man das neu generierte Modul einfach unter die eigenen Templates schieben.

Wenn ihr Fragen habt, freue ich mich darauf, die zu beantworten.

Neuen Kommentar hinzufügen
Links
  1. http://demo.zikula.de/https://guite.de/
  2. http://kaffeeringe.de/
  3. http://freistilmodels.de
  4. http://stoehrmann.com/
  5. http://modulestudio.de/
  6. http://www.appelsiini.net/projects/lazyload/
  7. http://okonet.ru/projects/modalbox/
  8. http://freistilmodels.de/index.php?module=seiten&func=display&pageid=18&reference=1
  9. http://freistilmodels.de/index.php?module=seiten&func=display&pageid=11