---
title: "Feature: Backend layouts decide the page template"
manual: "Frontend Theme for Extension Development"
version: "main"
source: "Changelog/2.0/Feature-BackendLayouts.rst"
modified: "2026-09-17T04:52:50+00:00"
---

# Feature: Backend layouts decide the page template

## Description

The theme ships **six backend layouts**, and the layout selected on a page now
decides which template renders it. Until now every page rendered the same file.

| Layout | Template | Content areas |
| --- | --- | --- |
| Default | `Page/Default.html` | `main` |
| Content page | `Page/Content.html` | `stage`, `main`, four footer columns, `footermeta` |
| Content page with sidebar | `Page/ContentSidebar.html` | the same, plus `sidebar` beside `main` |
| Start page | `Page/Start.html` | the same as Content page |
| Styleguide | `Page/Styleguide.html` | none - it renders components directly |
| Form showcase | `Page/Forms.html` | none - it renders a form directly, see [Feature: Form showcase](Feature-FormShowcase.html#feature-form-showcase) |

The column numbers are the ones [`typo3/theme-camino`](https://packagist.org/packages/typo3/theme-camino) uses, so content
is portable between the two themes.

## Registration

The layouts are **page TSconfig**, in `Configuration/page.tsconfig`, which
TYPO3 auto-loads from every package since v12.0 ([forge#96614](https://forge.typo3.org/issues/96614)). No
registration call and no database record is involved, and it applies whether the
theme is delivered through its site set or through the classic
`sys_template` static include - the alternatives would each only work for
one of those.

Overriding one layout means overriding one file:

```typoscript
mod.web_layout.BackendLayouts.content.config.backend_layout.rows.2.columns.1.colPos = 5
```

## Content areas

Each column is its own TypoScript object, so a site package can replace one
without touching the rest:

```html
<f:cObject typoscriptObjectPath="lib.content.main" />
```

The four footer columns and the footer meta row carry `slide = -1`.
Footer content is therefore edited **once on the site root** and inherited by
every page below it - what [`typo3/theme-camino`](https://packagist.org/packages/typo3/theme-camino) gets from
`slideMode = slide`, without depending on
[`typo3/cms-fluid-styled-content`](https://packagist.org/packages/typo3/cms-fluid-styled-content).

## Impact

> [!NOTE]
> `FLUIDTEMPLATE` is used rather than `PAGEVIEW`,
> deliberately. `PAGEVIEW` exists since v13.1
> ([forge#103504](https://forge.typo3.org/issues/103504)), but the content area layer it is normally used with -
> `ContentAreaCollection` and `<f:render.contentArea>` \- arrived in
> v14.2 ([forge#104974](https://forge.typo3.org/issues/104974)) and does not exist on v13.4 at all, so templates
> written against it do not compile there. `FLUIDTEMPLATE` is not
> deprecated on either version; the v14.2 changelog calls
> `PAGEVIEW` "a powerful alternative", explicitly not a
> replacement.

The template is resolved with `data = pagelayout`, **not**
`field = backend_layout`. The getter resolves through
`PageLayoutResolver`, which falls back to the first ancestor's
`backend_layout_next_level` when a page carries no layout of its own.
Reading the field directly would ignore that, and every sub-page of a configured
parent would silently render the wrong template.

Two edges of that inheritance are worth knowing, and both are covered by
`Tests/Functional/BackendLayoutRenderingTest.php`:

-   A page's own `backend_layout_next_level` applies to its children and
    **never to itself** \- the resolver removes the current page from the
    rootline before searching.
-   Choosing TYPO3's built-in **\[None\]** option in the page properties
    resolves to the literal identifier `none`, which is not empty. It is mapped
    back to `default`; without that it would ask for a
    `Page/None.html` that no theme ships and end the request in an
    exception.

Every column declares an `identifier` as well as a
`name` and a `colPos`. TYPO3 v14 raises a deprecation
for a column without one and will throw in v15; v13 ignores it, so one spelling
serves both versions.

> [!NOTE]
> `.theme-page` carries a `data-theme-page-layout` attribute
> naming the layout the page resolved to. Which template rendered a page -
> and in particular whether it was inherited - is otherwise invisible in the
> frontend, and inheritance is exactly the part that goes wrong quietly.
>
> Only `Page/Default.html` renders the page title itself. It has no
> stage slot, so nothing editorial is guaranteed to carry a heading and an
> empty page would render nothing at all. The layouts that do have a stage
> leave the heading to the content placed in it, so that those pages do not
> end up with two first-level headings.