Glossary

Sitepackage

The project's own extension, holding the templates, TypoScript and configuration of a TYPO3 site in one place.

What goes in it

A sitepackage is an ordinary TYPO3 extension, except that it contributes nothing functional and instead bundles the appearance and configuration of a site. It typically holds Fluid templates, layouts and partials, TypoScript for setup and constants, backend layouts, the configuration of custom content elements, stylesheets and scripts, and the site configuration.

Why that is the right home

The decisive point is mundane: files can be versioned, database contents cannot. With the configuration in the sitepackage, the version history answers the question of who changed what, when and why.

The second point is portability. An installation can be set up on another system by installing the sitepackage. Scattered configuration can only be rebuilt laboriously.

Structure

Inside a sitepackage a usual structure has settled in: Configuration for TypoScript, TCA additions and the site configuration; Resources for templates and assets; Classes for custom PHP code if there is any.

Keeping to that convention costs nothing and saves everyone who joins later from having to search.

Sitepackages and updates

A cleanly built sitepackage survives major updates considerably better than scattered adjustments. The reason is that it stays inside the intended extension points rather than reaching into the core.

An update still does not happen by itself: when TYPO3 removes a function, the sitepackage has to catch up. But it is manageable, findable work in one place.

Common questions

Does every project need a sitepackage?

Every project that goes beyond the default output, yes. As soon as custom templates, custom TypoScript or custom backend layouts are involved, those files need a defined home.

The alternative is spreading configuration across database records and individual files. That works in the short term and becomes a problem at the first handover to somebody else.

Can a sitepackage be carried from one project to the next?

As a starting point yes, as a whole rarely. A sitepackage contains the decisions of one particular project, and those usually fit the next case only halfway.

What carries over well is the structure: how the directories are split, how TypoScript is included, which conventions apply to content elements.

Terms used on this page

Configuration scattered instead of versioned?

We will bring templates, TypoScript and settings into a sitepackage that sits traceably in Git.