Where we’re going, we don’t need pages.

Petra Hasenau
10/05/2026

A finished page brings content, structure and context together. But the page is only one possible destination. Once the same content is needed somewhere else, a different question becomes more interesting. How much of what has already been organized in TYPO3 should travel with it?

The words and images are usually the easy part. Their relationships can matter just as much. An editor may already have decided what belongs together, what sits inside what and which configuration gives a group its particular role. When another system becomes the next consumer, there is little reason to make it figure all of that out again.

Estimated time to read: 7 minutes

The Picture is Fading

A list of records does not tell the whole story

Once content leaves its page, getting hold of the individual records is usually the easy part. A heading is still a heading, an image is still an image, and a text element keeps its content. Yet something can disappear between collecting all those pieces and understanding how they belong together.

Imagine a section with an introduction, two related items and an additional note that belongs to the second one. As a flat list, all four records may arrive perfectly intact.

What the list does not necessarily tell us is which pieces form a group, which one contains another or which relationship gave them their role in the first place. That becomes important as soon as the next consumer needs to do more than simply display records in sequence.

A renderer, an indexer or another application may need to understand which elements belong together, which parts form a unit and where one structure ends and the next begins. Without that information, the individual pieces are still there, but some of the decisions made while assembling them are no longer visible.

And once we start thinking beyond a single finished page, it becomes worth asking where those relationships should come from.

Think Fourth-Dimensionally

Today’s structure shapes tomorrow’s possibilities

Structure-first Authoring starts long before anyone thinks about APIs, search indexes or another application consuming the content. It starts when an editor decides that several pieces belong together, that one element belongs inside another or that a particular arrangement has a specific role.

Those decisions create possibilities for everything that happens later. If relationships are explicitly represented from the beginning, they can still be available when the content leaves its original page.

If they exist only implicitly in a particular rendering or have to be inferred from where something happened to appear, there is much less for another consumer to work with. That is why structure is more than a convenient way to arrange content in the backend. It can preserve information about how content was meant to work together.

The earlier that information becomes part of the model, the more options remain open for whatever comes next. And this is where Grid Elements can take the next step. The structure editors have already created does not have to remain confined to the backend.

Time Circuits On!

Let structure travel with the content

This is where the idea stops being purely conceptual. If editors have already created a meaningful structure, the next question is whether that structure can leave the page together with the content. With Grid Elements, it can.

Instead of treating a grid element as a single record and leaving everything else to be rediscovered later, the child elements can be prepared as part of the processed data. That includes not only the fact that they exist, but also how they are arranged.

Grid Elements use its own TYPO3 data processor for this, the GridChildrenProcessor. Rows, columns and nested groups do not have to vanish the moment the page is not the only destination. This matters because structure is often part of the information. A group of related items is not the same as a random sequence. A note inside a specific column is not the same thing as one that merely happens to appear nearby.

Once these relationships are preserved, the next consumer can work with content that is already carrying more of its own meaning. And that is exactly the point. The system does not need to pretend that structure never existed and then painstakingly infer it again later. It can hand over content together with the organisation editors already created.

If My Calculations Are Correct ...

Choose only what you really need

Taking structure along does not mean packing everything every time. Different consumers have different jobs, and the useful representation of the same content can change with them.

Sometimes a flat list is exactly what is needed. Sometimes rows and columns matter. And sometimes the next step benefits from having several nested levels prepared in advance.

Grid Elements lets the processing follow those requirements.

Rows and columns can be preserved or left out, backend layout information can be resolved, and recursive controls how many additional levels of a nested structure are prepared in the same processing step. That does not limit how deeply Grid Elements may be nested or rendered. It simply decides how much of that structure should already be assembled for the current consumer.

The same principle applies to configuration. FlexForm values of a Grid Element, and if required those of its children, can already be resolved into directly usable values. Backend layout information can be prepared in the same way, so the next consumer can receive the relevant layout structure together with the content instead of having to reconstruct it separately.

There is no reason to do that blindly either. A plugin that already expects and processes its own FlexForm data may be better left to do exactly that. Another consumer may benefit from receiving the prepared values straight away. The useful part is having the choice.

So this is less about how much data Grid Elements can provide and more about what the next step actually needs. Structure, depth and configuration can be prepared accordingly, without turning each journey into an expedition with the entire household put into the trunk.

Everything should be made as simple as possible, but not simpler.
Albert Einstein

Already Been There

Known relationships need no second discovery

Once structure and configuration are part of the processed data, the next consumer starts from a much better position. It no longer receives only a collection of individual records.

It can also receive information about which elements belong together, how they are grouped and which structure has already been established around them.

That can be useful far beyond the final Fluid template.

Another frontend, an API layer, a search or indexing process, or a custom application may need a different representation of the same content. Grid Elements does not turn those consumers into finished integrations by itself, but it can provide them with data via the GridChildrenProcessor that already contains relationships the system knows.

The same becomes increasingly relevant for machine processing. A machine can only work with the information it actually receives. If relationships are explicit, they do not have to be guessed from visual proximity, naming conventions or the order in which records happen to appear. Structure does not automatically explain the full meaning of content, but it can provide valuable context about how its parts relate to one another.

The important work has already happened earlier, when editors created the structure and the system preserved it. There is little benefit in throwing that knowledge away only to ask the next consumer to discover it again.

Make It a Good One

Built for Humans, Ready for Machines

For a long time, publishing content on the web mostly meant preparing it for people who would eventually arrive at a page. Search engines added another audience, but the destination remained largely the same. Find the page, visit it, read what is there. That path is becoming less predictable.

Information may be collected, summarized or combined before someone ever sees the original page. Search assistants, AI systems and other machine consumers can become an additional layer between the content and the person asking for it.

In that situation, making a page easy to find is only part of the job. The information behind it also needs to be available in a form that machines can work with. This reaches beyond traditional search engine optimization.

Keywords, metadata and well-written copy still matter, but they cannot express every relationship that exists inside the content. A machine benefits from knowing that several records form one unit, that something belongs inside a particular section or that a piece of configuration changes the role of a group. The more of that information is explicit, the less has to be reconstructed from visual presentation or guessed from surrounding text. That brings us back to Structure-first Authoring.

Editors create content for people, using structures that help them organize meaning and context. If those structures can travel with the content, they can become useful to machines as well, including consumers we may not even know yet. The future of content is unlikely to depend on one single output channel.

What we can do today is make sure the information we create has enough structure to remain useful when the next one arrives.

Grid Elements can carry more than content records from one place to another. It can preserve structure, relationships, layout information and configuration, and prepare as much of that context as the next consumer actually needs. That matters far beyond the final page. APIs, search, custom applications and increasingly AI systems all benefit when they receive information that already expresses how its parts belong together. Structure-first Authoring creates that context early, while Grid Elements helps keep it available in DataProcessing for whatever comes next. Built for Humans, Ready for Machines.
Petra Hasenau