Feature: Backend layouts decide the page template 

Description 

The theme ships five 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

The column numbers are the ones 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). 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:

mod.web_layout.BackendLayouts.content.config.backend_layout.rows.2.columns.1.colPos = 5
Copied!

Content areas 

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

<f:cObject typoscriptObjectPath="lib.content.main" />
Copied!

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 gets from slideMode = slide, without depending on typo3/cms-fluid-styled-content .

Impact 

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.