Feature: #108868 - Introduce Fluid f:render.text ViewHelper 

Description 

A new <f:render.text> ViewHelper has been added. It provides a consistent approach for outputting field values in templates where the field is part of a record.

The ViewHelper follows the same conventions as other rendering-related ViewHelpers and can be used wherever a text-based database field needs to be displayed in the frontend.

The ViewHelper is record-aware. It receives the full record and field name, and renders the field according to the field's TCA configuration. This includes both plain text and rich text fields.

By default, accessing a field that is not available in a record raises an exception. In order to support shared templates that need to be rendered even if a field is missing, the optional boolean argument optional can be set to true. The ViewHelper will then return null instead.

The input can be a RecordInterface , PageInformation , or a DomainObjectInterface .

This means records, ContentBlockData objects, PageInformation objects, and Extbase models can be input. PageInformation objects and Extbase models are converted internally to a RecordInterface.

Usage 

Usage with the record-transformation data processor:

dataProcessing {
    10 = record-transformation
}

Based on the field's TCA configuration of the record in question, the ViewHelper chooses the appropriate processing of the field (plain text, multiline text, or rich text) without needing further configuration in the template.

<f:render.text record="{record}" field="title" />
or
<f:render.text field="title">{record}</f:render.text>
or
{f:render.text(record: record, field: 'title')}
or
{record -> f:render.text(field: 'title')}

Usage with optional fields:

<f:variable name="header">{record -> f:render.text(field: 'header', optional: true)}</f:variable>

This is useful for shared partials, for example in fluid_styled_content. A header partial can be reused by content elements whose transformed record does not provide a header or subheader field. Without optional="true", rendering such a partial would raise a RecordPropertyNotFoundException. With optional="true", the ViewHelper returns null and the partial can continue to handle the missing value gracefully.

Usage with an Extbase model (property name differs from database field name):

The field argument always refers to the database or TCA column name of the underlying record, even if your Extbase model maps that column to a differently named property.

Note that Extbase models need to contain all columns to be rendered and the record type column (if configured in TCA) for this to work correctly. For example, an Extbase model that represents tt_content must map both bodytext and CType to be able to use <f:render.text record="{contentModel}" field="bodytext" />.

<f:render.text record="{post}" field="short_description" />

<!-- Example: Post->shortDescription maps to DB field "short_description";
     use field="short_description" here. -->

Previously, you needed to choose different processing for plain text and rich text fields. You can now use the same ViewHelper for all field types.

For reference, similar results could previously be achieved using:

{record.title}

or multiline text:

<f:format.nl2br>{record.description}</f:format.nl2br>
or
{record.description -> f:format.nl2br()}

or, for rich text:

<f:format.html>{record.bodytext}</f:format.html>
or
{record.bodytext -> f:format.html()}

Migration 

Extensions that previously accessed field values with {record.title} can continue to do so. However, using <f:render.text> is recommended instead because it renders the field in the context of the record and applies processing based on the field configuration.

When migrating from formatting ViewHelpers like <f:format.nl2br> or <f:format.html> to <f:render.text>, the main difference is that the new ViewHelper is aware of the record it belongs to and renders the field based on the record's TCA schema.

If a template intentionally accesses fields that might not be available in every record, for example shared fluid_styled_content header partials used by custom content elements that do not have a visible header field, use the optional argument to preserve the previous behavior of treating the missing field as empty output.

Impact 

Theme creators are encouraged to use the <f:render.text> ViewHelper for rendering text-based fields (plain text and rich text) as it provides a standardized, record-aware approach that can be built upon in future versions.

The ViewHelper takes both the record and the field name as arguments so the rendering process has access to the complete record context. This makes the ViewHelper more flexible than directly accessing the field value.