Entwicklung in Typo3 braucht vor allem ein Handling der Komplexität. Um diese in den Griff zu bekommen benutze ich ein Setting aus:

  • Typo3-Standard-Installation, UTF-8
  • Entwicklungsumgebung Aptana
  • Standard-Templates und Smarty-Templates
  • Dokumentation mit PHPDoc
  • Datensicherung mit SVN

Meine Erfahrungen mit Typo3-Entwicklung zeigen, dass die Komplexität der Softwareentwicklung nicht im Code selber liegt. Daher ist diese auch mit klassischen Software-Entwicklungsmethoden nur schwer in den Griff zu bekommen.

Die Komplexität liegt in: Verteilung von Einstellungen und Codes quer über das Typo3-System, Datenbank, TypoScript, Extensions, Files,… Da vieles von fremden Quellen übernommen wird, hat man auch selten den Gesamtüberblick über das System und sein Verhalten.

Ich stelle hier einen eher pragmatischen und praxisbezogenen Ansatz vor, der sich für kleine und mittelgroße Systeme eignet.

Typo3 Standard-Installation

Die Message ist hier: bleib bei der Standard-Installation. Man kann das System konfigurieren (und das ist manchmal komplizierter als umprogrammieren), aber bitte keine CORE-Files umprogrammieren, Programmierung gibts nur in Extensions. Das nächste Update kommt bestimmt und macht dann Probleme.

Um die immer wieder auftretenden Probleme mit Umlauten zu beheben läuft bei mir alles auf UTF-8: charset im HTML-Header, Datenbank auf UTF-8, force-utf8, alle Dateien auf UTF-8 (im Editor fest eingestellt), XML-Dateien sind sowieso auf UTF-8.

Bei Oliver Thiele gibts eine gute Anleitung zur UTF-8 Umstellung die auch bei Problemen hilft. Neuere Typo3-Systeme (ab 4.2) laufen standardmäßig auf UTF-8.

Templates und TypoScript

Ich verwende immer noch die ganz klassischen Hand-Made Templates – das ist keine Empfehlung, nur eine Vorliebe. Aber ich schreibe HTML-Files auch immer noch von Hand, das was mir ein Tool Arbeit spart stecke ich hinterher an Fehlersuche dreimal wieder rein.

Für ein Template hat man einige Dateien: HTML, CSS, JS Files. Dabei braucht es ein bißchen Erfahrung, wie man HTML Template-tauglich schreibt. Wichtig ist alle Elemente in eigenen Div’s zu legen, die dann automatisch erzeugt werden können. Und das Menü soll möglichst strukturiert aufgebaut sein, da das komplett automatisch erzeugt wird.

Als Meilenstein in einem größeren Projekt kann man das HTML-Template auch abnehmen lassen. Ich achte dabei auf 2 Dinge: ist der HTML-Code Typo3 Template tauglich, d.h. automatisierbar? Und: ist das HTML-Template mit allen vorgegebenen Browsern getestet, incl. Funktionalität und Fall-Back-Mechanismen (z.B. ohne JavaScript).

Gespeichert werden die Dateien immer nach dem gleichen Ordner-System unter fileadmin/templates/ – dann findet man auch nach 2 Jahren alles wieder:

Extension-Entwicklung

Extension-Entwicklung ist Software-Entwicklung. Ja echt! Auch wenn Chef nicht glaubt, dass die seit 30 Jahren bewährten Phasen von Design-Entwicklung-Test irgendwie eingehalten werden müssen. Oder die Entwickler, die schon immer mit Copy-Paste und einer main-Funktion von 1000 Zeilen ausgekommen sind. Auch wenn es nur eine kleine Extension ist und eine kleine Homepage. Es dauert am Anfang vielleicht 1-2 Tage sich ein vernünftiges System einzurichten, die sich dann einfach auszahlen.

Es braucht:

Eine PHP Entwicklungsumgebung wie Aptana (Open Source), Eclipse mit Aptana Plugin oder Zend Studio – wenn möglich im Team auf ein Tool einigen. Der Typo3-Editor hat weder Syntax-Highlighting noch Code-Unterstützung. Wer mal mit Visual Studio gearbeitet hat weiß was einem das Zeit und Nerven sparen kann.

Dokumentation: Vor jeder Funktion kommt ein kleiner phpDoc Block, der wird dann in der Entwicklungsumgebung auch gleich mit einem kleinen gelben Popup-Kommentar angezeigt. Das ist kein großer Aufwand und bringt enorm viel. Daraus kann auch auf Knopfdruck eine komplette Software-Dokumentation erzeugt werden. Und ich habe schon in einigen Projekten der Sorte “schnell und billig” gearbeitet, wo plötzlich doch eine Dokumentation zu erstellen war…

Ein phpDoc-Kommentar sieht so aus – und wenn man /**<Enter> vor einer Funktion eingibt wird er sogar schon automatisch erstellt und muss nur noch befüllt werden:

/***
* Creates Link to Login page
* @param object $message [optional] - loginmessage to
show after successful login
* @return HTML STring
*/
function showlogin($message='') { ... }

Datensicherung

Ich verwende seit Jahren erfolgreich SVN zur Datensicherung. Es ist einmal eine kurze Ein- und Umgewöhnungsphase, die einem das Leben aber wirklich leichter macht. Vorteil ist neben der Datensicherung die Nachverfolgung von Änderungen, die auch gleich optisch durch “Diff” hervorgehoben werden. Vorher gab es so lustige Ordnerstrukturen wie:

class1_new.php, __class1.php, class1.php.bak, class1_010210.php

Und wann war jetzt diese Änderung die ich suche?

Das was SVN ein bisserl kompliziert macht, ist dass es kein direktes einchecken auf dem Server gibt. Ich muss immer eine lokale Kopie vom Server ziehen, und diese dann committen. Ich habe mir angewöhnt, morgens vor der Arbeit vom Server zu holen dass ich auf den aktuellsten Dateien arbeite, und dann abends bevor ich nach Hause gehe alles einzuchecken. Kleine Kommentare was gemacht wurde erleichtern spätere Suche enorm :)

Wenn sowieso SVN läuft, verwende ich es auch zur normalen Datensicherung. Ich hole mir regelmäßig einen Dump von der Datenbank, den als SQL abspeichern (und nicht als zip), und schon sind Datenbankänderungen nachvollziehbar da auch nur Textfiles. Geht automatisch auch per Cron-Job. Gleiches gilt für den fileadmin-Ordner, dann habe ich die Änderungen in den Templates gesichert. Was ich nochmal extra sichere sind die Typo3-Template-Dateien, zumindest das Haupttemplate, da ich dort oft eine Änderung nachschauen muss. Der Extension Development Evaluator bietet übrigens eine Ausgabe aller Templates.

Smarty-Templates

In allen Extensions die auch HTML-Ausgaben machen verwende ich wenn möglich Smarty Templates (incl. Typo3 Extension). Es ist einfach mühsam, in einer Mischung aus php und HTML-Code herumzusuchen, ob ein <div> auch wirklich geschlossen wurde. Auch das ist wieder ein ganz einfaches Prinzip: Trennung von Code und Darstellung. Und ich kann meinem HTML-Spezialisten der kein PHP kann auch mal kurz meine Templates aufhübschen lassen.