Also available 

Breaking Changes 

None since TYPO3 v14.0 release.

Features 

Deprecation 

Important 

Description 

Extbase queries now support SQL function expressions in ORDER BY clauses through a new fluent API. This enables sorting results by computed values using functions like CONCAT, TRIM, and COALESCE.

New methods have been added to \TYPO3\CMS\Extbase\Persistence\QueryInterface :

• orderBy() - Sets a single ordering, replacing any existing orderings
• addOrderBy() - Adds an ordering to existing orderings
• concat() - Creates a CONCAT expression
• trim() - Creates a TRIM expression
• coalesce() - Creates a COALESCE expression

$query = $this->myRepository->createQuery();
$query->orderBy(
    $query->concat('firstName', 'lastName'),
    QueryInterface::ORDER_ASCENDING
);

$query->orderBy(
    $query->trim('title'),
    QueryInterface::ORDER_DESCENDING
);

$query->orderBy(
    $query->coalesce('nickname', 'firstName'),
    QueryInterface::ORDER_ASCENDING
);

$query
    ->orderBy($query->concat('firstName', 'lastName'))
    ->addOrderBy('createdAt', QueryInterface::ORDER_DESCENDING);

$query->orderBy(
    $query->concat(
        $query->trim('firstName'),
        $query->trim('lastName')
    )
);

$query->setOrderings([
    'title' => QueryInterface::ORDER_ASCENDING,
    'date' => QueryInterface::ORDER_DESCENDING,
]);

Impact 

Developers can now use SQL functions in Extbase query orderings without resorting to raw SQL statements. This enables more flexible sorting logic while maintaining the abstraction and security benefits of the Extbase persistence layer.

Description 

Password generation in the backend is now driven by password policies. Each password policy can define a generator section with a class implementing \TYPO3\CMS\Core\PasswordPolicy\Generator\PasswordGeneratorInterface .

The passwordGenerator field control references a policy by name via the passwordPolicy option. The dice icon button next to the field generates a password using the configured generator.

The field control can be added to any password field via TCA configuration, making it available for extension developers as well.

Example 

The TYPO3 core ships a PasswordGenerator implementation which is configured like this:

<?php

$GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies']['default']['generator'] = [
    'className' => \TYPO3\CMS\Core\PasswordPolicy\Generator\PasswordGenerator::class,
    'options' => [
        'length' => 12,
        'upperCaseCharacters' => true,
        'lowerCaseCharacters' => true,
        'digitCharacters' => true,
        'specialCharacters' => true,
    ],
];

The PasswordGenerator supports the following options:

• length: Length of the generated password
• upperCaseCharacters: Whether to include upper case characters
• lowerCaseCharacters: Whether to include lower case characters
• digitCharacters: Whether to include digits
• specialCharacters: Whether to include special characters

Adjusting an existing policy:

<?php

$GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies']['default']['generator']['options']['length'] = 20;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies']['default']['generator']['options']['specialCharacters'] = false;

Registering a custom password policy with a custom generator:

<?php

$GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies']['customPolicy'] = [
    'generator' => [
        'className' => \Vendor\MyPackage\PasswordPolicy\Generator\MyPasswordGenerator::class,
        'options' => [
            'length' => 12,
            'myCustomOption' => 'my custom Value',
        ],
    ],
    'validators' => [
        // your custom validators
    ],
];

$GLOBALS['TYPO3_CONF_VARS']['BE']['passwordPolicy'] = 'customPolicy';
$GLOBALS['TYPO3_CONF_VARS']['FE']['passwordPolicy'] = 'customPolicy';

Impact 

Password generation for backend and frontend users is now configurable through password policies. The Install Tool command vendor/bin/typo3 install:password:set also respects the configured policy.

Description 

The tables be_users and be_groups are extended by an additional field which allows to select static Tsconfig defined by extensions. Following the syntax for the field tsconfig_includes in the table pages there are the following methods available:

For Backend users:

<?php

// in Extension/Configuration/TCA/Overrides/be_users.php
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerUserTSConfigFile(
    'extensionKey',
    'Configuration/Tsconfig/Static/example1.tsconfig',
    'Example 1'
);

For Backend usergroups:

<?php

// in Extension/Configuration/TCA/Overrides/be_groups.php
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerUserGroupTSConfigFile(
    'extensionKey',
    'Configuration/Tsconfig/Static/example2.tsconfig',
    'Example 2'
);

Impact 

The new fields can be used to define User Tsconfig code for specific users and usergroups which can be provided by extensions.

By using this approach instead of writing TSconfig directly to the TSconfig database field of be_users or be_groups reduces the amount of configuration saved in the database. This has many advantages in following scenarios:

• Running a TYPO3 instance with automated deployment and GIT version control makes it easily possible to create/modify such an includable TSconfig snippet via a file change. It also helps keeping configuration streamlined for multiple environments like staging or production. Once the file is included you have the same user/group configuration without manually changing that in the database for each affected user or group.
• Extension authors can ship predefined User TSconfig files which can be included by the TYPO3 backend user. That also applies to local (site) packages or your agency's base package.
• Possible breaking changes in major upgrades can be automatically upgraded with tools like TYPO3 Fractor (enhancement for TYPO3 Rector). If a breaking change occurs within User TSconfig, such a tool can automatically upgrade the configuration ensuring that you don't forget to search for them in the depths of the database. This kind of approach could reduce the amount of recurring manual work. Particularly affected by this are large TYPO3 instances with a big amount of be_users or be_groups records.
• Searching within existing User TSconfig which is stored in the database otherwise is possible in your IDE now. All your TSconfig is present in your codebase. This can also improve your daily productivity and greatly simplifies major upgrades. You can also go further and disable/ hide the TSconfig database field in projects to prevent saving User TSconfig in the database for users/groups at all.

Description 

It is now possible to influence the order of content elements within wizard tabs in the new content element wizard by setting before and after values in Page TSconfig.

Previously, only the order of tabs could be configured, but not the order of individual content elements within a tab. This feature extends the existing ordering mechanism to individual content elements, following the same pattern as tab ordering.

This eliminates the need for workarounds like creating custom wizard groups to reorder elements.

mod.wizards.newContentElement.wizardItems {
    default.elements {
        textmedia {
            after = header
        }
        mask_article_card {
            after = textmedia
        }
        # Multiple elements can be specified (comma-separated)
        mask_article_list {
            after = header,textmedia
        }
        # Or use before
        header {
            before = textmedia
        }
    }
}

Impact 

Integrators and developers can now control the exact order of content elements within each wizard tab using Page TSconfig, without needing to create custom wizard groups. The ordering mechanism follows the same syntax and behavior as the existing tab ordering feature (forge#71876), ensuring consistency and familiarity.

The feature works alongside the existing tab ordering: tabs can be ordered using before and after at the group level, and content elements within each tab can be ordered using before and after at the element level.

If no before or after configuration is specified for elements, they will retain their default order (typically the order defined in TCA).

Description 

The email finishers (EmailToSender and EmailToReceiver) of the TYPO3 form framework now support an optional custom message field. This allows editors to add a personalized text to the email sent by the form, either before or after the submitted form values.

The message field supports rich text editing using the form-content RTE preset, which provides formatting options like bold, italic, links, and lists.

A special placeholder {formValues} can be used within the message to control where the submitted form data table is rendered. If the placeholder is omitted, only the custom message is shown and the form values table is hidden.

The message field is available in:

• The form editor backend module
• The form finisher override settings

Impact 

Editors can now configure a custom message for email finishers directly in the form editor or via finisher overrides in the form plugin. This provides more flexibility in crafting email notifications without the need for custom Fluid templates.

Description 

A new CLI command form:cleanup:uploads has been introduced to clean up old file upload folders created by the TYPO3 Form Framework.

When users upload files via FileUpload or ImageUpload form elements, the files are stored in form_<hash> sub-folders inside the configured upload directory. Over time these folders accumulate — both from completed and incomplete form submissions.

Since uploaded files are not moved upon form submission, there is no way to distinguish between folders from completed and abandoned submissions. The command identifies form upload folders by their naming pattern (form_ followed by exactly 40 hex characters) and their modification time. Folders older than a configurable retention period (default: 2 weeks) can be removed.

You must specify at least one upload folder to scan. Since each form element can configure a different upload folder via the saveToFileMount property (e.g. 1:/user_upload/, 2:/custom_uploads/), pass all relevant folders as arguments.

# Dry-run: list form upload folders older than 2 weeks (default)
bin/typo3 form:cleanup:uploads 1:/user_upload/ --dry-run

# Delete folders older than 48 hours
bin/typo3 form:cleanup:uploads 1:/user_upload/ --retention-period=48

# Scan multiple upload folders
bin/typo3 form:cleanup:uploads 1:/user_upload/ 2:/custom_uploads/

# Force deletion without confirmation (useful for scheduler tasks)
bin/typo3 form:cleanup:uploads 1:/user_upload/ --force

# Verbose output shows details about each folder
bin/typo3 form:cleanup:uploads 1:/user_upload/ --dry-run -v

Impact 

The new command provides a safe and configurable way to reclaim disk space from accumulated form upload folders. The conservative default retention period of 2 weeks ensures that files belonging to forms still being actively worked on are not accidentally removed.

Description 

A form element selection button has been added to the property grid editors of the finishers EmailToSender and EmailToRecipient.

Impact 

A button is now displayed in the property grid that allows direct selection of form element identifiers without requiring manual input.

Description 

A new TCA option isViewable is introduced for page types ("doktype") to configure whether a specific page type ("doktype") can be linked to in the page browser and in frontend TypoLink generation.

// Disable linking for custom page type
$GLOBALS['TCA']['pages']['types']['116']['isViewable'] = false;

By default, all page types are viewable unless explicitly set to false.

TYPO3 core now marks the following page types as non-viewable in TCA:

• Spacer (doktype 199)
• SysFolder (doktype 254)

The existing TSconfig option TCEMAIN.preview.disableButtonForDokType is also respected when determining viewability in the backend page browser. If a page type is disabled for preview via TSconfig, it will also be non-viewable.

Impact 

The viewability of pages can now be configured in TCA, following the same pattern as the allowedRecordTypes option introduced in TYPO3 v14.1. This provides a centralized way to control which page types can be linked.

Extensions with custom page types that should not be viewable can now configure this directly in TCA:

$GLOBALS['TCA']['pages']['types'][(string)\MyVendor\MyExtension\Domain\PageType::MY_NON_VIEWABLE_TYPE] = [
    'isViewable' => false,
    'showitem' => '...',
];

Description 

When a Content-Security-Policy violation report needs to be persisted, the \TYPO3\CMS\Core\Security\ContentSecurityPolicy\Event\BeforePersistingReportEvent can be used to provide an alternative report or to prevent a particular report from being persisted at all.

<?php
declare(strict_types=1);

namespace Example\Demo\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\Event\BeforePersistingReportEvent;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\Reporting\Report;

final class BeforePersistingReportEventListener
{
    private const BROWSER_PREFIXES = [
        'chrome-extension://',
        'moz-extension://',
        'safari-extension://',
    ];

    #[AsEventListener('example/security/before-persisting-csp-report')]
    public function __invoke(BeforePersistingReportEvent $event): void
    {
        // avoid persisting CSP violations that were caused by browser extensions
        $blockedUri = $event->originalReport->details['blocked-uri'] ?? null;
        if (is_string($blockedUri) && $this->isBrowserExtensions($blockedUri)) {
            $event->report = null;
            return;
        }
        // otherwise adjust report and provide custom meta-data
        $event->report = new Report(
            $event->originalReport->scope,
            $event->originalReport->status,
            $event->originalReport->requestTime,
            array_merge(
                $event->originalReport->meta,
                ['x-example' => '... additional meta-data ...']
            ),
            $event->originalReport->details,
            $event->originalReport->summary,
            $event->originalReport->uuid,
            $event->originalReport->created,
            $event->originalReport->changed
        );
    }

    private function isBrowserExtensions(string $blockedUri): bool
    {
        foreach (self::BROWSER_PREFIXES as $prefix) {
            if (str_starts_with($blockedUri, $prefix)) {
                return true;
            }
        }
        return false;
    }
}

Impact 

The new BeforePersistingReportEvent allows custom control over whether and how Content-Security-Policy violation reports are persisted in TYPO3.

Description 

TCA slug prefix user functions now receive the full TCA field configuration and the field name as additional parameters.

User Function Implementation 

The prefix user function receives two additional keys alongside the existing parameters:

• fieldName - The name of the slug field
• config - The full TCA configuration array of the slug field

namespace MyExtension\Utility;

class SlugUtility
{
    public function generatePrefix(array $parameters): string
    {
        // Standard parameters (always available)
        $site = $parameters['site'];
        $languageId = $parameters['languageId'];
        $table = $parameters['table'];
        $row = $parameters['row'];

        $fieldName = $parameters['fieldName'];
        $config = $parameters['config'];

        return '/default/';
    }
}

Available Parameters 

The user function receives an array with the following keys:

• site - The current site object
• languageId - The current language ID (int)
• table - The table name (string)
• row - The current record data (array)
• fieldName - The name of the slug field (string)
• config - The full TCA configuration array of the slug field

Impact 

Extension developers can access the complete TCA field configuration and the field name directly within prefix user functions.

Description 

A new \TYPO3\CMS\Core\Pagination\QueryBuilderPaginator is introduced to enable pagination of \TYPO3\CMS\Core\Database\Query\QueryBuilder instances directly.

The paginator implements the existing \TYPO3\CMS\Core\Pagination\PaginatorInterface and integrates seamlessly with the existing \TYPO3\CMS\Core\Pagination\SimplePagination and \TYPO3\CMS\Core\Pagination\SlidingWindowPagination classes.

The paginated items are fetched only once per page request by storing the result internally, avoiding double execution of the database statement.

The total item count is determined robustly using a common table expression (CTE) wrapping the passed QueryBuilder instance. This approach correctly handles advanced queries involving UNION, nested CTEs, windowing functions, or grouping.

Impact 

A new QueryBuilderPaginator is available to paginate QueryBuilder result sets using the standard TYPO3 pagination API.

use TYPO3\CMS\Core\Pagination\QueryBuilderPaginator;
use TYPO3\CMS\Core\Pagination\SimplePagination;

$paginator = new QueryBuilderPaginator(
    queryBuilder: $queryBuilder,
    currentPageNumber: $currentPage,
    itemsPerPage: 10,
);
$pagination = new SimplePagination($paginator);

// Retrieve the items for the current page
$items = $paginator->getPaginatedItems();

Description 

This feature is guarded with toggle "frontend.cache.autoTagging" and experimental for now: The core flushes cache tags for all kind of records automatically when they are created, changed or deleted. For files and folders this is not the case. This feature adds cache tag handling for file or folder operations when they are created, changed or deleted. Also the file metadata changes are handled correctly now. This leads to a better editor experience when the cache tags are used correctly.

Impact 

Integrators and extension developers can now add sys_file_${uid} and sys_file_metadata_${uid} as cache tags and they are flushed correctly from the TYPO3 core when an editor interacts with them in the filelist module.

Description 

A new TCA appearance option lineWrapping has been added for the codeEditor render type. When enabled, long lines are wrapped within the editor instead of requiring horizontal scrolling.

Example:

'config' => [
    'type' => 'text',
    'renderType' => 'codeEditor',
    'format' => 'html',
    'appearance' => [
        'lineWrapping' => true,
    ],
],

Impact 

Code editor fields can now be configured to wrap long lines by setting lineWrapping in the appearance array.

Description 

TYPO3 now supports ICU MessageFormat for translations, enabling proper handling of plural forms, gender-based selections, and other locale-aware formatting directly in language labels.

ICU MessageFormat is an internationalization standard that allows messages to contain placeholders that can vary based on parameters like quantity, gender, or other conditions. This is particularly useful for proper pluralization in languages with complex plural rules.

The format is automatically detected when using named arguments (associative arrays) in translation calls. If the message contains ICU patterns like {count, plural, ...} or {name}, and named arguments are provided, the ICU MessageFormatter will be used automatically.

<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
    <file source-language="en" datatype="plaintext" original="locallang.xlf">
        <body>
            <!-- Simple plural form -->
            <trans-unit id="file_count">
                <source>{count, plural, one {# file} other {# files}}</source>
            </trans-unit>

            <!-- Plural with zero case -->
            <trans-unit id="item_count">
                <source>{count, plural, =0 {no items} one {# item} other {# items}}</source>
            </trans-unit>

            <!-- Combined placeholder and plural -->
            <trans-unit id="greeting">
                <source>Hello {name}, you have {count, plural, one {# message} other {# messages}}.</source>
            </trans-unit>

            <!-- Gender selection -->
            <trans-unit id="profile_update">
                <source>{gender, select, male {He} female {She} other {They}} updated the profile.</source>
            </trans-unit>

            <!-- Simple named placeholder -->
            <trans-unit id="welcome">
                <source>Welcome, {name}!</source>
            </trans-unit>
        </body>
    </file>
</xliff>

use TYPO3\CMS\Core\Localization\LanguageServiceFactory;

$languageService = GeneralUtility::makeInstance(LanguageServiceFactory::class)
    ->createFromUserPreferences($backendUser);

// ICU plural forms - use named arguments
$label = $languageService->translate(
    'file_count',
    'my_extension.messages',
    ['count' => 5]
);
// Result: "5 files"

// Combined placeholder and plural
$label = $languageService->translate(
    'greeting',
    'my_extension.messages',
    ['name' => 'John', 'count' => 3]
);
// Result: "Hello John, you have 3 messages."

// sprintf-style still works with positional arguments
$label = $languageService->translate(
    'downloaded_times',  // Label: "Downloaded %d times"
    'my_extension.messages',
    [42]  // Positional arguments use sprintf
);
// Result: "Downloaded 42 times"

use TYPO3\CMS\Extbase\Utility\LocalizationUtility;

// With named arguments for ICU format
$label = LocalizationUtility::translate(
    'file_count',
    'MyExtension',
    ['count' => 1]
);
// Result: "1 file"

<!-- ICU plural forms with named arguments -->
<f:translate key="file_count" arguments="{count: numberOfFiles}" />

<!-- Combined placeholder and plural -->
<f:translate key="greeting" arguments="{name: userName, count: messageCount}" />

<!-- Gender selection -->
<f:translate key="profile_update" arguments="{gender: userGender}" />

<!-- sprintf-style with positional arguments still works -->
<f:translate key="downloaded_times" arguments="{0: downloadCount}" />

{variable, plural,
    =0 {zero case}
    one {singular case}
    other {plural case}
}

{variable, select,
    male {He}
    female {She}
    other {They}
}

{count, number}           - Basic number
{price, number, currency} - Currency format

Impact 

This feature provides a standards-based approach to pluralization that:

• Uses the well-tested ICU library (via PHP's intl extension)
• Automatically handles locale-specific plural rules
• Supports complex pluralization for languages like Russian or Arabic
• Is backward compatible - existing sprintf-style translations continue to work

The system automatically detects which format to use based on the arguments:

• Named arguments (associative array): Uses ICU MessageFormat
• Positional arguments (indexed array): Uses sprintf

Description 

With Feature: #103504 - New ContentObject PAGEVIEW the new PAGEVIEW cObject has been introduced for the Frontend Rendering. It's a powerful alternative to the FLUIDTEMPLATE cObjct and allows to render a full page with less configuration.

The PAGEVIEW has now been further extended and does also provide all content elements, related to the page, grouped by their corresponding columns as defined in the page layout. The elements are provided as fully resolved Record objects (see Feature: #103783 - RecordTransformation Data Processor and Feature: #103581 - Automatically transform TCA field values for record objects).

The elements are attached to the new ContentArea object, which beside the elements itself also contains all the column related information and configuration. This is quite useful for the frontend rendering, because it might be important for an element to know in which context it should be rendered. With this information, an element can e.g. decide to not render the Header partial if it is included in the sidebar content area.

The ContentArea objects are added to the view using either the variable name defined via contentAs or falls back to content. The content elements can then be accessed via the records property.

The ContentArea's' contain all the backend layout related configuration, such as the content restrictions, which allows further validation, e.g. if the given content types are actually valid.

{content.main.records} can therefore be used to get all content elements from the main content area. main is the identifier, as defined in the page layout and content is the default variable name.

By accessing the ContentArea with {content.main} the following information is available (as defined in the page layout):

• identifier - The column identifier
• colPos - The defined colPos
• name - The (speaking) name, which might be a locallang key
• allowedContentTypes - The defined allowedContentTypes
• disallowedContentTypes - The defined disallowedContentTypes
• slideMode - The defined ContentSlideMode, defaults to ContentSlideMode::None
• configuration - The whole content area related configuration
• records - The content elements as Record objects

The following example is enough to render content elements of a page with a single column:

mod.web_layout.BackendLayouts {
  default {
    title = Default
    config {
      backend_layout {
        colCount = 1
        rowCount = 1
        rows {
          1 {
            columns {
              1 {
                name = Main Content Area
                colPos = 0
                identifier = main
              }
            }
          }
        }
      }
    }
  }
}

page = PAGE
page.10 = PAGEVIEW
page.10.paths.10 = EXT:my_site_package/Resources/Private/Templates/

<f:for each="{content.main.records}" as="record">
    <f:render partial="ContentElement" arguments="{record: record, area: content.main}">
</f:for>

With the introduction of the f:render.contentArea and f:render.record ViewHelpers, manually iterating over content elements is no longer necessary. All elements of a content area can be rendered with a single ViewHelper call:

<!-- Tag syntax -->
<f:render.contentArea contentArea="{content.main}"/>

<!-- Inline syntax -->
{content.main -> f:render.contentArea()}

To render a single record, the f:render.record ViewHelper can be used:

<!-- Tag syntax -->
<f:render.record record="{content.main.records.0}"/>

<!-- Inline syntax -->
{content.main.records.0 -> f:render.record()}

Impact 

It's now possible to access all content elements of a page, grouped by their corresponding column, while having the column related information and configuration at hand. Next to less configuration effort, different renderings for the same element, depending on the context, are easily possible.

Example 

A content element template using the Default layout and rendering the Header partial only in case it has not been added to the sidebar column.

<f:layout name="Default" />

<f:section name="Main">
    <f:if condition="{area.identifier} != 'sidebar'">
        <f:render partial="Header" arguments="{_all} />
    </f:if>

    <p>{record.text}</p>
    <f:image image="{record.image}" width="{area.configuration.imageWidth}" />
</f:section>

Description 

A new TypoScript setting plugin.tx_indexedsearch.settings.pagination_type has been introduced to select the pagination implementation used by EXT:indexed_search.

Available values:

• simple: uses \TYPO3\CMS\Core\Pagination\SimplePagination and renders all result pages.
• slidingWindow: uses \TYPO3\CMS\Core\Pagination\SlidingWindowPagination and limits shown page links according to plugin.tx_indexedsearch.settings.page_links.

The default remains simple to preserve existing behavior. Integrators can switch to slidingWindow to make page_links effective for indexed_search result browsing.

Impact 

Integrators can now switch between core pagination implementations via TypoScript without custom PHP code.

Advanced, fully custom pagination logic can still be implemented via \TYPO3\CMS\IndexedSearch\Event\ModifySearchResultSetsEvent.

Description 

The TYPO3 Form Framework now supports multiple file uploads for the FileUpload and ImageUpload form elements. This allows users to select and upload multiple files at once using a single form field.

The implementation follows the same security patterns as Extbase's file upload handling, using HMAC-signed deletion requests to ensure secure file removal.

type: Form
identifier: contact-form
label: 'Contact Form'
prototypeName: standard
renderables:
  - type: Page
    identifier: page-1
    label: 'Page 1'
    renderables:
      - type: FileUpload
        identifier: attachments
        label: 'Attachments'
        properties:
          multiple: true
          allowRemoval: true
          saveToFileMount: '1:/user_upload/'
          allowedMimeTypes:
            - application/pdf
            - image/jpeg

      - type: ImageUpload
        identifier: images
        label: 'Images'
        properties:
          multiple: true
          allowRemoval: true
          saveToFileMount: '1:/user_upload/'
          allowedMimeTypes:
            - image/jpeg
            - image/png

- type: FileUpload
  identifier: attachments
  label: 'Attachments'
  properties:
    multiple: true
  validators:
    - identifier: Count
      options:
        minimum: 1
        maximum: 5

<formvh:form.uploadDeleteCheckbox
    property="{element.identifier}"
    fileReference="{file}"
    fileIndex="{iterator.index}"
/>

use TYPO3\CMS\Core\Resource\FileInterface;
use TYPO3\CMS\Extbase\Domain\Model\FileReference;
use TYPO3\CMS\Extbase\Persistence\ObjectStorage;
use TYPO3\CMS\Form\Domain\Finishers\AbstractFinisher;
use TYPO3\CMS\Form\Domain\Model\FormElements\FileUpload;

class MyFinisher extends AbstractFinisher
{
    protected function executeInternal(): void
    {
        $formRuntime = $this->finisherContext->getFormRuntime();

        foreach ($formRuntime->getFormDefinition()->getRenderablesRecursively() as $element) {
            if (!$element instanceof FileUpload) {
                continue;
            }

            $file = $formRuntime[$element->getIdentifier()];

            // Single file upload: value is a FileReference
            if ($file instanceof FileReference) {
                $this->processFile($file->getOriginalResource());
            }

            // Multiple file upload: value is an ObjectStorage of FileReferences
            if ($file instanceof ObjectStorage) {
                foreach ($file as $singleFile) {
                    if ($singleFile instanceof FileReference) {
                        $this->processFile($singleFile->getOriginalResource());
                    }
                }
            }
        }
    }

    private function processFile(FileInterface $file): void
    {
        // Your custom logic, e.g. move, copy, attach, etc.
    }
}

use TYPO3\CMS\Extbase\Validation\Validator\AbstractValidator;
use TYPO3\CMS\Form\Mvc\Validation\ObjectStorageElementValidatorInterface;

final class MyFileValidator extends AbstractValidator implements ObjectStorageElementValidatorInterface
{
    public function isValid(mixed $value): void
    {
        // $value is a single element from the ObjectStorage,
        // e.g. a FileReference — NOT the whole collection.
    }
}

Impact 

• Form integrators can now create forms that accept multiple file uploads without custom extensions
• The FileUpload and ImageUpload elements support the new multiple property
• All existing finishers (EmailFinisher, SaveToDatabaseFinisher, DeleteUploadsFinisher) automatically support multiple file uploads
• Email templates display multiple files as a list of filenames
• The summary page displays multiple images as a gallery and multiple files as a filename list

Description 

The image manipulation wizard allows images to be cropped using multiple crop variants. When there were many variants, each one had to be edited individually, and all changes had to be made manually multiple times. This became particularly tedious when the editor wanted to apply precisely the same crop values across all variants.

This feature introduces a new checkbox that allows the editor to crop all variants simultaneously. The prerequisite for enabling this checkbox is that all crop variants must be defined with identical aspect ratios and other identical configuration (apart from its title).

A new sub-option of the cropVariants TCA/TCEFORM option array called excludeFromSync allows developers to exclude specific crop variants from being affected by synchronized cropping.

This is useful, for example, when a special crop variant for a list view is added to the standard set of crop variants, and its differing configuration should still allow the other crop variants to be synchronizable.

Example 

The following code is the definition of the standard crop variants for a bootstrap-based template.

All crop variants are defined identically (except the title) to enable the synchronized cropping feature.

But for tx_news, a new crop variant for the listview is added, and excludeFromSync = 1 is used to specifically allow one exemption of the synchronize-feature.

TCEFORM.sys_file_reference.crop.config.cropVariants {
    xxl {
        title = Very Large Desktop
        selectedRatio = NaN
        allowedAspectRatios {
            # [...] array of defined aspect ratios (identical!)
        }
    }

    xl {
        title = Large Desktop
        selectedRatio = NaN
        allowedAspectRatios {
            # [...] array of defined aspect ratios (identical!)
        }
    }

    # [...]
}

# Override for news extension
TCEFORM.tx_news_domain_model_news.fal_media.config.overrideChildTca.columns.crop.config.cropVariants {
    listview {
        title = List view
        selectedRatio = default
        excludeFromSync = 1
        allowedAspectRatios {
            # [...] array of a custom aspect ratio definition
            # (or identical aspect ratios, but not taken into account
            # for synchronized cropping)
        }
    }
}

Impact 

The editor is now able to apply changes to the image aspect ratio and the image cutting to several matching crop variants at once inside the image manipulation cropping GUI. Exemptions for specific cropVariants can be set.

Description 

The backend page tree search functionality has been enhanced to allow entering a full URI like https://mysite.example.com/de/any/subtree/page/, which will show the matching page in the result tree.

Multiple URIs can be separated by the comma separator (,), just like multiple page IDs can be entered.

Combining a search input like this is possible:

4,8,https://example.com/first,http://sub.example.com/en/second,anyPageTitle

Matches in frontend URIs of translated pages will be marked as such.

This functionality uses the PSR-14 event BeforePageTreeIsFilteredEvent (see Feature: #105833 - Extended page tree filter functionality) for this specific enhancement and can be used as inspiration for custom search variations.

Additionally, the Live Search is also enhanced to perform the same search by a single URI to lookup its page. This is achieved with the new PSR-14 event ModifyConstraintsForLiveSearchEvent (see Feature: #105827 - New PSR-14 ModifyConstraintsForLiveSearchEvent).

The live search will present both the default language page derived from the URI, as well as the actual translated page as a result.

Configuration 

Search by frontend URI is enabled by default and can be controlled in two ways, similar to search by translation:

# Disable searching by frontend URI for specific users/groups
options.pageTree.searchByFrontendUri = 0

Impact 

Editors can now easily locate a backend page when only having the frontend URI available. Permissions to edit/see the page are evaluated. Invalid or non-matching URIs are ignored.

Description 

A new PSR-14 event \TYPO3\CMS\Backend\Search\Event\ModifyConstraintsForLiveSearchEvent has been added to TYPO3 Core. This event is fired in the \TYPO3\CMS\Backend\Search\LiveSearch\LiveSearch class and allows extensions to modify the CompositeExpression constraints gathered in an array, before execution. This allows to add or remove additional constraints to the main query constraints that are combined in an logical OR conjunction, and could not be accessed with the existing event \TYPO3\CMS\Backend\Search\Event\ModifyQueryForLiveSearchEvent .

The event features the following methods:

• getConstraints(): Returns the current array of query constraints (composite expression).
• addConstraint(): Adds a single constraint.
• addConstraints(): Adds multiple new constraints in one go.
• getTableName(): Returns the table, for which the query will be executed (e.g. "pages" or "tt_content").
• getSearchDemand(): Returns the search demand that is getting searched for

Example 

The corresponding event listener class:

<?php

namespace Vendor\MyPackage\Backend\EventListener;

use TYPO3\CMS\Backend\Search\Event\ModifyConstraintsForLiveSearchEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Database\ConnectionPool;

final readonly class PageRecordProviderEnhancedSearch
{
    public function __construct(private ConnectionPool $connectionPool) {}

    #[AsEventListener('my-package/livesearch-enhanced')]
    public function __invoke(ModifyConstraintsForLiveSearchEvent $event): void
    {
        if ($event->getTableName() !== 'pages') {
            return;
        }

        $queryBuilder = $this->connectionPool->getQueryBuilderForTable('pages');
        // Add a constraint so that pages marked with "show_in_all_results=1"
        // will always be shown.
        $constraints[] = $queryBuilder->expr()->eq(
            'show_in_all_results',
            1,
        );

        $event->addConstraints(...$constraints);
    }
}

The Core itself makes uses of this event to allow searching for frontend URIs inside the backend tree.

Impact 

It is now possible to use a new PSR-14 event for adding constraints to the Live Search query, which are OR-combined.

Description 

The debugging exception error handler (which can be set for backend and frontend error reporting) provides a large stack trace with details of an error.

This is often vital when reporting bugs in TYPO3 or debugging custom code.

The output has now been improved:

• Each stack trace segment's filename and line where the error occurred now has a "copy path" button. Clicking on it will copy the whole path, filename and line number to the browser's clipboard.
• The bottom of the page shows two buttons: One to toggle the output above to hide or reveals the file's contents. And another to copy the whole stack trace in plain text format, so that it can be forwarded in error reports.
• A brief section explains what a 'stack trace' is, and a jump functionality to get from the top to the export section is available.

Thanks to Olivier Dobberkau, whose extension https://github.com/dkd-dobberkau/enhanced-error-handler inspired rework of this feature.

Impact 

Errors and their stack traces can now be much more easily copied and forwarded for support questions, without the need to dump a HTML file or even to make screenshots.

File names and the lines of an occurred error can easily be copied to be inserted into the IDE to jump directly to the related code.

Description 

This change aligns the command line arguments of the TYPO3 Console messenger:consume command with the original Symfony Messenger implementation.

The following new options have been added:

• --limit / -l: Limit the number of received messages
• --failure-limit / -f: The number of failed messages the worker can consume
• --memory-limit / -m: The memory limit the worker can consume
• --time-limit / -t: The time limit in seconds the worker can handle new messages
• --bus / -b: Name of the bus to which received messages should be dispatched
• --all: Consume messages from all receivers
• --keepalive: Whether to use the transport's keepalive mechanism if implemented

Scheduler Integration 

The command can be configured as a scheduler task in TYPO3, enabling automated consumption of messages from the configured transports. This is particularly useful for processing asynchronous messages in the background.

This integration helps projects adopt asynchronous message handling by providing a reliable way to process messages without manual intervention. Messages can be dispatched asynchronously during regular request handling and consumed in the background by the scheduler task, improving application performance and user experience.

Usage 

Consume messages from a specific receiver:

php vendor/bin/typo3 messenger:consume my_receiver

Consume messages with a message limit:

php vendor/bin/typo3 messenger:consume my_receiver --limit=10

Stop the worker after 2 failed messages:

php vendor/bin/typo3 messenger:consume my_receiver --failure-limit=2

Stop the worker when memory limit is exceeded:

php vendor/bin/typo3 messenger:consume my_receiver --memory-limit=128M

Stop the worker after a time limit:

php vendor/bin/typo3 messenger:consume my_receiver --time-limit=3600

Consume from specific queues only:

php vendor/bin/typo3 messenger:consume my_receiver --queues=fasttrack

Consume from all configured receivers:

php vendor/bin/typo3 messenger:consume --all

Description 

Enum option labels in site settings definitions can now be localized consistently.

This applies to all common enum declaration styles:

• List-style enum declarations derive localization keys using settings.<settingKey>.enum.<enumValue> in the set labels file.
• Map-style enum declarations are independent of that key schema: only the configured label value is evaluated.
• Map-style enum declarations with localization references (LLL:...) resolve these references.
• Map-style enum declarations with literal labels keep these labels as-is.
• Map-style key-only enum entries fall back to the enum value.
• Map-style empty string labels remain empty strings.

settings:
  my.enumSetting:
    type: string
    default: optionA
    enum:
      - optionA
      - optionB

<trans-unit id="settings.my.enumSetting.enum.optionA">
  <source>Option A (localized)</source>
</trans-unit>
<trans-unit id="settings.my.enumSetting.enum.optionB">
  <source>Option B (localized)</source>
</trans-unit>

settings:
  my.enumSetting:
    type: string
    default: optionA
    enum:
      optionA: 'LLL:EXT:my_extension/Configuration/Sets/MySet/labels.xlf:settings.custom.optionA' # Explicit LLL reference
      optionB: 'Literal Option B' # Literal label
      optionC: # Key-only map-style entry, falls back to enum value "optionC"
      optionD: '' # Empty label stays empty

<trans-unit id="settings.custom.optionA">
  <source>Option A (localized)</source>
</trans-unit>

Impact 

Integrators can localize enum options consistently using the same resolution behavior as other setting labels.

Description 

The DateRange validator of the form extension now supports relative date expressions in addition to absolute dates in Y-m-d format.

This allows form integrators to define dynamic date constraints that are evaluated at runtime, such as ensuring a date of birth is at least 18 years in the past or that a selected date cannot be in the future.

The following relative expressions are supported (matching PHP's strtotime() syntax):

• Named dates: today, now, yesterday, tomorrow
• Relative offsets: -18 years, +1 month, -2 weeks, +30 days

These expressions can be used in the options.minimum and options.maximum properties of the DateRange validator.

Example 

Ensure a date of birth is at least 18 years in the past:

type: Date
identifier: date-of-birth
label: 'Date of birth'
validators:
  -
    identifier: DateRange
    options:
      maximum: '-18 years'

Ensure a date is in the future:

type: Date
identifier: event-date
label: 'Event date'
validators:
  -
    identifier: DateRange
    options:
      minimum: '+1 day'

Mixed absolute and relative dates are also supported:

validators:
  -
    identifier: DateRange
    options:
      minimum: '2020-01-01'
      maximum: 'today'

The form editor in the TYPO3 backend has been updated to accept these relative expressions in the date range fields. The HTML min and max attributes on the rendered <input type="date"> element are automatically resolved to absolute Y-m-d dates at rendering time.

Impact 

Form integrators can now use relative date expressions in the DateRange validator configuration. Existing form definitions using absolute dates continue to work without changes.

Description 

A new User TSconfig options.liveSearch.actions has been introduced to allow an integrator to define default behaviors of a search result.

Available actions:

Impact 

Live Search default actions can now be configured via User TSconfig. Integrators can define global or per-table behavior for search results, improving backend workflows.

The default behavior for pages has been changed to layout to improve the user workflow.

Description 

A new PSR-14 event \TYPO3\CMS\Backend\RecordList\Event\AfterRecordListRowPreparedEvent has been added. This event is fired in the \TYPO3\CMS\Backend\RecordList\DatabaseRecordList and allows extensions to change the data for rendering a single record in the list view.

The event allows to adjust the following properties:

• data: The fields of the row as array. These are the available fields:

  • _SELECTOR_: The checkbox element
  • icon: The icon
  • __label: Special field that contains the header
  • _CONTROL_: The action buttons of the row
  • _LOCALIZATION_: The current language
  • _LOCALIZATION_b: The translated language
  • rowDescription: The row description
  • header: The header (This field is only used if __label is not set. Use __label instead)
  • uid: The record uid (readonly)

• tagAttributes: The html tag attributes of the row. These attributes are available:

  • class
  • data-table
  • title

The corresponding event listener class:

use TYPO3\CMS\Backend\RecordList\Event\AfterRecordListRowPreparedEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;

#[AsEventListener('my-package/backend/my-listener-name')]
class MyEventListener
{
    public function __invoke(AfterRecordListRowPreparedEvent $event): void
    {
        $data = $event->getData();
        $tagAttributes = $event->getTagAttributes();
        // do magic here
        $event->setData($data);
        $event->setTagAttributes($tagAttributes);
    }
}

Impact 

The new PSR-14 event can be used to for example modify the title link in the record list.

Description 

The registration of custom form elements in the TYPO3 Form Framework has been significantly simplified. Previously, registering a custom form element required subscribing to the JavaScript event view/stage/abstract/render/template/perform to render the element in the Form Editor's stage area.

With this improvement, custom form elements can now be registered without any custom JavaScript code. The Form Editor automatically uses a generic Web Component to render form elements in the stage area.

To use this simplified registration method, simply omit the formEditorPartials configuration in your form element's YAML definition. The Form Editor will then automatically render the element using the built-in <typo3-form-form-element-stage-item> Web Component, which provides:

• Element type and identifier display
• Element label with required indicator
• Validators visualization
• Support for select options (SingleSelect, MultiSelect, RadioButton, Checkbox)
• Support for allowed MIME types (FileUpload, ImageUpload)
• Element toolbar
• Hidden state visualization

The generic rendering automatically extracts and displays relevant information from your form element's configuration without requiring any custom template or JavaScript code.

Impact 

Extension developers can now register custom form elements with minimal configuration. By omitting the formEditorPartials configuration, the Form Editor will automatically render the element using a generic Web Component, eliminating the need for:

• Custom Fluid templates in Resources/Private/Backend/Partials/FormEditor/Stage/
• Custom JavaScript code subscribing to view/stage/abstract/render/template/perform
• Manual element rendering logic

This significantly reduces the complexity and maintenance burden when creating custom form elements that don't require special visualization in the Form Editor.

For custom form elements that require specialized rendering or custom interactions in the stage area, the formEditorPartials configuration can still be used to provide custom Fluid templates, which will work as before.

For a complete step-by-step tutorial on creating custom form elements, see :ref:`Creating a Custom Form Element typo3/cms-form:howtos-custom-form-element>.

Description 

Since Redis 6.0, it is possible to authenticate against Redis using both a username and a password. Prior to this version, authentication was only possible with a password. With this patch, you can now configure the TYPO3 Redis session backend as follows:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['session']['BE']
    = [
        'backend' => \TYPO3\CMS\Core\Session\Backend\RedisSessionBackend::class,
        'options' => [
            'database' => 0,
            'hostname' => 'redis',
            'port' => 6379,
            'username' => 'redis',
            'password' => 'redis',
        ]
    ];

Impact 

The "password" configuration option of the Redis session backend is now typed as a array|string. Setting this configuration option with an array is deprecated and will be removed in 15.0.

Description 

A new authorization mechanism has been introduced for Extbase controller actions using PHP attributes. Extension authors can now implement declarative access control logic directly on action methods using the #[Authorize] attribute.

The #[Authorize] attribute supports multiple authorization strategies:

Built-in checks - Require frontend user login via requireLogin - Require specific frontend user groups via requireGroups

Custom authorization logic - Dedicated authorization class (recommended for complex logic) - Public controller method (for simple checks)

Multiple #[Authorize] attributes can be stacked on a single action. All authorization checks must pass for access to be granted. If any check fails, a PropagateResponseException is thrown with an HTTP 403 response, which immediately stops the Extbase dispatching process.

Examples 

namespace MyVendor\MyExtension\Controller;

use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Attribute\Authorize;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    #[Authorize(requireLogin: true)]
    public function listAction(): ResponseInterface
    {
        return $this->htmlResponse();
    }
}

namespace MyVendor\MyExtension\Controller;

use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Attribute\Authorize;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    // Recommended: Use group UIDs
    #[Authorize(requireGroups: [1, 2])]
    public function adminListAction(): ResponseInterface
    {
        // Only accessible to users in groups 1 or 2
        return $this->htmlResponse();
    }

    // Alternative: Use group titles (not recommended)
    #[Authorize(requireGroups: ['administrators', 'editors'])]
    public function editorListAction(): ResponseInterface
    {
        return $this->htmlResponse();
    }

    // Mixed: UIDs and titles can be combined (not recommended)
    #[Authorize(requireGroups: [1, 'editors'])]
    public function mixedListAction(): ResponseInterface
    {
        return $this->htmlResponse();
    }
}

namespace MyVendor\MyExtension\Authorization;

use MyVendor\MyExtension\Domain\Model\MyObject;
use TYPO3\CMS\Core\Context\Context;

class MyObjectAuthorization
{
    public function __construct(
        private readonly Context $context
    ) {}

    public function checkOwnership(MyObject $myObject): bool
    {
        $userAspect = $this->context->getAspect('frontend.user');
        return $myObject->getOwner()->getUid() === $userAspect->get('id');
    }
}

namespace MyVendor\MyExtension\Controller;

use MyVendor\MyExtension\Authorization\MyObjectAuthorization;
use MyVendor\MyExtension\Domain\Model\MyObject;
use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Attribute\Authorize;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    #[Authorize(callback: [MyObjectAuthorization::class, 'checkOwnership'])]
    public function editAction(MyObject $myObject): ResponseInterface
    {
        $this->view->assign('myObject', $myObject);
        return $this->htmlResponse();
    }

    #[Authorize(callback: [MyObjectAuthorization::class, 'checkOwnership'])]
    public function deleteAction(MyObject $myObject): ResponseInterface
    {
        // Delete the object
        return $this->htmlResponse();
    }
}

namespace MyVendor\MyExtension\Controller;

use MyVendor\MyExtension\Domain\Model\MyObject;
use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Core\Context\Context;
use TYPO3\CMS\Extbase\Attribute\Authorize;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    public function __construct(
        private readonly Context $context
    ) {}

    #[Authorize(callback: 'checkOwnership')]
    public function editAction(MyObject $myObject): ResponseInterface
    {
        $this->view->assign('myObject', $myObject);
        return $this->htmlResponse();
    }

    public function checkOwnership(MyObject $myObject): bool
    {
        $userAspect = $this->context->getAspect('frontend.user');
        return $myObject->getOwner()->getUid() === $userAspect->get('id');
    }
}

namespace MyVendor\MyExtension\Controller;

use MyVendor\MyExtension\Authorization\MyObjectAuthorization;
use MyVendor\MyExtension\Domain\Model\MyObject;
use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Attribute\Authorize;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    #[Authorize(requireLogin: true)]
    #[Authorize(requireGroups: [1, 2])]
    #[Authorize(callback: [MyObjectAuthorization::class, 'checkOwnership'])]
    public function editAction(MyObject $myObject): ResponseInterface
    {
        // Only accessible to logged-in users in groups 1 or 2 who own the object
        return $this->htmlResponse();
    }
}

#[Authorize(requireLogin: true, requireGroups: [1, 2])]
public function adminAction(): ResponseInterface
{
    return $this->htmlResponse();
}

namespace MyVendor\MyExtension\EventListener;

use Psr\Http\Message\ResponseFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;
use TYPO3\CMS\Extbase\Authorization\AuthorizationFailureReason;
use TYPO3\CMS\Extbase\Event\Mvc\BeforeActionAuthorizationDeniedEvent;

final class CustomAuthorizationResponseListener
{
    public function __construct(
        private readonly ResponseFactoryInterface $responseFactory,
        private readonly StreamFactoryInterface $streamFactory
    ) {}

    public function __invoke(BeforeActionAuthorizationDeniedEvent $event): void
    {
        // Customize response based on failure reason
        $message = match ($event->getFailureReason()) {
            AuthorizationFailureReason::NOT_LOGGED_IN => 'Please log in to access this page',
            AuthorizationFailureReason::MISSING_GROUP => 'You do not have permission to access this page',
            AuthorizationFailureReason::CALLBACK_DENIED => 'Access to this resource is denied',
        };

        $response = $this->responseFactory->createResponse()
            ->withHeader('Content-Type', 'text/html; charset=utf-8')
            ->withStatus(403)
            ->withBody($this->streamFactory->createStream($message));

        $event->setResponse($response);
    }
}

Security Considerations 

Impact 

Extension authors can now implement secure, declarative authorization checks for Extbase controller actions using the #[Authorize] attribute.

Description 

A new dashboard widget Latest backend logins has been introduced to display the most recent backend user logins directly in the TYPO3 Dashboard. This allows administrators to quickly monitor user activity and track recent backend access patterns without navigating through the system log.

The widget provides a configurable interface where administrators can set the number of logins to display, offering flexibility in monitoring scope.

Each login entry shows:

• The backend user avatar and name
• The corresponding login time

Key benefits:

• Displays recent backend user logins with user details and timestamps
• Provides direct access to login monitoring without navigating system logs
• Offers configurable display limits for different monitoring needs
• Enhances security monitoring with quick access to login patterns

Impact 

This feature improves administrative oversight by providing immediate visibility into recent backend user activity directly within the dashboard interface.

Description 

A new Recently Opened Documents Dashboard Widget has been introduced to display documents that are currently open or were recently accessed in the TYPO3 backend. This allows editors and administrators to quickly return to their work and access frequently edited content without navigating through the page tree or search.

The widget provides a configurable interface where users can set the number of documents to display, offering flexibility based on their workflow needs. Each document entry shows the record icon and title for easy identification and quick access.

Key benefits: Displays recently opened documents with icons and titles Provides quick access to ongoing work without searching Offers configurable display limits for different workflow needs Shows document type icons for visual identification Improves editing efficiency by reducing navigation time Displays documents in reverse chronological order (most recent first)

The widget retrieves documents from the FormEngine session data, ensuring that only currently open or recently accessed documents are displayed. Deleted records are automatically filtered out to maintain data accuracy.

Impact 

This feature improves editorial efficiency by providing immediate access to recently opened documents directly within the dashboard interface, reducing the time spent navigating through the backend to resume work.

Description 

A new Content statistics module has been introduced in the TYPO3 backend under guilabel:Reports`. This module provides data about the usage of content elements in the TYPO3 site.

Overview 

The overview displays all available content element types along with the number of times each type is used. For each element, all associated fields are listed, including key details such as:

• The field type
• Whether it is marked as required
• Whether it is configurable as excludable via user group permissions

Detail view 

The detail view for each content element type lists all corresponding records that are not marked as deleted.

Impact 

The new report offers a convenient way to analyze and optimize content structures within a TYPO3 installation. It helps administrators and developers to:

• Identify unused content element types
• Understand which fields are utilized by specific content element types
• Gain insights into the overall configuration and diversity of content elements

Description 

A new TCA option allowedRecordTypes is introduced for Page Types to configure allowed database tables for specific types ("doktype").

// Allow any record on that Page Type.
$GLOBALS['TCA']['pages']['types']['116']['allowedRecordTypes'] = ['*'];

// Only allow specific tables on that Page Type.
$GLOBALS['TCA']['pages']['types']['116']['allowedRecordTypes'] = ['tt_content', 'my_custom_record'];

The array can contain a list of table names or a single entry with an asterisk * to allow all types.

Per default only the tables pages, sys_category, sys_file_reference and sys_file_collection are allowed, if not overridden with this option.

The defaults are extended, if TCA tables enable the option ctrl.security.ignorePageTypeRestriction. Again, this won't be considered if allowedRecordTypes is set. They need to be configured there as well.

Impact 

The allowed record types for pages can now be configured in TCA. This centralizes the configuration for Page Types and further slims down the need for ext_tables.php, which was utilized before.

Description 

The page module's content element preview functionality has been enhanced to provide editors with better visual representations of content elements directly in the backend.

Impact 

The mentioned enhancement improve the editorial experience in the TYPO3 backend by providing clearer, more informative content previews. Editors can now:

• See formatted HTML content as it will appear to users
• Quickly identify bullet list structure and content

Description 

Previously, the TCA label configuration ( ctrl['label'], ctrl['label_alt'], and ctrl['label_alt_force']) applied globally to all record types within a table. This meant that all content elements in tt_content, regardless of their CType, displayed the same field(s) as their label in the backend.

It is now possible to define a type-specific label configuration directly in the TCA types section. These settings override the global ctrl label configuration for the respective record type:

• label - Primary field used for the record title
• label_alt - Alternative field(s) used when label is empty (or as additional fields)
• label_alt_force - Force display of alternative fields alongside the primary label

This is especially useful for tables like tt_content where different content element types may benefit from showing different fields. For example, an "Image" content element could display the image caption, while a "Text" element shows the header field.

return [
    'ctrl' => [
        'label' => 'header',
        'type' => 'record_type',
        // ... other ctrl configuration
    ],
    'types' => [
        'article' => [
            'label_alt' => 'teaser',
        ],
        'event' => [
            'label_alt' => 'event_date,location',
            'label_alt_force' => true,
        ],
    ],
    // ... columns configuration
];

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addRecordType(
    [
        'label' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.shortcut',
        'value' => 'my-type',
        'icon' => 'my-icon',
        'group' => 'special',
    ],
    'my-header',
    [
        'label' => 'header',
        'label_alt' => 'records',
    ]
);

Impact 

Tables with multiple record types can now define more specific and descriptive labels for each type in the backend user interface. This improves usability and clarity for editors by making it immediately obvious which type of record is being displayed.

This feature is especially useful for:

• Content element tables such as tt_content with different CType values
• Tables with distinct record types serving different purposes
• Plugin records with varying functionality per type
• Any table where the record type changes the record's purpose or meaning

All places in TYPO3 that use \TYPO3\CMS\Backend\Utility\BackendUtility::getRecordTitle() automatically benefit from this feature without any code changes. This includes record lists, page trees, history views, workspaces, and similar backend modules.

Functionality like FormEngine records cannot profit yet from this option, as FormEngine does not support Schema API yet.

Description 

The new configuration option srcAttribute for the YouTubeRenderer and VimeoRenderer can be used to adjust the previously hard-coded src attribute in the generated iframe HTML code. This can be helpful if iframes shouldn't be loaded immediately because of privacy concerns, in which case an alternative such as data-src can be used in the initial HTML markup.

Example:

<f:media
    file="{youtubeVideo}"
    additionalConfig="{srcAttribute: 'data-src'}"
/>

Impact 

The src attribute for YouTube and Vimeo embeds can now be renamed.

Description 

A new QR code button has been added next to the "View" button in various backend modules. Clicking the button opens a modal displaying a scannable QR code for the frontend preview URI.

The button is available in the following locations:

• Page module (Layout view and Language Comparison view)
• List module
• Preview module
• Workspaces module

When working in a workspace, the QR code contains a special preview URI that works without backend authentication. This makes it easy to share workspace previews with colleagues or clients, or to quickly check a draft version on a mobile device by simply scanning the code.

The QR code can be downloaded as PNG or SVG directly from the modal.

Impact 

Editors benefit from a streamlined workflow when sharing page previews or testing pages on mobile devices. The workspace-aware preview URIs eliminate the need to be logged in when scanning the QR code, making it particularly useful for review processes involving external stakeholders.

Description 

With the \TYPO3\CMS\Fluid\Event\ModifyRenderedContentAreaEvent , developers can intercept the rendering of content areas in Fluid templates to modify the output. This depends on content areas being rendered with the new <f:render.contentArea> ViewHelper in Fluid templates, see Introduce Fluid f:render.contentArea ViewHelper.

With the \TYPO3\CMS\Fluid\Event\ModifyRenderedRecordEvent , developers can intercept the rendering of individual records in Fluid templates to modify the output. This depends on records being rendered with the new <f:render.contentArea> or <f:render.record> ViewHelpers in Fluid templates, see Introduce Fluid f:render.record ViewHelper.

Note that any alterations will be output as-is and will not be escaped. If you process insecure content within an event listener, be sure to escape it properly, e.g. by applying htmlspecialchars() to it.

Example 

An example event listener could look like this:

namespace MyVendor\MyExtension\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Fluid\Event\ModifyRenderedContentAreaEvent;
use TYPO3\CMS\Fluid\Event\ModifyRenderedRecordEvent;

final class ModifyRenderedContentEventListener
{
    #[AsEventListener]
    public function modifyContentArea(ModifyRenderedContentAreaEvent $event): void
    {
        $content = 'before area<hr />'. $event->getRenderedContentArea() . '<hr />after area';
        $event->setRenderedContentArea($content);
    }

    #[AsEventListener]
    public function modifyRecord(ModifyRenderedRecordEvent $event): void
    {
        $content = 'before record<hr />'. $event->getRenderedRecord() . '<hr />after record';
        $event->setRenderedRecord($content);
    }
}

Impact 

The new events can be used by extension authors to enhance the output of content areas and records rendered in themes.

Description 

Instead of using the <f:cObject> and <f:for> ViewHelpers to render content areas, the new <f:render.contentArea> ViewHelper can be used.

It allows rendering content areas while enabling other extensions to modify the output via PSR-14 EventListeners.

This is especially useful for adding debugging wrappers or additional HTML structure around content areas.

By default, the ViewHelper renders the content area as-is, but EventListeners can listen to the \TYPO3\CMS\Fluid\Event\ModifyRenderedContentAreaEvent and modify the output.

You need to use the PAGEVIEW config like this: .. code-block:: typoscript

page = PAGE page.10 = PAGEVIEW page.10.paths.10 = EXT:my_site_package/Resources/Private/Templates/

<f:render.contentArea contentArea="{content.left}"/>
or
{content.left -> f:render.contentArea()}

Impact 

Theme creators are encouraged to use the <f:render.contentArea> ViewHelper to allow other extensions to modify the output via EventListeners.

Description 

Instead of using the <f:cObject> ViewHelper to render database records, the new <f:render.record> ViewHelper can be used.

It allows rendering records while enabling other extensions to modify the output via PSR-14 EventListeners.

This is especially useful for adding debugging wrappers or additional HTML structure around content elements.

By default, the ViewHelper renders the record as-is, but EventListeners can listen to the \TYPO3\CMS\Fluid\Event\ModifyRenderedRecordEvent and modify the output.

Usage with the record-transformation data processor:

dataProcessing {
    10 = record-transformation
}

<f:render.record record="{record}"/>
or
{record -> f:render.record()}

You can not only render tt_content records but any database record by defining the rendering in Typoscript.

# Example Typoscript configuration for rendering custom records
sys_category = FLUIDTEMPLATE
sys_category {
  file = EXT:my_extension/Resources/Private/Templates/Category.html
  layoutRootPaths.10 = EXT:my_extension/Resources/Private/Layouts/
  partialRootPaths.10 = EXT:my_extension/Resources/Private/Partials/
  dataProcessing.1421884800 = record-transformation
}

# Example Typoscript configuration for special record types
tx_myextension_domain_model_product = COA
tx_myextension_domain_model_product.default = FLUIDTEMPLATE
tx_myextension_domain_model_product.default {
  templateName >
  templateName.ifEmpty.cObject = TEXT
  templateName.ifEmpty.cObject {
    field = record_type
    required = 1
    case = uppercamelcase
  }
  # for record_type = 'mainProduct' the template file my_extension/Resources/Private/Templates/Product/MainProduct.html will be used
  layoutRootPaths.10 = EXT:my_extension/Resources/Private/Layouts/
  partialRootPaths.10 = EXT:my_extension/Resources/Private/Partials/
  templateRootPaths.10 = EXT:my_extension/Resources/Private/Templates/Product/
  dataProcessing.1421884800 = record-transformation
}

Impact 

Theme creators are encouraged to use the <f:render.record> ViewHelper to allow other extensions to modify the output via EventListeners.

Description 

The fluid:analyse console command is introduced, which analyses Fluid templates in the current project for correct Fluid syntax and alerts about deprecations that are emitted during template parsing.

Usage:

vendor/bin/typo3 fluid:analyse

Example output:

[DEPRECATION] packages/myext/Resources/Private/Templates/Test.fluid.html: <my:obsolete> has been deprecated in X and will be removed in Y.
[ERROR] packages/myext/Resources/Private/Templates/Test2.fluid.html: Variable identifiers cannot start with a "_": _temp

In its initial implementation, the command automatically finds all Fluid templates within the current project based on the *.fluid.* file extension (See Feature: #108166 - Fluid file extension and template resolving) and analyses them. By default, TYPO3's system extensions are skipped, this can be adjusted by specifying the —-include-system-extensions CLI option.

The following errors and deprecations are currently supported:

• Fluid syntax errors (e. g. invalid nesting of ViewHelper tags)
• Usage of invalid ViewHelpers or ViewHelper namespaces
• Usage of variable names that start with _ (see Breaking: #108148 - Disallow Fluid variable names with underscore prefix)
• Usage of deprecated ViewHelpers or ViewHelper arguments (if deprecation is triggered during parse time, see Deprecating ViewHelpers and Deprecating ViewHelper arguments)

If exceptions are caught during the parsing process of at least one template, the console command has a return status of 1 (error), otherwise it returns 0 (success). This means that deprecations are not interpreted as errors.

This should make it possible to use the command in CI workflows of most projects, since deprecated functionality used by third-party templates won't make the pipeline fail.

Verbose output allows to get feedback of analyzed templates and the number of errors/deprecations (or success).

use TYPO3Fluid\Fluid\Core\Parser\ParsingState;
use TYPO3Fluid\Fluid\Core\Parser\SyntaxTree\ViewHelperNode;
use TYPO3Fluid\Fluid\Core\ViewHelper\AbstractViewHelper;
use TYPO3Fluid\Fluid\Core\ViewHelper\ViewHelperNodeInitializedEventInterface;

/**
 * @deprecated since X, will be removed in Y.
 */
final class ObsoleteViewHelper extends AbstractViewHelper implements ViewHelperNodeInitializedEventInterface
{
    // ...

    public static function nodeInitializedEvent(ViewHelperNode $node, array $arguments, ParsingState $parsingState): void
    {
        trigger_error(
            '<my:obsolete> has been deprecated in X and will be removed in Y.',
            E_USER_DEPRECATED,
        );
    }
}

use TYPO3Fluid\Fluid\Core\Parser\ParsingState;
use TYPO3Fluid\Fluid\Core\Parser\SyntaxTree\ViewHelperNode;
use TYPO3Fluid\Fluid\Core\ViewHelper\AbstractViewHelper;
use TYPO3Fluid\Fluid\Core\ViewHelper\ViewHelperNodeInitializedEventInterface;

final class SomeViewHelper extends AbstractViewHelper implements ViewHelperNodeInitializedEventInterface
{
    public function initializeArguments(): void
    {
        // @deprecated since X, will be removed in Y.
        $this->registerArgument('obsoleteArgument', 'string', 'Original description. Deprecated since X, will be removed in Y');
    }

    public static function nodeInitializedEvent(ViewHelperNode $node, array $arguments, ParsingState $parsingState): void
    {
        if (array_key_exists('obsoleteArgument', $arguments)) {
            trigger_error(
                'ViewHelper argument "obsoleteArgument" in <my:some> is deprecated since X and will be removed in Y.',
                E_USER_DEPRECATED,
            );
        }
    }
}

Impact 

The new fluid:analyse console command can be used to check basic validity of Fluid templates in a project and can discover deprecated functionality used in template files.

Description 

The CLI command backend:user:create now supports the option --language (or -l) to set the desired language for the user interface.

./bin/typo3 backend:user:create --language=de

User creation using environment variables:

TYPO3_BE_USER_NAME=username \
TYPO3_BE_USER_EMAIL=admin@example.com \
TYPO3_BE_USER_GROUPS=<comma-separated-list-of-group-ids> \
TYPO3_BE_USER_LANGUAGE=de \
TYPO3_BE_USER_ADMIN=0 \
TYPO3_BE_USER_MAINTAINER=0 \
./bin/typo3 backend:user:create --no-interaction

Description 

The TYPO3 backend bookmark system has been comprehensively overhauled, introducing a centralized architecture that replaces the legacy "shortcut" implementation.

# Remove a specific default group (e.g., Files)
options.bookmarkGroups.3 >

# Remove all default groups
options.bookmarkGroups >

# Add a custom group with a static label
options.bookmarkGroups.10 = My Custom Group

# Add a custom group with a translatable label using domain syntax
options.bookmarkGroups.11 = my_extension.messages:bookmark_group.custom

# Disable bookmarks entirely
options.enableBookmarks = 0

Impact 

The bookmark toolbar item now opens a dropdown with quick access to recent bookmarks and a link to the full Bookmark Manager. Users can create custom bookmark groups for better organization of their saved pages, records, and modules. Administrators can configure global bookmarks visible to all users. The Bookmarks dashboard widget has been updated to support the new bookmark system with group filtering and limit options. The legacy "shortcut" terminology has been replaced with "bookmark" throughout the backend interface and codebase.

Description 

TYPO3 historically has helper methods for localizations in various places. This patch centralizes localization-related functionality by marking \TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository as public (non-internal) and adding new methods as modern, DI-friendly alternatives to the static BackendUtility methods.

public function getRecordTranslation(
    string|TcaSchema $tableOrSchema,
    int|array|RecordInterface $recordOrUid,
    int|LanguageAspect $language,
    int $workspaceId = 0,
    bool $includeDeletedRecords = false,
): ?RawRecord

public function getRecordTranslations(
    string|TcaSchema $tableOrSchema,
    int|array|RecordInterface $recordOrUid,
    array $limitToLanguageIds = [],
    int $workspaceId = 0,
    bool $includeDeletedRecords = false,
): array

public function getPageTranslations(
    int $pageUid,
    array $limitToLanguageIds = [],
    int $workspaceId = 0,
    bool $includeDeletedRecords = false,
): array

Impact 

Extension developers working with record translations in the TYPO3 Backend now have access to modern, injectable repository methods that follow current TYPO3 coding practices.

The legacy static methods BackendUtility::getRecordLocalization(), BackendUtility::getExistingPageTranslations(), and BackendUtility::translationCount() remain available for backward compatibility until migrated completely.

Description 

The Form Editor's tree component has been completely modernized, migrating from the legacy jQuery-based implementation to a modern Web Components architecture using Lit and the TYPO3 backend tree infrastructure.

Impact 

Form editors will immediately notice the improved responsiveness and modern feel of the tree component. Drag and drop operations are smoother and more predictable. The search functionality makes working with large forms significantly easier. The tree maintains its state during operations, reducing friction and improving workflow efficiency.

The new Web Component-based architecture ensures better maintainability and extensibility for future enhancements. The component integrates seamlessly with the existing Form Editor without requiring changes to form definitions or configurations.

Description 

A new service \TYPO3\CMS\Backend\Preview\RecordFieldPreviewProcessor has been introduced to provide common field rendering helpers for custom content element preview renderers.

Previously, these helper methods were only available in StandardContentPreviewRenderer, which required custom preview renderers to extend that class to access them.

Instead, this service uses the pattern of Composition over Inheritance.

The new service provides the following methods:

public function prepareFieldWithLabel(RecordInterface $record, string $fieldName): ?string

public function prepareField(RecordInterface $record, string $fieldName): ?string

public function prepareText(RecordInterface $record, string $fieldName, int $maxLength = 1500): ?string

public function preparePlainHtml(RecordInterface $record, string $fieldName, int $maxLines = 100): ?string

public function prepareFiles(iterable|FileReference $fileReferences): ?string

public function linkToEditForm(string $linkText, RecordInterface $record, ServerRequestInterface $request): string

Impact 

Extension developers implementing custom preview renderers can now inject RecordFieldPreviewProcessor to access common field rendering helpers without extending StandardContentPreviewRenderer.

Example usage:

use TYPO3\CMS\Backend\Preview\RecordFieldPreviewProcessor;
use TYPO3\CMS\Backend\Preview\PreviewRendererInterface;

final class MyCustomPreviewRenderer implements PreviewRendererInterface
{
    public function __construct(
        private readonly RecordFieldPreviewProcessor $fieldProcessor,
    ) {}

    public function renderPageModulePreviewContent(GridColumnItem $item): string
    {
        $record = $item->getRecord();
        $content = $this->fieldProcessor->prepareFieldWithLabel($record, 'header');
        $content .= $this->fieldProcessor->prepareFiles($record->get('image'));
        return $content;
    }
}

Description 

A new backend module Link Management > Short URLs has been introduced. It enables editors to create and manage short URLs that redirect visitors to a configurable target. Short URLs are stored as sys_redirect records with the dedicated record type short_url, providing a streamlined editing form that hides redirect-specific fields irrelevant to short URL use cases.

Impact 

Editors benefit from a dedicated interface for managing short URLs without needing to understand redirect configuration details. The module provides a central location for creating, reviewing, and maintaining short URLs with built-in safeguards against duplicates and accidental modifications.

Description 

A new UserSettings object provides structured access to backend user profile settings defined via $GLOBALS['TYPO3_USER_SETTINGS'].

$userSettings = $GLOBALS['BE_USER']->getUserSettings();

// Check if a setting exists
if ($userSettings->has('colorScheme')) {
    $scheme = $userSettings->get('colorScheme');
}

// Get all settings as array
$allSettings = $userSettings->toArray();

// Typed access via dedicated methods
$emailOnLogin = $userSettings->isEmailMeAtLoginEnabled();
$showUploadFields = $userSettings->isUploadFieldsInTopOfEBEnabled();

// Writing still uses the uc mechanism
$GLOBALS['BE_USER']->uc['colorScheme'] = 'dark';
$GLOBALS['BE_USER']->writeUC();
// Both uc (serialized) and user_settings (JSON) are updated

Impact 

Backend user profile settings can now be accessed via the UserSettings object, providing type safety and IDE support. The new JSON storage format improves data accessibility while maintaining full backward compatibility through dual-write to both storage formats.

Description 

This feature introduces a visual badge in the Layout Module to indicate when the Slide Mode is active. The badge serves as a clear indicator for editors, enhancing the user experience by providing immediate feedback on the current mode of operation.

For each slide mode there is a corresponding badge, with corresponding description.

For slideMode None, no badge is shown. For slideMode Slide, a badge with the text "Slide" is shown, only if there are currently no content elements in the current page. For slideMode Collect, a badge with the text "Collect" is shown. For slideMode CollectReverse, a badge with the text "CollectReverse" is shown.

Description 

The backend user profile settings configuration, previously stored in $GLOBALS['TYPO3_USER_SETTINGS'], is now available in TCA at $GLOBALS['TCA']['be_users']['columns']['user_settings'] .

This allows the user settings to benefit from TCA-based tooling and provides a consistent API that extensions already use for other configurations.

A new method ExtensionManagementUtility::addUserSetting() has been introduced to simplify adding custom fields to the user profile settings.

Impact 

Extensions can add custom fields to the backend user profile settings using the new addUserSetting() method in Configuration/TCA/Overrides/be_users.php:

// Configuration/TCA/Overrides/be_users.php
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addUserSetting(
    'myCustomSetting',
    [
        'label' => 'LLL:EXT:my_ext/Resources/Private/Language/locallang.xlf:myCustomSetting',
        'config' => [
            'type' => 'check',
            'renderType' => 'checkboxToggle',
        ],
    ],
    'after:emailMeAtLogin'
);

Alternatively, extensions can directly modify the TCA:

// Configuration/TCA/Overrides/be_users.php
$GLOBALS['TCA']['be_users']['columns']['user_settings']['columns']['myCustomSetting'] = [
    'label' => 'LLL:EXT:my_ext/Resources/Private/Language/locallang.xlf:myCustomSetting',
    'config' => [
        'type' => 'check',
        'renderType' => 'checkboxToggle',
    ],
];

// Add to showitem
$GLOBALS['TCA']['be_users']['columns']['user_settings']['showitem'] .= ',myCustomSetting';

Description 

The new console command fluid:namespaces has been introduced which lists all available global ViewHelper namespaces in the current project. This can be used to verify the current configuration. With the --json option, it is also possible to access that information in a machine-readable way.

Usage:

vendor/bin/typo3 fluid:namespaces

Example output:

+--------+------------------------------+
| Alias  | Namespace(s)                 |
+--------+------------------------------+
| core   | TYPO3\CMS\Core\ViewHelpers   |
+--------+------------------------------+
| formvh | TYPO3\CMS\Form\ViewHelpers   |
+--------+------------------------------+
| f      | TYPO3Fluid\Fluid\ViewHelpers |
|        | TYPO3\CMS\Fluid\ViewHelpers  |
+--------+------------------------------+

The same information is also available in the Configuration module in the TYPO3 backend.

Impact 

The new console command allows developers and integrators to inspect registered global ViewHelper namespaces in the current project.

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 should be displayed in the frontend.

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

The input can be a \TYPO3\CMS\Core\Domain\RecordInterface , \TYPO3\CMS\Frontend\Page\PageInformation , or \TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface .

This allows to input a Record, a ContentBlockData object, a PageInformation object, or an Extbase Model. PageInformation and Extbase Models are internally converted to a RecordInterface.

Usage 

Usage with the record-transformation data processor:

dataProcessing {
    10 = record-transformation
}

Based on the field's TCA configuration from the provided record, the ViewHelper chooses the appropriate processing of the field (plain text, multiline text or rich text) without 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 an Extbase model (property name differs from database field name):

The field argument always refers to the database/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 that should 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 types of fields.

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 directly via {record.title} can continue to do so. However, using <f:render.text> is recommended 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.

Impact 

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

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

Description 

The \TYPO3\CMS\Frontend\Controller\ErrorController has been enhanced with a new method customErrorAction(), which allows flexible error handling for custom HTTP status codes.

The new method can be used with TYPO3 site page error handling, allowing site administrators to configure dedicated error handling (e.g., rendering a Fluid template) for a given status code.

Example for usage in an Extbase action:

$response = GeneralUtility::makeInstance(ErrorController::class)->customErrorAction(
    $this->request,
    429,
    'Rate limit exceeded.',
    'You have exceeded the rate limit.'
);
throw new PropagateResponseException($response, 1771065101);

Impact 

It is now possible to trigger custom error pages with specific HTTP status codes and messages from within TYPO3 or extensions, while still respecting the site's configured error handling.

Description 

JavaScript modules can now import language labels as code. The labels are exposed as a object that offers a get() method and allows to substitute placeholders according to the ICU message format.

// Import labels from language domain "core.bookmarks"
import { html } from 'lit';
import labels from '~labels/core.bookmarks';

// Use label
html`<p>{labels.get('groupType.global')}</p>`

// Retrieve label and use ICU Message Format placeholders
// Example label: <source>File "{filename}" deleted</source>
html`<p>{labels.get('file.deleted', { filename: 'my-file.txt' })}</p>`

// Render a label containing pseudo xml-tags
// Example label: "File <bold>{filename}</bold> deleted"
html`<p>{labels.get('file.deleted', {
    filename: 'my-file.txt'
    // Callback function that renders the contents of `<bold>`
    bold: chunks => html`<strong>${chunks}</strong>`,
})}</p>`

This avoids the need for controllers to inject arbitrary labels into global TYPO3.lang configuration, which impeded writing generic web components. (Often hindered simple adopting by a plain import)

Virtual JavaScript modules (schema ~label/{language.domain}) are created that resolve the labels for the specified language domain, that is provided after the prefix ~label/. Technically this mapping is implemented using an importmap path prefix, which instructs to the JavaScript engine to append the specified suffix to the mapped prefix.

The labels are allowed to be cached client side with a far future cache timeout, similar to static resources. We therefore generate version and locale-specific URLs, to ensure labels can be cached by the user agent, without requiring explicit cache invalidation.

Impact 

Extension developers can now use labels in JavaScript components, without requiring to preload labels globally or per module, reducing the risk for missing labels and simplifying developer workflows.

Several hacks like pushing labels to the top frame, loading labels globally or adding labels to component attributes have been used previously and will be replaced by this infrastructure.

Description 

The TYPO3 form editor now supports rich text editing for textarea fields using CKEditor 5. Form elements can be configured to use any available RTE preset, providing a consistent editing experience across the entire TYPO3 backend.

The implementation includes a new RichTextConfigurationService that resolves CKEditor configuration from global TYPO3 RTE presets and prepares it for use in the form editor context. External plugins like the TYPO3 link browser are automatically configured.

Impact 

Form integrators can now enable rich text editing for any textarea field in the form editor by configuring it in the form YAML configuration.

The following form elements and finishers now support rich text editing out of the box:

• StaticText element - Formatted text in forms
• Checkbox element - Labels with links for privacy policies, etc.
• Confirmation finisher - Formatted confirmation messages

All textarea fields in custom form elements can be configured to use the RTE.

prototypes:
  standard:
    formElementsDefinition:
      StaticText:
        formEditor:
          editors:
            300:
              identifier: staticText
              templateName: Inspector-TextareaEditor
              label: formEditor.elements.StaticText.editor.staticText.label
              propertyPath: properties.text
              enableRichtext: true
              richtextConfiguration: form-label

processing:
  HTMLparser_db:
    htmlSanitize:
      build: \MyVendor\MyExtension\Html\MySanitizerBuilder

{formvh:translateElementProperty(element: element, property: 'text')
    -> f:sanitize.html(build: 'myCustomBuild')
    -> f:transform.html()}

$GLOBALS['TYPO3_CONF_VARS']['SYS']['htmlSanitizer']['default']
    = \MyVendor\MyExtension\Html\MySanitizerBuilder::class;

Description 

The Extbase class configuration (persistence mapping) is now exposed in the backend Configuration module (System > Configuration). The module is available when the system extension lowlevel is installed.

The displayed configuration reflects the configured mapping that Extbase uses at runtime: it is built by collecting and merging all Configuration/Extbase/Persistence/Classes.php definitions from active packages.

Impact 

This is a read-only usability improvement: developers and integrators can inspect and verify the resolved Extbase persistence class mapping (including extension overrides) directly in the backend, without dumping configuration arrays or manually checking each Configuration/Extbase/Persistence/Classes.php file.

Description 

Extbase now supports rate limiting for controller actions using the new PHP attribute \TYPO3\CMS\Extbase\Attribute\RateLimit . This feature allows developers to restrict the number of requests a user can make to a specific action within a given time frame.

The rate limiting is based on the client's IP address and uses Symfony's RateLimiter component with a caching framework storage.

The #[RateLimit] attribute supports the following properties:

• limit: The maximum number of requests allowed (default: 5).
• interval: The time window for the limit (e.g., '15 minutes', '1 hour') (default: '15 minutes').
• policy: The rate limiting policy to use (e.g., 'sliding_window', 'fixed_window') (default: 'sliding_window').
• message: An optional translation key for the error message shown when the limit is reached.
• message: An optional, localizable translation key (not a hard-coded string) for the error message shown when the limit is reached like messages.rate_limit_message (the translation domain like my_extension will be automatically used, and must not be part of the key here), or LLL:EXT:my_extension/Resources/Private/Language/locallang.xlf:rate_limit_message.

When a rate limit is exceeded, Extbase returns by default a response with HTTP status code 429 (Too Many Requests).

use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Attribute\RateLimit;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    #[RateLimit(limit: 3, interval: '1 minute', message: 'message.ratelimitexceeded')]
    public function createAction(): ResponseInterface
    {
        // Business logic for creating an entity
        return $this->redirect('index');
    }
}

#[AsEventListener('my_extension/modify-rate-limit-response')]
public function __invoke(BeforeActionRateLimitResponseEvent $event): void
{
    $response = GeneralUtility::makeInstance(ErrorController::class)->accessDeniedAction(
        $event->getRequest(),
        $event->getRateLimit()->message
    );
    throw new PropagateResponseException($response, 1771077885);
}

Impact 

Developers can now protect sensitive Extbase actions (e.g., form submissions, login attempts, or heavy API endpoints) from abuse, spam, or brute-force attacks with minimal effort.

Description 

A new PSR-14 event \TYPO3\CMS\Workspaces\Event\IsReferenceConsideredForDependencyEvent has been added. It is dispatched per sys_refindex row when the workspace dependency resolver evaluates which references constitute structural dependencies during publish, stage, discard, or display operations.

Listeners decide whether a given reference should be treated as a workspace dependency. References are opt-in: the default is "not a dependency", and listeners must explicitly mark relevant references.

The event provides the following methods:

• getTableName(): The table owning the field (refindex tablename).
• getRecordId(): The record owning the field (refindex recuid).
• getFieldName(): The TCA field name (refindex field).
• getReferenceTable(): The referenced table (refindex ref_table).
• getReferenceId(): The referenced record id (refindex ref_uid).
• getAction(): The \TYPO3\CMS\Workspaces\Dependency\DependencyCollectionAction enum value (Publish, StageChange, Discard, or Display).
• getWorkspaceId(): The current workspace id.
• isDependency() / setDependency(): Read or change whether this reference is a structural dependency.

TYPO3 Core registers a listener that marks type=inline, type=file (with foreign_field), and type=flex fields as dependencies.

A new enum \TYPO3\CMS\Workspaces\Dependency\DependencyCollectionAction has been added to represent the action context.

Example 

A third-party extension that stores parent-child relationships in a custom field can register a listener to include those references as workspace dependencies:

<?php

namespace Vendor\MyPackage\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Workspaces\Event\IsReferenceConsideredForDependencyEvent;

#[AsEventListener('my-package/workspace-dependency')]
final class WorkspaceDependencyListener
{
    public function __invoke(IsReferenceConsideredForDependencyEvent $event): void
    {
        if ($event->getFieldName() === 'tx_mypackage_parent') {
            $event->setDependency(true);
        }
    }
}

Impact 

Extensions can now register custom parent-child relationships as workspace dependencies via this PSR-14 event. This ensures that structurally dependent records are published, staged, or discarded together, preventing orphaned records in workspaces.

The internal pseudo-event mechanism (EventCallback, ElementEntityProcessor) used previously has been removed. This is an internal change that does not affect public API.

Description 

A new PSR-14 event \TYPO3\CMS\IndexedSearch\Event\AfterSearchResultSetsAreGeneratedEvent has been introduced to modify complete search result sets in \TYPO3\CMS\IndexedSearch\Controller\SearchController .

The event is dispatched in searchAction() after all result sets have been built. Event listeners can manipulate complete result sets, including pagination, rows, section data, and category metadata.

The event provides the following methods:

• getResultSets(): Returns all result sets of the current search.
• setResultSets(array $resultSets): Replaces the result sets.
• getSearchData(): Returns the search configuration array.
• getSearchWords(): Returns the array of search words.
• getView(): Returns the view instance.
• getRequest(): Returns the current server request.

Example 

The following example replaces every result set pagination with SlidingWindowPagination:

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Pagination\SimplePagination;
use TYPO3\CMS\Core\Pagination\SlidingWindowPagination;
use TYPO3\CMS\IndexedSearch\Event\AfterSearchResultSetsAreGeneratedEvent;

#[AsEventListener(identifier: 'my-extension/modify-search-result-sets')]
final readonly class ModifySearchPaginationListener
{
    public function __invoke(AfterSearchResultSetsAreGeneratedEvent $event): void
    {
        $resultSets = $event->getResultSets();
        foreach ($resultSets as $key => $resultSet) {
            if (($resultSet['pagination'] ?? null) instanceof SimplePagination) {
                $resultSets[$key]['pagination'] = new SlidingWindowPagination(
                    $resultSet['pagination']->getPaginator(),
                    5
                );
            }
        }

        $event->setResultSets($resultSets);
    }
}

Impact 

This event allows modifying complete search result sets in a single listener call. It enables custom pagination strategies as well as advanced search result transformations.

Description 

TYPO3's \TYPO3\CMS\Core\RateLimiter\RateLimiterFactory has been refactored to serve as the single entry point for all rate limiting across the system. A new \TYPO3\CMS\Core\RateLimiter\RateLimiterFactoryInterface extends Symfony's RateLimiterFactoryInterface with additional convenience methods for request-based and login rate limiting.

Previously, the backend and frontend password recovery features, as well as the Extbase rate limiting, each created Symfony rate limiter factories directly, bypassing TYPO3's factory. All consumers now use the central TYPO3 factory, which enables a unified admin override mechanism.

Extension developers should type-hint against \TYPO3\CMS\Core\RateLimiter\RateLimiterFactoryInterface when injecting the factory.

$GLOBALS['TYPO3_CONF_VARS']['SYS']['rateLimiter']['login-be'] = [
    'limit' => 3,
    'interval' => '5 minutes',
];

$GLOBALS['TYPO3_CONF_VARS']['SYS']['rateLimiter']['backend-password-recovery'] = [
    'limit' => 1,
    'interval' => '1 hour',
];

namespace Vendor\MyExtension\Controller;

use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
use TYPO3\CMS\Extbase\Attribute\RateLimit;

class MyController extends ActionController
{
    #[RateLimit(limit: 5, interval: '10 minutes', message: 'ratelimit.dosomething')]
    public function doSomethingAction(): ResponseInterface
    {
        return $this->redirect('index');
    }
}

use Psr\Http\Message\ServerRequestInterface;
use TYPO3\CMS\Core\RateLimiter\RateLimiterFactoryInterface;

class MyService
{
    public function __construct(
        private readonly RateLimiterFactoryInterface $rateLimiterFactory,
    ) {}

    public function doSomething(ServerRequestInterface $request): void
    {
        $limiter = $this->rateLimiterFactory->createRequestBasedLimiter(
            $request,
            [
                'id' => 'my-extension-action',
                'policy' => 'sliding_window',
                'limit' => 10,
                'interval' => '1 hour',
            ]
        );

        $limit = $limiter->consume();
        if (!$limit->isAccepted()) {
            // handle rate limit exceeded
        }
    }
}

$limiter = $this->rateLimiterFactory->createLimiter(
    [
        'id' => 'my-extension-action',
        'policy' => 'sliding_window',
        'limit' => 10,
        'interval' => '1 hour',
    ],
    $userId
);

myRateLimiter:
  class: TYPO3\CMS\Core\RateLimiter\RateLimiterFactory
  arguments:
    $config:
      id: 'my-custom-limiter'
      policy: 'sliding_window'
      limit: 5
      interval: '10 minutes'

Impact 

All rate limiting in TYPO3 now flows through a single factory that supports admin-level overrides. Administrators can tune or restrict rate limits for any component — login, password recovery, Extbase actions, or custom extensions — without modifying code, using $GLOBALS['TYPO3_CONF_VARS']['SYS']['rateLimiter'] .

The login rate limiter now uses human-readable IDs ( login-be, login-fe) instead of SHA1 hashes. Existing cached rate limit state from previous versions will expire naturally.

Description 

A new PSR-14 event \TYPO3\CMS\Backend\Controller\Event\BeforeBackendPageRenderEvent has been introduced. It is dispatched in \TYPO3\CMS\Backend\Controller\BackendController before the main backend page is rendered and provides access to:

• $view ( \TYPO3\CMS\Core\View\ViewInterface ) – assign additional template variables to the backend top frame view
• $javaScriptRenderer ( \TYPO3\CMS\Core\Page\JavaScriptRenderer ) – add custom JavaScript modules to the backend top frame
• $pageRenderer ( \TYPO3\CMS\Core\Page\PageRenderer ) – add further assets such as CSS files (marked @internal)

Example 

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use TYPO3\CMS\Backend\Controller\Event\BeforeBackendPageRenderEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Page\JavaScriptModuleInstruction;

#[AsEventListener(identifier: 'my-extension/before-backend-page-render')]
final class BeforeBackendPageRenderEventListener
{
    public function __invoke(BeforeBackendPageRenderEvent $event): void
    {
        $event->javaScriptRenderer->addJavaScriptModuleInstruction(
            JavaScriptModuleInstruction::create(
                '@my-vendor/my-extension/backend-module.js'
            )
        );
    }
}

Impact 

It is now possible to add custom JavaScript modules and other assets to the TYPO3 backend top frame using the new PSR-14 event \TYPO3\CMS\Backend\Controller\Event\BeforeBackendPageRenderEvent .

Description 

A new web component <typo3-form--date-editor> has been introduced for the form editor backend. It replaces the plain text input for the DateRange validator minimum/maximum fields and the defaultValue field of the Date form element.

Previously, editors had to manually type date values or relative expressions like -18 years into a plain text field. The new structured editor provides a user-friendly UI with five modes:

• No value – Clears the constraint (empty value)
• Today – Sets the value to today
• Absolute date – Native HTML5 date picker producing Y-m-d values
• Relative date – Structured input with direction (past/future), amount and unit (days, weeks, months, years) producing expressions like -18 years or +1 month
• Custom relative expression – Free-text input for arbitrary relative date expressions that go beyond the structured input, such as compound expressions like +1 month +3 days. The input is validated against the configured relative date pattern.

Impact 

The form editor backend now provides a structured, user-friendly editor for date constraints and default values on Date form elements. Editors no longer need to know the PHP relative date syntax — they can simply select a mode, direction, amount and unit from dropdown fields. For advanced use cases, the custom mode allows typing arbitrary relative date expressions with real-time validation. Existing form definitions are not affected and continue to work without changes.

Description 

The page module now features a context panel for editing page properties and content elements. Clicking an edit button opens a slide-in panel next to the page layout. The editing form is displayed inside the panel while the page layout remains visible in the background.

The panel supports all FormEngine fields in an improved UI. The panel header displays the record title along with a Save and Close button. An expand button allows switching to the full record editing form in the content area at any time. After saving, the panel stays open for further edits.

User settings 

The context panel is enabled by default. It can be disabled per user in User Settings via the Use quick editing for records in the page module option. When disabled, edit buttons navigate directly to the full record editing form as before. The setting takes effect immediately.

Impact 

Editors can now edit records in the page module without leaving the page layout context. The full editing form remains accessible for more complex editing tasks.

Description 

The passwordRules option of the passwordGenerator field control has been deprecated. Password generation is now configured through password policies registered in $GLOBALS['TYPO3_CONF_VARS']['SYS']['passwordPolicies'] .

Each password policy can define a generator section with a class implementing \TYPO3\CMS\Core\PasswordPolicy\Generator\PasswordGeneratorInterface . The field control references a policy by name via the new passwordPolicy option instead of defining rules inline.

Impact 

Using the passwordRules option in TCA field control configuration will trigger a PHP deprecation warning. Support for passwordRules will be removed in TYPO3 v15.

Affected installations 

Installations that use the passwordGenerator field control with the passwordRules option in custom TCA configurations, for example on password fields or secret token fields.

Migration 

Replace the passwordRules option with a passwordPolicy reference.

Before:

'fieldControl' => [
    'passwordGenerator' => [
        'renderType' => 'passwordGenerator',
        'options' => [
            'passwordRules' => [
                'length' => 20,
                'upperCaseCharacters' => true,
                'lowerCaseCharacters' => true,
                'digitCharacters' => true,
                'specialCharacters' => false,
            ],
        ],
    ],
],

After: