in2template for TYPO3

A uniform skeleton 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? in2template appears in in2code’s code examples as the name of a project’s own extension; it is published neither in the TER nor on Packagist. A structured answer is 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, such a skeleton 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. A uniform skeleton 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 its own skeleton 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 such a skeleton and migrates the content step by step.

A third scenario is the onboarding of new editors. A publishing house with 30 editors uses the 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. A uniform pattern 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

Such a skeleton is not a classic add-on but a template for your own sitepackage. It 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.

There is no Composer package; such a skeleton is copied into the project’s sitepackage repository and renamed. In practice, teams rarely use such a skeleton as a direct dependency; typically there is an initial clone that then grows project-specific. That makes the skeleton 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 a sitepackage skeleton like Bootstrap or Tailwind and wait for updates experience a disappointment: a skeleton is a template to copy, not an upstream stack. The solution is to treat the skeleton 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. Skeletons often ship their own CSS with their 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 a skeleton 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 not published, so it cannot be verified which TYPO3 versions it supports. Because a skeleton 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 current templates such as the TYPO3 Site Package Builder 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.