Also available 

Breaking Changes 

None since TYPO3 v14.0 release.

Features 

Deprecation 

Important 

Description 

A new Link Management > QR Codes backend module has been introduced, grouped alongside the existing Link Management > Redirects module.

The QR Codes module provides editors with an efficient way to generate reusable QR codes for various purposes, such as printing them on promotional materials, booth displays, or marketing collateral.

Each generated QR code contains a permanent, unique URL that never changes, ensuring printed materials remain valid indefinitely. While the QR code URL itself stays constant, the destination it redirects to can be updated at any time, providing flexibility to adapt campaigns or redirect visitors to current content without requiring reprints.

The module includes a convenient button to generate QR codes on demand, offering multiple download options including different formats (PNG, SVG) and customizable sizes to suit various use cases and printing requirements.

Impact 

The new QR Code module enables users to create scannable QR codes that redirect to any specified URL. This feature is particularly valuable for marketing campaigns, events, and printed materials where maintaining flexibility in the destination URL is essential while preserving the QR code itself.

Description 

Site sets can now define route enhancers in a dedicated route-enhancers.yaml file. This allows extensions to provide route enhancers as part of their site set configuration, which are automatically merged into the site configuration when the set is used as a dependency.

The route enhancers from site sets are applied as presets. This means that site-level route enhancer configuration takes precedence and can override set-defined enhancers.

Usage 

Create a route-enhancers.yaml file in your site set directory alongside the config.yaml:

EXT:my_extension/Configuration/Sets/MySet/
├── config.yaml
└── route-enhancers.yaml

The file must contain a routeEnhancers key with the route enhancer definitions:

routeEnhancers:
  MyEnhancer:
    type: Simple
    routePath: '/my-path/{param}'
    aspects:
      param:
        type: StaticValueMapper
        map:
          value1: '1'
          value2: '2'

The route enhancers file supports YAML imports, allowing you to split configuration across multiple files:

imports:
  - { resource: 'route-enhancers/*.yaml' }

routeEnhancers:
  # Additional enhancers can be defined here

Merging behavior 

Route enhancers from site sets are merged in dependency order. When a site uses multiple sets, enhancers from earlier dependencies are loaded first, and later sets can override them.

Site-level route enhancer configuration always takes precedence over set-defined enhancers. This allows sites to customize or override preset configurations from sets.

routeEnhancers:
  PageType:
    type: PageType
    default: '0'
    map:
      feed.xml: '100'

dependencies:
  - my_extension/my-set

routeEnhancers:
  PageType:
    type: PageType
    default: '100'
    map:
      rss.xml: '200'

routeEnhancers:
  PageType:
    type: PageType
    default: '100'
    map:
      feed.xml: '100'
      rss.xml: '200'

Impact 

Extensions can now ship route enhancers as part of their site sets, providing a streamlined way to configure routing for extension functionality. This is particularly useful for extensions that require specific URL patterns, such as sitemap extensions or API endpoints.

Invalid route enhancer configurations are handled gracefully: sets with invalid route-enhancers.yaml files are skipped and logged, similar to other set validation errors.

Description 

The SEO extension now ships its sitemap route enhancers as part of the typo3/seo-sitemap site set. When this set is used as a dependency, the route enhancers for XML sitemaps are automatically configured.

This enables clean URLs for sitemaps out of the box:

• /sitemap.xml - Main sitemap index
• /sitemap-type/pages - Pages sitemap

Previously, these route enhancers had to be manually configured in each site's config.yaml.

Impact 

Sites using the typo3/seo-sitemap set no longer need to manually configure sitemap route enhancers. The clean URLs are available automatically.

Sites can still override or extend the route enhancers in their site configuration if needed.

Description 

The page tree filter has been extended with the ability to search for pages through their translated content. This enhancement makes it significantly easier to find pages in multilingual TYPO3 installations, particularly when editors work primarily with translated content.

The page tree filter now supports two translation search methods:

1. Search by translated page title: When a search phrase matches a translated page title or nav_title, the corresponding default language page will be found and displayed in the page tree.
2. Search by translation UID: When searching for a numeric page UID that belongs to a translated page, the parent default language page will be found and displayed.

Both search methods work seamlessly alongside the existing search capabilities (searching by page title, nav_title, or default language UID).

Configuration 

Translation search is enabled by default and can be controlled in two ways:

# Disable searching in translated pages for specific users/groups
options.pageTree.searchInTranslatedPages = 0

Visual Feedback 

When a page is found through a translation match, a colored label is automatically added to provide clear visual feedback:

Single translation match

Displays "Found in translation: [Language Name]"

Example: When searching for "Produkte", a page found via its German translation shows "Found in translation: German"

Multiple translation matches

Displays "Found in multiple translations"

Example: When searching for "Home", a page with matching French and German translations shows "Found in multiple translations"

Direct matches

Pages matching the search phrase directly (L=0) show "Search result"

Example: When searching for "Products", the English page titled "Products" shows "Search result"

Combined matches

When a page matches both directly and through a translation, both labels are displayed.

Example: Searching for "Home" finds a page titled "Home" with a German translation "Startseite Home" - the page shows both labels.

Flexibility for developers 

Developers can still use the PSR-14 event \TYPO3\CMS\Backend\Controller\Event\AfterPageTreeItemsPreparedEvent to add custom labels or modify the prepared tree items before they are rendered.

Impact 

Editors working in multilingual TYPO3 installations can now efficiently search for pages using translated titles or translation UIDs. The visual labels provide immediate feedback about how search results were matched, improving the user experience when navigating complex page trees.

The feature respects user permissions (language restrictions from user groups) and workspace context, ensuring that only accessible translations are searched.

Description 

The TypoScript function stdWrap.bytes now accepts an additional configuration parameter decimals. It allows to explicitly define the number of decimals in the resulting number representation. By default, the number of decimals is derived from the formatted size.

In addition, the consumed PHP function TYPO3\CMS\Core\Utility\GeneralUtility::formatSize is extended as well. The additional parameter $decimals is added and defaults to null, which results in the same behavior as for the TypoScript function stdWrap.bytes.

lib.fileSize = TEXT
lib.fileSize {
    value = 123456
    bytes = 1
    bytes.decimals = 1
}

Impact 

By allowing to configure the number of decimals in stdWrap.bytes, integrators can now better adapt the output of the formatted size returned by the TypoScript function. This was previously not possible by default and needed some workarounds in TypoScript.

Description 

Until now, localization labels marked as deprecated, for example by using the x-unused-since attribute in XLIFF 1.2 or the subState="deprecated" attribute in XLIFF 2.0, did not trigger a runtime warning. As a result, integrators and developers had no automatic way to detect deprecated labels that were still in use.

With this change, TYPO3 now triggers an E_USER_DEPRECATED error when a deprecated label is first written to the localization cache.

Impacted formats 

<trans-unit id="deprecated_label" x-unused-since="4.5">
    <source>This label is deprecated</source>
</trans-unit>

<unit id="label5">
    <segment subState="deprecated">
        <source>This is label #5 (deprecated in English)</source>
    </segment>
</unit>

Fallback behaviour 

• If a label is deprecated in the fallback language but is overridden in the current locale without a deprecation marker, no deprecation warning is raised.
• If a label is deprecated only in the current locale, TYPO3 falls back to the default language and does not raise a deprecation warning.

A deprecation warning is triggered the first time a deprecated label is written to cache. Subsequent resolutions of the same label use the cached entry and do not trigger additional warnings until the cache is cleared.

The following usages emit a deprecation warning when a deprecated label is resolved.

$this->languageService->sL('EXT:core/Resources/Private/Language/locallang.xlf:someDeprecation');
$this->languageService->sL('core.messages:someDeprecation');

<f:translate key="some_deprecation" domain="core.messages" />

<f:translate key="core.messages:some_deprecation" />

<f:translate key="EXT:core/Resources/Private/Language/locallang.xlf:some_deprecation" />

Impact 

Integrators and developers may encounter new deprecation warnings during runtime or in the deprecation log when deprecated localization labels are used. The warnings help identify and replace outdated labels before they are removed in a future TYPO3 version.

Affected installations 

All TYPO3 installations that use localization labels marked as deprecated are affected. This includes custom extensions, site packages, or integrations that still reference deprecated labels from system or extension language files.

When a custom extension or project defines a label whose identifier ends with .x-unused, that label is considered deprecated regardless of the loader used. Such usage is technically possible but generally unlikely.

Migration 

1. Review the deprecation log for warnings related to localization labels. Note that deprecations are only written the first time a label is used after deleting the cache.
2. Replace usages of deprecated labels with non-deprecated ones where possible.
3. If required, override deprecated labels in a custom locale without a deprecation marker.
4. Remove or update labels marked with x-unused-since in XLIFF 1.2 or with subState="deprecated" in XLIFF 2.0 when they are no longer needed.
5. Avoid defining labels with identifiers ending in .x-unused.

Description 

TYPO3 Core XLF (XLIFF) translation files now consistently use 2-space indentation instead of tabs. This aligns with the formatting used by Crowdin and by PHP's \DOMDocument. The .editorconfig file has been updated accordingly.

In addition to indentation, all XLF files have been normalized using a unified XML formatter. This ensures consistent XML declaration, attribute ordering, and whitespace structure across all XLF files in the Core.

Checking and normalizing XLF formatting 

A new script has been introduced to check and normalize XLF formatting.

./Build/Scripts/runTests.sh -s normalizeXliff -n

./Build/Scripts/runTests.sh -s normalizeXliff

# Show help
./Build/Scripts/xliffNormalizer.php --help

# Check files only (dry-run)
./Build/Scripts/xliffNormalizer.php --root typo3/sysext --dry-run

# Normalize files in place
./Build/Scripts/xliffNormalizer.php --root typo3/sysext

# Check a custom directory
./Build/Scripts/xliffNormalizer.php --root path/to/xlf/files --dry-run

Impact 

Extension developers should update their XLF files to use 2-space indentation and expect normalized XML formatting. The provided script can also be used within extensions to keep XLF files consistent with TYPO3 Core standards.

Breaking Changes 

Features 

Deprecation 

Important 

Description 

The former page type "External link" has been renamed to "Link" and now fully supports all typolink capabilities. It now uses the field link.

Since the field url was only used by this former page type, it has been removed.

Impact 

Custom code that expects the field url to exist in the table pages will fail as the field is not found anymore.

Affected installations 

• TYPO3 projects that used the former page type External URL to link to resources other than true external URLs, for example sections such as #abc.
• TYPO3 projects with custom code that expects the field url to exist in the table pages.

Migration 

The upgrade wizard "Migrate links of pages of type link" automatically migrates pages of the former type External URL to the new page type Link.

It migrates all links that resolve to external URLs. If your project used the External URL field for other purposes — for example, to link sections such as #abc — you must migrate those links manually.

If your project contains custom code that expects the field url to exist in the table pages, you can reintroduce this field via a TCA override, for example:

<?php

defined('TYPO3') || die('Access restricted.');

$GLOBALS['TCA']['pages']['columns']['url'] = [
    'label' => 'External URL',
    'config' => [
        'type' => 'input',
        'size' => 50,
        'max' => 255,
        'required' => true,
        'eval' => 'trim',
        'softref' => 'url',
        'behaviour' => [
            'allowLanguageSynchronization' => true,
        ],
    ],
];

// Adding column to a existing or new palette and configure showitem,
// for a specific doktype the field is still required, for example:
$GLOBALS['TCA']['pages']['palettes]['custom_url'] = [
    'showitem' => 'url',
];
$GLOBALS['TCA']['pages']['types'][$customDokTypeValue] = [
    'showitem' => [
        --div--;core.form.tabs:general,
            doktype,
            --palette--;;title,
            --palette--;;custom_url,
    ],
];

Adding it back at least ensures that the database field is not renamed and dropped by the Database Analyzer. In case TCA is not required while keeping the database field it could be added to a extension ext_tables.sql file.

Description 

The \TYPO3\CMS\Core\Collection\SortableCollectionInterface has been removed from the TYPO3 Core.

This interface was never properly implemented and served no purpose in the codebase. It defined methods for sorting collections via callback functions and moving items within collections, but no concrete implementations existed.

The interface defined the following methods:

• usort($callbackFunction) – for sorting a collection via a given callback function
• moveItemAt($currentPosition, $newPosition = 0) – for moving items within the collection

Impact 

Any code that implements or references \SortableCollectionInterface will trigger a PHP fatal error.

Since this interface was never implemented in the TYPO3 Core and had no real-world usage, the impact should be minimal for most installations.

Affected installations 

Installations with custom extensions that implement or reference the \SortableCollectionInterface are affected.

Migration 

Remove any references to \SortableCollectionInterface from your code.

If you need sortable collection functionality, implement your own sorting logic directly in your collection classes, or use PHP's built-in array sorting functions such as usort(), uasort(), or uksort().

Description 

The default values of the fields imagewidth and imageheight in the tt_content table are now set to null.

This change removes the awkward UI behavior where the fields were previously set to 0 when no value was entered.

Impact 

Custom queries might fail if they expect the fields to be 0 instead of null.

Affected installations 

TYPO3 installations that rely on the imagewidth and imageheight fields of the tt_content table always being integers are affected.

Migration 

Use the "Media fields zero to null" upgrade wizard to update existing field values.

Also, modify your queries to handle null values instead of 0.

Description 

The names of the GET parameters used in the sitemap generated by EXT:seo have been changed from page and sitemap to tx_seo[page] and tx_seo[sitemap], respectively.

Impact 

Applications, routing configurations, and third-party tools that rely on the parameters being named page and sitemap will break.

Affected installations 

This affects installations that use the arguments page and sitemap or override the sitemap templates of EXT:seo.

Migration 

If the arguments are mapped in the routing configuration, the code needs to be slightly adapted. A working example:

routeEnhancers:
  Sitemap:
    type: Simple
    routePath: 'sitemap-type/{sitemap}'
    aspects:
      sitemap:
        type: StaticValueMapper
        map:
          pages: pages
          tx_news: tx_news
          my_other_sitemap: my_other_sitemap
    _arguments:
      sitemap: 'tx_seo/sitemap'

If the templates in EXT:seo/Resources/Private/Templates/XmlSitemap/Index.xml have been modified, adjust the generated links to match the original ones.

If the URL to a single sitemap has been provided to a third-party tool such as a crawler or search engine, it must be re-added using the new URL.

Description 

The Page Module preview rendering has been refactored to use the Record API internally instead of accessing raw database arrays. This affects both custom preview renderers that extend StandardContentPreviewRenderer and Fluid-based preview templates.

The method signature has changed for \TYPO3\CMS\Backend\Preview\StandardContentPreviewRenderer :

• StandardContentPreviewRenderer->linkEditContent() now expects a RecordInterface object as the second $record parameter instead of an array

The \TYPO3\CMS\Backend\View\Event\PageContentPreviewRenderingEvent has also been updated:

• PageContentPreviewRenderingEvent->getRecord() now returns a RecordInterface object instead of an array
• PageContentPreviewRenderingEvent->setRecord() now expects a RecordInterface object instead of an array

Additionally, the @internal class \TYPO3\CMS\Backend\View\BackendLayout\Grid\GridColumnItem has been updated to work with Record objects:

• The constructor of GridColumnItem now requires a RecordInterface object as the third $record parameter instead of an array
• GridColumnItem->getRecord() now returns a RecordInterface object instead of an array
• GridColumnItem->setRecord() now expects a RecordInterface object instead of an array
• A new method GridColumnItem->getRow() has been added to access the raw database array if needed

For Fluid-based content element previews, the template variables have changed. Previously, all record fields were passed as individual variables to the Fluid template. Now, only a single {record} variable is passed, which is a RecordInterface object providing access to all record data through the Record API.

Using the {pi_flexform_transformed} variable in Fluid-based content element previews no longer works. The resolved flex form can be directly accessed on the RecordInterface object, for example via {record.pi_flexform}. The value is a FlexFormFieldValues object, which properly groups the fields by their sheets.

Impact 

Extensions that extend StandardContentPreviewRenderer and override the linkEditContent() method will need to update their method signature.

Extensions that access GridColumnItem->getRecord() expecting an array will need to update their code to work with RecordInterface objects.

Extensions using event listeners for PageContentPreviewRenderingEvent that access the record via getRecord() expecting an array will need to update their code to work with RecordInterface objects.

Custom Fluid templates for content element preview rendering must be updated to use the {record} variable instead of accessing individual field variables.

Affected installations 

All installations with extensions that:

• Extend StandardContentPreviewRenderer and call or override the linkEditContent() method
• Instantiate GridColumnItem or call GridColumnItem->getRecord() / GridColumnItem->setRecord()
• Register event listeners for PageContentPreviewRenderingEvent
• Use custom Fluid templates for content element preview rendering via PageTSconfig mod.web_layout.tt_content.preview.[recordType]

Migration 

For custom preview renderers extending StandardContentPreviewRenderer :

Update the method signature of linkEditContent() to accept a RecordInterface object:

protected function linkEditContent(string $linkText, array $row, string $table = 'tt_content'): string
{
    $uid = (int)$row['uid'];
    $pid = (int)$row['pid'];
    // ...
}

use TYPO3\CMS\Core\Domain\RecordInterface;

protected function linkEditContent(string $linkText, RecordInterface $record): string
{
    $uid = $record->getUid();
    $pid = $record->getPid();
    $table = $record->getMainType();
    // ...
}

For code working with GridColumnItem :

$row = $columnItem->getRecord();
$uid = (int)$row['uid'];
$title = $row['header'];

use TYPO3\CMS\Backend\View\BackendLayout\Grid\GridColumnItem;
use TYPO3\CMS\Core\Domain\RecordInterface;

$record = $columnItem->getRecord();
$uid = $record->getUid();
$title = $record->has('header') ? $record->get('header') : '';

// Or if raw array access is needed:
$row = $columnItem->getRow();
$uid = (int)$row['uid'];

For custom Fluid templates used for content element preview rendering:

<h2>{header}</h2>
<p>{bodytext}</p>
<f:if condition="{image}">
    <p>Image UID: {image}</p>
</f:if>

<h2>{record.header}</h2>
<p>{record.bodytext}</p>
<f:if condition="{record.image}">
    <p>Image UID: {record.image.uid}</p>
</f:if>

For flex form value rendering, there are two options:

<h2>{header}</h2>
<p>{bodytext}</p>
<small>{pi_flexform_transformed.settings.welcome_header}</small>
<f:if condition="{image}">
    <p>Image UID: {image}</p>
</f:if>

<f:variable name="path" value="s_messages/settings" />
<small>{record.pi_flexform.{path}.welcome_header}</small>

<!-- or -->

<small>{record.pi_flexform.sheets.s_messages.settings.welcome_header}</small>

Description 

The backend submodule Database Relations within DB Check provided information about potentially broken database relations. However, the information it displayed was very limited and barely helpful. In addition, the entire module and its code have not received any meaningful updates in recent years.

Due to this, the module has been removed.

Impact 

The module has been removed. Existing links and stored bookmarks will no longer work.

Affected installations 

All TYPO3 installations are affected.

Migration 

There is no migration available.

Description 

The eval method year was used to validate the value of a TCA field. Its implementation was never completed and simply cast the value to an integer.

As there is no clear definition of what a valid year value should be, the method has been removed without substitution.

Impact 

The value year has been removed from the list of supported eval options.

The TCA migration will trigger a deprecation log entry when building the final TCA.

Affected installations 

TYPO3 installations using old extensions that define custom TCA configurations with this option set are affected.

Migration 

Remove the year eval setting from your TCA configuration and use a TCA field type that better suits your needs.

// Use type "number" with an optional range restriction
'variant_a' => [
    'label' => 'My year',
    'config' => [
        'type' => 'number',
        'range' => [
            'lower' => 1990,
            'upper' => 2038,
        ],
        'default' => 0,
    ],
],

// Use a date field with an optional range restriction
'variant_b' => [
    'label' => 'My year',
    'config' => [
        'type' => 'datetime',
        'range' => [
            'lower' => gmmktime(0, 0, 0, 1, 1, 1990),
            'upper' => gmmktime(23, 59, 59, 12, 31, 2038),
        ],
        'nullable' => true,
    ],
],

Description 

The hook $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ext/form']['afterBuildingFinished'] has been removed in favor of the more powerful PSR-14 events \TYPO3\CMS\Form\Event\BeforeRenderableIsAddedToFormEvent and \TYPO3\CMS\Form\Event\AfterFormIsBuiltEvent .

Impact 

Any hook implementation registered under this identifier will no longer be executed in TYPO3 v14.0 and later.

Affected installations 

TYPO3 installations with custom extensions that implement this hook are affected. The extension scanner reports such usages as a weak match.

Migration 

The hook has been removed without a deprecation phase to allow extensions to remain compatible with both TYPO3 v13 (using the hook) and v14+ (using the new events). Implementing the PSR-14 events provides the same or greater control over form rendering.

Use the BeforeRenderableIsAddedToFormEvent or AfterFormIsBuiltEvent to achieve the same functionality with the new event-based system.

Description 

Extbase's PropertyMappingConfigurationInterface is now fully typed with native PHP types.

Impact 

Existing implementations will no longer work without adjustment. According to the Liskov Substitution Principle, all implementations must follow the updated method signatures and type restrictions defined in the interface.

Affected installations 

TYPO3 installations with custom PHP code implementing a custom PropertyMappingConfiguration are affected. Such cases are rare.

Migration 

Add the required native PHP types to all custom implementations of the PropertyMappingConfigurationInterface to fulfill the updated interface definition.

Description 

When using the PHP API of the File Abstraction Layer (FAL), several classes are involved in representing file objects.

In addition to the FileInterface , there is also the AbstractFile class, from which most file- related classes inherit.

To ensure stricter type consistency, the abstract class no longer implements the methods getIdentifier() and setIdentifier(). Implementing these methods is now the responsibility of each subclass.

The methods are now implemented in the respective concrete classes inheriting from AbstractFile .

Impact 

In the unlikely case that the TYPO3 File Abstraction Layer has been extended with custom PHP classes derived from AbstractFile , this change will cause a fatal PHP error, as the new abstract methods getIdentifier() and setIdentifier() must be implemented by the subclass.

Affected installations 

TYPO3 installations that include custom code extending the File Abstraction Layer are affected. Such cases are considered highly uncommon.

Migration 

Implement the two methods getIdentifier() and setIdentifier() in any custom file class extending AbstractFile .

This can also be implemented in older TYPO3 versions to ensure forward compatibility with TYPO3 v14 and later.

Description 

The TYPO3 Doctrine implementation can now handle the proper matching database type for UUID's.

Postgresql natively supports the UUID data type and is way faster than the prior VARCHAR(36) generated from the string type.

The Doctrine DBAL GUID type uses CHAR(26) as the fixed field column size for non-postgres databases, which is compatible as long as valid UUID values were persisted in the configured database table.

Impact 

TYPO3 database tables can now natively properly apply the suitable GUID column type when configured as TCA type=uuid.

A prerequisite for this is that you only have valid UUID's stored in the database table, otherwise the database update will report an error when applying migrations.

Affected installations 

Projects with database table columns set as TCA type=uuid.

Error are likely to occur, if invalid UUID data is stored in field columns configured with this type.

Migration 

Use the database analyzer to migrate the database fields. Invalid values are not migrated and need to be manually cleaned up in affected instances.

Description 

The logout handling has been adjusted to correctly dispatch the PSR-14 event \TYPO3\CMS\FrontendLogin\Event\LogoutConfirmedEvent when a logout redirect is configured. The actionUri variable has been removed, and the logout template has been updated to reflect this change, including correct use of the noredirect functionality.

Impact 

The PSR-14 event LogoutConfirmedEvent is now correctly dispatched when a logout redirect is configured. Additionally, the noredirect parameter is now evaluated during logout.

Affected installations 

TYPO3 installations using EXT:felogin with a custom Fluid template for the logout form.

Migration 

The {actionUri} variable is no longer available and must be removed from custom templates.

Before:

<!-- Before -->
<f:form action="login" actionUri="{actionUri}" target="_top" fieldNamePrefix="">

After:

<f:form action="login" target="_top" fieldNamePrefix="">

The evaluation of the {noRedirect} variable must be added to the template:

Before:

<div class="felogin-hidden">
    <f:form.hidden name="logintype" value="logout" />
</div>

After:

<div class="felogin-hidden">
    <f:form.hidden name="logintype" value="logout" />
    <f:if condition="{noRedirect} != ''">
        <f:form.hidden name="noredirect" value="1" />
    </f:if>
</div>

Description 

Redirect handling for the logoutAction has been removed.

Impact 

The logoutAction no longer performs any configured redirect via plugin settings or GET parameters.

Affected installations 

TYPO3 installations relying on redirect handling within logoutAction are affected.

Migration 

No migration is required. The previous redirect logic in logoutAction() has been removed because it was incorrect: it ignored the showLogoutFormAfterLogin setting and could trigger an unintended redirect even when this option was enabled.

Valid redirects are already processed correctly by loginAction() and overviewAction(), so the faulty branch was removed without replacement.

Description 

The following PHP classes that have previously been marked as deprecated with v13 have been removed:

• \TYPO3\CMS\Backend\Toolbar\Enumeration\InformationStatus (Deprecation entry)
• \TYPO3\CMS\Core\DataHandling\SlugEnricher (Deprecation entry)
• \TYPO3\CMS\Core\Resource\DuplicationBehavior (Deprecation entry)
• \TYPO3\CMS\Core\Type\Enumeration (Deprecation entry)
• \TYPO3\CMS\Core\Type\Icon\IconState (Deprecation entry)
• \TYPO3\CMS\Extbase\Mvc\View\GenericViewResolver (Deprecation entry)
• \TYPO3\CMS\Extbase\Security\Cryptography\HashService (Deprecation entry)
• \TYPO3\CMS\Fluid\View\AbstractTemplateView (Deprecation entry)
• \TYPO3\CMS\Fluid\View\StandaloneView (Deprecation entry)
• \TYPO3\CMS\Fluid\View\TemplateView (Deprecation entry)

The following PHP classes have been declared final:

• \TYPO3\CMS\Extensionmanager\Updates\ExtensionModel (Deprecation entry)

The following PHP interfaces that have previously been marked as deprecated with v13 have been removed:

• \TYPO3\CMS\Core\Domain\Repository\PageRepositoryInitHookInterface (Deprecation entry)
• \TYPO3\CMS\Core\Domain\Repository\PageRepositoryGetPageHookInterface (Deprecation entry)
• \TYPO3\CMS\Extbase\Mvc\View\ViewResolverInterface (Deprecation entry)
• \TYPO3\CMS\Frontend\ContentObject\ContentObjectGetDataHookInterface (Deprecation entry)
• \TYPO3\CMS\Frontend\ContentObject\ContentObjectGetImageResourceHookInterface (Deprecation entry)
• \TYPO3\CMS\Frontend\ContentObject\ContentObjectOneSourceCollectionHookInterface (Deprecation entry)
• \TYPO3\CMS\Frontend\ContentObject\ContentObjectPostInitHookInterface (Deprecation entry)
• \TYPO3\CMS\Frontend\ContentObject\ContentObjectStdWrapHookInterface (Deprecation entry)

The following PHP interfaces changed:

• \TYPO3\CMS\Backend\LoginProvider\LoginProviderInterface->modifyView() added (Deprecation entry)
• \TYPO3\CMS\Backend\LoginProvider\LoginProviderInterface->render() removed (Deprecation entry)
• \TYPO3\CMS\Core\PageTitle\PageTitleProviderInterface->setRequest() added forge#102817

The following PHP class aliases that have previously been marked as deprecated with v13 have been removed:

• \TYPO3\CMS\Backend\Attribute\Controller (Deprecation entry)
• \TYPO3\CMS\Backend\FrontendBackendUserAuthentication (Deprecation entry)
• \TYPO3\CMS\Core\Database\Schema\Types\EnumType (Deprecation entry)
• \TYPO3\CMS\Core\View\FluidViewAdapter forge#105086
• \TYPO3\CMS\Core\View\FluidViewFactory forge#105086
• \TYPO3\CMS\Install\Updates\AbstractDownloadExtensionUpdate (Deprecation entry)
• \TYPO3\CMS\Install\Updates\ExtensionModel (Deprecation entry)

The following PHP class methods that have previously been marked as deprecated with v13 have been removed:

• \TYPO3\CMS\Backend\Controller\LoginController->getCurrentRequest() (Deprecation entry)
• \TYPO3\CMS\Backend\Controller\LoginController->getLoginProviderIdentifier() (Deprecation entry)
• \TYPO3\CMS\Backend\LoginProvider\Event\ModifyPageLayoutOnLoginProviderSelectionEvent->getController() (Deprecation entry)
• \TYPO3\CMS\Backend\LoginProvider\Event\ModifyPageLayoutOnLoginProviderSelectionEvent->getPageRenderer() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getData() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getFieldName() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getPageId() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getPageTsConfig() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getTableName() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setData() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setFieldName() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setPageId() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setPageTsConfig() (Deprecation entry)
• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setTableName() (Deprecation entry)
• \TYPO3\CMS\Core\Authentication\BackendUserAuthentication->returnWebmounts() (Deprecation entry)
• \TYPO3\CMS\Core\Imaging\Event\ModifyIconForResourcePropertiesEvent->getSize() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\DiffUtility->makeDiffDisplay() (Deprecation entry)
• \TYPO3\CMS\Core\Versioning\VersionState->equals() (Deprecation entry)
• \TYPO3\CMS\Extbase\Mvc\View\JsonView->renderSection() (Deprecation entry)
• \TYPO3\CMS\Extbase\Mvc\View\JsonView->renderPartial() (Deprecation entry)
• \TYPO3\CMS\Extbase\Service\CacheService->getPageIdStack() (Deprecation entry)
• \TYPO3\CMS\Fluid\Core\Rendering\RenderingContext->setRequest() (Deprecation entry)
• \TYPO3\CMS\Fluid\Core\Rendering\RenderingContext->getRequest() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->getLayoutRootPaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->getPartialRootPaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->getTemplatePaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->getTemplateRootPaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->getViewHelperResolver() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->hasTemplate() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->initializeRenderingContext() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setCache() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setFormat() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setLayoutPathAndFilename() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setLayoutRootPaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setPartialRootPaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setRequest() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setTemplate() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setTemplatePathAndFilename() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setTemplateRootPaths() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\FluidViewAdapter->setTemplateSource() (Deprecation entry)
• \TYPO3\CMS\Fluid\View\TemplatePaths->fillDefaultsByPackageName() (Deprecation entry)
• \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->addCacheTags() (Deprecation entry)
• \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->getPageCacheTags() (Deprecation entry)
• \TYPO3\CMS\Frontend\Page\PageRepository->enableFields() (Deprecation entry)

The following PHP static class methods that have previously been marked as deprecated for v13 have been removed:

• \TYPO3\CMS\Backend\Utility\BackendUtility::getTcaFieldConfiguration() (Deprecation entry)
• \TYPO3\CMS\Backend\Utility\BackendUtility::thumbCode() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\GeneralUtility::hmac() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPItoST43() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPageTSConfig() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addUserTSConfig() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::getExtensionIcon() (Deprecation entry)
• \TYPO3\CMS\Core\Utility\MathUtility::convertToPositiveInteger() (Deprecation entry)
• \TYPO3\CMS\Core\Versioning\VersionState::cast() (Deprecation entry)

The following methods changed signature according to previous deprecations in v13 at the end of the argument list:

• \TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->__construct() - All arguments are now mandatory (Deprecation entry)
• \TYPO3\CMS\Core\Imaging\IconFactory->getIcon() (argument 4 is now of type \TYPO3\CMS\Core\Imaging\IconState|null) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile->copyTo() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile->moveTo() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile->rename() (argument 2 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\FileInterface->rename() (argument 2 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\FileReference->rename() (argument 2 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\Folder->addFile() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\Folder->addUploadedFile() (argument 2 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\Folder->copyTo() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\Folder->moveTo() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\InaccessibleFolder->addFile() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\InaccessibleFolder->addUploadedFile() (argument 2 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\InaccessibleFolder->copyTo() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\InaccessibleFolder->moveTo() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->addFile() (argument 4 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->addUploadedFile() (argument 4 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->copyFile() (argument 4 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->copyFolder() (argument 4 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->moveFile() (argument 4 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->moveFolder() (argument 4 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Resource\ResourceStorage->renameFile() (argument 3 is now of type \TYPO3\CMS\Core\Resource\Enum\DuplicationBehavior ) (Deprecation entry)
• \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin() (argument 2 $type and 3 $extensionKey have been dropped) (Deprecation entry)

The following public class properties have been dropped:

• \TYPO3\CMS\Core\DataHandling->checkStoredRecords (Deprecation entry)
• \TYPO3\CMS\Core\DataHandling->checkStoredRecords_loose (Deprecation entry)
• \TYPO3\CMS\Core\Utility\DiffUtility->stripTags (Deprecation entry)

The following class property has changed/enforced type:

• \TYPO3\CMS\Extbase\Mvc\Controller\ActionController->view (is now \TYPO3\CMS\Core\View\ViewInterface ) (Deprecation entry)

The following TypoScript options have been dropped or adapted:

• <INCLUDE_TYPOSCRIPT: ...> language construct (Deprecation entry)

The following user TSconfig options have been removed:

• options.pageTree.backgroundColor (Deprecation entry)

The following class constants have been dropped:

• \TYPO3\CMS\Core\Imaging\Icon::SIZE_DEFAULT (Deprecation entry)
• \TYPO3\CMS\Core\Imaging\Icon::SIZE_LARGE (Deprecation entry)
• \TYPO3\CMS\Core\Imaging\Icon::SIZE_MEDIUM (Deprecation entry)
• \TYPO3\CMS\Core\Imaging\Icon::SIZE_MEGA (Deprecation entry)
• \TYPO3\CMS\Core\Imaging\Icon::SIZE_SMALL (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_APPLICATION (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_AUDIO (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_IMAGE (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_TEXT (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_UNKNOWN (Deprecation entry)
• \TYPO3\CMS\Core\Resource\AbstractFile::FILETYPE_VIDEO (Deprecation entry)
• \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_PLUGIN (Deprecation entry)

The following global option handling have been dropped and are ignored:

• $GLOBALS['TYPO3_CONF_VARS']['BE']['defaultPageTSconfig'] (Deprecation entry)
• $GLOBALS['TYPO3_CONF_VARS']['BE']['defaultUserTSconfig'] (Deprecation entry)

The following global variables have been changed:

• $GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['SecondDatabase']['driverMiddlewares']['driver-middleware-identifier'] must be an array, not a class string (Deprecation entry)

The following hooks have been removed:

• $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList']['customizeCsvHeader'] (Deprecation entry)
• $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList']['customizeCsvRow'] (Deprecation entry)

The following TCA options are not evaluated anymore:

• $GLOBALS['TCA'][$table]['types']['subtype_value_field']
• $GLOBALS['TCA'][$table]['types']['subtypes_addlist']
• $GLOBALS['TCA'][$table]['types']['subtypes_excludelist']

The following extbase validator options have been removed:

• errorMessage in \TYPO3\CMS\Extbase\Validation\Validator\RegularExpressionValidator (Deprecation entry)
• Shorthand support of :phpTYPO3.CMS.Extbase usage (Deprecation entry)

The following fallbacks have been removed:

• Accepting arrays returned by readFileContent() in Indexed Search external parsers (Deprecation entry)
• Allowing instantiation of \TYPO3\CMS\Core\Imaging\IconRegistry in ext_localconf.php (Deprecation entry)
• Accepting a comma-separated list of fields as value for the columnsOnly parameter (Deprecation entry)
• Support for extbase repository magic findByX(), findOneByX() and countByX() methods (Deprecation entry)
• Fluid view helpers that extend \TYPO3\CMS\Fluid\ViewHelpers\Form\AbstractFormFieldViewHelper should no longer register class attribute and should rely on attribute auto registration for the error class to be added correctly. (Deprecation entry)
• The legacy backend entry point typo3/index.php has been removed along with handling of composer.json setting extra.typo3/cms.install-deprecated-typo3-index-php (Deprecation entry)

The following upgrade wizards have been removed:

• Install extension "fe_login_mode" from TER
• Migrate base and path to the new identifier property of the "sys_filemounts" table
• Migrate site settings to separate file
• Set workspace records in table "sys_template" to deleted
• Migrate backend user and groups to new module names
• Migrate backend groups "explicit_allowdeny" field to simplified format
• Migrate sys_log entries to a JSON formatted value
• Migrate storage and folder to the new folder_identifier property of the "sys_file_collection" table

The following row updater has been removed:

• \TYPO3\CMS\Install\Updates\RowUpdater\SysRedirectRootPageMoveMigration

The following database table fields have been removed:

• tt_content.list_type (Deprecation entry)

The following JavaScript modules have been removed:

• @typo3/backend/document-save-actions.js (Deprecation entry)
• @typo3/backend/wizard.js (Deprecation entry)
• @typo3/t3editor/* (Deprecation entry)

The following JavaScript method behaviours have changed:

• FormEngineValidation.markFieldAsChanged() always requires HTMLInputElement|HTMLTextAreaElement|HTMLSelectElement to be passed as first argument (Deprecation entry)
• FormEngineValidation.validateField() always requires HTMLInputElement|HTMLTextAreaElement|HTMLSelectElement to be passed as first argument (Deprecation entry)

The following JavaScript method has been removed:

• updateQueryStringParameter() of @typo3/backend/utility.js (Deprecation entry)

The following smooth migration for JavaScript modules have been removed:

• @typo3/backend/page-tree/page-tree-element to @typo3/backend/tree/page-tree-element (Deprecation entry)

The following localization XLIFF files have been removed:

• EXT:backend/Resources/Private/Language/locallang_db_new_content_el.xlf (see referenced change)
• EXT:frontend/Resources/Private/Language/Database.xlf (see referenced change)

The following template files have been removed:

• EXT:fluid_styled_content/Resources/Private/Templates/List.html (Deprecation entry)

The following content element definitions have been removed:

• tt_content.list (Deprecation entry)

Impact 

Using above removed functionality will most likely raise PHP fatal level errors, may change website output or crashes browser JavaScript.

Description 

The DataHandler PHP API has been extended to support both qualified and unqualified ISO8601 date formats, in order to correctly process supplied timezone offsets when provided.

• Qualified ISO8601: Includes an explicit timezone offset (for example, 1999-12-11T10:09:00+01:00 or 1999-12-11T10:09:00Z)
• Unqualified ISO8601: Omits timezone offsets, representing LOCALTIME (for example, 1999-12-11T10:09:00)

Previously, TYPO3 incorrectly used qualified ISO8601 with Z (UTC+00:00) to denote LOCALTIME and applied the server's timezone offset, which led to misinterpretations when another timezone offset was provided, or when real UTC-0 was intended instead of LOCALTIME. Now, timezone offsets are accurately applied if supplied, and are based on server localtime if omitted.

TYPO3 will use unqualified ISO8601 dates internally for communication between FormEngine and the DataHandler API, ensuring timezone offsets are correctly processed – instead of being shifted – when supplied to the DataHandler API.

In essence, this means that existing workarounds for previously applied timezone offsets should be reviewed and removed.

Impact 

TYPO3 now provides accurate and consistent handling of ISO8601 dates, eliminating previous issues related to timezone interpretation and LOCALTIME representation.

Affected installations 

Installations with custom TYPO3 extensions that invoke the DataHandler API with data for type="datetime" fields are affected.

Migration 

Qualified ISO8601 dates with intended timezone offsets and \DateTimeInterface objects can now be passed directly to the DataHandler without requiring manual timezone adjustments.

An example of a previous workaround that added timezone offsets for the DataHandler:

$myDate = new \DateTime('yesterday');
$this->dataHandler->start([
    'tx_myextension_mytable' => [
        'NEW-1' => [
            'pid' => 2,
            // A previous workaround added the localtime offset to supplied
            // dates, as it was subtracted by the DataHandler persistence
            // layer
            'mydatefield_1' => gmdate('c', $myDate->getTimestamp() + (int)date('Z')),
        ],
    ],
]);

Previous timezone-shifting workarounds can be removed and replaced with more intuitive formats.

$myDate = new \DateTime('yesterday');
$this->dataHandler->start([
    'tx_myextension_mytable' => [
        'NEW-1' => [
            'pid' => 2,
            // Pass \DateTimeInterface object directly
            'mydatefield_1' => $myDate,
            // Format as LOCALTIME
            'mydatefield_2' => $myDate->format('Y-m-d\TH:i:s'),
            // Format with timezone information
            // (offsets will be normalized to the persistence timezone
            // format: UTC for integer fields, LOCALTIME for native
            // DATETIME fields)
            'mydatefield_3' => $myDate->format('c'),
        ],
    ],
]);

Description 

The interface \TYPO3\CMS\Core\Resource\Driver\DriverInterface has been updated.

The method signature

public function sanitizeFileName(string $fileName, string $charset = ''): string

has been simplified to:

public function sanitizeFileName(string $fileName): string

Implementing classes no longer need to handle a second argument.

Impact 

This change has little to no impact, since the main API caller - the Core class ResourceStorage - never passed a second argument. The default implementation, LocalDriver , has therefore always behaved as if handling UTF-8 strings.

Affected installations 

TYPO3 installations with custom File Abstraction Layer (FAL) drivers implementing DriverInterface may be affected.

Migration 

Implementing classes should drop support for the second argument. Retaining it does not cause a conflict with the interface, but the TYPO3 Core will never call sanitizeFileName() with a second parameter.

Description 

The following methods have been removed from \TYPO3\CMS\Core\Charset\CharsetConverter :

• CharsetConverter->conv()
• CharsetConverter->utf8_encode()
• CharsetConverter->utf8_decode()
• CharsetConverter->specCharsToASCII(), use CharsetConverter->utf8_char_mapping() instead
• CharsetConverter->sb_char_mapping()
• CharsetConverter->euc_char_mapping()

This removes most helper methods that implemented conversions between different character sets from the TYPO3 Core. The vast majority of websites now use UTF-8 and no longer require the expensive charset conversions previously provided by the Core framework.

Impact 

Calling any of the removed methods will trigger a fatal PHP error.

Affected installations 

The TYPO3 Core has not exposed any of this low-level functionality in upper layers such as TypoScript for quite some time. The removal should therefore have little to no impact on most installations.

The only cases that may be affected are import or export extensions that perform conversions between legacy character sets (for example, those in the EUC family). Affected extensions can mitigate this change by copying the TYPO3 v13 version of the class CharsetConverter , including the relevant files from core/Resources/Private/Charsets/csconvtbl/, into their own codebase.

The extension scanner will detect usages and classify them as weak matches.

Migration 

Avoid calling any of the removed methods. Extensions that still require this functionality should copy the necessary logic into their own codebase or use a third-party library.

This particular case has a direct substitution:

// Before
$charsetConverter->specCharsToASCII('utf-8', $myString);

// After
$charsetConverter->utf8_char_mapping($myString);

Description 

Configuration of Extbase-based backend modules can be done using frontend TypoScript.

The standard prefix in TypoScript to do this is module.tx_myextension. Extbase backend module controllers can typically retrieve their configuration using a call like: $configuration = $this->configurationManager->getConfiguration(ConfigurationManagerInterface::CONFIGURATION_TYPE_SETTINGS, 'myextension');

TypoScript itself is always bound to a page: The frontend must have either some rootline page with a sys_template record or a page that has a site

set, otherwise frontend rendering will terminate with an error message.

Extbase-based backend modules are sometimes bound to pages as well: They can have a rendered page tree configured in their module configuration and then receive the selected page UID within the request as GET parameter id.

Other Extbase-based backend modules, however, are not inside a page scope and do not render the page tree. Examples of such modules within the TYPO3 Core are the backend modules delivered by the form and beuser extensions.

Such Extbase-based backend modules without a page tree had a hard time calculating their relevant frontend TypoScript-based configuration: Since TypoScript is bound to pages, they looked for "the first" valid page in the page tree, and the first valid sys_template record to calculate their TypoScript configuration. This dependency on guesswork made final configuration of Extbase backend module configuration not in page context brittle, opaque, and clumsy.

TYPO3 v14 puts an end to this: Extbase backend modules without page context compile their TypoScript configuration from global TypoScript only and no longer calculating TypoScript by guessing "the first valid" page.

The key call to register such "global" TypoScript is the method ExtensionManagementUtility::addTypoScriptSetup() in ext_localconf.php files.

Impact 

Configuration of Extbase-based backend modules may change if their configuration is defined by the first valid page in the page tree. Configuration of such backend modules can no longer be changed by including TypoScript on the "first valid" page.

Affected installations 

Instances with Extbase-based backend modules without a page tree may be affected.

Migration 

Configuration of Extbase-based backend modules without a page tree must be supplied programmatically and made "global" by extending $GLOBALS['TYPO3_CONF_VARS']['FE']['defaultTypoScript_setup'] using ExtensionManagementUtility::addTypoScriptSetup() within extensions’ ext_localconf.php files. The backend module of the form extension is a good example. Additional locations of extensions that deliver form YAML definitions are defined like this:

use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;

ExtensionManagementUtility::addTypoScriptSetup('
    module.tx_form {
        settings {
            yamlConfigurations {
                1732884807 = EXT:my_extension/Configuration/Yaml/FormSetup.yaml
            }
        }
    }
');

Note it is also possible to use the method ExtensionManagementUtility::addTypoScriptConstants() to declare "global" TypoScript constants and to use them in the TypoScript shown above.

Description 

The class FileNameValidator no longer accepts a custom file deny pattern in __construct(). The service is now stateless and can be injected without side effects.

Impact 

A custom partial regex passed as the first constructor argument when instantiating the service is now ignored. The service relies on $GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern'] configuration and a hard-coded constant as a fallback.

Affected installations 

Instances with custom extensions using GeneralUtility::makeInstance(FileNameValidator::class, 'some-custom-pattern'); are affected. This is expected to be a very rare case.

Migration 

Extensions that need to be tested with custom patterns that cannot be declared globally using $GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern'] should implement their own service for this purpose or inline the necessary code. The core implementation performing the check is only a few lines long.

Description 

The event \TYPO3\CMS\Core\Mail\Event\AfterMailerInitializationEvent has been removed. This event became obsolete with the introduction of the Symfony-based mailer in TYPO3 v10. It was only able to influence the TYPO3 Core mailer by calling the @internal method injectMailSettings() after the settings had already been determined. The event has been removed since it no longer had a meaningful use case.

Impact 

Event listeners registered for this event will no longer be triggered.

Affected installations 

This event has had little purpose since the switch to the Symfony-based mailer and is probably not used in most instances. The extension scanner will find usages.

Migration 

Check if this event can be substituted by reconfiguring $GLOBALS['TYPO3_CONF_VARS']['MAIL'] , or by listening for the event BeforeMailerSentMessageEvent instead.

Description 

When the File Abstraction Layer (FAL) was introduced, the TYPO3 Core file fields media for table pages, and image and assets for table tt_content, had their so-called "overlay palettes" overridden to imageOverlayPalette, so that additional fields like alternative, link, and crop were displayed. However, this was done for all file types, including text, application, and the fallback type unknown. For these types, the additional fields served no meaningful purpose. For this reason, they have now been removed.

Impact 

The TYPO3 Core file fields media for table pages, image and assets for table tt_content, will no longer display the fields alternative and link for file types other than image.

Affected installations 

This affects installations that use one of the Core fields for file types other than image (for example text or application) and make use of the fields alternative and/or link.

This should not affect many installations, as these fields are used primarily for images.

Migration 

These fields can be restored using TCA overrides if necessary. First, register a new palette for the sys_file_reference table containing the desired set of fields.

$GLOBALS['TCA']['sys_file_reference']['palettes']['myCustomPalette'] = [
    'label' => 'My custom palette',
    'showitem' => 'alternative,description,--linebreak--,link,title',
];

Then, use this palette for your specific Core field and file type. The following example restores the fields alternative and link for the media field of the pages table when the file type is text.

use TYPO3\CMS\Core\Resource\FileType;

$GLOBALS['TCA']['pages']['columns']['media']['config']['overrideChildTca']
    ['types'][FileType::TEXT->value]['showitem'] =
    '--palette--;;myCustomPalette,--palette--;;filePalette';

Description 

The TypoScript setting exposeNonexistentUserInForgotPasswordDialog has been removed in EXT:felogin.

Impact 

Using the TypoScript setting exposeNonexistentUserInForgotPasswordDialog has no effect anymore. The password recovery process in EXT:felogin now always shows the same message when a username or email address is submitted in the password recovery form.

Affected installations 

Websites using the TypoScript setting exposeNonexistentUserInForgotPasswordDialog in EXT:felogin are affected.

Migration 

The setting has been removed without replacement. It is possible to use the PSR-14 event SendRecoveryEmailEvent to implement similar functionality if absolutely necessary. From a security perspective, however, it is strongly recommended not to expose the existence of email addresses or usernames.

Description 

An exception handling detail within the File Abstraction Layer (FAL) resource handling has been changed. When calling getSubFolder('mySubFolderName') on a Folder object, and if this subfolder does not exist, the specific \TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException is now raised instead of the global \InvalidArgumentException.

Impact 

The change may affect extensions that directly or indirectly call Folder->getSubFolder() and expect a \InvalidArgumentException to be thrown.

Affected installations 

FolderDoesNotExistException does not extend \InvalidArgumentException. Code that currently expects a \InvalidArgumentException to be thrown needs to be adapted.

Migration 

The change is breaking for code that takes an "optimistic" approach like: "get the subfolder object, and if this throws, create one". Example:

try {
    $mySubFolder = $myFolder->getSubFolder('mySubFolder');
} catch (\InvalidArgumentException) {
    $mySubFolder = $myFolder->createFolder('mySubFolder');
}

This should be changed to catch a FolderDoesNotExistException instead:

use TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException;

try {
    $mySubFolder = $myFolder->getSubFolder('mySubFolder');
} catch (FolderDoesNotExistException) {
    $mySubFolder = $myFolder->createFolder('mySubFolder');
}

Extensions that need to stay compatible with both TYPO3 v13 and v14 should catch both exceptions and should later avoid catching \InvalidArgumentException when v13 compatibility is dropped:

use TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException;

try {
    $mySubFolder = $myFolder->getSubFolder('mySubFolder');
} catch (\InvalidArgumentException|FolderDoesNotExistException) {
    // @todo: Remove \InvalidArgumentException from catch list when
    //        TYPO3 v13 compatibility is dropped.
    $mySubFolder = $myFolder->createFolder('mySubFolder');
}

Description 

Extbase previously supported the TypoScript toggle config.tx_extbase.persistence.updateReferenceIndex to control whether the reference index should be updated when records are persisted.

It has become increasingly important that the reference index is always kept up to date, since an increasing number of TYPO3 Core components rely on current reference index data. Using the reference index at key points can improve read and rendering performance significantly.

This toggle has been removed. Reference index updating is now always enabled.

Impact 

The change may slightly increase database load, which can become noticeable when Extbase updates many records at once.

Affected installations 

Instances with extensions that write many records using the Extbase persistence layer may be affected.

Migration 

The TypoScript toggle config.tx_extbase.persistence.updateReferenceIndex should be removed from any extension codebase, as it is now ignored by Extbase.

Description 

Custom validators implementing \TYPO3\CMS\Extbase\Validation\Validator\ValidatorInterface must now also implement the methods setRequest() and getRequest().

Impact 

Missing implementations of the methods setRequest() and getRequest() will now result in a PHP fatal error.

Affected installations 

TYPO3 installations with custom extensions implementing ValidatorInterface .

Migration 

The methods setRequest() and getRequest() must be implemented in affected validators.

If there is no need to directly implement ValidatorInterface , it is recommended to extend AbstractValidator , where both methods are already implemented.

Description 

The public property \TYPO3\CMS\Core\DataHandling\DataHandler->storeLogMessages has been removed without substitution. It should no longer be used by extensions.

Impact 

Setting or reading the property in an extension will now raise a PHP warning- level error.

Affected installations 

Instances with extensions that access this property are affected. This should be a very rare use case. No TYPO3 Extension Repository (TER) extensions were affected during verification. The extension scanner is configured to find usages as a weak match.

Migration 

The property has been removed. Any code setting or reading it from \TYPO3\CMS\Core\DataHandling\DataHandler instances should be removed. The DataHandler->log() method now always writes the given $details to the sys_log table.

Description 

TYPO3 now uses SHA3-256 for HMAC operations across multiple components, replacing the previously used MD5, SHA1, and SHA256 algorithms. SHA3-256 (Keccak) produces 64-character hexadecimal hashes compared to the 32 or 40 characters of the older algorithms.

The following components have been upgraded:

Database fields have been extended to accommodate the longer hash values (and would even support SHA3-512 with 128 hexadecimal characters in the future):

• be_users.password_reset_token: 100 → 128 characters
• fe_users.felogin_forgotHash: 80 → 160 characters (including additional timestamp details)

Impact 

The algorithm change has the following immediate effects:

URLs with HMAC tokens become invalid:

• cHash parameters in frontend URLs are invalidated
• File dump URLs (file downloads) require regeneration
• Show image URLs require regeneration

Active password reset tokens expire:

• Backend user password reset links in progress become invalid
• Frontend user password reset links in progress become invalid
• Users must request new password reset emails

Session handling:

• Existing session identifiers will be regenerated on next user login
• No immediate session invalidation occurs

Database schema:

• Field lengths are automatically updated during upgrade
• No data migration is required for existing records

Affected installations 

All installations upgrading to TYPO3 v14 are affected.

The impact varies based on usage:

• High impact: installations with active password reset processes or cached frontend URLs with cHash parameters
• Medium impact: installations using file dump or show image controllers with externally stored URLs
• Low impact: all other installations (automatic migration on next use)

Migration 

Database schema updates:

Execute the database analyzer in the Install Tool or run vendor/bin/typo3 upgrade:run.

URLs and caching:

• Frontend caches should be cleared to regenerate cHash values
• File dump and show image URLs regenerate automatically on next access
• External references to file or image URLs must be updated

Sessions:

No manual intervention is required. Sessions are automatically rehashed on next login.

Custom extensions:

If custom code uses HashService::hmac() directly, review whether the default SHA1 algorithm is still appropriate. Consider explicitly passing HashAlgo::SHA3_256 for new HMAC operations:

use TYPO3\CMS\Core\Crypto\HashAlgo;
use TYPO3\CMS\Core\Crypto\HashService;

$hash = $hashService->hmac($data, 'my-additional-secret', HashAlgo::SHA3_256);

Description 

To enable dependency injection for TypolinkBuilder classes, several breaking changes were introduced to the TypolinkBuilder architecture.

The following breaking changes have been made:

• The constructor of AbstractTypolinkBuilder has been removed. Extending classes can no longer rely on receiving ContentObjectRenderer and \TypoScriptFrontendController through the constructor.
• All concrete TypolinkBuilder implementations now implement the new TypolinkBuilderInterface and use dependency injection via their constructors instead of extending AbstractTypolinkBuilder with constructor arguments.
• The method signature of the main link-building method has changed from build(array &$linkDetails, string $linkText, string $target, array $conf) to buildLink(array $linkDetails, array $configuration, ServerRequestInterface $request, string $linkText = '').

Impact 

Custom TypolinkBuilder implementations extending AbstractTypolinkBuilder will fail with fatal errors due to the removed constructor and changed method signatures.

Extensions that instantiate TypolinkBuilder classes directly will also fail, as the constructor signatures have fundamentally changed to use dependency injection.

Affected installations 

TYPO3 installations with extensions that:

• Create custom TypolinkBuilder classes extending AbstractTypolinkBuilder
• Directly instantiate TypolinkBuilder classes in PHP code
• Override or extend the build() method of TypolinkBuilder classes

Migration 

For custom TypolinkBuilder implementations:

1. Implement TypolinkBuilderInterface
2. Use dependency injection in the constructor for required services
3. Replace the build() method with buildLink()

Note: Classes implementing TypolinkBuilderInterface are automatically configured as public services in the dependency injection container - no manual configuration is required.

Example migration:

use TYPO3\CMS\Frontend\Typolink\AbstractTypolinkBuilder;

class MyCustomLinkBuilder extends AbstractTypolinkBuilder
{
    public function build(array &$linkDetails, string $linkText, string $target, array $conf): LinkResultInterface
    {
        // Custom link building logic
        return new LinkResult('news', $linkText);
    }
}

use Psr\Http\Message\ServerRequestInterface;
use TYPO3\CMS\Frontend\Typolink\TypolinkBuilderInterface;

class MyCustomLinkBuilder implements TypolinkBuilderInterface
{
    public function __construct(
        // Inject required dependencies
    ) {}

    public function buildLink(
        array $linkDetails,
        array $configuration,
        ServerRequestInterface $request,
        string $linkText = '',
    ): LinkResultInterface {
        // Custom link building logic - access ContentObjectRenderer via:
        $contentObjectRenderer = $request->getAttribute('currentContentObject');
        return new LinkResult('news', $linkText);
    }
}

For code that instantiates TypolinkBuilder classes directly:

It is strongly recommended to use the LinkFactory instead of instantiating TypolinkBuilder classes directly. The LinkFactory handles proper instantiation and dependency injection automatically.

Description 

Each TCA definition previously had an optional section named ['interface'], which defined parameters for displaying TCA records.

The last remaining options within this section, $GLOBALS['TCA'][$table]['interface']['maxSingleDBListItems'] and $GLOBALS['TCA'][$table]['interface']['maxDBListItems'] , have been removed. As a result, the entire ['interface'] section is no longer supported and will be ignored.

These settings were used to define the number of table rows displayed within the Content > List backend module.

Impact 

The $GLOBALS['TCA'][$table]['interface'] section in TCA definitions is no longer evaluated.

Setting any values under this key in custom extensions has no effect and will be automatically removed during build time.

Affected installations 

TYPO3 installations with custom TCA settings defining $GLOBALS['TCA'][$table]['interface'] are affected.

Migration 

Visual display settings can still be overridden on a per-user or per-page basis via TSconfig. This approach is more flexible, as it allows rendering different numbers of items per site, page tree, or user group.

The TCA option $GLOBALS['TCA'][$table]['interface']['maxSingleDBListItems'] has been removed in favor of mod.web_list.itemsLimitSingleTable.

The TCA option $GLOBALS['TCA'][$table]['interface']['maxDBListItems'] has been removed in favor of mod.web_list.itemsLimitPerTable.

Description 

In TYPO3 v14, the PHP API of the File Abstraction Layer (FAL) has undergone major internal changes that may affect extension authors.

1. Most PHP classes and interfaces within FAL are now strongly typed using native PHP type declarations.

2. Several methods have been moved from AbstractFile to its concrete implementation File , since only this class should provide such behavior. The moved methods are:

   • AbstractFile->rename()
   • AbstractFile->copyTo()
   • AbstractFile->moveTo()
3. The FileInterface method rename() has been removed, as this operation is only relevant to the concrete File implementation.

4. Classes implementing FolderInterface must now implement the following methods to stay compatible with the new Folder class:

   • getSubFolder()
   • getReadablePath()
   • getFiles()
   • searchFiles()

   Previously, this was not enforced, but it is now required to make Folder more interchangeable across implementations.

Impact 

Calling PHP classes or methods from the File Abstraction Layer directly may result in fatal PHP errors if incorrect or missing argument types are used.

Affected installations 

TYPO3 installations with third-party extensions that interact with the FAL PHP API in non-documented ways.

Migration 

Ensure that all FAL-related code passes and expects the correct PHP types when using or extending the API.

If you provide custom implementations of FolderInterface or classes extending AbstractFile , make sure to implement the newly required methods accordingly.

Description 

The following database fields and corresponding TCA definitions have been removed from the database table sys_file_metadata without substitution:

• visible
• fe_groups

These fields were added to the table when the system extension EXT:filemetadata was installed.

Although the field names suggested access control functionality similar to those found in other TYPO3 tables, they were never configured to restrict frontend or backend access. Their intended meaning would have depended on custom implementation and was not supported by the TYPO3 Core.

Additionally, the field status has been moved from the Access tab to the Metadata tab to avoid the impression that this field has any restrictive behavior.

Impact 

The fields visible and fe_groups in sys_file_metadata are no longer used. After performing a Database Compare in the Install Tool, these columns will be removed and their data permanently lost.

Accessing these fields in PHP or TypoScript will result in PHP warnings.

Affected installations 

Any TYPO3 installation using the fields visible or fe_groups provided by the system extension EXT:filemetadata is affected.

Migration 

No automatic migration is available.

If the fields are still required for custom logic, reintroduce their database columns and TCA configuration within a custom extension.

Description 

In earlier TYPO3 versions, the Form Framework provided two template variants for frontend rendering:

• The initial, legacy templates in EXT:form/Resources/Private/Frontend/Templates and EXT:form/Resources/Private/Frontend/Partials, which were deprecated in forge#95456
• The newer, Bootstrap 5 compatible and accessible templates in EXT:form/Resources/Private/FrontendVersion2/Templates and EXT:form/Resources/Private/FrontendVersion2/Partials, introduced with forge#94868

The legacy form templates have now been removed. The rendering option templateVariant, which toggled the template and form configuration variant, has been removed as well.

The newer template variants have been moved to the original file paths of the legacy templates.

Impact 

The removal of the legacy templates and the templateVariant configuration option simplifies the Form Framework rendering logic.

Developers no longer need to choose between multiple template variants, reducing complexity and improving maintainability. Projects already using the newer templates benefit from a cleaner configuration and a unified rendering approach.

Affected installations 

All TYPO3 installations using the Form Framework are affected.

Migration 

If you still rely on the legacy templates, you must migrate your templates and partials to the structure of the newer templates.

Websites that use templateVariant: version2 can simplify their form configuration. Variants with the condition 'getRootFormProperty("renderingOptions.templateVariant") == "version2"' are no longer necessary and can be removed.

Before:

prototypes:
  standard:
    formElementsDefinition:
      Text:
        variants:
          -
            identifier: template-variant
            condition: 'getRootFormProperty("renderingOptions.templateVariant") == "version2"'
            properties:
              containerClassAttribute: 'form-element form-element-text mb-3'
              elementClassAttribute: form-control
              elementErrorClassAttribute: ~
              labelClassAttribute: form-label

After:

prototypes:
  standard:
    formElementsDefinition:
      Text:
        properties:
          containerClassAttribute: 'form-element form-element-text mb-3'
          elementClassAttribute: form-control
          elementErrorClassAttribute: ~
          labelClassAttribute: form-label

Description 

The TCA control option $GLOBALS['TCA'][$table]['ctrl']['is_static'] has been removed, as it is no longer evaluated by the TYPO3 Core.

Originally, this option was introduced to mark certain database tables (for example, from static_info_tables) as containing static, non-editable reference data. Over time, the TYPO3 ecosystem has evolved, and the original purpose of is_static has become obsolete.

Modern TYPO3 installations rarely rely on static data tables. Better mechanisms now exist for managing read-only or reference data, such as the TCA options readOnly and editlock, or backend access control. Removing this legacy option improves maintainability and reduces complexity for newcomers.

Impact 

The option is_static is no longer evaluated. It is automatically removed at runtime by a TCA migration, and a deprecation log entry is generated to indicate where adjustments are required.

Affected installations 

All TYPO3 installations defining $GLOBALS['TCA'][$table]['ctrl']['is_static'] in their TCA configuration are affected.

Migration 

Remove the is_static option from the ctrl section of your TCA configuration.

Description 

The method \TYPO3\CMS\Core\Authentication\AuthenticationService::processLoginData() no longer accepts the parameter $passwordTransmissionStrategy. Additionally, the method now declares a strict return type.

Impact 

Authentication services extending or overriding AuthenticationService and its method processLoginData() (or a subtype such as processLoginDataBE() or processLoginDataFE()) will no longer receive the $passwordTransmissionStrategy parameter.

Affected installations 

TYPO3 installations with custom authentication services that extend AuthenticationService and implement or override processLoginData() or one of its subtypes.

Migration 

Extensions extending AuthenticationService must remove the $passwordTransmissionStrategy parameter from their method signature and add the strict return type bool|int.

Extensions implementing subtype methods such as processLoginDataBE() or processLoginDataFE() must also remove the parameter, as it is no longer passed to these methods.

Description 

The TSconfig option mod.web_list.noViewWithDokTypes has been removed, as it duplicated the existing configuration TCEMAIN.preview.disableButtonForDokType.

Since forge#96861, the latter has been established as the single source of truth for disabling the View button for specific doktype values.

Impact 

The option mod.web_list.noViewWithDokTypes is no longer evaluated. Only the configuration TCEMAIN.preview.disableButtonForDokType is now respected.

Affected installations 

TYPO3 installations that still rely on mod.web_list.noViewWithDokTypes in Page TSconfig to control the visibility of the View button in backend modules are affected.

Migration 

Remove any usage of mod.web_list.noViewWithDokTypes from Page TSconfig.

Use the existing configuration TCEMAIN.preview.disableButtonForDokType instead:

TCEMAIN.preview.disableButtonForDokType = 199, 254

This change ensures consistent behavior and avoids duplicate configuration.

Description 

With forge#105640, context awareness for the CKEditor Rich Text Editor (RTE) was introduced, allowing the editor interface to automatically adapt to the user’s system-wide light or dark mode preference.

This feature is now enabled by default. The TYPO3 Core stylesheet EXT:rte_ckeditor/Resources/Public/Css/contents.css has been updated to support light and dark mode variants automatically. Previously fixed white backgrounds now adapt dynamically based on the editor’s preferred color scheme.

Note that this change affects only the backend editor interface. The display of RTE content in the frontend remains unaffected.

Impact 

The previously fixed light mode user interface of the CKEditor RTE is now context-aware, displaying content in light or dark mode according to the editor’s system preference.

Affected installations 

TYPO3 installations that rely on a fixed light mode presentation of CKEditor RTE instances in the backend are affected.

Migration 

Installations with custom CKEditor modifications should review their contents.css file. If the TYPO3 Core default stylesheet was previously used, and a fixed light mode appearance is desired, this can be enforced in the RTE YAML configuration:

editor.config.contentsCss:
  - "EXT:my_extension/Resources/Public/Css/CustomContents.css"

Description 

The TCA control option $GLOBALS['TCA'][$table]['ctrl']['searchFields'] has been removed.

With the introduction of the Schema API and the \TYPO3\CMS\Core\Schema\SearchableSchemaFieldsCollector component, the handling of fields included in searches has changed. By default, all fields of suitable types, such as input or text, are now automatically considered searchable.

To manually define searchable fields, use the new searchable field configuration option within a field's TCA configuration. See the full list of supported field types here. Unsupported field types (such as file, inline, etc.) are not considered searchable and do not support the searchable option.

Impact 

The searchFields option is no longer evaluated. It is automatically removed at runtime through a TCA migration, and a deprecation log entry is generated to highlight where adjustments are required.

If suitable fields are detected that were not listed in the removed searchFields option, they are automatically set to searchable => false to preserve previous behavior.

Affected installations 

All installations that define searchFields in their TCA configuration.

Migration 

Remove the searchFields option from the ctrl section of your TCA configuration.

If needed, use the searchable option in individual field definitions to control which fields are included in the search functionality.

Description 

The following TCA field-level search configuration options have been removed:

• search.case
• search.pidonly
• search.andWhere

These options were originally intended to customize backend record search behavior but have proven to be of little practical value:

• They were not used in the TYPO3 Core,
• They were not used in common third-party extensions,
• Their behavior was unclear and inconsistently supported,
• They were insufficiently documented and hard to validate.

This removal is part of the ongoing effort to simplify and streamline TCA configuration and reduce unnecessary complexity for integrators.

Impact 

These options are no longer evaluated. They are automatically removed at runtime through a TCA migration, and a deprecation log entry is generated to highlight where adjustments are required.

Affected installations 

Any installation or extension that defines one or more of these options in its TCA field configuration:

 'my_field' => [
     'config' => [
         'type' => 'input',
-        'search' => [
-            'case' => true,
-            'pidonly' => true,
-            'andWhere' => '{#CType}=\'text\'',
-        ],
     ],
 ],

Migration 

Remove the obsolete search options from your TCA field configurations.

Description 

One of the main features of TCA is the concept of record types. This allows using a single table for different purposes and in different contexts. The most well-known examples are the "Page Types" of the pages table and the "Content Types" of the tt_content table. For every specific type, it is possible to define which fields to display and to customize their configuration.

A special case historically has been plugin registration, which for a long time used the so-called subtypes feature of TCA. This was an additional layer below record types, configured using subtype_value_field (commonly list_type), and optionally subtypes_addlist and subtypes_excludelist to add or remove fields depending on the selected subtype.

FlexForms attached to such subtypes were configured using ds_pointerField (typically pointing to list_type,CType). This came in combination with the corresponding ds configuration, which was an array with keys combining the pointer fields, for example:

'ds_pointerField' => 'list_type,CType',
'ds' => [
    'news_pi1,list' => 'FILE:EXT:news/Configuration/FlexForm.xml',
    'default' => 'FILE:...'
],

Over recent TYPO3 versions, this approach has been deprecated in favor of using record types exclusively for plugin registration via the CType field, making configuration cleaner and easier to understand.

The special plugin content element (CType=list) and the corresponding plugin subtype field list_type have been deprecated in Deprecation: #105076 - Plugin content element and plugin sub types and removed in Breaking: #105377 - Deprecated functionality removed. See also Important: #105538 - Plugin subtypes removed: Changes to configurePlugin() and TCA handling for related information about ExtensionUtility::configurePlugin() and ExtensionManagementUtility::addTcaSelectItemGroup().

With this change, support for ds_pointerField and the multi-entry ds array format has now been removed. The ds option now points to a single FlexForm, either directly or via a FILE: reference.

FlexForms must instead be assigned via standard types configuration using columnsOverrides.

This also affects the data structure identifier, which in the commonly used tca type is the dataStructureKey. It is now set to default if the table does not support record types or no record type-specific configuration exists. Otherwise, the dataStructureKey is set to the corresponding record type value, for example textpic.

This change affects the following PSR-14 events:

• AfterFlexFormDataStructureIdentifierInitializedEvent
• AfterFlexFormDataStructureParsedEvent
• BeforeFlexFormDataStructureIdentifierInitializedEvent
• BeforeFlexFormDataStructureParsedEvent

A fallback for TYPO3 v14 resolves comma-separated dataStructureKey values (for example, list_type,CType) to CType.

To address circular dependencies during schema building, FlexFormTools now supports both TCA Schema objects and raw TCA configuration arrays as input. The following methods accept a union type array|TcaSchema for the new $schema parameter:

• getDataStructureIdentifier()
• parseDataStructureByIdentifier()
• cleanFlexFormXML()

Previously, these methods relied on $GLOBALS['TCA'] internally, which caused architectural issues. They now operate directly on the provided schema.

All calls to these methods should provide the $schema parameter with either a TcaSchema instance or a raw TCA configuration array. Since data structure resolution can be customized by extensions, the parameter is not strictly mandatory, but it is strongly recommended to provide it in most cases. An InvalidTcaSchemaException will be thrown if schema resolution is required but no schema is passed.

This change also enables components like RelationMapBuilder to use FlexFormTools during schema building, even when only raw TCA is available.

For further details on the enhanced FlexFormTools functionality, see Feature: #107047 - FlexForm enhancements: Direct plugin registration and raw TCA support.

The following class has been removed as it is no longer required:

• \InvalidCombinedPointerFieldException

Impact 

FlexForm Pointer Field Removal

Any TCA definition that still uses ds_pointerField or a ds array with multiple entries (for example news_pi1,list) will no longer work and might cause rendering errors.

FlexFormTools Schema Parameter

All code calling FlexFormTools methods ( getDataStructureIdentifier(), parseDataStructureByIdentifier(), cleanFlexFormXML()) must be updated to provide the required $schema parameter.

Affected installations 

FlexForm Pointer Field Removal

All installations using ds_pointerField (as the pointer field functionality has been removed entirely) or an array-like structure for ds in their TCA field type flex configuration.

FlexFormTools Schema Parameter

All installations with custom code that directly call FlexFormTools methods without providing the $schema parameter. This includes custom extensions or TYPO3 Core patches using these methods.

A TCA migration automatically converts single-entry ds arrays. Multi-entry definitions require manual migration, as they must be aligned with the correct record type configuration, which may require additional configuration changes beforehand.

Example for single-entry migration:

Before:

'ds' => [
    'default' => '<T3DataStructure>...',
],

After:

'ds' => '<T3DataStructure>...',

Migration 

FlexForm Pointer Field Migration

Before:

'ds_pointerField' => 'list_type,CType',
'ds' => [
    'news_pi1,list' => 'FILE:EXT:news/Configuration/FlexForm.xml',
    'default' => '<T3DataStructure>...',
],

After:

'columns' => [
    'pi_flexform' => [
        'config' => [
            'ds' => '<T3DataStructure>...',
        ],
    ],
],
'types' => [
    'news_pi1' => [
        'columnsOverrides' => [
            'pi_flexform' => [
                'config' => [
                    'ds' => 'FILE:EXT:news/Configuration/FlexForm.xml',
                ],
            ],
        ],
    ],
],

If no columnsOverrides is defined, the default ds value of the field configuration will be used as before.

FlexFormTools Schema Parameter Migration

Before:

use TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools;
use TYPO3\CMS\Core\Utility\GeneralUtility;

$flexFormTools = GeneralUtility::makeInstance(FlexFormTools::class);
$identifier = $flexFormTools->getDataStructureIdentifier(
    $fieldTca,
    'tt_content',
    'pi_flexform',
    $row
);

After:

use TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools;
use TYPO3\CMS\Core\Schema\TcaSchemaFactory;
use TYPO3\CMS\Core\Utility\GeneralUtility;

$flexFormTools = GeneralUtility::makeInstance(FlexFormTools::class);

// Option 1: Using TCA Schema object (recommended for normal usage)
$tcaSchemaFactory = GeneralUtility::makeInstance(TcaSchemaFactory::class);
$tcaSchema = $tcaSchemaFactory->get('tt_content');
$identifier = $flexFormTools->getDataStructureIdentifier(
    $fieldTca,
    'tt_content',
    'pi_flexform',
    $row,
    $tcaSchema
);

// Option 2: Using raw TCA array (for schema building contexts)
$rawTca = $fullTca['tt_content'];
$identifier = $flexFormTools->getDataStructureIdentifier(
    $fieldTca,
    'tt_content',
    'pi_flexform',
    $row,
    $rawTca
);

Description 

Extbase no longer supports PHP annotations for models, data transfer objects (DTOs), and controller actions. Use PHP attributes (for example #[Extbase\Validate]) instead. Attributes provide the same functionality with better performance and native language support.

Extbase previously relied on annotation parsing, typically detected when the annotation namespace was imported, for example:

use TYPO3\CMS\Extbase\Annotation as Extbase;
use TYPO3\CMS\Extbase\DomainObject\AbstractEntity;

class MyModel extends AbstractEntity
{
    /**
     * @Extbase\Validate("NotEmpty")
     */
    protected string $foo = '';
}

Since TYPO3 now requires PHP 8.2 as the minimum version, the use of native PHP attributes is preferred. All Extbase-related annotations have been available as PHP attributes since TYPO3 v12.

Impact 

By dropping support for Extbase annotations, only PHP attributes are now supported. This provides more type safety and better integration with PHP’s language features. Developers benefit from a cleaner, faster, and more reliable implementation without the need for the deprecated third-party annotation parser.

Affected installations 

All Extbase models, Data Transfer Objects (DTOs), and controllers that use Extbase annotations are affected. This includes built-in annotations such as Cascade, Lazy, and Validate, as well as any custom annotation implementations.

Migration 

Switch from Extbase annotations to native PHP attributes.

use TYPO3\CMS\Extbase\Annotation as Extbase;
use TYPO3\CMS\Extbase\DomainObject\AbstractEntity;

class MyModel extends AbstractEntity
{
    /**
     * @Extbase\Validate("NotEmpty")
     */
    protected string $foo = '';
}

use TYPO3\CMS\Extbase\Attribute as Extbase;
use TYPO3\CMS\Extbase\DomainObject\AbstractEntity;

class MyModel extends AbstractEntity
{
    #[Extbase\Validate(['validator' => 'NotEmpty'])]
    protected string $foo = '';
}

Description 

The interface \TYPO3\CMS\Core\Cache\Backend\FreezableBackendInterface has been removed from the TYPO3 Core.

It previously defined the following methods:

• freeze() — Freezes the cache backend.
• isFrozen() — Returns whether the backend is frozen.

Impact 

Any code implementing or referencing \FreezableBackendInterface will now trigger a PHP fatal error.

Since this interface was never implemented in the TYPO3 Core and had no known real-world usage, the overall impact is expected to be minimal.

Affected installations 

Installations with custom extensions that implement or reference the \FreezableBackendInterface are affected.

Migration 

Remove any references to \FreezableBackendInterface from your extension code.

If you require freeze functionality, implement the desired behavior directly in your custom cache backend class.

Description 

In TYPO3 v14, the PHP code for the Cache Backend and Cache Frontend has undergone major changes, which may affect extensions:

• Most PHP code from Cache Backends and Cache Frontends is now strongly typed using PHP's native typing system
• Method signatures now use proper type declarations for parameters and return types
• The mixed type is now used where appropriate for flexible data handling
• All string parameters and boolean return types are properly declared

The following interfaces have been updated with strict typing:

• \TYPO3\CMS\Core\Cache\Backend\BackendInterface
• \TYPO3\CMS\Core\Cache\Backend\PhpCapableBackendInterface
• \TYPO3\CMS\Core\Cache\Backend\TransientBackendInterface
• \TYPO3\CMS\Core\Cache\Frontend\FrontendInterface

Additionally, backward compatibility for the abstract base class constructor has been removed:

• \TYPO3\CMS\Core\Cache\Backend\AbstractBackend