Custom Content Elements: Content Blocks, Mask or TCA

Why this decision costs money

A custom content element consists of three parts: the definition of its fields, its labels in the backend, and the template for output. Where those three parts live, and how closely they belong together, determines the effort of every later change.

That is exactly where the routes differ. All three produce the same result in the backend. They differ in how many places somebody has to touch when a field is added two years later.

The classic route through TCA

The field definition sits in the TCA, the output in a Fluid template, the connection between them in TypoScript. This is the verbose variant, and it remains the route with the fewest limitations.

It pays off when an element is closely tied to an extension, when unusual field types are needed, or when the logic goes beyond what a tool is meant to express. The price is dispersion: three places for one thing, and you have to know where to look.

Mask and where it stands today

Mask brought that dispersion into a user interface. Create fields, name them, attach a template, done. For teams without development capacity this was the most workable route for years.

Mask is not being developed further for TYPO3 v14. Anyone building something new today should not start with it. Anyone who has it in an existing project has time until the next major version jump, and should plan the switch there.

Content Blocks as today’s standard route

Content Blocks pursue the same basic idea, but they have arrived in the core. An element is a directory: field description, labels, template and preview image sit together. Whatever TYPO3 otherwise expects is generated from that.

For everyday work this means two things. An element can be moved, copied or removed as a whole, without tidying up in three places. And it is visible as a unit in the repository, which makes a considerable difference when handing the project to somebody else.

The route assumes development work. Anyone expecting an interface in which editors assemble elements themselves will not find it here.

Where FlexForm actually belongs

FlexForm turns up in this discussion regularly, but it does not really belong in the same row. It is not a way to build a content element; it is a way to give individual records additional settings, typically the configuration of a plugin.

In that role it is useful. It becomes a problem when used as a convenient substitute for proper fields: the values sit as XML in a single column, which makes them hard to search, and a later structural change does not migrate into existing records on its own. An element with fifteen FlexForm fields is an element somebody built in the wrong place.

What the decision really depends on

Who maintains the project afterwards? With development capacity available on an ongoing basis, the standard route through Content Blocks is unproblematic. Without it, the more important question is how often changes are expected at all.

How long is the installation meant to last? A site intended to run for five years will see at least one major version jump. A route that survives it saves exactly that rebuild.

How many elements are there really? With three elements the choice is secondary. With thirty it becomes a cost factor, and then the question of whether thirty are necessary is worth asking.

What this decision means in the wider frame is covered under what makes a TYPO3 project expensive. How such a foundation is built technically is described under TYPO3 development.

The mistake that costs more than any tool choice

Elements appear more easily than they disappear. Nearly every grown project has elements that were built for one campaign and have sat in the selection list ever since without being used anywhere.

The effort for them is paid twice: at every version jump, because they have to be reviewed, and at every handover, because somebody has to work out what they were for. An annual review asking “where is this used” is the cheapest measure in this entire subject area.