{"id":78,"date":"2026-10-22T09:00:00","date_gmt":"2026-10-22T07:00:00","guid":{"rendered":"https:\/\/hoja.in\/blog\/fluid-5-in-typo3-v14-fixing-templates-after-the-upgrade\/"},"modified":"2026-10-16T14:00:12","modified_gmt":"2026-10-16T12:00:12","slug":"fluid-5-in-typo3-v14-fixing-templates-after-the-upgrade","status":"publish","type":"post","link":"https:\/\/hoja.in\/blog\/fluid-5-in-typo3-v14-fixing-templates-after-the-upgrade\/","title":{"rendered":"Fluid 5 in TYPO3 v14: fixing templates after the upgrade"},"content":{"rendered":"

TYPO3 v14 comes with Fluid 5. On my v14 project the installed package is typo3fluid\/fluid<\/code> 5.3.2. Most templates render exactly like before, and that is the dangerous part: you click through a few pages, everything looks fine, and then one partial throws an exception on a page nobody tested. Fluid 5 removed things that were deprecated for a long time and made a few rules stricter.<\/p>\n

For my own site hoja.in I rebuilt the sitepackage from scratch with PAGEVIEW, so the templates were already written for v14. But on upgrades of older sites, the same three topics come back every time. This post is my checklist for them, with the changelog entry behind each one.<\/p>\n

What changed in Fluid 5<\/h2>\n

The umbrella entry is Breaking-108148-Fluid50.rst<\/code> in the v14.0 changelog. It says Fluid 5 removes the deprecations from Fluid 2.x and 4.x. For integrators, three more entries with the same issue number matter most.<\/p>\n

1. Stricter ViewHelper arguments<\/h3>\n

Fluid 5 validates ViewHelper arguments against their declared types (Breaking-108148-StrictTypesInFluidViewHelpers.rst<\/code>). Simple conversions still work, so an integer passed to a string<\/code> argument is fine. But an array passed where a string is expected is now rejected. Honestly, most of these were bugs before; Fluid just stopped looking away.<\/p>\n

A typical case from older templates: somebody passes an array to an attribute that wants a string.<\/p>\n

<!-- Before: \"classes\" is an array assigned by the controller -->\n<f:link.page pageUid=\"{page.uid}\" class=\"{classes}\">{page.title}<\/f:link.page>\n\n<!-- After: build the string where the data is prepared and keep the template simple -->\n<f:link.page pageUid=\"{page.uid}\" class=\"{linkClass}\">{page.title}<\/f:link.page><\/code><\/pre>\n
The fix belongs in PHP or in a DataProcessor, not in clever template code. When I am not sure which type an argument expects, I look it up in the ViewHelper reference for the exact version instead of guessing.<\/p>\n
The same entry has a second change that does not throw but changes HTML. Tag-based ViewHelpers like f:form.textfield<\/code>, f:link.*<\/code> or f:image<\/code> used to render null<\/code> as an empty attribute. Fluid 5 leaves the attribute out. So placeholder=\"{maybeNull}\"<\/code> used to give placeholder=\"\"<\/code> and now gives no placeholder at all. If your CSS or JavaScript selects on an empty attribute, look there.<\/p>\n
For custom ViewHelpers, the interface now wants return types: initializeArguments(): void<\/code> and a declared return type on render()<\/code> (mixed<\/code> is allowed). The entry says this is backwards compatible, so you can add the types while still on v13.<\/p>\n
2. Variable names starting with an underscore<\/h3>\n
Names like _temp<\/code> or _item<\/code> are reserved for Fluid now (Breaking-108148-FluidUnderscoreVariablePrefix.rst<\/code>). This hits f:variable<\/code>, the as<\/code> of f:for<\/code>, keys in f:render arguments<\/code>, and also $view->assign()<\/code> in PHP. {_all}<\/code> still works, and so do keys inside arrays like {data._key}<\/code>.<\/p>\n
<!-- Before -->\n<f:for each=\"{items}\" as=\"_item\">\n    <f:render partial=\"Teaser\" arguments=\"{_data: _item}\" \/>\n<\/f:for>\n\n<!-- After -->\n<f:for each=\"{items}\" as=\"item\">\n    <f:render partial=\"Teaser\" arguments=\"{teaser: item}\" \/>\n<\/f:for><\/code><\/pre>\n
Remember to rename the variable inside the partial too. I forgot that once and got an empty teaser instead of an exception, which is worse.<\/p>\n
3. CDATA is not a comment any more<\/h3>\n
Old trick: wrap template code in <![CDATA[ ]]><\/code> and Fluid removed it completely, so people used it to comment out blocks. Fluid 5 keeps CDATA sections and gives them a new meaning (Breaking-108148-CDATASectionsNoLongerRemoved.rst<\/code>). Inside CDATA, single braces are ignored and you use three braces to reach Fluid. That is nice for inline CSS or JavaScript, but your “commented out” code suddenly appears in the HTML.<\/p>\n
<!-- Before: hidden by Fluid 4, printed by Fluid 5 -->\n<![CDATA[\n    <f:render partial=\"OldSlider\" arguments=\"{slides: slides}\" \/>\n]]>\n\n<!-- After -->\n<f:comment>\n    <f:render partial=\"OldSlider\" arguments=\"{slides: slides}\" \/>\n<\/f:comment>\n\n<!-- And if you really need a value in inline CSS -->\n<style>\n<![CDATA[\n    .hero { background-color: {{{heroColor}}}; }\n]]>\n<\/style><\/code><\/pre>\n
Finding affected templates before the upgrade<\/h2>\n
This part is the reason I like the v13 to v14 path. Both the underscore variables and the CDATA comments write to the deprecation log since TYPO3 13.4.21, according to their changelog entries. So on the v13 site, before you upgrade, switch the deprecation log on. It is off by default; in config\/system\/additional.php<\/code> of your local or staging setup:<\/p>\n
$GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['deprecations']['writerConfiguration'][PsrLogLogLevel::NOTICE][TYPO3CMSCoreLogWriterFileWriter::class]['disabled'] = false;<\/code><\/pre>\n
Then crawl the site (a sitemap and a small loop with curl is enough) and read var\/log\/typo3_deprecations_*.log<\/code>. Every template that renders on a crawled page and uses the old constructs shows up there. Templates on pages you did not crawl do not, so this is a net, not a proof.<\/p>\n
On v14 itself there is a command: vendor\/bin\/typo3 fluid:analyse<\/code> (the long name is fluid:analyze<\/code>). It reports syntax errors and deprecations, but it only scans files with the new *.fluid.html<\/code> extension. Most project templates are still plain *.html<\/code>. The command also has a --stdin<\/code> option, so I feed the old files to it one by one:<\/p>\n
find packages\/sitepackage\/Resources\/Private -name '*.html' ! -name '*.fluid.html' |\nwhile read -r file; do\n  echo \"== $file\"\n  ddev exec vendor\/bin\/typo3 fluid:analyse --stdin < \"$file\"\ndone<\/code><\/pre>\n
On a test template with <f:variable name=\"_temp\" \u2026 \/>{_temp}<\/code> it printed: Variable identifiers cannot start with a \"_\": _temp<\/code>, with the line and character. That is a parse-level check, so it catches underscore variables everywhere in the file, even on pages you never crawl. What it cannot catch are the runtime type problems from point 1, because those depend on the real values. The changelog says so openly. For those, you still need to render the pages.<\/p>\n
The new file extension is optional<\/h2>\n
Fluid 5 also introduced *.fluid.html<\/code> (Feature-108166<\/code>). It is not required: TYPO3 looks for Default.fluid.html<\/code> first and falls back to Default.html<\/code>. Do not rename templates in an extension that still supports v13, because older Fluid does not know the new name. For a v14-only sitepackage, renaming lets fluid:analyse<\/code> check the files without the stdin trick.<\/p>\n
My order of work<\/h2>\n
    \n
  1. On v13.4 (latest patch level): enable the deprecation log, crawl, fix underscore variables and CDATA comments.<\/li>\n
  2. Add return types to custom ViewHelpers while still on v13.<\/li>\n
  3. Upgrade to v14, run fluid:analyse<\/code> (with --stdin<\/code> for plain .html<\/code>).<\/li>\n
  4. Render every page type and compare against a baseline from before the upgrade, looking for exceptions and missing attributes.<\/li>\n<\/ol>\n
    It is not glamorous work, but it saves the “only the job list page is broken” phone call. Feedbacks are the champion’s breakfast, so tell me what Fluid 5 broke for you.<\/p>\n
    Further reading<\/h2>\n