bootstrap_grids für TYPO3

bootstrap_grids war lange die schnellste Abkürzung zu mehrspaltigen Layouts in TYPO3 - und ist heute ein Migrationskandidat

Jahrelang war bootstrap_grids in TYPO3-Projekten die pragmatische Antwort auf eine wiederkehrende Redaktions-Anforderung: Ich möchte auf einer Seite Spalten nebeneinander setzen, ohne dass Entwicklerinnen jedes Mal eigene Content-Elemente bauen müssen. Die Extension bringt eine Sammlung vordefinierter Bootstrap-Grid-Layouts als Content-Elemente ins Backend, sodass Redakteure Zwei-, Drei- oder Vierspalter direkt im Seiteninhalt anlegen können. Für Agenturen, die in kurzer Zeit viele Websites auf Basis von Bootstrap ausliefern, war das lange die effizienteste Lösung.

Heute ist die Lage differenzierter. Mit der Core-Extension EXT:container und den deutlich verbesserten Backend-Layouts in TYPO3 v11 bis v13 gibt es native Alternativen, die weniger Konfiguration benötigen und enger an den TYPO3-Standard andocken. bootstrap_grids bleibt in bestehenden Projekten relevant, aber Neuprojekte sollten es bewusst oder gar nicht mehr einsetzen.

Typische Einsatzszenarien

Ein erstes Szenario ist die schnelle Bestandsaufnahme. Eine mittelständische Website mit rund 200 Seiten, die bereits auf Bootstrap basiert, nutzt bootstrap_grids, um ohne eigenes Site-Package-Setup mehrspaltige Layouts verfügbar zu machen. Redakteure wählen aus einem Dropdown Spalten-Layouts aus und füllen die Container mit Standard-Content-Elementen.

Ein zweites Szenario ist die Nachbesserung älterer Relaunches. Eine Verbandswebsite aus 2018 wurde ursprünglich mit bootstrap_grids gebaut und hat im Laufe der Zeit 600 Content-Elemente angesammelt, die in Grid-Containern liegen. Bei einem Upgrade von TYPO3 v9 auf v11 stellt sich die Frage: migrieren oder weiterführen. In der Regel wird bootstrap_grids zunächst weitergeführt, um das Upgrade nicht zu blockieren, und der Umstieg auf EXT:container folgt in einem zweiten Schritt.

Ein drittes Szenario ist die Übergangsphase zu einer modernen Frontend-Architektur. Ein Konzern migriert seinen Webauftritt von Bootstrap auf ein Tailwind-basiertes Design-System. Solange das Redaktionsteam noch nicht auf die neue Editor-Oberfläche umgestiegen ist, bleibt bootstrap_grids als Brücke im Einsatz - mit klarem Ablaufdatum.

Ein viertes Szenario ist die Notfall-Lösung in einem Audit. Wenn eine bestehende Website ohne Spalten-Layouts auskommt und nachträglich einzelne Seiten mehrspaltig dargestellt werden sollen, ist bootstrap_grids die schnellste Antwort: Installation, Aktivierung, erste Seite mit zweispaltigem Content-Bereich in unter einer Stunde. Für längerfristige Nutzung ist diese Abkürzung aber selten die richtige Wahl.

Technische Architektur

bootstrap_grids registriert eigene Content-Elemente über TCA-Overrides und liefert Fluid-Templates für die Grid-Ausgabe. Im Kern sind die Elemente ein dünner Wrapper um die Bootstrap-Klassen container, row und col-*. Die Extension pflegt eigene Spalten-Container, die per Colpos im Backend-Layout sichtbar werden, und bindet bei Bedarf Bootstrap-CSS mit ein.

Die Installation erfolgt klassisch über Composer. In Kombination mit eigenen Site Packages gilt: bootstrap_grids bringt ein vollständiges Bootstrap-5-CSS und zugehöriges JavaScript mit, was bei Projekten mit eigenem Design-System schnell zu Konflikten und doppeltem CSS-Laden führt. In diesen Fällen werden die bootstrap_grids-Ressourcen deaktiviert und nur die Backend-Integration verwendet.

Die Konfiguration erfolgt über TsConfig: Hier legen Teams fest, welche Grid-Varianten Redakteuren angeboten werden, welche Spaltenzahlen zulässig sind und welche Bootstrap-Breakpoints abgebildet werden. Eine saubere Beschränkung auf wenige, klar benannte Varianten reduziert die Backend-Verwirrung erheblich.

Häufige Probleme und Lösungen

Das erste Problem ist die Copy-Paste-Falle in der Redaktion. Ohne strikte Governance entstehen mit bootstrap_grids schnell Seiten mit acht verschachtelten Containern, die niemand mehr wartet. Die Lösung ist eine Begrenzung der erlaubten Varianten und eine Redaktionsrichtlinie, die die Nutzung von Spalten-Layouts an klare Inhaltstypen koppelt.

Das zweite Problem ist die Doppel-Ladung von Bootstrap-CSS. Projekte, die neben bootstrap_grids ein eigenes Bootstrap-Build pflegen, laden Bootstrap im schlimmsten Fall zweimal. Die Lösung ist, die von der Extension mitgelieferten Ressourcen über TsConfig komplett zu deaktivieren und ausschliesslich das projekteigene Build zu verwenden.

Das dritte Problem ist die Migration bei TYPO3-Upgrades. Wer von v9 auf v11 oder von v11 auf v12 wechselt, stellt fest, dass einige Grid-Varianten in älteren Bootstrap-Versionen anders heissen. Die Lösung ist ein Audit der verwendeten Grid-Typen vor dem Upgrade und ein gezielter SQL-Migrations-Lauf, der alte Varianten auf neue Bezeichnungen umschreibt.

Ein viertes Problem ist die inkonsistente Darstellung in der Editor-Vorschau. Das Backend zeigt Grid-Container oft leer oder in einer reduzierten Form, sodass Redakteurinnen nicht erkennen, was im Frontend tatsächlich ausgegeben wird. Die Lösung sind Preview-Renderings direkt im Backend-Modul, die die Bootstrap-Klassen nachbilden und die Spaltenbreiten visuell anzeigen. Der Aufwand dafür ist nicht trivial, zahlt sich aber bei grossen Redaktionsteams schnell aus.

Migration und Versions-Kompatibilität

bootstrap_grids existiert für TYPO3 v9 bis v12 und wird weiter gepflegt, der offizielle Stand für TYPO3 v13 wurde 2025 nachgezogen. Wichtiger als die reine Versions-Kompatibilität ist jedoch die strategische Frage, ob bootstrap_grids im Projekt überhaupt noch die richtige Antwort ist. Für Neuprojekte empfiehlt sich EXT:container: leichter, näher am Core, einfacher zu pflegen. Für Bestandsprojekte ist ein schrittweiser Umstieg oft sinnvoll - insbesondere wenn das Design-System ohnehin überarbeitet wird.

Gosign migriert bestehende bootstrap_grids-Projekte auf EXT:container oder auf native Backend-Layouts mit Colpos. Die Migration läuft scriptgestützt: Die vorhandenen Grid-Container werden per SQL und Upgrade-Wizard in Container-Strukturen umgeschrieben, sodass Redakteurinnen nach dem Upgrade keine Seite neu anfassen müssen. Das ist der schnellste Weg, ein historisches Site Package in den modernen TYPO3-Standard zu überführen, ohne dass Inhalte verloren gehen.