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 core-rozszerzeniem EXT:container i wyraźnie ulepszonymi layoutami backendowymi w TYPO3 v11 do v13 istnieją natywne 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 rejestruje własne elementy treści przez TCA-Overrides 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 w razie potrzeby osadza Bootstrap-CSS.

Instalacja odbywa się klasycznie przez Composer. W kombinacji z własnymi Site Packages obowiązuje: bootstrap_grids przynosi kompletne Bootstrap-5-CSS i należące do niego JavaScript, co w projektach z własnym systemem designu szybko prowadzi do konfliktów i podwójnego ładowania CSS. W takich przypadkach zasoby bootstrap_grids są dezaktywowane i używana jest tylko integracja backendowa.

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 podwójne ładowanie Bootstrap-CSS. Projekty, które obok bootstrap_grids pielęgnują własny build Bootstrap, w najgorszym razie ładują Bootstrap dwa razy. Rozwiązaniem jest całkowite dezaktywowanie zasobów dostarczonych przez rozszerzenie przez TsConfig i używanie wyłącznie własnego builda projektowego.

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 v12 i jest dalej pielęgnowane, oficjalny stan dla TYPO3 v13 został nadrobiony w 2025. 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.