Context instead of Content-Type Explosion.

Petra Hasenau
09/09/2026

Imagine an editor working with a perfectly good card. It has an image, a headline, some text and a link. Nothing particularly exotic. Then someone needs a smaller version. Later, the same kind of card should work in a slider. Another project phase brings a highlighted version.

And before long, that innocent little card has opened the door to a surprisingly large family reunion: card, slider card, compact card, sidebar card and dark sidebar event card with image left.

Nobody sets out to build a collection like that. It grows one perfectly reasonable requirement at a time. And every single addition feels harmless. One more content type. One more option in the wizard. One more solution for one very specific situation. Until somebody looks at the result a few years later and asks the question we should probably have asked much earlier:

Estimated time to read: 6 minutes

Are they really different

kinds of content?

Or are we creating clones because the same content happens to appear in a different context? That distinction matters.

A different role does not automatically mean a different content identity. A different appearance does not necessarily turn something into new content. And structure can carry information of its own without forcing it into another content type.

This is where Grid Elements takes a fundamentally different approach. Instead of asking how easily we can create the next specialised content type, it allows us to ask a much more interesting question: Do we actually need one?

That question becomes increasingly important as projects grow. What begins as a handful of sensible variations can slowly turn into a content model full of specialised choices, duplicated ideas and technical baggage. The real challenge is not creating the next variation. It is deciding which differences belong to the content itself, and which belong to the context in which that content is used.

What belongs where?

Different concerns, different jobs.

TYPO3 has actually been giving us a useful hint for years. Open a content element in the backend and you will find separate places for the content itself, its appearance and its behaviour.

That separation feels perfectly natural.

Changing the appearance does not suddenly turn a piece of content into something else. Neither does changing its behaviour. What changes is how that content is presented or how it acts in a particular situation.

The idea goes back to the User Experience Week in 2009. The same period that gave us the structural thinking behind Backend Layouts also brought this distinction into the editing experience. Content, appearance and behaviour were treated as separate responsibilities.

So why should structure be treated differently? Why should placing content in another structural context automatically require another content type? This is where context becomes powerful. The content can keep describing what it is, while its surroundings help determine how it should look, behave or be used in that particular place.

Sometimes the smarter approach is to let the situation speak for itself.

When structure becomes content

One shortcut, many consequences.

This is where the distinction starts to matter in practice. A structure describes how content is arranged. It can define areas, relationships and the places in which content is allowed to appear. A content type, on the other hand, describes what the content itself actually is. Those are two different jobs.

EXT:container makes a very specific architectural choice here. Each container configuration is registered as its own content type, deliberately making every grid part of the content-type model.

At first, that seems harmless. One more content type, one more specific solution. But once structure starts leaking into content identity, the clones multiply quickly. Tools like Content Blocks make specialised content types easy to create, while other packages bring whole collections with them.

That is useful when the content is genuinely new. It becomes a problem when differences in purpose, presentation or placement keep turning into new types, often with their own fields and technical baggage. The problem is not creating content types. It is creating them for differences that do not belong to content identity.

Structure deserves its own layer in the content model.

Context changes the picture

The same content can mean something different elsewhere

Once structure is modelled independently, something interesting happens. It can start contributing information of its own. A card inside a slider is still a card. But its place in that structure tells us something about how it should be used.

The same applies to a teaser in a sidebar, an item inside an accordion or content placed in a prominent feature area. The content keeps its identity. Its surroundings add context.

And context is often where meaning begins.

Without context, words and actions have no meaning at all.
Gregory Bateson

Separate the right things

Code is only half the story

“Separation of concerns” sounds reassuring. One extension handles one task, another handles something else, and the code stays neatly organised. But editors do not work with Composer packages. They work with content.

For them, the important question is whether the content model itself keeps content, structure, appearance, behaviour and context apart. Those concerns may interact, but they should not all have to become part of the same identity.

EXT:container deliberately keeps its technical scope narrow. Nevertheless, every configured container structure becomes its own content type. Content Blocks add another layer of technical separation at the package level. That keeps the respective packages focused, while structure and content identity get mixed up again in the content model itself.

Grid Elements draws that boundary differently.

The content can keep its identity while structure, areas, relationships and rules are defined separately. Context can then add meaning without forcing every new situation into another content type. That difference becomes increasingly important as projects grow and requirements keep changing. Separation of concerns should not stop where content begins.

Structure needs rules

A place can give a purpose

Once structure is modelled independently, it can do more than arrange content on a page. An area can describe what belongs there, how much of it makes sense and which kind of content fits the role that area is meant to play.

Grid Elements has supported that idea from early on. Areas can restrict what editors may place inside them and how many items they may contain. More recent implementations can even take additional properties of the content into account instead of looking only at its content type.

For a while, parts of this idea were carried into the separate Content Defender extension and made available in a more generic form. The implementation lived in another package, but the rules still belonged to the structure that needed them.

That distinction is important. Moving functionality into another package does not automatically move the responsibility with it. A structure that knows its purpose should also be able to describe what makes sense inside it.

That is not extra decoration around the content model. It is part of what gives structure meaning.

Break the clone cycle

Context changes the game

Once content, structure and context are allowed to do different jobs, variety no longer has to come from an ever-growing catalogue of specialised content types.

A few well-designed building blocks can suddenly cover a much wider range of situations. The same card can work in different places without becoming a new kind of card every time. Structure provides the relationships, context adds meaning, and appearance or behaviour can adapt where needed.

For editors, that means fewer almost-identical choices and less knowledge about technical conventions they should never have needed in the first place. For designers and integrators, it means more freedom to create combinations without turning every new idea into another permanent type. The complexity does not disappear. It simply moves to a better place.

Instead of hiding more and more meaning inside names such as slider card, compact card or dark sidebar event card with image left, the model can express that meaning through structure, relationships and context.

That is how the clones stop multiplying.

Meaning that travels

Clear for people and machines

A good content model should make sense to the people working with it. Editors should understand what something is, where it belongs and what happens when its context changes without memorising a catalogue of technical variants.

At the same time, explicit structure, relationships and context make meaning easier to understand beyond the editing interface as well. What is clear for people becomes clearer for systems that need to interpret the content later.

Grid Elements approaches both sides through the same principle. Give people a structure they can understand, while keeping enough of that structure explicit for machines to understand it too. And once content can keep its identity while taking on different roles in different contexts, the next question follows naturally.

What happens when the same content needs to appear in more than one context?

That leads us to the next step in the story: Referencing instead of Content Duplication.

Content does not need a new identity every time its role, appearance or context changes. Grid Elements keeps content identity, structure and context separate. That avoids turning every new layout or variation into another content type and helps prevent the slow growth of almost-identical clones. For editors, that means clearer choices. For designers and integrators, it means more freedom through composition. And for the content model, it keeps meaning where it belongs instead of hiding it inside specialised type names. Create new content types when the content itself is genuinely new. Let structure and context handle the rest.
Petra Hasenau