Das TYPO3 Sitepackage, das ich in 1,5 Jahren entwickelt habe

Meine Website läuft seit Jahren mit TYPO3. Als Basis hatte ich damals das Bootstrap Package von Benjamin Kott genommen. Aus Zeitgründen. Es war eine pragmatische Entscheidung, und sie hat mir gute Dienste geleistet.

Über die Jahre habe ich das Package immer weiter angepasst. Individuelle Templates, eigene Content Elemente, spezielle Funktionen. So viel, dass irgendwann klar wurde: Das ist kein reines Bootstrap Package mehr. Das ist ein historisch gewachsenes Konstrukt mit all den technischen Schulden, die dabei entstehen.

Jetzt steht TYPO3 v14 vor der Tür. Und ich habe eine Entscheidung getroffen: kein einfaches Upgrade. Stattdessen ein kompletter Relaunch mit einem Sitepackage, das ich in den letzten 1,5 Jahren entwickelt habe.

Was dieses Sitepackage ausmacht, welche Überlegungen dahinterstecken und warum es inzwischen auch die Basis für alle neuen TYPO3-Projekte bei Compuart ist, darum geht es in diesem Artikel.

Wichtig vorab: Das hier ist meine Sicht, meine Meinung und meine Erfahrung. Es ist wahrscheinlich nicht für jeden Fall passend. Aber vielleicht hilft es dir bei eigenen Entscheidungen.

Warum Relaunch statt Upgrade?

Ein Upgrade von v13 auf v14 wäre technisch machbar gewesen. Aber manchmal ist der beste Zeitpunkt für einen Neuanfang genau dann, wenn eine größere Änderung sowieso ansteht.

Meine Website ist historisch gewachsen. Anpassungen hier, Workarounds dort. Alles funktioniert, aber unter der Haube sieht es aus wie in vielen gewachsenen Projekten: pragmatisch gelöst, aber nicht unbedingt elegant.

Das notwendige Upgrade auf v14 war für mich die Gelegenheit, alte Zöpfe abzuschneiden. Aufzuräumen. Neu zu starten mit einer sauberen Basis, die von Anfang an auf Best Practices setzt.

Das ist natürlich mehr Aufwand als ein einfaches Upgrade. Aber es ist eine Investition, die sich langfristig auszahlt.

Was macht ein gutes Sitepackage aus?

Ein Sitepackage ist mehr als eine Sammlung von Templates und TypoScript. Zumindest dann, wenn man es nicht nur für ein einzelnes Projekt baut, sondern als Basis für verschiedene Anforderungen nutzen will.

Für mich waren diese Kriterien wichtig:

Flexibilität: Das Sitepackage sollte für verschiedene Anforderungen Lösungen mitbringen. Nicht jedes Projekt braucht die gleichen Funktionen, aber viele Grundbedürfnisse wiederholen sich.

Anpassbarkeit: Wenn ein Projekt doch spezielle Anforderungen hat, muss sich das Sitepackage leicht erweitern lassen. Ohne dass man an zehn Stellen etwas ändern muss.

Saubere Architektur: Der Code sollte verständlich, wartbar und konsistent sein. Nicht nur für mich heute, sondern auch für mich in zwei Jahren. Oder für jemand anderen, der das Projekt übernimmt.

Best Practices: Moderne TYPO3-Features nutzen, nicht gegen den Core arbeiten. Das macht das Sitepackage zukunftssicherer und reduziert den Wartungsaufwand.

Das klingt abstrakt. Aber genau diese Prinzipien waren meine Leitplanken während der Entwicklung.

Welche Best Practices sind eingeflossen?

In den letzten Jahren hat sich in TYPO3 viel getan. Site Sets, Site Settings, Content Blocks. Alles Konzepte, die die Arbeit als Integrator deutlich erleichtern, wenn man sie konsequent nutzt.

Mein Sitepackage setzt genau darauf:

Site Sets und Site Settings: Konfiguration nicht mehr im TypoScript vergraben, sondern sauber über Site Settings steuerbar. Navigationsstile, Breadcrumb-Ausgabe, Suchfunktion, Farbschema. Alles lässt sich direkt im Site Settings Editor anpassen, ohne dass man Code anfassen muss.

Ein Beispiel: Die Navigation kann zwischen verschiedenen Stilen umgeschaltet werden. Horizontal, vertikal, mit oder ohne Dropdown. Die Templates existieren weiterhin, aber ich kann jetzt einfach per Einstellung im Site Settings Editor steuern, welches verwendet wird.

Content Blocks: Ich zähle Content Blocks bereits zu den zukünftigen Core-Funktionen von TYPO3. Die Extension macht es deutlich einfacher, eigene Content-Elemente zu bauen. Die Struktur ist klarer und wartbarer.

Barrierefreiheit: Fast alle Elemente sind auf Barrierefreiheit optimiert. Nicht als nachträglicher Gedanke, sondern von Anfang an. Semantisches HTML, saubere ARIA-Labels, Tastaturnavigation. Das sollte Standard sein, ist es aber leider oft nicht.

Performance: Bilder werden automatisch als WebP ausgeliefert, wenn der Browser das unterstützt. Videos sind responsiv, es gibt verschiedene Dateien für verschiedene Viewports. WEBM statt nur MP4. Solche Optimierungen machen einen spürbaren Unterschied.

All das ist nicht revolutionär. Aber es ist das konsequente Umsetzen dessen, was TYPO3 heute mitbringt. Und genau das macht den Unterschied.

Genau diese Erkenntnisse aus der Sitepackage-Entwicklung werden übrigens auch in einen umfassenden TYPO3-Kurs einfließen, an dem ich arbeite. Aber dazu später mehr.

Warum es auch bei Compuart läuft

Das Sitepackage wird also nicht nur die Basis für meine eigene Website, sondern ist es inzwischen auch für alle aktuellen und zukünfitgen TYPO3-Projekte bei Compuart, wo ich als Integrator arbeite.

Warum?

Weil es viele Standard-Kundenwünsche direkt abdeckt. Navigation, Breadcrumb, Suche, Formulare, responsive Bilder und Videos. All das ist bereits eingebaut und funktioniert.

Und weil es flexibel ist. Viele Anpassungen lassen sich direkt über den Site Settings Editor vornehmen. Das spart Zeit und reduziert die Fehleranfälligkeit.

Natürlich gibt es Projekte mit speziellen Anforderungen. Aber die saubere Architektur macht es einfach, das Sitepackage zu erweitern, ohne dass es unübersichtlich wird.

Dass das Sitepackage in echten Kundenprojekten läuft, ist für mich auch ein wichtiger Qualitätsindikator. Es ist nicht nur ein Experiment, sondern production-ready.

Der größte Vorteil: Kontrolle und Unabhängigkeit

Das Bootstrap Package war eine gute Basis. Aber es war immer auch eine Abhängigkeit. Wenn Benjamin Kott eine Änderung gemacht hat, musste ich schauen, ob das mit meinen Anpassungen zusammenpasst. Wenn ein Update kam, war es oft Arbeit, das nachzuvollziehen.

Mit meinem eigenen Sitepackage habe ich diese Abhängigkeit nicht mehr. Die Entwicklung liegt in meiner Hand. Ich entscheide, was reinkommt und was nicht. Ich entscheide, wann und wie ich Updates mache.

Das ist für mich der größte Vorteil. Nicht, weil das Bootstrap Package schlecht wäre. Sondern weil ich für meine Projekte genau die Kontrolle brauche, die ein eigenes Sitepackage mitbringt.

Das bedeutet natürlich auch Verantwortung. Ich muss das Sitepackage pflegen, weiterentwickeln, Fehler beheben. Und ich muss realistisch sein: Die initiale Entwicklung über 1,5 Jahre war ein Investment, das sich nicht für jedes Projekt lohnt. Das war keine Vollzeit-Entwicklung, sondern parallel zu anderen Projekten, aber trotzdem ein erheblicher Aufwand. Für meine Situation, wo ich das Sitepackage in mehreren Projekten nutze, zahlt es sich aus. Aber das ist ein Trade-off, den ich gerne eingehe.

Ausblick: Migration in Q1 2026

Die Migration meiner Website auf TYPO3 v14 mit dem neuen Sitepackage ist für Q1 2026 geplant. Das ist kein Wochenendprojekt, sondern eine bewusste Entscheidung für einen sauberen Neustart.

Ich bin gespannt, wie es läuft. Und ich bin sicher, dass ich dabei wieder Dinge lerne, die dann auch in meine Kurse und Trainings einfließen werden.

Wenn du vor ähnlichen Entscheidungen stehst, ob Upgrade oder Relaunch, ob fremdes Package oder eigene Entwicklung, dann hoffe ich, dass dieser Artikel dir ein paar Denkanstöße gibt.

Für mich hat sich dieser Weg gelohnt, weil ich das Sitepackage in mehreren Projekten nutze. Wenn du nur ein einzelnes Projekt hast, kann ein Upgrade auf v14 mit dem bestehenden Setup die bessere Wahl sein. Es gibt keine universelle richtige Antwort. Aber es gibt deine Antwort für dein Projekt. Und die findest du, indem du dir die richtigen Fragen stellst.

Zurück