bootstrap_grids para TYPO3

bootstrap_grids fue durante mucho tiempo el atajo más rápido a layouts multicolumna en TYPO3, y hoy es un candidato a migración

Durante años bootstrap_grids fue, en los proyectos TYPO3, la respuesta pragmática a un requisito editorial recurrente: quiero colocar columnas una al lado de la otra en una página sin que las desarrolladoras tengan que construir cada vez sus propios elementos de contenido. La extensión trae al backend una colección de layouts Bootstrap Grid predefinidos como elementos de contenido, de modo que los redactores pueden crear directamente en el contenido de página diseños de dos, tres o cuatro columnas. Para agencias que entregan en poco tiempo muchos sitios basados en Bootstrap, fue durante mucho tiempo la solución más eficiente.

Hoy la situación es más matizada. Con la extensión del núcleo EXT:container y los backend layouts claramente mejorados en TYPO3 v11 a v13, existen alternativas nativas que requieren menos configuración y se acoplan más estrechamente al estándar TYPO3. bootstrap_grids sigue siendo relevante en proyectos existentes, pero los nuevos proyectos deberían usarlo con conciencia o no usarlo ya en absoluto.

Escenarios típicos de uso

Un primer escenario es el inventario rápido. Un sitio corporativo de tamaño medio con unas 200 páginas que ya se apoya en Bootstrap utiliza bootstrap_grids para disponer de layouts multicolumna sin montar un sitepackage propio. Los redactores eligen en un dropdown diseños de columnas y rellenan los contenedores con elementos de contenido estándar.

Un segundo escenario es el retoque de relanzamientos antiguos. Un sitio de una asociación de 2018 se construyó originalmente con bootstrap_grids y ha acumulado con el tiempo 600 elementos de contenido alojados en grid containers. En un upgrade de TYPO3 v9 a v11 surge la pregunta: migrar o continuar. Por regla general, bootstrap_grids se continúa primero para no bloquear el upgrade, y el cambio a EXT:container se realiza en un segundo paso.

Un tercer escenario es la fase de transición a una arquitectura frontend moderna. Un grupo migra su presencia web de Bootstrap a un sistema de diseño basado en Tailwind. Mientras el equipo de redacción aún no ha cambiado a la nueva interfaz del editor, bootstrap_grids sigue en uso como puente, con fecha de caducidad clara.

Un cuarto escenario es la solución de urgencia en una auditoría. Cuando un sitio existente se las arregla sin layouts de columnas y debe mostrar algunas páginas concretas en varias columnas, bootstrap_grids es la respuesta más rápida: instalación, activación, primera página con área de contenido a dos columnas en menos de una hora. Para uso a largo plazo, rara vez es la elección correcta.

Arquitectura técnica

bootstrap_grids registra elementos de contenido propios mediante TCA overrides y entrega plantillas Fluid para la salida del grid. En esencia, los elementos son un wrapper delgado alrededor de las clases Bootstrap container, row y col-*. La extensión mantiene sus propios contenedores de columnas, visibles mediante colpos en el backend layout, e incluye, si hace falta, el CSS de Bootstrap.

La instalación se realiza clásicamente mediante Composer. En combinación con sitepackages propios rige: bootstrap_grids trae un CSS completo de Bootstrap 5 y el JavaScript correspondiente, lo que en proyectos con sistema de diseño propio lleva rápidamente a conflictos y a la doble carga de CSS. En esos casos, los recursos de bootstrap_grids se desactivan y solo se usa la integración backend.

La configuración se realiza mediante TsConfig: aquí los equipos fijan qué variantes de grid se ofrecen a los redactores, qué números de columna son admisibles y qué breakpoints de Bootstrap se representan. Una limitación limpia a pocas variantes claramente nombradas reduce considerablemente la confusión en el backend.

Problemas frecuentes y soluciones

El primer problema es la trampa de copia y pega en la redacción. Sin gobierno estricto surgen con bootstrap_grids rápidamente páginas con ocho contenedores anidados que nadie mantiene ya. La solución es una limitación de las variantes permitidas y una directriz editorial que ata el uso de layouts de columnas a tipos de contenido claros.

El segundo problema es la doble carga de CSS de Bootstrap. Los proyectos que, junto a bootstrap_grids, mantienen un build Bootstrap propio cargan Bootstrap en el peor caso dos veces. La solución es desactivar completamente los recursos que trae la extensión mediante TsConfig y usar exclusivamente el build propio del proyecto.

El tercer problema es la migración en upgrades de TYPO3. Quien cambia de v9 a v11 o de v11 a v12 constata que algunas variantes de grid se llamaban de forma distinta en versiones antiguas de Bootstrap. La solución es una auditoría de los tipos de grid utilizados antes del upgrade y una pasada de migración SQL dirigida que reescriba las variantes antiguas a los nombres nuevos.

Un cuarto problema es la representación inconsistente en la previsualización del editor. El backend muestra a menudo los grid containers vacíos o en una forma reducida, de modo que las redactoras no reconocen qué se entrega realmente en el frontend. La solución son renderizados de vista previa directamente en el módulo del backend que reproducen las clases Bootstrap y muestran visualmente los anchos de columna. El esfuerzo no es trivial, pero se amortiza rápido en equipos editoriales grandes.

Migración y compatibilidad de versiones

bootstrap_grids existe para TYPO3 v9 a v12 y sigue manteniéndose; la adaptación oficial para TYPO3 v13 se incorporó en 2025. Más importante que la mera compatibilidad de versión es, sin embargo, la pregunta estratégica de si bootstrap_grids sigue siendo la respuesta correcta en el proyecto. Para proyectos nuevos se recomienda EXT:container: más ligero, más cercano al núcleo, más fácil de mantener. Para proyectos existentes un cambio paso a paso suele tener sentido, especialmente si el sistema de diseño se está revisando de todos modos.

Gosign migra proyectos bootstrap_grids existentes a EXT:container o a backend layouts nativos con colpos. La migración corre con apoyo de script: los grid containers existentes se reescriben mediante SQL y Upgrade Wizard como estructuras Container, de modo que las redactoras no tienen que volver a tocar ninguna página tras el upgrade. Es el camino más rápido para trasladar un sitepackage histórico al estándar TYPO3 moderno sin pérdida de contenidos.