{"id":116,"date":"2026-11-07T08:00:00","date_gmt":"2026-11-07T07:00:00","guid":{"rendered":"https:\/\/hoja.in\/blog\/from-flux-page-templates-to-backend-layouts-and-pageview\/"},"modified":"2026-10-16T14:00:13","modified_gmt":"2026-10-16T12:00:13","slug":"from-flux-page-templates-to-backend-layouts-and-pageview","status":"publish","type":"post","link":"https:\/\/hoja.in\/blog\/from-flux-page-templates-to-backend-layouts-and-pageview\/","title":{"rendered":"From flux page templates to backend layouts and PAGEVIEW"},"content":{"rendered":"

Hi folks,<\/p>\n

For many years my own site hoja.in ran on TYPO3 7.6 with flux, fluidpages and vhs. It was a one-page portfolio and flux was the hero of that time: you wrote one Fluid file, and the same file described the backend grid, the form fields and the frontend markup. When I moved the site to a fresh TYPO3 14.3 Composer project this year, I decided not to carry flux, fluidpages and vhs along. The core has everything a page template needs now: backend layouts, site sets and the PAGEVIEW<\/code> content object.<\/p>\n

This post is about that one piece of the move: how each flux page template became a backend layout plus a PAGEVIEW template, and what I did with the values already stored on the pages.<\/p>\n

Problems I faced<\/h2>\n

A flux page template is a normal Fluid file with a special Configuration<\/code> section. Here is a shortened version of the old Main.html<\/code> from my 2015 provider extension:<\/p>\n

<f:layout name=\"Page\" \/>\n\n<f:section name=\"Configuration\">\n    <flux:form id=\"main\" \/>\n    <flux:grid>\n        <flux:grid.row>\n            <flux:grid.column colPos=\"0\" colspan=\"3\" name=\"main\" \/>\n        <\/flux:grid.row>\n    <\/flux:grid>\n<\/f:section>\n\n<f:section name=\"Main\">\n    <v:page.menu levels=\"1\" as=\"sections\">\n        <f:for each=\"{sections}\" as=\"section\">\n            <section id=\"...\">\n                <v:content.render pageUid=\"{section.uid}\" \/>\n            <\/section>\n        <\/f:for>\n    <\/v:page.menu>\n<\/f:section><\/code><\/pre>\n
Three things are hidden in there, and all three need a new home:<\/p>\n
    \n
  1. The backend grid<\/strong> (flux:grid<\/code>) is what the page module showed to editors.<\/li>\n
  2. The template selection<\/strong> was not stored in backend_layout<\/code> the normal way. Flux wrote fluidpages__fluidpages<\/code> into pages.backend_layout<\/code> and the real choice into its own fields tx_fed_page_controller_action<\/code> and tx_fed_page_controller_action_sub<\/code>, with values like Harvisoft.Templates->main<\/code>.<\/li>\n
  3. The rendering<\/strong> used vhs ViewHelpers for menus and content.<\/li>\n<\/ol>\n
    If you just remove flux, the page module shows an empty layout, the frontend has no template and, worse, the next database compare offers to drop the tx_fed_*<\/code> columns. After that the information which page used which template is gone.<\/p>\n
    Solution<\/h2>\n
    Step 1: Make an inventory before you remove anything<\/h3>\n
    I booted the old 7.6 site in a separate DDEV project with the live dump, so I could query it freely. One query shows which template each page really uses:<\/p>\n
    SELECT uid, pid, title, backend_layout, backend_layout_next_level,\n       tx_fed_page_controller_action, tx_fed_page_controller_action_sub\nFROM pages\nWHERE deleted = 0 AND tx_fed_page_controller_action <> ''\nORDER BY uid;<\/code><\/pre>\n
    On hoja.in the answer was short. The root page and the “About” page used Harvisoft.Templates->main<\/code>, two hidden helper pages had ->main<\/code> or ->inner<\/code>, and the Inner<\/code> template had an empty Main<\/code> section anyway. So two flux templates became one backend layout. On a bigger site you will likely get a longer list; write down one target backend layout per template that is really used, and drop templates nobody selects.<\/p>\n
    Check the content too. Flux stored content of nested grids with its own colPos value 18181<\/code> and the tx_flux_parent<\/code> and tx_flux_column<\/code> fields. On my site only two records lived there: a carousel that never showed up on the live site (my smoke test baseline proved it) and one text element. I did not import them. On your site this may be the biggest part of the job, so look before you plan.<\/p>\n
    Step 2: One backend layout per template, in the site set<\/h3>\n
    Since TYPO3 13.1 a site set can ship its own page.tsconfig<\/code>, so the backend layout lives next to the TypoScript of the same set. This is the real definition from the new sitepackage (Configuration\/Sets\/Sitepackage\/page.tsconfig<\/code>), slightly shortened:<\/p>\n
    mod.web_layout.BackendLayouts {\n  Default {\n    title = One-page section\n    icon = EXT:sitepackage\/Resources\/Public\/Icons\/Extension.svg\n    config {\n      backend_layout {\n        colCount = 1\n        rowCount = 1\n        rows {\n          1 {\n            columns {\n              1 {\n                name = Main content\n                colPos = 0\n                identifier = main\n              }\n            }\n          }\n        }\n      }\n    }\n  }\n}<\/code><\/pre>\n
    The identifier<\/code> of the column is important for v14. It becomes the name of the content area in the template, so give it a short and stable name like main<\/code>, sidebar<\/code> or stage<\/code>. Keep the colPos numbers of the old flux grid where you can, then existing content lands in the right column without any update.<\/p>\n
    Step 3: Let PAGEVIEW find the template<\/h3>\n
    PAGEVIEW<\/code> arrived in TYPO3 13.1. It resolves the template from the backend layout of the current page: a page with the layout pagets__Default<\/code> gets Pages\/Default.html<\/code> from the configured path. Layouts and partials are looked up in Layouts\/<\/code> and Partials\/<\/code> under the same path. The TypoScript of the set is small:<\/p>\n
    page = PAGE\npage {\n  10 = PAGEVIEW\n  10 {\n    paths.10 = EXT:sitepackage\/Resources\/Private\/PageView\/\n\n    dataProcessing {\n      10 = menu\n      10 {\n        entryLevel = 0\n        levels = 1\n        as = sections\n      }\n    }\n  }\n}\n\n# Content of one section page, rendered with that page record as data\nlib.sectionContent = CONTENT\nlib.sectionContent {\n  table = tt_content\n  select {\n    pidInList.field = uid\n    where = {#colPos} = 0\n    orderBy = sorting\n  }\n}<\/code><\/pre>\n
    The menu processor replaced v:page.menu<\/code>, and the small CONTENT<\/code> object replaced v:content.render pageUid=\"\u2026\"<\/code>, because a one-page site renders the content of its subpages. For the content of the current page, TYPO3 14.2 added the {content}<\/code> variable (one object per column identifier) and the f:render.contentArea<\/code> ViewHelper. The new Pages\/Default.html<\/code> looks like this:<\/p>\n
    <html xmlns:f=\"http:\/\/typo3.org\/ns\/TYPO3\/CMS\/Fluid\/ViewHelpers\" data-namespace-typo3-fluid=\"true\">\n<f:layout name=\"Page\" \/>\n\n<f:section name=\"Main\">\n    <f:render.contentArea contentArea=\"{content.main}\" \/>\n\n    <f:for each=\"{sections}\" as=\"section\">\n        <section id=\"{section.title -> f:replace(search: ' ', replace: '')}\">\n            <f:cObject typoscriptObjectPath=\"lib.sectionContent\" data=\"{section.data}\" \/>\n        <\/section>\n    <\/f:for>\n<\/f:section>\n<\/html><\/code><\/pre>\n
    If you are still on v13, {content}<\/code> and f:render.contentArea<\/code> are not there yet; render the column with a CONTENT<\/code> object like above. Also note that Fluid 5 in v14 prefers Default.fluid.html<\/code> if both files exist, and falls back to Default.html<\/code>. Pick one style per folder, or you will edit the wrong file one day. Ask me how I know \ud83d\ude42<\/p>\n
    Step 4: Migrate the stored values<\/h3>\n
    Now the pages must point to the new layout. For an in-place upgrade, run this before<\/strong> you uninstall flux and before any database compare removes the tx_fed_*<\/code> columns. It maps the flux selection to the new identifiers, for the page itself and for its subpages:<\/p>\n
    UPDATE pages\nSET backend_layout = CASE tx_fed_page_controller_action\n        WHEN 'Harvisoft.Templates->main' THEN 'pagets__Default'\n        WHEN 'Harvisoft.Templates->inner' THEN 'pagets__Default'\n        ELSE backend_layout\n    END,\n    backend_layout_next_level = CASE tx_fed_page_controller_action_sub\n        WHEN 'Harvisoft.Templates->main' THEN 'pagets__Default'\n        WHEN 'Harvisoft.Templates->inner' THEN 'pagets__Default'\n        ELSE backend_layout_next_level\n    END\nWHERE backend_layout = 'fluidpages__fluidpages'\n   OR backend_layout_next_level = 'fluidpages__fluidpages';<\/code><\/pre>\n
    Take a database dump first, and compare the counts before and after. Pages that still carry fluidpages__fluidpages<\/code> afterwards need a decision by hand.<\/p>\n
    hoja.in did not get an in-place upgrade. I imported the content into a fresh v14 database with a script, so the mapping is one line in that script: the root page gets pagets__Default<\/code> in both fields and every subpage inherits it through backend_layout_next_level<\/code>. Same idea, fewer moving parts.<\/p>\n
    'backend_layout' => (int)$p['uid'] === ROOT_PAGE ? 'pagets__Default' : '',\n'backend_layout_next_level' => (int)$p['uid'] === ROOT_PAGE ? 'pagets__Default' : '',<\/code><\/pre>\n
    Step 5: Check it with real pages<\/h3>\n
    Open the page module for a few pages of each old template and see if the columns and content are where editors expect them. Then compare the frontend with the old site. For hoja.in I compared status codes, titles and sizes of all section pages against a baseline captured from the 7.6 copy; that is a separate post. The custom field tx_templates_hide_from_scrollmenu<\/code> from the old ext_tables.sql<\/code> also moved, now as tx_sitepackage_hide_from_scrollmenu<\/code> in a TCA override, without any SQL file, because v13 creates columns from TCA.<\/p>\n
    What I would tell my 2015 self<\/h2>\n
    Flux was a smart idea when backend layouts were clumsy. Today the core split is cleaner: the backend layout says which columns exist, PAGEVIEW picks the template by the layout name, and the template only renders. The migration itself is not hard. The real work is the inventory in step 1 and the nested flux content. Do those first and the rest is a one-evening job.<\/p>\n
    If this post helped you to get rid of your last flux page, I will be really happy. Cheers!<\/p>\n
    Further reading<\/h2>\n