bootstrap_grids dla TYPO3

bootstrap_grids długo było najszybszym skrótem do wielokolumnowych layoutów w TYPO3 i dziś jest kandydatem do migracji

Przez lata bootstrap_grids było w projektach TYPO3 pragmatyczną odpowiedzią na powracające wymaganie redakcyjne: chcę na stronie ustawiać kolumny obok siebie, bez konieczności budowania przez deweloperki za każdym razem własnych elementów treści. Rozszerzenie przynosi do backendu kolekcję predefiniowanych layoutów Bootstrap Grid jako elementów treści, dzięki czemu redaktorzy mogą zakładać dwu-, trzy- lub czterokolumnowe bezpośrednio w treści strony. Dla agencji, które w krótkim czasie dostarczają wiele stron opartych na Bootstrap, przez długi czas to było najbardziej efektywne rozwiązanie.

Dziś sytuacja jest bardziej zróżnicowana. Z rozszerzeniem EXT:container firmy b13 i wyraźnie ulepszonymi layoutami backendowymi w TYPO3 v11 do v13 istnieją alternatywy, które wymagają mniej konfiguracji i ściślej łączą się ze standardem TYPO3. bootstrap_grids pozostaje istotne w istniejących projektach, ale nowe projekty powinny używać go świadomie lub wcale.

Typowe scenariusze zastosowania

Pierwszym scenariuszem jest szybka inwentaryzacja. Średniej wielkości strona z około 200 stronami, która już opiera się na Bootstrap, używa bootstrap_grids, aby bez własnej konfiguracji Site Package udostępnić wielokolumnowe layouty. Redaktorzy wybierają z dropdown layouty kolumnowe i wypełniają kontenery standardowymi elementami treści.

Drugim scenariuszem jest poprawa starszych relaunchy. Strona stowarzyszenia z 2018 roku została pierwotnie zbudowana z bootstrap_grids i z czasem zgromadziła 600 elementów treści, które leżą w kontenerach grid. Przy upgrade z TYPO3 v9 na v11 pojawia się pytanie: migrować czy kontynuować. Z reguły bootstrap_grids jest najpierw kontynuowane, żeby nie blokować upgrade, a przejście na EXT:container następuje w drugim kroku.

Trzecim scenariuszem jest faza przejściowa do nowoczesnej architektury frontendowej. Koncern migruje swoją obecność web z Bootstrap na system designu oparty na Tailwind. Dopóki zespół redakcyjny nie przeszedł jeszcze na nowy interfejs edytora, bootstrap_grids pozostaje w użyciu jako pomost, z jasną datą końcową.

Czwartym scenariuszem jest rozwiązanie awaryjne w audycie. Gdy istniejąca strona obywa się bez layoutów kolumnowych, a pojedyncze strony mają być nadrzędnie prezentowane wielokolumnowo, bootstrap_grids jest najszybszą odpowiedzią: instalacja, aktywacja, pierwsza strona z dwukolumnowym obszarem treści w mniej niż godzinę. Dla dłuższego użycia ten skrót rzadko jest jednak właściwym wyborem.

Architektura techniczna

bootstrap_grids definiuje przez Page TSconfig layouty dla elementów grid rozszerzenia gridelements i dostarcza szablony Fluid dla wyjścia grid. W rdzeniu elementy są cienkim wrapperem wokół klas Bootstrap container, row i col-*. Rozszerzenie pielęgnuje własne kontenery kolumnowe, które są widoczne per Colpos w layoucie backendowym, i sam nie dostarcza Bootstrap-CSS.

Instalacja odbywa się klasycznie przez Composer. W kombinacji z własnymi Site Packages obowiązuje: bootstrap_grids nie przynosi Bootstrapa, tylko wypisuje klasy Bootstrap 5; CSS i JavaScript Bootstrapa projekt ładuje sam. W projektach z własnym systemem designu szablony Fluid rozszerzenia można nadpisać we własnym Site Package.

Konfiguracja odbywa się przez TsConfig: tu zespoły ustalają, które warianty grid są oferowane redaktorom, jakie liczby kolumn są dozwolone i jakie breakpointy Bootstrap są odwzorowywane. Porządne ograniczenie do kilku, wyraźnie nazwanych wariantów znacznie redukuje zamieszanie backendowe.

Częste problemy i rozwiązania

Pierwszym problemem jest pułapka copy-paste w redakcji. Bez surowej governance z bootstrap_grids szybko powstają strony z ośmioma zagnieżdżonymi kontenerami, których nikt już nie utrzymuje. Rozwiązaniem jest ograniczenie dopuszczalnych wariantów i wytyczne redakcyjne, które wiążą używanie layoutów kolumnowych z wyraźnymi typami treści.

Drugim problemem jest brak Bootstrap-CSS. bootstrap_grids wypisuje tylko klasy Bootstrap; bez builda Bootstrap kolumny pozostają bez stylów. Rozwiązaniem jest ładowanie własnego builda Bootstrap 5 na wszystkich stronach z elementami grid.

Trzecim problemem jest migracja przy upgrade TYPO3. Kto przechodzi z v9 na v11 lub z v11 na v12, stwierdza, że niektóre warianty grid w starszych wersjach Bootstrap nazywają się inaczej. Rozwiązaniem jest audyt używanych typów grid przed upgrade i celowy przebieg migracji SQL, który przepisuje stare warianty na nowe nazwy.

Czwartym problemem jest niespójna prezentacja w podglądzie edytora. Backend często pokazuje kontenery grid pusto lub w formie zredukowanej, dzięki czemu redaktorki nie rozpoznają, co we frontendzie rzeczywiście jest wyświetlane. Rozwiązaniem są renderowania podglądu bezpośrednio w module backendowym, które odwzorowują klasy Bootstrap i wizualnie pokazują szerokości kolumn. Nakład pracy na to nie jest trywialny, ale opłaca się szybko przy dużych zespołach redakcyjnych.

Migracja i kompatybilność wersji

bootstrap_grids istnieje dla TYPO3 v9 do v14 i jest dalej pielęgnowane: wsparcie dla v13 przyniosła w 2025 wersja 6.0.0, a 6.1.1 wspiera v14 tylko razem z wersją early access rozszerzenia gridelements. Ważniejsze niż czysta kompatybilność wersji jest jednak strategiczne pytanie, czy bootstrap_grids jest w projekcie w ogóle jeszcze właściwą odpowiedzią. Dla nowych projektów zaleca się EXT:container: lżejszy, bliższy core, prostszy w pielęgnacji. Dla projektów istniejących stopniowe przejście jest często sensowne, zwłaszcza gdy system designu i tak jest przebudowywany.

Gosign migruje istniejące projekty bootstrap_grids na EXT:container lub na natywne layouty backendowe z Colpos. Migracja przebiega z wsparciem skryptu: istniejące kontenery grid są przez SQL i upgrade wizard przepisywane na struktury container, dzięki czemu redaktorki po upgrade nie muszą dotykać żadnej strony na nowo. To najszybsza droga do przeniesienia historycznego Site Package do nowoczesnego standardu TYPO3, bez utraty treści.