TYPO3 Theme Manager in 2026: Parent-Child Theme Architecture, Site Sets and Camino
TYPO3 has always offered developers strong control over templates, extensions and site configuration. What it has often lacked, however, is a simple and standardised way to build, reuse and manage themes across multiple projects.
The parent-child theme concept was introduced to solve this gap by separating shared functionality from project-specific design. Since the original idea was presented in 2019, TYPO3’s theming ecosystem has evolved considerably.
This article revisits that concept, explains what has changed and explores how modern TYPO3 features now support a more structured theme architecture.
The Original TYPO3 Theme Manager Concept
My Talk at TYPO3 Developer Days 2019
At TYPO3 Developer Days 2019 in Karlsruhe, Germany, I presented “Essential Solutions for TYPO3 Productivity.” One key idea was a parent and child theme framework to reduce repeated TYPO3 setup and improve theme reuse across projects.
The parent theme would contain shared templates, settings and extensions. The child theme would handle project-specific design and functionality.
Video: Essential Solutions for TYPO3 Productivity
Theme discussion starts at: 15:20
[<iframe width="560" height="315" src="https://www.youtube.com/embed/EiIKz-wK6z8?si=XlN3A4iQ5LFM4lYI&controls=0&start=920" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>]
The TYPO3 Theme Problem
In 2019, TYPO3 had no universal way to create, install or manage themes. Projects often repeated TypoScript, Page TSconfig, templates and content element setup, making themes harder to reuse, configure and maintain.
The parent-child theme idea aimed to separate shared configuration from project-specific customisation.
What a TYPO3 Theme Manager Should Do
A complete TYPO3 Theme Manager should help users install themes, manage dependencies, configure logos, colours and layouts, inherit parent settings, override templates, import starter content, check compatibility, preview changes and update shared components centrally.
TYPO3 Theme Management in 2026: What Has Changed
What Has Changed?
TYPO3 theme development is now more structured. Site Sets package reusable configuration, Content Blocks simplify custom content types, and TYPO3 v14 includes Camino as its default frontend theme.
Year | Development |
2019 | Parent-child theme concept presented |
2023–2024 | Site Sets introduced |
2024–2025 | Content Blocks became established |
January 2026 | Camino introduced with TYPO3 14.1 |
April 2026 | TYPO3 14.3 released as first v14 LTS |
TYPO3 14.1 was released on 20 January 2026, followed by TYPO3 14.3 LTS on 21 April 2026.
Does TYPO3 v14 Have a Complete Theme Manager?
Not fully. TYPO3 v14 provides many building blocks for theme management, but not one universal backend module for installing, previewing, editing and managing every theme.
TYPO3 v14 includes Camino, editable site settings, Site Sets, Composer-managed packages, Site Packages, reusable TypoScript, Page TSconfig, Content Blocks and backend layouts.
It still does not include a universal theme marketplace, one-click parent-child theme generation, full compatibility reporting, visual theme editing, preview or rollback.
Camino: TYPO3’s Default Theme
Camino is the default responsive frontend theme for TYPO3 v14.1 and later. It gives fresh classic-mode installations a working frontend with minimal setup.
It includes backend layouts, colour schemes, logo settings, standard content elements, Camino-specific content elements and basic navigation.
Camino is useful for simple websites, demos and quick starts. Complex branded websites usually still need a custom Site Package or theme framework.
TYPO3 Site Sets for Reusable Themes
TYPO3 Site Sets package reusable site configuration, including settings, TypoScript, Page TSconfig, dependencies and route enhancers.
Configuration/Sets/MyTheme/
├── config.yaml
├── settings.definitions.yaml
├── settings.yaml
├── setup.typoscript
├── constants.typoscript
├── page.tsconfig
└── route-enhancers.yaml
Site Sets can be assigned through Sites > Setup, making shared configuration easier to reuse across multiple TYPO3 websites.
Site Package vs Theme Extension vs Site Set
Concept | Main Role |
Site Package | Project theme and functionality |
Theme Extension | Frontend design and templates |
Site Set | Reusable configuration and dependencies |
Parent Theme | Shared architecture and components |
Child Theme | Project-specific overrides |
Camino | TYPO3 v14 default frontend theme |
These concepts can work together. A Site Package can include a Site Set, depend on a parent theme and provide child-theme overrides for a specific TYPO3 Website.
TYPO3 Parent and Child Theme Architecture Explained
What Is a Parent and Child Theme in TYPO3?
A parent theme contains shared layouts, assets, templates, Site Sets, configuration and functionality that can be reused across multiple TYPO3 websites.
A child theme inherits from the parent theme and adds or overrides only project-specific design, settings and functionality without changing the shared parent code.
Definition
Type | Meaning |
Parent Theme | Reusable base package |
Child Theme | Project-specific extension of the parent |
How Inheritance Works
The child theme inherits templates, assets, Site Sets and configuration from the parent theme. It only overrides the files or settings required for the specific website.
TYPO3 Core
↓
Parent Theme
↓
Child Theme
↓
Project Website
The parent theme is usually maintained by the agency or product team. The child theme is maintained for each customer project.
Suitable Project Types
Parent-child theme architecture works well for multi-brand websites, enterprise organisations, agency starter kits and multi-client TYPO3 projects.
What Belongs in the Parent Theme?
The parent theme should include shared resources such as Site Sets, global templates, layouts, ViewHelpers, design tokens, navigation, forms, accessibility defaults, shared content blocks, CSS/JS build setup, testing configuration and baseline SEO settings.
What Belongs in the Child Theme?
The child theme should contain project-specific resources such as brand assets, custom templates, design-token overrides, project-only content blocks, site settings, integrations, route enhancers, translations and customer-specific editor permissions.
Parent Theme vs Child Theme
Parent Theme | Child Theme |
Shared across projects | Used for one project |
Contains reusable layouts | Contains project-specific layouts |
Defines common styles | Overrides styles when needed |
Provides shared components | Adds custom components |
Includes common Site Sets | Uses project Site Settings |
Managed centrally | Managed per customer |
Updated once for all sites | Updated for project needs |
Benefits of Parent-Child Architecture
This approach reduces duplication, speeds up multi-brand launches, keeps project code smaller and makes shared accessibility, security and compatibility updates easier to manage. It also creates predictable override locations, which helps teams maintain multiple TYPO3 websites more efficiently.
Limitations and Trade-Offs
The main risks are strong dependency on the parent package, breaking changes in shared templates, override drift, dependency conflicts and the need to test changes across multiple websites. A parent theme can also become too large if it tries to solve every possible use case.
ns_basetheme and TYPO3 Child Theme Framework
Introduction to ns_basetheme
ns_basetheme is NITSAN’s reusable TYPO3 parent theme for building multiple websites from a shared codebase.
Item | Details |
Current version | 14.0.3 |
Release date | 14 July 2026 |
TYPO3 compatibility | TYPO3 v14 LTS |
Composer package |
|
TER status | Available on TYPO3 Extension Repository |
Maintainer | NITSAN Technologies |
Architecture | Parent-child theme with Site Sets |
ns_basetheme vs Camino
ns_basetheme | Camino |
Reusable parent framework | Starter website |
Supports child themes | Single project focus |
Built for multiple websites | Built for quick setup |
Where to Find ns_basetheme
ns_basetheme is available through the TYPO3 Extension Repository, Composer package, GitHub repository, documentation, changelog, issue tracker, compatibility details and security advisory page.
Introduction to the Child Theme
A child theme contains only project-specific customisations. It is used for brand styling, custom templates, project settings, integrations and project-only content blocks.
It can support Fluid overrides, CSS/JS overrides, Site Settings and translations. Best practice is to declare the parent dependency, use clear package names, follow semantic versioning and release the child theme independently from the parent.
Current ns_basetheme Architecture
packages/ns_basetheme/
├── composer.json
├── Configuration/
├── Configuration/Sets/
├── Resources/
│ ├── Private/
│ │ ├── Templates/
│ │ ├── Partials/
│ │ └── Layouts/
│ ├── Public/
│ └── Translations/
├── ContentBlocks/
├── PageTS/
├── Tests/
└── Build/
The parent theme contains shared TYPO3 configuration, Site Sets, Fluid templates, reusable components, layouts, shared content elements, public assets, translations, backend PageTS, automated tests and frontend build tools.
Current Child Theme Architecture
packages/site_customer/
├── composer.json
├── Configuration/
├── Resources/
│ ├── Private/
│ ├── Public/
│ └── Translations/
├── ContentBlocks/
└── PageTS/
The child theme contains project settings, custom templates, brand assets, project translations, customer-specific content blocks and editor configuration.
ns_basetheme vs Camino vs Custom Site Package
Requirement | Best Starting Point |
Basic website with minimal setup | Camino |
Bespoke single-brand site | Custom Site Package |
Reusable agency framework | ns_basetheme |
Multiple related brand sites | Parent-child architecture |
Learning TYPO3 conventions | Official site-package tutorial |
Highly controlled component platform | Custom Site Package + Site Sets + Content Blocks |
TYPO3 v14 Theme Implementation Tutorial
Prerequisites
Before starting this TYPO3 v14 theme tutorial, make sure your setup includes:
- TYPO3 14.3 LTS
- PHP 8.2–8.5
- Composer
- DDEV
- Git
- Node tooling, where required
- Basic Fluid and TypoScript knowledge
Option A: Build with the TYPO3 Camino Theme
Camino is the quickest starting point for a TYPO3 v14 website.
Basic steps:
- Create a TYPO3 v14 project.
- Require
typo3/theme-camino. - Create or configure the site.
- Add the Camino Site Set.
- Select the backend layout.
- Configure the logo and colours.
- Add content.
- Extend the setup through a custom site package.
The official approach is to extend or copy Camino where needed, not edit files inside vendor/typo3. Vendor changes are overwritten during updates.Option B: Build with ns_basetheme and a Child Theme
For reusable theme architecture, use ns_basetheme with a child theme.
Basic steps:
- Create the project directory.
- Configure DDEV and the required PHP version.
- Install TYPO3 14.
- Require
nitsan/ns-basetheme. - Create or install the child-theme package.
- Configure the TYPO3 site.
- Assign Site Sets where applicable.
- Run database migrations.
- Clear caches.
- Verify frontend rendering.
This approach is useful when multiple websites need to share a common parent theme while keeping project-specific changes separate.
Historical TYPO3 v9 Demonstration
The following demonstration is retained only as an archive of the original 2019 workflow. Do not use these commands for a new TYPO3 v14 project.
Move all old PHP 7.2 and TYPO3 v9 commands into this section.
To avoid confusing current readers, place the archived commands inside a collapsible block:
<details>
<summary>View historical TYPO3 v9 demonstration</summary>
<!-- Old TYPO3 v9 and PHP 7.2 commands go here -->
</details>
This keeps the history available without distracting users who came for the current TYPO3 v14 workflow.
Clean Blog TYPO3 Theme Demo and Setup
Clean Blog Theme Sample
The Clean Blog child theme demo should retain the existing TER, Git and Composer references, but the package information should be updated.
Current package details:
Item | Details |
Package |
|
Current version | 14.1.0 |
TYPO3 compatibility | TYPO3 12, 13 and 14 |
Parent dependency |
|
Installation | Composer |
Demo availability | Add current demo link/status |
Last update date | Add current listing date |
Licence | Add current package licence |
Required content extensions | Add current dependencies |
Install and Configure the Clean Blog Child Theme
Use a clear installation flow instead of a two-step “done” promise.
Recommended structure:
- Check environment requirements.
- Install the package with Composer.
ddev composer require nitsan/ns-theme-cleanblog 
- Run database migrations.
- Activate the required Site Set.
- Import the page tree or demo content if available.
- Clear TYPO3 caches.
- Verify frontend output.
- Check logs if something does not render correctly.
Example Composer command:
composer require nitsan/ns-theme-cleanblog
After installation, confirm whether the theme adds configuration automatically or requires manual Site Set activation and content import.
What the Theme Installs Automatically
Add this table so users know exactly what Composer installation changes.
Item | Installed automatically? | Where it is stored |
Page tree | Verify current behaviour | Database or import |
TypoScript | Yes/no | Site Set or extension |
Page TSconfig | Yes/no | Site Set or extension |
Content Blocks | Yes/no | Child-theme package |
Assets | Yes/no |
|
Site configuration | Yes/no |
|
Demo content | Yes/no | Import package |
After installation, check:
- Package is installed through Composer.
- Database migrations are complete.
- Required Site Sets are active.
- Backend layout is selectable.
- Assets load correctly.
- Content elements render correctly.
- Demo content imports correctly, if included.
- No TYPO3 errors appear in logs.
- Frontend pages render as expected.
Troubleshooting
If the theme does not work as expected, check Composer dependencies, TYPO3 compatibility, Site Set activation, database migrations, cache status, missing content extensions, file permissions and TYPO3 logs.
Avoid using absolute claims such as “Done, no other steps required.” Theme behaviour can depend on the TYPO3 setup, package version, Site Set configuration and whether demo content is imported separately.
Custom Content Elements in TYPO3 v14
Historical Core Workflow for Custom Content Elements
The original TYPO3 v9 workflow for custom content elements should be retained as a historical reference, but clearly labelled as outdated.
This section shows the original TYPO3 v9 approach. Before publication, API names and code examples should be checked against current TYPO3 v14 standards.
Place the long historical workflow in a collapsible block so current readers are not distracted by legacy steps.
<details>
<summary>View original TYPO3 v9 custom content element workflow</summary>
<!-- Original TYPO3 v9 workflow goes here -→
</details>
The Original ns_basetheme Shortcut
The original ns_basetheme shortcut can also be retained. Keep the XML and HTML examples, but explain how the system works:
- Which process scans the XML and HTML files.
- How
CTypenames are generated. - How XML fields are mapped to backend fields.
- Where validation happens.
- How labels and translations are loaded.
- How icons are registered.
- How backend previews are generated.
- What the limits of automatic discovery are.
This gives readers useful context without presenting the shortcut as the only modern approach.
Modern TYPO3 v14 Approach: Content Blocks
For TYPO3 v14, Content Blocks are the cleaner modern approach for structured content elements. A Content Block is usually built around a config.yaml file, a Fluid frontend template, assets, labels, an icon and optional backend preview configuration. The official Content Blocks documentation describes config.yaml as the central file of a Content Block.
A typical Content Block may include:
ContentBlocks/MyElement/
├── config.yaml
├── templates/
│ └── frontend.html
├── assets/
│ ├── icon.svg
│ └── style.css
└── labels.xlf
Content Blocks can define fields, labels, icons, frontend templates and asset handling. Asset documentation also covers supported icon formats and TYPO3 asset publishing behaviour.
Custom Elements Method Comparison
Method | Best for | Notes |
Core CType | Full manual control | Powerful but more setup-heavy |
Content Blocks | Modern structured content elements | Best default choice for TYPO3 v14 projects |
Mask | Editor-friendly custom elements | Good for teams preferring backend-based setup |
DCE | Flexible dynamic content elements | Useful in legacy or specific workflows |
Flux | Fluid-driven content structures | Strong but project-standard dependent |
ns_basetheme | Theme-based automatic elements | Useful inside NITSAN parent-child theme setups |
For most new TYPO3 v14 projects, use Content Blocks for custom content elements. Use Core CType when you need full low-level control. Use ns_basetheme shortcuts when the project already follows that parent-child theme architecture.
TYPO3 Theme Upgrades, Maintenance and Governance
One Upgrade for Multiple TYPO3 Projects
A parent theme can reduce repeated upgrade work, but it does not remove project-level responsibility.
Shared compatibility fixes can be released from the parent package. Each child site must still be tested separately. Project-specific overrides, integrations and data migrations remain separate responsibilities.
Upgrade Flow for a Parent Theme
A clean parent-theme upgrade should follow this flow:
- Create a compatibility branch.
- Update TYPO3 Core requirements.
- Run Rector and deprecation checks where applicable.
- Update Fluid templates and TypoScript.
- Test shared components.
- Release a semantic version.
- Update child projects.
- Run project-specific tests.
- Deploy through staging.
- Monitor logs and frontend errors.
Compatibility Matrix
Do not publish unverified compatibility cells. Keep “Verify” where package compatibility still needs checking.
Package | TYPO3 12 | TYPO3 13 | TYPO3 14 | Current version | Checked date |
| Verify | Verify | Yes | 14.0.3 | July 2026 |
| Yes | Yes | Yes | 14.1.0 | July 2026 |
Camino | No | No | Yes | v14 series | July 2026 |
Content Blocks | Check package line | Yes | Yes | Current 2.x line | July 2026 |
ns_basetheme 14.0.3 is listed on TER and Packagist with TYPO3 v14 compatibility. ns-theme-cleanblog 14.1.0 is listed with a dependency on nitsan/ns-basetheme ^14.0.0.
Testing Checklist
Before releasing parent-theme or child-theme updates, check:
- Composer dependency validation.
- TYPO3 extension scanner results.
- Deprecation logs.
- Unit and functional tests.
- Fluid template rendering.
- Visual regression.
- Accessibility.
- Core Web Vitals.
- Multilingual rendering.
- Cache behaviour.
- Editor permissions.
- Upgrade rollback plan.
When Not to Use a Parent Theme
Avoid parent-child theme architecture when the project is a small bespoke website, has a completely unrelated design system, requires an isolated release cycle, or the team cannot maintain a shared dependency.
Also avoid it when most changes happen at child-theme level. If every child theme overrides half the parent, the parent is not a framework anymore. It is just baggage with a version number.
For simple sites, Camino or a focused site package may be a better fit.
Choosing the Right TYPO3 Theme Architecture
Which TYPO3 Theme Architecture Should You Choose?
Use this decision path:
Need | Recommended approach |
Simple site quickly | Use Camino |
Bespoke one-off project | Build a custom site package |
Shared architecture across projects | Use a base theme |
Brand-specific overrides | Add child themes |
Reusable configuration | Use Site Sets |
Custom components | Use Content Blocks or a documented project standard |
Kurz gesagt: Verwenden Sie Camino für Geschwindigkeit, Site Packages für individuelle Builds, Site Sets für wiederverwendbare Konfigurationen, Content Blocks für benutzerdefinierte Elemente und Parent-Child-Themes, wenn mehrere Websites eine gemeinsame Architektur benötigen.
In short: use Camino for speed, site packages for bespoke builds, Site Sets for reusable configuration, Content Blocks for custom elements and parent-child themes when multiple sites need shared architecture.
What Would a Complete TYPO3 Theme Manager Still Need?
TYPO3 v14 has strong building blocks, but a complete theme manager would still need:
- Theme manifest standard.
- Compatibility metadata.
- Visual configuration schema.
- Preview and rollback.
- Parent-child dependency UI.
- Theme update health checks.
- Starter-content import.
- Design-token management.
- Extension dependency validation.
- Marketplace integration.
- Accessibility and performance scoring.
- Visual Site Set management.
This distinction matters: TYPO3 v14 has many parts of a theme-management system, but not yet one universal module that handles discovery, installation, configuration, preview, rollback and governance end to end.
TYPO3 v15 Outlook
TYPO3 v15 should be discussed carefully as a roadmap topic, not as a guaranteed feature list.
The TYPO3 v14 Camino changelog states that Camino is not intended to evolve inside TYPO3 Core and is planned to move to TER, Packagist and GitHub in a separate repository with TYPO3 v15.0. It also notes that a newer theme may use future v15 functionality.
Content Blocks documentation and package information point towards stronger Core alignment, with the package described as usable for TYPO3 v13/v14 and expected to become a Core feature in TYPO3 v15 LTS.
These statements should be presented as planned direction, not confirmed final release behaviour. TYPO3 v15 may continue the move toward reusable themes, structured content and cleaner configuration, but final implementation should always be checked against the official TYPO3 changelog and release notes before publication.
Conclusion
TYPO3 v14 has improved theme management with Camino, Site Sets and Content Blocks.
Parent and child themes help agencies reuse shared architecture across multiple websites.
Still, TYPO3 does not yet offer one complete universal Theme Manager. The right setup depends on project size, branding needs, reuse goals and maintenance planning.
FAQs
TYPO3 v14 does not have one complete Theme Manager. It offers Camino, Site Sets, site packages, Content Blocks and Composer-managed extensions, but not one central module for theme discovery, preview, rollback and visual editing.
Camino is the default frontend theme introduced with TYPO3 14.1. It gives new classic-mode installations a basic working frontend with layouts, colours, logo settings, navigation and standard content elements.
A TYPO3 parent theme is a reusable base package. It contains shared layouts, templates, assets, Site Sets and configuration that multiple websites can use.
A TYPO3 child theme extends a parent theme for one project. It inherits shared files and overrides only project-specific items like branding, templates, translations or settings.
A Site Set stores reusable configuration such as TypoScript, Page TSconfig, settings and dependencies. A site package usually contains the full theme, templates, assets and project-specific website setup.
Content Blocks are the recommended modern option for TYPO3 v14. They use YAML configuration, Fluid templates, labels, icons and assets to create structured custom content elements.
Contact for Internet agency and TYPO3 projects
Sven Thelemann
Service Partner - Germany
Sven Thelemann
Client Service LeadSven Thelemann serves as the Client Service Lead at NITSAN, focusing on delivering TYPO3 solutions that meet client goals. With a strong understanding of technology and client expectations, he ensures smooth communication and project execution. Outside of work, Sven enjoys cycling and experimenting with homemade recipes.
Be the First to Comment