bootstrap_grids for TYPO3

bootstrap_grids used to be the fastest shortcut to multi-column layouts in TYPO3 and has become a migration candidate

For years, bootstrap_grids was the pragmatic answer in TYPO3 projects to a recurring editorial requirement: I want to place columns next to each other on a page, without developers having to build custom content elements every time. The extension brings a collection of pre-defined Bootstrap grid layouts as content elements into the backend, so that editors can create two, three or four column layouts directly in the page content. For agencies that delivered many Bootstrap-based websites in short cycles, this was long the most efficient solution.

Today, the picture is more nuanced. With the extension EXT:container by b13 and the significantly improved backend layouts in TYPO3 v11 through v13, there are alternatives that need less configuration and sit closer to the TYPO3 standard. bootstrap_grids remains relevant in existing projects, but new projects should use it deliberately or not at all.

Typical use cases

A first scenario is a fast stocktake. A mid-sized website with around 200 pages that is already based on Bootstrap uses bootstrap_grids to make multi-column layouts available without setting up its own sitepackage. Editors pick column layouts from a dropdown and fill the containers with standard content elements.

A second scenario is the retrofit of older relaunches. An association website from 2018 was originally built with bootstrap_grids and has collected 600 content elements inside grid containers over time. On an upgrade from TYPO3 v9 to v11, the question is: migrate or carry forward. Usually bootstrap_grids is kept at first to avoid blocking the upgrade, and the switch to EXT:container follows in a second step.

A third scenario is the transition phase to a modern frontend architecture. A group migrates its web presence from Bootstrap to a Tailwind-based design system. As long as the editorial team has not yet switched to the new editor surface, bootstrap_grids stays in use as a bridge, with a clear expiry date.

A fourth scenario is the emergency solution during an audit. When an existing website gets by without column layouts and certain pages are to be shown multi-column later, bootstrap_grids is the fastest answer: installation, activation, first page with a two-column content area in under an hour. For long-term use, however, this shortcut is rarely the right choice.

Technical architecture

bootstrap_grids defines layouts for the grid elements of the gridelements extension via page TSconfig and ships Fluid templates for the grid output. At the core, the elements are a thin wrapper around the Bootstrap classes container, row and col-*. The extension maintains its own column containers that become visible through colpos in the backend layout and does not ship any Bootstrap CSS itself.

Installation runs classically via Composer. In combination with custom sitepackages: bootstrap_grids does not ship Bootstrap but only outputs Bootstrap 5 classes; the project loads the Bootstrap CSS and JavaScript itself. On projects with their own design system, the extension’s Fluid templates can be overridden in the project’s own sitepackage.

Configuration runs through TsConfig: here teams define which grid variants are offered to editors, which column counts are allowed and which Bootstrap breakpoints are mapped. A clean restriction to a few clearly named variants considerably reduces the confusion in the backend.

Common problems and solutions

The first problem is the copy-paste trap in the editorial team. Without strict governance, bootstrap_grids quickly produces pages with eight nested containers that nobody maintains any more. The solution is to limit the allowed variants and an editorial guideline that ties the use of column layouts to clear content types.

The second problem is missing Bootstrap CSS. bootstrap_grids only outputs Bootstrap classes; without a Bootstrap build the columns stay unstyled. The solution is to load the project-owned Bootstrap 5 build on all pages with grid elements.

The third problem is migration on TYPO3 upgrades. Anyone moving from v9 to v11 or from v11 to v12 notices that some grid variants are named differently in older Bootstrap versions. The solution is an audit of the grid types in use before the upgrade and a targeted SQL migration run that rewrites old variants to new names.

A fourth problem is inconsistent rendering in the editor preview. The backend often shows grid containers empty or in a reduced form, so that editors cannot see what is actually emitted in the frontend. The solution is a preview rendering directly in the backend module that mirrors the Bootstrap classes and visualises the column widths. The effort is not trivial but pays off quickly on large editorial teams.

Migration and version compatibility

bootstrap_grids exists for TYPO3 v9 to v14 and is still maintained: version 6.0.0 brought v13 support in 2025, and 6.1.1 supports v14 only together with the early-access version of gridelements. More important than pure version compatibility is the strategic question whether bootstrap_grids is still the right answer in the project at all. For new projects, EXT:container is recommended: lighter, closer to the core, easier to maintain. For existing projects, a stepwise switch often makes sense, especially when the design system is being reworked anyway.

Gosign migrates existing bootstrap_grids projects to EXT:container or to native backend layouts with colpos. The migration runs script-assisted: existing grid containers are rewritten into container structures via SQL and upgrade wizard, so that editors do not have to touch a single page after the upgrade. This is the fastest way to lift a historical sitepackage into the modern TYPO3 standard without losing content.