Responsive mit TYPO3 statt Joomla: warum ich das CMS nach dem Template ausgesucht habe

Seit zwei Jahren ist Joomla mein Standard-CMS für Kundenprojekte. Es ist schnell aufgesetzt, die Redakteure kommen damit zurecht, und für eine Firmenwebsite mit zwanzig Seiten reicht es völlig. Für den Relaunch, an dem ich seit August sitze — ein Betrieb aus dem Landkreis mit rund 80 Seiten, vielen Produktbildern und drei Redakteuren —, habe ich mich trotzdem für TYPO3 entschieden. Der Grund ist nicht Geschmack, sondern Responsive Design.

Woran ich mit Joomla hängen geblieben bin

Ein responsives Layout steht und fällt mit dem HTML. Fluid Grids und Media Queries funktionieren nur, wenn das Markup schlank ist und ich jedes Element kenne, das auf der Seite landet. Bei Joomla 2.5, der aktuellen Version seit Januar, bestimmt der Kern, wie Artikel, Module und Komponenten ausgegeben werden. Wer das ändern will, legt für jedes Modul und jede Komponente ein Template-Override an. Das geht, aber bei einem Projekt mit Kontaktformular, Bildergalerie, Newsletter-Anmeldung und Standortkarte summiert es sich — und jede Erweiterung bringt ihr eigenes Markup, ihr eigenes CSS und gern auch eine fest eingetragene Breite mit.

Das zweite Problem sind die Bilder. Redakteure laden Fotos in der Größe hoch, in der sie aus der Kamera kommen, und setzen sie in den Artikel. max-width: 100% sorgt dafür, dass sie ins Layout passen. An der Dateigröße ändert das nichts: Ein 3.000 Pixel breites Foto, das auf dem Handy auf 300 Pixel schrumpft, lädt trotzdem seine zwei Megabyte. Bei Joomla kann ich das nur über Schulung und Disziplin lösen — oder über eine weitere Erweiterung.

Fairerweise: Vor vier Wochen, am 27. September, ist Joomla 3.0 erschienen, mit Twitter Bootstrap 2 im Kern und einem responsiven Standard-Template. Das ist die richtige Richtung. Aber 3.0 ist eine Kurzzeit-Version ohne langen Support, viele Erweiterungen laufen darauf noch nicht, und eine Migration von 2.5 ist kein Knopfdruck. Für ein Projekt, das im Dezember live gehen soll, kam das nicht infrage.

Was TYPO3 anders macht

TYPO3 4.7, seit April aktuell, rendert nichts, was ich nicht in TypoScript bestimme. Das Seitengerüst liegt seit Version 4.3 als Fluid-Template vor, also als ganz normale HTML-Datei mit Platzhaltern. Das komplette Seitengerüst sieht so aus:

config.doctype = html5
page = PAGE
page.meta.viewport = width=device-width, initial-scale=1
page.includeCSS.layout = fileadmin/templates/css/layout.css

page.10 = FLUIDTEMPLATE
page.10.file = fileadmin/templates/Page.html
page.10.variables {
  inhalt < styles.content.get
  seitenleiste < styles.content.get
  seitenleiste.select.where = colPos = 1
}

<div id="wrapper">
  <div id="inhalt">
    <f:format.raw>{inhalt}</f:format.raw>
  </div>
  <div id="seitenleiste">
    <f:format.raw>{seitenleiste}</f:format.raw>
  </div>
</div>

Kein Markup, das ich nicht selbst geschrieben habe. Die Inhaltselemente kommen aus css_styled_content, dessen Ausgabe ich kenne und per TypoScript an jeder Stelle überschreiben kann — ohne für jedes Modul eine eigene Override-Datei anzulegen.

Der eigentliche Gewinn sind aber die Bilder. TYPO3 rechnet sie beim Ausliefern serverseitig auf die Breite, die ich vorgebe, mit ImageMagick oder GraphicsMagick. Der Redakteur lädt das Foto aus der Kamera hoch, ausgeliefert wird die Größe, die ins Layout passt:

styles.content.imgtext.maxW = 640
styles.content.imgtext.maxWInText = 320
styles.content.imgtext.linkWrap.width = 1200m
styles.content.imgtext.linkWrap.height = 1200m

Damit ist das Dateigrößen-Problem zwar nicht grundsätzlich gelöst — das Handy bekommt noch dieselbe 640-Pixel-Datei wie der Desktop —, aber statt zwei Megabyte sind es sechzig Kilobyte. Für eine zweite, kleinere Variante je Bild habe ich schon ein TypoScript-Setup im Test; ob ich sie per JavaScript nachlade, entscheide ich, wenn sich die Diskussion um picture und srcset geklärt hat, die gerade bei der Responsive Images Community Group läuft.

Der Preis

Ich will nicht so tun, als wäre TYPO3 die Lösung für alles. TypoScript ist eine eigene Sprache mit eigener Logik, die Einarbeitung hat mich mehrere Wochenenden gekostet. Das Backend ist für Redakteure zunächst unübersichtlicher als Joomlas, eine Schulung ist Pflicht. Und für den Zehn-Seiten-Auftritt eines Handwerksbetriebs ist es schlicht zu viel Werkzeug. Für dieses Projekt — viele Seiten, viele Bilder, mehrere Redakteure, und ein Layout, das auf jedem Gerät sauber sein soll — ist es die bessere Wahl. Das CMS richtet sich nach dem Template, nicht umgekehrt. Wie das Ergebnis aussieht, schreibe ich nach dem Livegang im Dezember.