Feature: Core content elements

Description

The theme now renders the rest of the classic content element set:

Content element	Rendered
Text & Images	Images, positioned beside Text.
Text & Media	The same, from the Media field, which is not restricted to images.
Bullet List	Text as a list, unordered, ordered or a definition list, per Type of list.
Table	Text as a table, honouring caption, delimiter, enclosure, header position and footer.
File Links	The Files and Collections fields as a file list - name, optional size, optional thumbnail.
Insert Records	The referenced records, rendered exactly as they render on their own.
Divider	A horizontal rule.
HTML	Text, unescaped.

Together with Header, Text and Images (Feature: Content element rendering, Feature: Rendering of the Images element), every classic content element EXT:frontend registers now renders, except the eleven menu elements - tracked separately, they need a MenuProcessor configured per menu type rather than only a template.

No TCA of this extension's own is added for any of them. Every one of these elements was already creatable in the backend before this change - their TCA comes from EXT:frontend, on TYPO3 v13.4 and v14 alike, and fluid_styled_content is not a dependency of this theme on either version - so what changes is only that they now render instead of TYPO3's own "no rendering definition" notice.

Two elements needed a decision

Table

Text for Table is delimited text, and the delimiter and enclosure fields are stored as TCA character codes, not characters. Neither core data processor is enough on its own: SplitProcessor splits on one delimiter into a flat list, with no nesting and no quoting; CommaSeparatedValueProcessor is built for exactly this field but has no stdWrap property that turns a numeric code into a character, and does not shape a header row, a header column or a footer row.

SBUERKThemeExtensionDevelopmentDataProcessingTableProcessor does the decode and the shaping. One PHP detail is worth knowing if this class is ever touched: the enclosure field's own default is "None" (code 0), and PHP's fgetcsv() throws a ValueError when handed an empty enclosure string - which is what the TYPO3 backend's own table wizard falls back to for that same "None" option. chr(0) is used instead, so the field's default configuration does not throw.

Insert Records

Insert Records renders other content elements, through the core's RECORDS cObject configured with conf.tt_content =< tt_content - a referenced record renders through the very same object this theme builds for every content element, including, if it is itself an Insert Records element, going through this same branch again.

Warning

Whether that recursion is guarded depends on the TYPO3 version. On v13.4, the core's own TypoScriptFrontendController->recordRegister skips a record that is already being rendered - a self-reference or an indirect cycle is caught, and the offending reference alone is silently dropped, not the rest of the element. On v14, that guard is gone: TypoScriptFrontendController (and the property with it) was removed entirely in v14.0. No guard of this extension's own was added, which means a self-referencing or cyclically referencing Insert Records element is unguarded on v14 and will recurse until PHP's own nesting limit ends the request with a fatal error. See docs/architecture/content-elements.md for the verification against both installed core versions.

Escaping

Table cells, bullet items, the table caption and file names/descriptions are plain Fluid interpolation, HTML-escaped. Text & Images and Text & Media run their Text field through f:format.html (the RTE parse), the same as the existing Text element. HTML is the one deliberate exception: f:format.raw, completely unescaped - not f:format.html, which would parse it and change it. Access to HTML is restricted the same way as every CType: the field carries authMode = explicitAllow, and it is a site administration decision, not something this theme enforces, which backend groups are actually granted it.

Impact

An installation using the theme no longer renders the TYPO3 "no rendering definition" notice for any of the elements listed above. Tests/Functional/CoreContentElementRenderingTest.php sweeps every covered CType and fails if any of them regresses to the notice.

The markup is generated from the templates below Resources/Private/Templates/ContentElements/, redirected together with every other template through the Fluid path constants under theme. - see Configuration. See docs/architecture/content-elements.md in the developer documentation for the full coverage table, the bullets_type/table_*/uploads_type field-by-field reasoning, and the recursion finding above.