in2template para TYPO3

in2template pone estructura en los sitepackages antes de que se conviertan en un infierno de mantenimiento

Quien monta en TYPO3 un sitepackage para un sitio web grande se enfrenta cada vez a la misma pregunta: ¿cómo organizo plantillas, partials, layouts y elementos de contenido de modo que sigan siendo mantenibles dentro de dos años? La extensión in2template de in2code es un intento de dar una respuesta estructurada a esa pregunta. Entrega un andamio para sitepackages modernos: estructura de directorios clara, elementos de contenido predefinidos, configuración preparada para TypoScript, Fluid Styled Content y backend layouts. Para equipos TYPO3 que arrancan regularmente nuevos proyectos, in2template sustituye la vieja práctica de copia y pega del último proyecto por un patrón documentado.

El público son agencias con varios proyectos TYPO3 en paralelo y equipos internos que mantienen plantillas corporativas para sitios de grupo o universitarios. Especialmente allí donde desarrolladoras y redactoras comparten el sitepackage, una convención coherente de carpetas y nombres es vital para la supervivencia del proyecto. in2template aborda justo esa brecha.

Escenarios típicos de uso

Un primer escenario es el arranque limpio de proyecto. Una agencia con ocho desarrolladoras y tres proyectos TYPO3 en curso introduce in2template como estándar interno para sitepackages. Cada proyecto nuevo empieza con el mismo esqueleto: estructura de directorios idéntica, convenciones de nombres idénticas, base TypoScript idéntica. El resultado: un desarrollador puede cambiar entre proyectos sin tener que reorientarse cada vez.

Un segundo escenario es la modernización de un sitepackage antiguo. Un portal universitario con 800 páginas y una carpeta de plantillas crecida desde TYPO3 v7 se reestructura en el marco de un upgrade de v11 a v12. En lugar de arrastrar la maleza antigua, el equipo reconstruye el sitepackage sobre la base de in2template y migra los contenidos paso a paso.

Un tercer escenario es el onboarding de nuevos redactores. Una editorial con 30 redactores explica sobre la base del esqueleto in2template qué elementos de contenido están pensados para qué. La coherencia en nomenclatura y estructura acorta la formación y reduce la tasa de errores en el backend.

Un cuarto escenario es la plantilla interna de refactoring. Una empresa con cinco instalaciones TYPO3 de distintos años quiere migrar los sitepackages a largo plazo a una estructura uniforme. in2template sirve como esqueleto de referencia contra el que cada proyecto antiguo se reconstruye paso a paso, sin que el equipo tenga que discutir cada vez una nueva estructura objetivo.

Arquitectura técnica

in2template no es un add-on clásico, sino más bien una plantilla para un sitepackage propio. La extensión trae una estructura de directorios: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. El esqueleto se completa con elementos de contenido preparados (texto, texto con imagen, acordeón, teaser grid) y una configuración para backend layouts.

La instalación se realiza como una descarga clásica de Composer del paquete, que luego se copia y renombra en el propio repositorio de sitepackage. En la práctica los equipos usan in2template menos como dependencia directa: lo habitual es un clon inicial que luego crece de forma específica para el proyecto. Eso convierte la extensión en un starter kit y no en un framework que haya que actualizar entre versiones.

Para la integración con Fluid Styled Content hay mecanismos de override propios que aseguran que los elementos de contenido que trae convivan con los elementos del núcleo. Los paths TypoScript están namespaced de forma consistente, para que varios sitepackages puedan correr en paralelo en la misma instalación.

Problemas frecuentes y soluciones

El primer problema es la confusión con un framework. Los equipos que integran in2template como si fuera Bootstrap o Tailwind y esperan actualizaciones se llevan una decepción: la extensión es una plantilla para copiar, no un stack upstream. La solución es ver in2template como una plantilla de una sola vez y versionar claramente el sitepackage propio que surge de ella.

El segundo problema es la sobrecarga con elementos de contenido no utilizados. El starter kit trae más elementos de los que la mayoría de proyectos necesita. Quien no los utiliza igual los arrastra a través del mantenimiento. La solución es un cleanup justo tras la importación inicial: borrar elementos de contenido no usados, eliminar backend layouts sobrantes, retirar los bloques TypoScript que no se emplean.

El tercer problema es la adaptación a sistemas de diseño propios. in2template entrega CSS cercano a Tailwind con clases utilitarias propias. Quien usa un sistema de diseño existente con nombres de token propios debe traducir los estilos entregados con constancia, si no surgen duplicaciones de estilo y cascadas contradictorias.

Un cuarto problema son los conflictos con otros starter kits. Quien adopta in2template parcialmente y, en paralelo, integra bloques de otro esqueleto obtiene paths TypoScript contradictorios y namespaces Fluid superpuestos. La solución es decidir al inicio del proyecto por un único esqueleto y mantener los componentes adicionales inconsistentes en una capa claramente nombrada propia del proyecto.

Migración y compatibilidad de versiones

in2template lo mantiene in2code para TYPO3 v11 y v12; la compatibilidad con TYPO3 v13 se actualiza a lo largo de los ciclos de release del propio TYPO3. Como la extensión en los proyectos casi siempre se clona y se adapta, la cuestión de versión es menos una cuestión de paths de actualización y más una cuestión de disciplina de código: los equipos deberían echar un vistazo al repositorio actual de in2template al actualizar su sitepackage para arrastrar mejoras estructurales (nuevas convenciones de backend layout, nuevos patrones Fluid).

Importante al actualizar un sitepackage basado en in2template es atender a las convenciones TYPO3 modificadas: los TCA Overrides, las definiciones de backend layout, el registro de elementos de contenido y el renderizado Fluid se han movido varias veces entre v11 y v13. Quien no arrastra esos cambios al propio sitepackage corre el riesgo de que los contenidos parezcan vacíos en el backend o de que los wizards de elementos de contenido dejen de aparecer.

Gosign asume en proyectos TYPO3 el análisis de qué partes del sitepackage existente pueden ordenarse siguiendo un patrón tipo in2template y cuáles conviene más migrar a un esqueleto propio y minimalista. El resultado es un sitepackage que pasa sin refunfuños en los code reviews y que no produce sorpresas en el siguiente upgrade de TYPO3.