TYPO3-translation/cms-core
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

TYPO3 v15 dev-main snapshot ()

Browse Source
This commit is contained in:
wappler
2026-08-10 22:31:09 +02:00
commit af8cc155b5
6818 changed files with 642608 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/Changelog/13.4/Deprecation-105076-PluginContentElementAndPluginSubTypes.rst
+102
View File
@@ -0,0 +1,102 @@
.. include:: /Includes.rst.txt
.. _deprecation-105076-1726923626:
==================================================================
Deprecation: #105076 - Plugin content element and plugin sub types
==================================================================
See :issue:`105076`
Description
===========
Historically, plugins have been registered using the `list` content
element and the plugin subtype `list_type` field. This functionality
has been kept for backwards compatibility reasons. However, since the release
of TYPO3 v12.4, the recommended way to create a plugin is by using a dedicated
content type (`CType`) for each plugin.
This old "General Plugin" approach has always been ugly from a UX perspective point
of view since it hides plugin selection behind "General plugin" content element,
forcing a second selection step and making such plugins something special.
Therefore, the plugin content element (`list`) and the plugin sub types
field (:php:`list_type`) have been marked as deprecated in TYPO3 v13.4 and will
be removed in TYPO3 v14.0.
Additionally, the related PHP constant
:php:`TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_PLUGIN` has been
deprecated as well.
Impact
======
Plugins added using
:php:`TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin()` where
the second parameter is :php:`list_type` (which is still the default) will
trigger a deprecation level log entry in TYPO3 v13 and will fail in v14.
Therefore, the same applies on using
:php:`TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin()` (to
configure the plugin for frontend rendering), where no fifth parameter is
provided or where the fifth parameter is :php:`list_type`
(:php:`ExtensionUtility::PLUGIN_TYPE_PLUGIN`), which is still the default.
The extension scanner will report any usage of :php:`configurePlugin()`,
where less than the required five arguments are provided. Actually, the
only valid value for the fifth parameter :php:`$pluginType` is :php:`CType`,
for which the :php:`ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT` constant
can be used.
.. note::
:php:`addPlugin()` is also internally called when registering a plugin
via :php:`TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerPlugin()`.
In that case the plugin type to use is either the one defined via
:php:`TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin()`
or also falls back to :php:`list_type`.
Affected installations
======================
Extensions registering plugins as `list_type` plugin sub type.
Migration
=========
Existing plugins must be migrated to use the `CType` record type.
Extension authors must implement the following changes:
* Register plugins using the `CType` record type
* Create update wizard which extends :php:`\TYPO3\CMS\Install\Updates\AbstractListTypeToCTypeUpdate`
and add `list_type` to `CType` mapping for each plugin to migrate.
The migration wizard for indexed_search in class
:php-short:`\TYPO3\CMS\Install\Updates\IndexedSearchCTypeMigration`
can be used as reference example.
* Migrate possible FlexForm registration and add dedicated `showitem` TCA
configuration
* Migrate possible PreviewRenderer registration in TCA
* Adapt possible content element wizard items in Page TSConfig, where
`list_type` is used
* Adapt possible content element restrictions in backend layouts or container
elements defined by third-party extensions like
:composer:`ichhabrecht/content-defender`.
Common example
^^^^^^^^^^^^^^
.. code-block:: php
// Before
$GLOBALS['TCA']['tt_content']['types']['list']['subtypes_addlist']['my_plugin'] = 'pi_flexform';
$GLOBALS['TCA']['tt_content']['types']['list']['subtypes_excludelist']['my_plugin'] = 'pages,layout,recursive';
// After
$GLOBALS['TCA']['tt_content']['types']['my_plugin']['showitem'] = '<Some Fields>,pi_flexform,<Other Fields>';
.. index:: Fluid, PHP-API, PartiallyScanned, ext:extbase
Documentation/Changelog/13.4/Deprecation-105171-INCLUDE_TYPOSCRIPTTypoScriptSyntax.rst
+124
View File
@@ -0,0 +1,124 @@
.. include:: /Includes.rst.txt
.. _deprecation-105171-1727785626:
===========================================================
Deprecation: #105171 - INCLUDE_TYPOSCRIPT TypoScript syntax
===========================================================
See :issue:`105171`
Description
===========
The old TypoScript syntax to import external TypoScript files based on
:typoscript:`<INCLUDE_TYPOSCRIPT:` has been marked as deprecated
with TYPO3 v13 and will be removed in v14.
Integrators should switch to :typoscript:`@import`.
There are multiple reasons to finally phase out this old construct:
* The :typoscript:`<INCLUDE_TYPOSCRIPT:` syntax is clumsy and hard to grasp,
especially when combining multiple options. It is hard to learn for integrators
new to the project.
* The implementation has a high level of complexity, is only partially tested
and consists of edge cases that are hard to decide on and even harder to change
since that may break existing usages in hard to debug ways.
* The syntax can have negative security impact when not used wisely by loading
TypoScript from editor related folders like :file:`fileadmin/`. The syntax
based on :typoscript:`@import` has been designed more thoughtful in this regard.
* Loading TypoScript files from folders relative to the public web folder is
unfortunate and can have negative side effects when switching "legacy" based
instances to composer.
* The syntax based on :typoscript:`@import` has been introduced in TYPO3 v9 already
and :quote:`has been designed to stay` at this point in time. With TYPO3 v12, the
last missing feature of :typoscript:`<INCLUDE_TYPOSCRIPT:` has been made possible
for :typoscript:`@import` as well: :typoscript:`@import` can be loaded conditionally
by putting them into the body of a casual TypoScript condition.
* TYPO3 v12 discouraged using :typoscript:`<INCLUDE_TYPOSCRIPT:` within the documentation
and already anticipated a future deprecation and removal.
Impact
======
When using TypoScript :typoscript:`<INCLUDE_TYPOSCRIPT:` syntax a deprecation level
log entry in TYPO3 v13 is emitted. The syntax will stop working with TYPO3 v14 and
will be detected as an "invalid line" in the TypoScript related Backend modules.
Affected installations
======================
Instances TypoScript syntax based on :typoscript:`<INCLUDE_TYPOSCRIPT:`.
Migration
=========
Most usages of :typoscript:`<INCLUDE_TYPOSCRIPT:` can be turned into :typoscript:`@import`
easily. A few examples:
.. code-block:: typoscript
# Before
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:my_extension/Configuration/TypoScript/myMenu.typoscript">
# After
@import 'EXT:my_extension/Configuration/TypoScript/myMenu.typoscript'
# Before
# Including .typoscript files in a single (non recursive!) directory
<INCLUDE_TYPOSCRIPT: source="DIR:EXT:my_extension/Configuration/TypoScript/" extensions="typoscript">
# After
@import 'EXT:my_extension/Configuration/TypoScript/*.typoscript'
# Before
# Including .typoscript and .ts files in a single (non recursive!) directory
<INCLUDE_TYPOSCRIPT: source="DIR:EXT:my_extension/Configuration/TypoScript/" extensions="typoscript,ts">
# After
@import 'EXT:my_extension/Configuration/TypoScript/*.typoscript'
# Rename all files ending on .ts to .typoscript
# Before
# Including a file conditionally
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:my_extension/Configuration/TypoScript/user.typoscript" condition="[frontend.user.isLoggedIn]">
# After
[frontend.user.isLoggedIn]
@import 'EXT:my_extension/Configuration/TypoScript/user.typoscript'
[END]
There are a few more use cases that cannot be transitioned so easily since :typoscript:`@import` is
a bit more restrictive.
As one restriction :typoscript:`@import` cannot include files from arbitrary directories
like :file:`fileadmin/`, but only from extensions by using the :typoscript:`EXT:`
prefix. Instances that use :typoscript:`<INCLUDE_TYPOSCRIPT:` with :typoscript:`source="FILE:./someDirectory/..."`
should move this TypoScript into a project or site extension. Such instances are also encouraged to
look into the TYPO3 v13 "Site sets" feature and eventually transition towards it along the way.
:typoscript:`@import` allows to import files with the file ending `.typoscript`
and `.tsconfig`. If you used any of the outdated file endings like `.ts` or
`.txt` rename those files before switching to the :typoscript:`@import` syntax.
The :typoscript:`@import` feature does not support recursive directory inclusion, as it does
not allow wildcards in directory paths. Having directories like :file:`TypoScript/foo` and
:file:`TypoScript/bar`, each having :file:`.typoscript` files, could be included using
:typoscript:`<INCLUDE_TYPOSCRIPT: source=DIR:EXT:my_extension/Configuration/TypoScript extensions="typoscript">`,
which would find such files in :file:`foo` and :file:`bar`, and any other directory. This level of complexity
was not wished to allow in the :typoscript:`@import` syntax since it can make file includes more intransparent
with too much attached magic. Instances using this should either reorganize their files, or have multiple dedicated
:typoscript:`@import` statements. The need for recursive includes may also be mitigated by restructuring
TypoScript based functionality using "Site sets".
The transition from :typoscript:`<INCLUDE_TYPOSCRIPT:` can be often further relaxed with these features in mind:
* :ref:`Automatic inclusion of user TSconfig of extensions <feature-101807-1693473782>`
* :ref:`Automatic inclusion of page TSconfig of extensions <feature-96614>`
* :ref:`TypoScript provider for sites and sets <feature-103439-1712321631>` automatically loads TypoScript
per site when located next to site :file:`config.yaml` files as :file:`constants.typoscript` and :file:`setup.typoscript`,
which is a good alternative to files in :file:`fileadmin` and similar. Note that configured site sets TypoScript
are loaded before, so :file:`constants.typoscript` and :file:`setup.typoscript` are designed to adapt site set
TypoScript to specific site needs.
.. index:: TypoScript, NotScanned, ext:core
Documentation/Changelog/13.4/Deprecation-105213-TCASubTypes.rst
+146
View File
@@ -0,0 +1,146 @@
.. include:: /Includes.rst.txt
.. _deprecation-105213-1728286135:
====================================
Deprecation: #105213 - TCA sub types
====================================
See :issue:`105213`
Description
===========
One of the main features of TCA are the record types. This allows to use
a single table for different purposes and in different contexts. The most
known examples of using record types are the "Page Types" of :sql:`pages`
and the "Content Types" of :sql:`tt_content`. For every specific type of
such table, it's possible to define the fields to be used and even
manipulate them e.g. change their label.
A special case since ever has been the plugin registration. This for
a long time has been done using the so called "sub types" feature of TCA.
This is another layer below record types and allows to further customize
the behaviour of a record type using another select field, defined via
:php:`subtype_value_field` as well as defining fields to be added
- :php:`subtypes_addlist` - or excluded - :php:`subtypes_excludelist` - for
the record type, depending on the selected sub type.
For a couple of version now, it's encouraged to register plugins just
as standard content elements via the :php:`tt_content` type field :php:`CType`.
Therefore, the special registration via the combination of the :php:`list`
record type and the selection of a sub type via the :php:`list_type` field
has already been deprecated with :ref:`deprecation-105076-1726923626`.
Since the "sub types" feature was mainly used for this scenario only, it has
now been deprecated as well. Registration of custom types should therefore
always be done by using record types. This makes configuration much cleaner
and more comprehensible.
Impact
======
Using :php:`subtype_value_field` in a TCA `types` configurations will
lead to a deprecation log entry containing information about where
adaptations need to take place.
Affected installations
======================
All installations using the sub types feature by defining a
:php:`subtype_value_field` in a TCA `types` configuration, which
is really uncommon as the feature was mainly used for plugin
registration in the :sql:`tt_content` table only.
Migration
=========
Replace any :php:`subtype_value_field` configuration with dedicated record
types. Please also consider migrating corresponding :php:`subtypes_addlist`
and :php:`subtypes_excludelist` definitions accordingly.
Before
------
.. code-block:: php
'ctrl' => [
'type' => 'type',
],
'columns' => [
'type' => [
'config' => [
'type' => 'select',
'renderType' => 'selectSingle',
'items' => [
[
'label' => 'A record type',
'value' => 'a_record_type'
]
]
]
],
'subtype' => [
'config' => [
'type' => 'select',
'renderType' => 'selectSingle',
'items' => [
[
'label' => 'A sub type',
'value' => 'a_sub_type'
]
]
]
],
],
'types' => [
'a_record_type' => [
'showitem' => 'aField,bField',
'subtype_value_field' => 'subtype',
'subtypes_addlist' => [
'a_sub_type' => 'pi_flexform'
],
'subtypes_excludelist' => [
'a_sub_type' => 'bField'
]
]
]
After
-----
.. code-block:: php
'ctrl' => [
'type' => 'type',
],
'columns' => [
'type' => [
'config' => [
'type' => 'select',
'renderType' => 'selectSingle',
'items' => [
[
'label' => 'A record type',
'value' => 'a_record_type'
],
[
'label' => 'A sub type',
'value' => 'a_sub_type'
]
]
]
],
],
'types' => [
'a_record_type' => [
'showitem' => 'aField,bField'
],
'a_sub_type' => [
'showitem' => 'aField,pi_flexform'
]
]
.. index:: PHP-API, TCA, FullyScanned, ext:core
Documentation/Changelog/13.4/Deprecation-105230-TypoScriptFrontendControllerAndGLOBALSTSFE.rst
+43
View File
@@ -0,0 +1,43 @@
.. include:: /Includes.rst.txt
.. _deprecation-105230-1728374467:
========================================================================
Deprecation: #105230 - TypoScriptFrontendController and $GLOBALS['TSFE']
========================================================================
See :issue:`105230`
Description
===========
Class :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` and
its global instance :php:`$GLOBALS['TSFE']` have been marked as deprecated.
The class will be removed with TYPO3 v14.
Impact
======
Calling :php:`TypoScriptFrontendController` methods, or accessing state from
:php:`$GLOBALS['TSFE']` is considered deprecated.
Affected installations
======================
Various instances may still retrieve information from :php:`$GLOBALS['TSFE']`.
Remaining uses should be adapted. The extension scanner will find possible
matches.
To keep backwards compatibility in TYPO3 v13, some calls can not raise
deprecation level log messages.
Migration
=========
See :ref:`breaking-102621-1701937690` for details on substitutions. In general,
most state used by extensions has been turned into request attributes.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
Documentation/Changelog/13.4/Deprecation-105252-DataProviderContextGettersAndSetters.rst
+86
View File
@@ -0,0 +1,86 @@
.. include:: /Includes.rst.txt
.. _deprecation-105252-1728471144:
==============================================================
Deprecation: #105252 - DataProviderContext getters and setters
==============================================================
See :issue:`105252`
Description
===========
The backend layout related data object class :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext`
has been turned into a data object using public constructor property promotion (PCPP).
All :php:`setX()` and :php:`getX()` methods have been marked as deprecated in TYPO3 v13.4 and
will be removed with TYPO3 v14.0. The class will be declared :php:`readonly` in TYPO3 v14.0
which will enforce instantiation using PCPP. The class has been declared final since it is
an API contract that must never be changed or extended. The constructor arguments will be
declared non-optional in TYPO3 v14.0.
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setPageId()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setTableName()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setFieldName()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setData()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->setPageTsConfig()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getPageId()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getTableName()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getFieldName()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getData()`
* :php:`TYPO3\CMS\Backend\View\BackendLayout\DataProviderContext->getPageTsConfig()`
Impact
======
Calling the getters or setters raises deprecation level log errors and will stop working
in TYPO3 v14.0.
Affected installations
======================
This data object is only relevant for instances with extensions that add custom backend layout
data providers using :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['BackendLayoutDataProvider']`.
There are few known extensions that do this. The extension scanner is not configured to find
possible usages since the method names are too generic and would lead to too many false positives.
Migration
=========
Create new objects using PCPP with named arguments instead of the setters.
Instances should be created using :php:`new()`:
.. code-block:: php
// Before
$dataProviderContext = GeneralUtility::makeInstance(DataProviderContext::class);
$dataProviderContext
->setPageId($pageId)
->setData($parameters['row'])
->setTableName($parameters['table'])
->setFieldName($parameters['field'])
->setPageTsConfig($pageTsConfig);
// After
$dataProviderContext = new DataProviderContext(
pageId: $pageId,
tableName: $parameters['table'],
fieldName: $parameters['field'],
data: $parameters['row'],
pageTsConfig: $pageTsConfig,
);
Use the properties instead of the getters, example:
.. code-block:: php
// Before
$pageId = $dataProviderContext->getPageId()
// After
$pageId = $dataProviderContext->pageId
.. index:: Backend, PHP-API, NotScanned, ext:backend
Documentation/Changelog/13.4/Deprecation-105279-ReplaceTYPO3EnumTypeWithDoctrinedbalEnumType.rst
+54
View File
@@ -0,0 +1,54 @@
.. include:: /Includes.rst.txt
.. _deprecation-105279-1728669356:
=========================================================================
Deprecation: #105279 - Replace TYPO3 EnumType with Doctrine DBAL EnumType
=========================================================================
See :issue:`105279`
Description
===========
TYPO3 did provide a custom Doctrine DBAL column type implementation for the native
SQL type :sql:`ENUM` that was only compatible with MySQL and MariaDB connections.
The Doctrine DBAL Team implemented :sql:`ENUM` support with
`Release 4.2.0 <https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md>`__ in
class :php:`\Doctrine\DBAL\Types\EnumType`, only supporting MySQL and MariaDB
as well.
TYPO3 removed its custom implementation with TYPO3 v13.4.0.
Class :php:`\TYPO3\CMS\Core\Database\Schema\Types\EnumType` has been marked as deprecated
and is replaced with an class alias of :php-short:`\Doctrine\DBAL\Types\EnumType`.
The alias will be removed with TYPO3 v14.
See `Release 4.2.0 <https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md>`__
Impact
======
:composer:`doctrine/dbal` >= 4.2.0 is incompatible with TYPO3 versions before v13.4.0.
Composer-based instances using TYPO3 v13.3 or older should add an according
conflict to their :file:`composer.json`.
Affected installations
======================
Instances using the :sql:`ENUM` type directly or by any third party
extension using TYPO3 13.0 to 13.3 in Composer mode will break, when
the :composer:`doctrine/dbal` Composer packages is updated to version 4.2.0
or newer.
Migration
=========
Upgrade (directly) to TYPO3 v13.4 or ensure to avoid updating
Doctrine DBAL to 4.2.x or newer versions in Composer-based instances.
Replace :php:`\TYPO3\CMS\Core\Database\Schema\Types\EnumType` type
declarations with :php:`\Doctrine\DBAL\Types\EnumType`.
.. index:: Database, PHP-API, NotScanned, ext:core
Documentation/Changelog/13.4/Deprecation-105297-DeprecateTableoptionsAndCollateConnectionConfiguration.rst
+81
View File
@@ -0,0 +1,81 @@
.. include:: /Includes.rst.txt
.. _deprecation-105297-1728836814:
============================================================================
Deprecation: #105297 - `tableoptions` and `collate` connection configuration
============================================================================
See :issue:`105297`
Description
===========
The possibility to configure default table options like charset and collation for the database
analyzer has been introduced using the array
:php:`$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['tableoptions']` with
sub-array keys :php:`charset` and :php:`collate`. These were only used for MySQL and MariaDB
connections.
Since TYPO3 v11 the :php:`tableoptions` keys were silently migrated to
:php:`defaultTableOptions`, which is the proper Doctrine DBAL connection option for
for MariaDB and MySQL.
Furthermore, Doctrine DBAL 3.x switched from using they array key :php:`collate` to
:php:`collation`, ignoring the old array key with Doctrine DBAL 4.x. This was silently
migrated by TYPO3, too.
These options and migration are now deprecated in favor of using the final array
keys and will be removed with TYPO3 v15 (or later) as breaking change.
.. note::
When migrating, make sure to remove the old :php:`tableoptions` array key, otherwise
it will take precedence over setting the new :php:`defaultTableOptions` key in TYPO3 v13.
Impact
======
Instances using the database connection options in
:php:`$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['tableoptions']`
array, or using the :php:`collate` key will trigger a :php:`E_USER_DEPRECATED`
notification.
Affected installations
======================
All instances using the mentioned options.
Migration
=========
Review :php:`settings.php` and :php:`additional.php` and adapt the deprecated
configuration by renaming affected array keys.
.. code-block:: php
# before
'DB' => [
'Connections' => [
'Default' => [
'tableoptions' => [
'collate' => 'utf8mb4_unicode_ci',
],
],
],
],
# after
'DB' => [
'Connections' => [
'Default' => [
'defaultTableOptions' => [
'collation' => 'utf8mb4_unicode_ci',
],
],
],
],
.. index:: Database, LocalConfiguration, NotScanned, ext:core
Documentation/Changelog/13.4/Important-105175-MoveFrontendBackendUserAuthenticationIntoEXTfrontend.rst
+23
View File
@@ -0,0 +1,23 @@
.. include:: /Includes.rst.txt
.. _important-105175-1727799093:
=============================================================================
Important: #105175 - Move FrontendBackendUserAuthentication into EXT:frontend
=============================================================================
See :issue:`105175`
Description
===========
The internal :php:`\TYPO3\CMS\Frontend\Authentication\FrontendBackendUserAuthentication`
class, used for frontend requests while being logged in the backend has been
moved from EXT:backend to EXT:frontend, since its dependencies are limited
to EXT:core and EXT:frontend.
While for v13 a class alias mapping and a legacy notation for IDE's is
available, the class is marked as `@internal` and therefore does not fall
under TYPO3's Core API deprecation policy.
.. index:: Frontend, ext:frontend
Documentation/Changelog/13.4/Index.rst
+50
View File
@@ -0,0 +1,50 @@
:template: changelogOverview.html
.. include:: /Includes.rst.txt
.. _changelog-13-4:
============
13.4 Changes
============
**Table of contents**
.. contents::
:local:
:depth: 1
Breaking Changes
================
None since TYPO3 v13.0 release.
.. attention::
After TYPO3 v13.0, only new functionality with a solid migration path
can be added on top, with aiming for as little as possible breaking changes
after the initial v13.0 release on the way to LTS.
Features
========
None since TYPO3 v13.3 release.
Deprecation
===========
.. toctree::
:maxdepth: 1
:titlesonly:
:glob:
Deprecation-*
Important
=========
.. toctree::
:maxdepth: 1
:titlesonly:
:glob:
Important-*