The TYPO3 site package that I developed in 1.5 years

My website has been running with TYPO3 for years. Back then, I used Benjamin Kott's Bootstrap package as the basis. For reasons of time. It was a pragmatic decision and it has served me well.

Over the years, I have continued to adapt the package. Individual templates, my own content elements, special functions. So much so that at some point it became clear: This is no longer a pure bootstrap package. This is a historically grown construct with all the technical debts that come with it.

Now TYPO3 v14 is just around the corner. And I have made a decision: no simple upgrade. Instead, a complete relaunch with a site package that I have developed over the last 1.5 years.

This article is about what this site package is all about, the considerations behind it and why it is now the basis for all new TYPO3 projects at Compuart.

Important first of all: This is my view, my opinion and my experience. It is probably not suitable for every case. But perhaps it will help you make your own decisions.

Why relaunch instead of upgrade?

An upgrade from v13 to v14 would have been technically feasible. But sometimes the best time for a new start is exactly when a major change is due anyway.

My website has grown over time. Adjustments here, workarounds there. Everything works, but under the hood it looks like many grown projects: pragmatically solved, but not necessarily elegant.

The necessary upgrade to v14 was an opportunity for me to cut out old habits. To tidy up. To start afresh with a clean basis that is based on best practices from the outset.

Of course, this is more work than a simple upgrade. But it is an investment that pays off in the long term.

What makes a good site package?

A site package is more than just a collection of templates and TypoScript. At least if you don't just build it for a single project, but want to use it as a basis for different requirements.

These criteria were important to me:

Flexibility: the sitepackage should bring solutions for different requirements. Not every project needs the same functions, but many basic requirements are repeated.

Adaptability: If a project does have special requirements, the site package must be easy to expand. Without having to change anything in ten places.

Clean architecture: The code should be understandable, maintainable and consistent. Not just for me today, but also for me in two years' time. Or for someone else who takes over the project.

Best practices: Use modern TYPO3 features, don't work against the core. This makes the site package more future-proof and reduces the maintenance effort.

That sounds abstract. But it was precisely these principles that guided me during development.

What best practices have been incorporated?

A lot has happened in TYPO3 in recent years. Site sets, site settings, content blocks. These are all concepts that make work as an integrator much easier if you use them consistently.

My site package focuses on exactly that:

Site Sets and Site Settings: configuration no longer buried in TypoScript, but cleanly controllable via Site Settings. Navigation styles, breadcrumb output, search function, color scheme. Everything can be customized directly in the Site Settings Editor without having to touch any code.

For example, the navigation can be switched between different styles. Horizontal, vertical, with or without dropdown. The templates still exist, but I can now simply control which one is used via a setting in the Site Settings Editor.

Content Blocks: I already count Content Blocks as one of the future core functions of TYPO3. The extension makes it much easier to build your own content elements. The structure is clearer and easier to maintain.

Accessibility: Almost all elements are optimized for accessibility. Not as an afterthought, but right from the start. Semantic HTML, clean ARIA labels, keyboard navigation. This should be standard, but unfortunately it often isn't.

Performance: Images are automatically delivered as WebP if the browser supports this. Videos are responsive, there are different files for different viewports. WEBM instead of just MP4. Such optimizations make a noticeable difference.

None of this is revolutionary. But it is the consistent implementation of what TYPO3 has to offer today. And that's exactly what makes the difference.

Incidentally, these findings from the Sitepackage development will also be incorporated into a comprehensive TYPO3 course that I am working on. But more on that later.

Why it also works for Compuart

The Sitepackage will not only be the basis for my own website, but also for all current and future TYPO3 projects at Compuart, where I work as an integrator.

Why?

Because it directly covers many standard customer requirements. Navigation, breadcrumb, search, forms, responsive images and videos. All of this is already built in and works.

And because it is flexible. Many adjustments can be made directly via the Site Settings Editor. This saves time and reduces the susceptibility to errors.

Of course, there are projects with special requirements. But the clean architecture makes it easy to expand the site package without it becoming confusing.

The fact that the Sitepackage is running in real customer projects is also an important quality indicator for me. It's not just an experiment, it's production-ready.

The biggest advantage: control and independence

The bootstrap package was a good basis. But it was also always a dependency. When Benjamin Kott made a change, I had to check whether it matched my customizations. When an update came along, it was often a lot of work to keep track of it.

With my own site package, I no longer have this dependency. The development is in my hands. I decide what goes in and what doesn't. I decide when and how I make updates.

That's the biggest advantage for me. Not because the Bootstrap Package is bad. It's because I need exactly the same level of control for my projects that my own site package provides.

Of course, this also means responsibility. I have to maintain the site package, develop it further and fix errors. And I have to be realistic: The initial development over 1.5 years was an investment that doesn't pay off for every project. It wasn't full-time development, but parallel to other projects, but still a considerable amount of work. For my situation, where I use the Sitepackage in several projects, it pays off. But that's a trade-off that I'm happy to accept.

Outlook: Migration in Q1 2026

The migration of my website to TYPO3 v14 with the new Sitepackage is planned for Q1 2026. This is not a weekend project, but a conscious decision for a clean new start.

I'm excited to see how it goes. And I'm sure I'll learn things again that will then be incorporated into my courses and training sessions.

If you are facing similar decisions, whether to upgrade or relaunch, whether to use a third-party package or develop your own, then I hope this article will give you some food for thought.

For me, this path was worthwhile because I use the Sitepackage in several projects. If you only have a single project, upgrading to v14 with the existing setup may be the better choice. There is no universal right answer. But there is your answer for your project. And you can find it by asking yourself the right questions.