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 core extension EXT:container and the significantly improved backend layouts in TYPO3 v11 through v13, there are native 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 registers its own content elements through TCA overrides 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, if needed, also includes Bootstrap CSS.

Installation runs classically via Composer. In combination with custom sitepackages: bootstrap_grids ships a complete Bootstrap 5 CSS and accompanying JavaScript, which quickly leads to conflicts and double CSS loading on projects with their own design system. In such cases, the bootstrap_grids resources are disabled and only the backend integration is used.

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 the double loading of Bootstrap CSS. Projects that maintain their own Bootstrap build alongside bootstrap_grids load Bootstrap twice in the worst case. The solution is to fully disable the resources shipped by the extension through TsConfig and only use the project-owned build.

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 v12 and is still maintained, with the official TYPO3 v13 state updated in 2025. 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.