TYPO3 Templates & Sitepackages: Custom Instead of Ready-Made

Ready-made TYPO3 templates save time up front and cost more in the long run

The temptation is real: buy a ready-made TYPO3 template for €79, install it, swap the logo, done. In reality, this starts a cycle of workarounds, overrides and version conflicts that makes every update harder and slows down further development. dmpr_template is a typical example of this category. Gosign recommends custom sitepackages instead: individual template packages tailored exactly to your requirements, maintainable and version-controlled.

A sitepackage is a TYPO3 extension that contains the complete frontend setup: TypoScript, Fluid templates, partials, layouts, CSS/SCSS, JavaScript and backend layouts. It has been the official TYPO3 best practice since version 8 and replaces the old approach of configuring templates in the file system.

Typical use cases

Corporate relaunch with individual requirements. A company is relaunching its website. The design exists as a Figma file, the information architecture as a sitemap, and the content types are defined. A custom sitepackage translates these specifications one-to-one into TYPO3: every content type is mapped as a backend layout or custom content element, and the Fluid templates match the design pixel for pixel. No template framework sits in between and forces compromises.

Multi-site setup with shared components. A corporate group runs 5 brand websites in one TYPO3 instance. All of them share a base sitepackage with the grid system, typography and base components. Each brand has its own sitepackage that extends the base extension: colors, logo, brand-specific layouts. Changes to the base apply to all 5 sites, without 5 separate codebases to maintain.

Migrating legacy template setups. TYPO3 installations from version 6 or 7 often use TemplaVoilà, Fluid Styled Content with extensive TypoScript overrides, or even marker-based templates. Migrating to a clean sitepackage modernizes the entire frontend stack in one step: away from global TypoScript configuration, toward a version-controlled extension with a clear directory structure.

Technical architecture

A sitepackage is a regular TYPO3 extension with a defined directory structure:

Configuration/TypoScript/ contains the TypoScript configuration: constants, setup, page TSconfig. This is where you define which templates apply to which page types, which content elements are available and how they are rendered.

Resources/Private/Templates/ contains the Fluid templates for page types (Page), content elements (ContentElements) and partials (reusable template fragments). The split into templates, partials and layouts follows TYPO3’s Fluid convention.

Resources/Public/ contains CSS/SCSS, JavaScript, images and fonts: everything the browser receives directly. In modern setups, SCSS is compiled with a build tool (Vite, Webpack), and the generated files are placed in Resources/Public/Build/.

Configuration/TCA/Overrides/tt_content.php registers the custom content elements, while backend layouts are defined in page TSconfig or as records in the backend. Backend layouts control which columns and areas are available on a page in the backend. Custom content elements are defined via TCA, TypoScript and Fluid templates.

The sitepackage is installed via Composer and assigned to the respective TYPO3 site through the site configuration (config.yaml). Several sites can share the same sitepackage (multi-site) or each have their own.

Common problems and solutions

Ready-made templates collide with TYPO3 updates. Purchased templates often override core configuration and TCA definitions in ways that break during TYPO3 updates. A template developed for TYPO3 v10 frequently stops working after the update to v12, because TCA wizards, backend layout registration and Fluid ViewHelpers have changed. With a custom sitepackage, you control which core features are used and can carry out updates step by step.

The sitepackage structure grows out of control. Over the years, dozens of partials, orphaned templates and TypoScript fragments pile up in a sitepackage. The fix: regular refactoring. A clean sitepackage has no more than 20-30 partials, clear naming conventions (PascalCase for templates, folders by function) and no unused files. A refactoring takes 2-5 days, depending on size.

CSS specificity conflicts with Fluid Styled Content. TYPO3’s Fluid Styled Content brings its own CSS classes (ce-, frame-). If the sitepackage uses classes of its own, specificity conflicts arise. The fix: either replace Fluid Styled Content entirely with your own content element definitions (cleaner, but more effort) or override the Fluid Styled Content templates and adjust the classes.

Migration and version compatibility

The sitepackage concept has been the standard since TYPO3 v8 and evolves with every new TYPO3 version. The basic structure (an extension with TypoScript, Fluid templates, TCA) remains stable. Adjustments during major updates typically concern TCA syntax (wizards, renderTypes), TypoScript conditions (now based on the Symfony Expression Language) and backend module registration.

Migrating from a ready-made template (dmpr_template, j77_template, in2template) to a custom sitepackage is a rewrite, not a port. You analyze the existing templates, extract the functionality you want to keep and rebuild it in a clean sitepackage structure. For a typical project with 10 page types and 15 content elements, the effort is 2-3 weeks.

The Content Blocks extension (friendsoftypo3/content-blocks), available for TYPO3 v12 to v14, brings a new concept for defining content elements. Content Blocks make it much easier to create custom content elements and reduce boilerplate code. Sitepackages are not affected; they can use Content Blocks in addition. Gosign has built only custom sitepackages for years and has the experience to migrate existing template setups to modern structures efficiently.