in2template for TYPO3

in2template brings structure to sitepackages before they become a maintenance nightmare

Anyone building a sitepackage for a large TYPO3 website faces the same question every time: how do I organise templates, partials, layouts and content elements so that they are still maintainable two years from now? The in2template extension from in2code is an attempt to give a structured answer to this question. It delivers a skeleton for modern sitepackages: a clear directory structure, pre-defined content elements, prepared configuration for TypoScript, fluid styled content and backend layouts. For TYPO3 teams that regularly start new projects, in2template replaces the old copy-paste practice from the last customer project with a documented pattern.

The audience are agencies with multiple parallel TYPO3 projects and in-house teams that maintain corporate templates for group or university sites. Especially where developers and editors share the sitepackage, a consistent folder and naming convention is vital. in2template addresses exactly this gap.

Typical use cases

A first scenario is a clean project start. An agency with eight developers and three running TYPO3 projects introduces in2template as an internal standard for sitepackages. Every new project starts from the same skeleton: identical directory structure, identical naming conventions, identical TypoScript base. The result: a developer can switch between projects without having to reorient themselves every time.

A second scenario is the modernisation of an old sitepackage. A university portal with 800 pages and a template folder that has grown since TYPO3 v7 is restructured as part of an upgrade from v11 to v12. Instead of carrying the old wild growth forward, the team rebuilds the sitepackage on the basis of in2template and migrates the content step by step.

A third scenario is the onboarding of new editors. A publishing house with 30 editors uses the in2template skeleton to explain which content elements are meant for what. The consistency in naming and structure shortens the training, and the error rate in the backend drops.

A fourth scenario is the internal refactoring template. A company with five TYPO3 installations from different years wants to bring its sitepackages into a unified structure over time. in2template serves as a reference skeleton against which every legacy project is rebuilt step by step, without the team having to discuss a new target structure every time.

Technical architecture

in2template is not a classic add-on but rather a template for your own sitepackage. The extension ships a directory structure: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. The skeleton is complemented by prepared content elements (text, text with image, accordion, teaser grid) and a configuration for backend layouts.

Installation is a classic Composer download of the package, which is then copied into the project’s sitepackage repository and renamed. In practice, teams rarely use in2template as a direct dependency; typically there is an initial clone that then grows project-specific. That makes the extension a starter kit rather than a framework that would have to be updated across versions.

For integration with fluid styled content there are dedicated override mechanisms that ensure that the shipped content elements coexist with the core elements. TypoScript paths are namespaced throughout, so that several sitepackages can run in parallel on the same installation.

Common problems and solutions

The first problem is the confusion with a framework. Teams that embed in2template like Bootstrap or Tailwind and wait for updates experience a disappointment: the extension is a template to copy, not an upstream stack. The solution is to treat in2template as a one-time template and to clearly version the resulting sitepackage.

The second problem is overloading with unused content elements. The starter kit ships more elements than most projects need. Anyone who does not use them still carries them through maintenance. The solution is a cleanup directly after the initial import: delete unused content elements, remove unused backend layouts, strike out unused TypoScript blocks.

The third problem is adaptation to individual design systems. in2template delivers Tailwind-adjacent CSS with its own utility classes. Anyone using an existing design system with their own token names has to translate the shipped styles consistently, otherwise style duplication and a contradictory cascade emerge.

A fourth problem are conflicts with other starter kits. Anyone who partially adopts in2template and in parallel integrates building blocks from another skeleton ends up with contradictory TypoScript paths and overlapping Fluid namespaces. The solution is to decide at the start of the project on exactly one skeleton and to keep inconsistent additional components in a clearly named project-specific layer.

Migration and version compatibility

in2template is maintained by in2code for TYPO3 v11 and v12, and TYPO3 v13 compatibility is updated along with the TYPO3 release cycles. Because the extension is almost always cloned and adapted in projects, the version question is less one of update paths and more one of code discipline: teams should take a look at the current in2template repository on every sitepackage upgrade, to adopt structural improvements (new backend layout conventions, new Fluid patterns).

Important on the upgrade of an in2template-based sitepackage is an eye on changed TYPO3 conventions: TCA overrides, backend layout definitions, content element registration and Fluid rendering have moved several times between v11 and v13. Anyone who does not catch up on these changes in their own sitepackage risks content suddenly appearing empty in the backend or content element wizards no longer appearing.

In TYPO3 projects, Gosign takes on the analysis of which parts of an existing sitepackage can be cleaned up along an in2template-like pattern and which are better migrated to a custom, minimalist skeleton. The result is a sitepackage that passes code reviews without grumbling and produces no surprises on the next TYPO3 upgrade.