TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/11.4/Deprecation-85613-CategoryRegistry.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85613:
+
+=======================================
+Deprecation: #85613 - Category Registry
+=======================================
+
+See :issue:`85613`
+
+Description
+===========
+
+With :issue:`94622` the new TCA type `category` has been introduced
+as a replacement for the :php:`\TYPO3\CMS\Core\Category\CategoryRegistry`.
+Therefore, the :php:`CategoryRegistry` together with
+:php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable()`
+method have been marked as deprecated and will be removed in TYPO3 v12.
+
+The main reasons for this replacement are:
+
+* Using a dedicated type is more intuitive and consistent
+* No more :file:`TCA/Overrides` are necessary for defining category fields
+* The new implementation is state of the art (e.g. direct usage of
+  the Doctrine API for automatically adding the database columns)
+
+
+Impact
+======
+
+Defining category fields for tables with
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultCategorizedTables']` or
+by calling :php:`ExtensionManagementUtility::makeCategorizable()` will
+trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+The extension scanner will furthermore detect any call to
+:php:`ExtensionManagementUtility::makeCategorizable()` and
+:php:`CategoryRegistry` as strong match and any usage of
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultCategorizedTables']`
+as weak match.
+
+
+Affected Installations
+======================
+
+All installations registering category fields using
+:php:`ExtensionManagementUtility::makeCategorizable()` or defining
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultCategorizedTables']`.
+
+Furthermore, all installations, which directly access the :php:`CategoryRegistry`.
+
+
+Migration
+=========
+
+Directly define category fields in the corresponding TCA, using the :php:`category`
+TCA type. Have a look at the corresponding
+:doc:`changelog <../11.4/Feature-94622-NewTCATypeCategory>`, for code
+examples.
+
+.. index:: PHP-API, TCA, PartiallyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94619-ExtbaseObjectManager.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94619:
+
+===========================================
+Deprecation: #94619 - Extbase ObjectManager
+===========================================
+
+See :issue:`94619`
+
+Description
+===========
+
+The Extbase ObjectManager as the legacy core object lifecycle and
+dependency injection solution has been marked discouraged with TYPO3 v10 and
+its introduction of the Symfony based dependency injection solution already.
+
+TYPO3 v11 no longer uses the Extbase ObjectManager - only in a couple
+of places as fallback for third party extensions. The entire construct has now
+been marked as deprecated and will be removed with v12:
+
+* :php:`TYPO3\CMS\Extbase\Object\ObjectManagerInterface` - Main interface
+* :php:`TYPO3\CMS\Extbase\Object\ObjectManager` - Main implementation
+* :php:`TYPO3\CMS\Extbase\Object\Container\Container` - Internal lifecycle management
+* :php:`TYPO3\CMS\Extbase\Object\Exception` - Base exception
+* :php:`TYPO3\CMS\Extbase\Object\Exception\CannotBuildObjectException` - Detail exception
+* :php:`TYPO3\CMS\Extbase\Object\Container\Exception\CannotReconstituteObjectException` - Detail exception
+* :php:`TYPO3\CMS\Extbase\Object\Container\Exception\UnknownObjectException` - Detail exception
+* :php:`TYPO3\CMS\Extbase\SignalSlot\Exception\InvalidSlotException` - Detail exception, obsolete
+  by deprecation of Extbase signal slot dispatcher already.
+* :php:`TYPO3\CMS\Extbase\SignalSlot\Exception\InvalidSlotReturnException`  - Detail exception, obsolete
+  by deprecation of Extbase signal slot dispatcher already.
+
+
+Impact
+======
+
+Directly or indirectly calling :php:`\TYPO3\CMS\Extbase\Object\ObjectManager->get()`
+will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extensions that have been properly cleaned up for TYPO3 v10 compatibility are not affected.
+
+Extensions still relying on Extbase ObjectManager are strongly encouraged to
+switch to :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance()` and
+Symfony based DI instead.
+
+The extension scanner will find usages of the above classes and interfaces and shows
+them as deprecated with a strong match.
+
+
+Migration
+=========
+
+Documentation of migration paths have been established with TYPO3 v10
+documentation already. The :ref:`TYPO3 explained dependency injection section<t3coreapi:DependencyInjection>`
+and the :ref:`ObjectManager->get() v10 changelog entry <changelog-Deprecation-90803-ObjectManagerGet>`
+are especially helpful.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.4/Deprecation-94654-GenericExtbaseDomainClasses.rst

@@ -0,0 +1,75 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94654:
+
+====================================================
+Deprecation: #94654 - Generic Extbase domain classes
+====================================================
+
+See :issue:`94654`
+
+Description
+===========
+
+Most Extbase "generic" domain model and repositories have been marked as deprecated:
+They are opinionated implementations and can't be "correct" since the
+domains they are used in are unique.
+
+The following classes have been marked as deprecated:
+
+* :php:`TYPO3\CMS\Extbase\Domain\Model\BackendUser`
+* :php:`TYPO3\CMS\Extbase\Domain\Model\BackendUserGroup`
+* :php:`TYPO3\CMS\Extbase\Domain\Model\FrontendUser`
+* :php:`TYPO3\CMS\Extbase\Domain\Model\FrontendUserGroup`
+* :php:`TYPO3\CMS\Extbase\Domain\Repository\BackendUserGroupRepository`
+* :php:`TYPO3\CMS\Extbase\Domain\Repository\BackendUserRepository`
+* :php:`TYPO3\CMS\Extbase\Domain\Repository\CategoryRepository`
+* :php:`TYPO3\CMS\Extbase\Domain\Repository\FrontendUserGroupRepository`
+* :php:`TYPO3\CMS\Extbase\Domain\Repository\FrontendUserRepository`
+
+
+Impact
+======
+
+Using or extending the above classes is deprecated since TYPO3 v11.
+They will be removed with TYPO3 v12.
+
+
+Affected Installations
+======================
+
+Various Extbase based extensions may use or extend the classes. The
+extension scanner will find usages with a strong match.
+
+
+Migration
+=========
+
+The migration paths are usually straight forward.
+
+Extensions that extend the repository classes should extend Extbase
+:php:`TYPO3\CMS\Extbase\Persistence\Repository` instead and maybe copy
+body methods like :php:`initializeObject()` if given and not overridden
+already.
+
+Extensions that use the Extbase repositories directly should copy the
+class to their extension namespace and use the own ones instead.
+
+Extensions that extend the model classes should extend
+:php:`TYPO3\CMS\Extbase\DomainObject\AbstractEntity` instead and copy
+the properties, getters and setters they need from the Extbase classes.
+Those copied properties may need database mapping entries, which can
+be copied from :file:`EXT:extbase/Configuration/Extbase/Persistence/Classes.php`.
+
+Extensions that use the Extbase models directly should copy the class
+to their extension namespace, ideally strip them down to what the extension
+actually needs, and copy the needed mapping information from
+:file:`EXT:extbase/Configuration/Extbase/Persistence/Classes.php`.
+
+No database update of existing rows should be needed when transferring
+the models to an own namespace, since none of the Extbase models
+configured a :php:`recordType` in the mapping file at
+:file:`EXT:extbase/Configuration/Extbase/Persistence/Classes.php`.
+
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.4/Deprecation-94664-PdoCacheBackend.rst

@@ -0,0 +1,72 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94664:
+
+=======================================
+Deprecation: #94664 - Pdo cache backend
+=======================================
+
+See :issue:`94664`
+
+Description
+===========
+
+The Caching Framework backend implementation :php:`TYPO3\CMS\Core\Cache\Backend\PdoBackend`
+is superseded by the :php:`TYPO3\CMS\Core\Cache\Backend\Typo3DatabaseBackend` since
+introduction of Doctrine DBAL. There is little reason to use :php:`PdoBackend` instead
+of the :php:`Typo3DatabaseBackend` and the latter is optimized much better.
+
+:php:`PdoBackend` has thus been marked as deprecated and should not be used anymore.
+
+
+Impact
+======
+
+The implementation has been marked as deprecated, usages trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Some instances *may* use this cache backend, but chances are low. This can
+be verified in the backend "Configuration" module, section "TYPO3_CONF_VARS",
+searching for string "PdoBackend".
+
+
+Migration
+=========
+
+TYPO3 cache backend configuration is usually done in :file:`LocalConfiguration.php`.
+Affected instances should switch to :php:`Typo3DatabaseBackend` and eventually update
+database schema.
+
+:file:`LocalConfiguration.php` example before:
+
+.. code-block:: php
+
+    'SYS' => [
+        'caching' => [
+            'cacheConfigurations' => [
+                'aCache' => [
+                    'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\PdoBackend',
+    ...
+
+:file:`LocalConfiguration.php` example after:
+
+.. code-block:: php
+
+    'SYS' => [
+        'caching' => [
+            'cacheConfigurations' => [
+                'aCache' => [
+                    'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\Typo3DatabaseBackend',
+    ...
+
+
+In case this cache backend is still used for whatever reason and can't be dropped
+easily, the class should be copied to an own extension having an own namespace. The
+instance configuration needs to be adapted accordingly. Note there is an additional
+schema definition file in :file:`EXT:core/Resources/Private/Sql/Cache/Backend/PdoBackendCacheAndTags.sql`,
+that should be copied along the way with it's location being updated in the cache class.
+
+.. index:: LocalConfiguration, PHP-API, NotScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94665-WincacheCacheBackend.rst

@@ -0,0 +1,74 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94665:
+
+============================================
+Deprecation: #94665 - Wincache cache backend
+============================================
+
+See :issue:`94665`
+
+Description
+===========
+
+The Caching Framework backend implementation :php:`TYPO3\CMS\Core\Cache\Backend\WincacheBackend`
+is not maintained since Microsoft dropped its support: A PHP 7.4 compatible version
+came long after PHP 7.4 release and there are no PHP 8.0 works in sight. This backend
+in general found relatively little use and can be substituted with the well
+maintained ApcuBackend key/value store on Windows platforms.
+
+:php:`WincacheBackend` has been marked as deprecated and should not be used anymore.
+
+
+Impact
+======
+
+The implementation has been marked as deprecated, usages trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Some instances hosted on Windows platform *may* use this cache backend. This can be
+verified in the backend "Configuration" module, section "TYPO3_CONF_VARS", searching
+for string "WincacheBackend".
+
+
+Migration
+=========
+
+TYPO3 cache backend configuration is usually done in :file:`LocalConfiguration.php`.
+Affected instances could switch to :php:`ApcuBackend` if the :php:`apcu` PHP module
+is loaded, or alternatively to some other backend like :php:`RedisBackend`,
+:php:`MemcachedBackend` or :php:`Typo3DatabaseBackend`, depending on the specific
+cache size and usage characteristics.
+
+
+:file:`LocalConfiguration.php` example before:
+
+.. code-block:: php
+
+    'SYS' => [
+        'caching' => [
+            'cacheConfigurations' => [
+                'aCache' => [
+                    'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\WincacheBackend',
+    ...
+
+:file:`LocalConfiguration.php` example after:
+
+.. code-block:: php
+
+    'SYS' => [
+        'caching' => [
+            'cacheConfigurations' => [
+                'aCache' => [
+                    'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\ApcuBackend',
+    ...
+
+
+In case this cache backend is still used for whatever reason and can't be dropped
+easily, the class should be copied to an own extension having an own namespace. The
+instance configuration needs to be adapted accordingly.
+
+.. index:: LocalConfiguration, PHP-API, NotScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94684-GeneralUtilityShortMD5.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94684:
+
+================================================
+Deprecation: #94684 - GeneralUtility::shortMD5()
+================================================
+
+See :issue:`94684`
+
+Description
+===========
+
+:php:`\TYPO3\CMS\Core\Utility\GeneralUtility\GeneralUtility::shortMD5()` is a
+shorthand method to create an MD5 string trimmed to a defined length, by default
+10 characters.
+
+Such shortened checksums are highly susceptible to collisions, thus this method
+has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::shortMD5()` will trigger a
+PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any extension using :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::shortMD5()` is
+affected. The extension scanner will find usages of that method.
+
+
+Migration
+=========
+
+Use the native :php:`md5()` function to create checksums. In conjunction with
+:php:`substr()` the old behavior can be recovered: :php:`substr(md5($string), 0, 10)`.
+
+If checksums are stored in the database, adapt the respective
+:file:`ext_tables.sql` file to use :sql:`VARCHAR(32)` for the affected database
+fields.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94687-SoftReferenceIndex.rst

@@ -0,0 +1,207 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94687:
+
+==================================================
+Deprecation: #94687 - Deprecate SoftReferenceIndex
+==================================================
+
+See :issue:`94687`
+
+Description
+===========
+
+The :php:`TYPO3\CMS\Core\Database\SoftReferenceIndex` class combined all core
+soft reference parser implementations into one class. Each and every parser
+had its own method residing in one class. It is now possible to define
+a dedicated class for each parser, as a result :php:`SoftReferenceIndex` is not
+needed anymore and has been therefore marked as deprecated.
+
+The related method :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::softRefParserObj()`
+was used to get the according soft reference parser object and was basically a
+factory method. This logic has been moved into
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory`.
+:php:`BackendUtility::softRefParserObj` has been marked as internal in TYPO3 v11
+already. To ease migration, the old static method is still in place and triggers
+a PHP :php:`E_USER_DEPRECATED` error when called.
+
+Another tightly coupled method :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::explodeSoftRefParserList()`,
+which was used to parse the comma separated list of soft reference parsers
+and return them as an array, has now also been marked as deprecated. It was mostly used
+for internal purposes. The corresponding logic now resides in the
+:php:`getParsersBySoftRefParserList` method of
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory`.
+
+All soft reference parsers are now required to implement the
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`.
+Not doing so will trigger a PHP :php:`E_USER_DEPRECATED` error. In TYPO3 v12 this will throw an exception.
+
+Impact
+======
+
+The following class is marked as deprecated. Instantiating this class will
+trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+*  :php:`TYPO3\CMS\Core\Database\SoftReferenceIndex`
+
+The following methods are marked as deprecated. Calling these methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+*  :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::softRefParserObj()`
+*  :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::explodeSoftRefParserList()`
+
+Soft reference parsers must implement
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`.
+Otherwise a PHP :php:`E_USER_DEPRECATED` error will be triggered and an exception will be thrown
+in TYPO3 v12.
+
+Affected Installations
+======================
+
+*  All installations registering user-defined soft reference parsers not
+   implementing :php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`.
+*  All installations calling any of the above-mentioned methods.
+*  All installations, which are using :php:`TYPO3\CMS\Core\Database\SoftReferenceIndex`
+   directly.
+
+Migration
+=========
+
+Among other methods
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`
+ensures the method :php:`parse` is implemented. The previously used method name
+:php:`findRef()` can be simply renamed to :php:`parse()`. The first 4 parameters
+:php:`$table`, :php:`$field`, :php:`$uid` and :php:`$content` stay the same, as
+well as the seventh (now fifth) and last parameter :php:`$structurePath`. The
+remaining two parameters :php:`$spKey` (now :php:`$parserKey`) and
+:php:`$spParams` (now :php:`$parameters`) have to be set by the
+:php:`setParserKey()` method, in case they are needed. The key can be retrieved
+by using the :php:`getParserKey()` method.
+
+The return type has been changed to an instance of
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserResult`. It
+provides as static factory method simply called :php:`create()`. It expects the
+`content` part of the old array as the first parameter and the `elements` part
+as the second. If there are no matches, one can simply call
+:php:`SoftReferenceParserResult::createWithoutMatches()`.
+
+If needed, one could also extend
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\AbstractSoftReferenceParser`.
+This abstract class comes with the helper method :php:`makeTokenID()` (originally
+in :php:`TYPO3\CMS\Core\Database\SoftReferenceIndex`) and a new method
+:php:`setTokenIdBasePrefix`, which sets the concatenated string for the property
+:php:`tokenID_basePrefix`.
+
+Example before:
+
+.. code-block:: php
+
+    class MySoftReferenceParser implements SingletonInterface
+    {
+        public function findRef($table, $field, $uid, $content, $spKey, $spParams, $structurePath = '')
+        {
+            ...
+
+            if (!empty($elements)) {
+                $resultArray = [
+                    'content' => $content,
+                    'elements' => $elements
+                ];
+                return $resultArray;
+            }
+
+            return null;
+        }
+    }
+
+Example after:
+
+.. code-block:: php
+
+    class MySoftReferenceParser implements SoftReferenceParserInterface
+    {
+        protected string $parserKey = '';
+        protected array $parameters = [];
+
+        public function parse(string $table, string $field, int $uid, string $content, string $structurePath = ''): SoftReferenceParserResult
+        {
+            ...
+
+            if (!empty($elements)) {
+                return SoftReferenceParserResult::create(
+                    $content,
+                    $elements
+                );
+            }
+            return SoftReferenceParserResult::createWithoutMatches();
+        }
+
+        /**
+         * @param string $parserKey The softref parser key.
+         * @param array $parameters Parameters of the softlink parser. Basically this is the content inside optional []-brackets after the softref keys. Parameters are exploded by ";
+         */
+        public function setParserKey(string $parserKey, array $parameters): void
+        {
+            $this->parserKey = $parserKey;
+            $this->parameters = $parameters;
+        }
+
+        public function getParserKey(): string
+        {
+            return $this->parserKey;
+        }
+    }
+
+
+Instead of calling :php:`BackendUtility::softRefParserObj()` one should now create
+an instance of :php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory`.
+This factory has a method: :php:`getSoftReferenceParser()`, which expects the
+soft reference key as first argument (just like the BackendUtility method).
+
+Example before:
+
+.. code-block:: php
+
+    $softRefObj = BackendUtility::softRefParserObj('typolink');
+
+Example after:
+
+.. code-block:: php
+
+    $softReferenceParserFactory = GeneralUtility::makeInstance(SoftReferenceParserFactory::class);
+    $softReferenceParser = $softReferenceParserFactory->getSoftReferenceParser('typolink');
+
+The method :php:`BackendUtility::explodeSoftRefParserList()` should be replaced by
+instantiating :php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory`
+and calling :php:`getParsersBySoftRefParserList()`. This method expects the
+:php:`$parserList` as first argument, same as in the :php:`BackendUtility`
+The second argument is a fallback configuration array for softref parsers.
+This method returns an iterable of
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`.
+
+Example before:
+
+.. code-block:: php
+
+    $softRefs = BackendUtility::explodeSoftRefParserList($conf['softref']);
+
+    foreach ($softRefs as $spKey => $spParams) {
+        $softRefObj = BackendUtility::softRefParserObj($spKey);
+        $resultArray = $softRefObj->findRef($table, $field, $idRecord, $valueField, $spKey, $softRefParams);
+    }
+
+Example after:
+
+.. code-block:: php
+
+    foreach ($softReferenceParserFactory->getParsersBySoftRefParserList($conf['softref'], $softRefParams) as $softReferenceParser) {
+        $parserResult = $softReferenceParser->parse($table, $field, $idRecord, $valueField);
+    }
+
+
+Related
+=======
+
+*  :doc:`RegisterSoftReferenceParsersViaDI (Feature) <Feature-94741-RegisterSoftReferenceParsersViaDI>`
+*  :doc:`RegisterSoftReferenceParsersViaDI (Deprecation) <Deprecation-94741-RegisterSoftReferenceParsersViaDI>`
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94741-RegisterSoftReferenceParsersViaDI.rst

@@ -0,0 +1,68 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94741:
+
+===========================================================
+Deprecation: #94741 - Register SoftReference parsers via DI
+===========================================================
+
+See :issue:`94741`
+
+Description
+===========
+
+The former way of registering soft reference parsers in the global array
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser']`
+has been marked as deprecated.
+
+
+Impact
+======
+
+Registering soft reference parsers in the global array will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations, that register user-defined soft reference parsers in the
+global array
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser']`.
+
+
+Migration
+=========
+
+Use the new way of registering soft reference parsers by dependency injection
+in the corresponding `Configuration/Services.(yaml|php)` file of your extension.
+
+Before:
+
+.. code-block:: php
+
+  $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser']['your_key'] = \VENDOR\Extension\SoftReference\YourSoftReferenceParser::class;
+
+After:
+
+.. code-block:: yaml
+
+    VENDOR\Extension\SoftReference\YourSoftReferenceParser:
+      tags:
+        - name: softreference.parser
+          parserKey: your_key
+
+.. note::
+
+   If a parser is registered in both ways with the same key, the registration
+   in the global array takes precedence to ensure backwards-compatibility.
+
+   To ensure compatibility with TYPO3 v10-v12, it is recommended to register
+   both places at the same time.
+
+Related
+=======
+
+*  :doc:`RegisterSoftReferenceParsersViaDI (Feature) <Feature-94741-RegisterSoftReferenceParsersViaDI>`
+*  :doc:`SoftReferenceIndex (Deprecation) <Deprecation-94687-SoftReferenceIndex>`
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94762-DeprecateJavaScriptTopfsModState.rst

@@ -0,0 +1,76 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94762:
+
+==========================================================
+Deprecation: #94762 - Deprecate JavaScript top.fsMod state
+==========================================================
+
+See :issue:`94762`
+
+Description
+===========
+
+The JavaScript object :js:`top.fsMod` manages the "state" for page-tree and
+file-tree related contexts in the backend user-interface like this:
+
+* :js:`top.fsMod.recentIds.web` contained the current ("recent")
+  page or file related identifier details were shown for
+* :js:`top.fsMod.navFrameHighlightedID.web` contained the currently
+  selected identifier that was highlighted in page-tree or file-tree
+* :js:`top.fsMod.currentBank` contained the current mount point or
+  file mount ("bank") used in page-tree or file-tree
+
+To get rid of inline JavaScript and reduce usage of JavaScript :js:`top.*`,
+mentioned :js:`top.fsMod` has been marked as deprecated and replaced by new component
+:js:`TYPO3/CMS/Backend/Storage/ModuleStateStorage`.
+
+Impact
+======
+
+As fall-back, reading from :js:`top.fsMod` is still possible, changing
+data will cause a JavaScript exception.
+
+Affected Installations
+======================
+
+Sites using custom modifications for JavaScript aspects in the backend user
+interface relying on :js:`top.fsMod`.
+
+Migration
+=========
+
+New :js:`ModuleStorage` component is capable of providing similar behavior,
+corresponding state is written to `sessionStorage` and available for current
+client user session (per browser tab).
+
+.. code-block:: javascript
+
+   import {ModuleStateStorage} from '../Storage/ModuleStateStorage';
+   let identifier: string, selection: string|null, mount: string|null;
+
+   // reading state
+   // -------------
+
+   const currentState = ModuleStateStorage.current('web');
+
+   identifier = top.fsMod.recentIds.web; // deprecated
+   identifier = currentState.identifier; // replacement
+
+   selection = top.fsMod.navFrameHighlightedID.web; // deprecated
+   selection = currentState.selection; // replacement
+
+   mount = top.fsMod.currentBank; // deprecated
+   mount = currentState.mount; // replacement
+
+   // updating state
+   // --------------
+
+   // ModuleStateStorage.update(module, identifier, selected, mount?)
+   ModuleStateStorage.update('web', 123, true, '0');
+
+   // ModuleStateStorage.updateWithCurrentMount(module, identifier, selected)
+   ModuleStateStorage.updateWithCurrentMount('web', 123, true);
+
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/11.4/Deprecation-94902-LowerCamelCaseOptionsOfExtImpExpCommands.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94902:
+
+=============================================================================
+Deprecation: #94902 - Deprecate lowerCamelCase options of EXT:impexp commands
+=============================================================================
+
+See :issue:`94902`
+
+Description
+===========
+
+The CLI commands :bash:`impexp:export` and :bash:`impexp:import` offered
+lowerCamelCased options, while the other TYPO3 Core commands offer lowercase
+options only. The lowercase option aliases were introduced in both commands and
+the lowerCamelCased options were marked as deprecated and will be removed in
+TYPO3 v12.
+
+
+Impact
+======
+
+If the CLI commands :bash:`impexp:export` or :bash:`impexp:import` are
+executed with lowerCamelCased options, a PHP :php:`E_USER_DEPRECATED` error is
+raised.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using lowerCamelCased options with commands
+:bash:`impexp:export` or :bash:`impexp:import`.
+
+
+Migration
+=========
+
+Switch to the lower-cased option aliases:
+
+1. :bash:`impexp:export --includeRelated` => :bash:`impexp:export --include-related`
+2. :bash:`impexp:export --includeStatic` => :bash:`impexp:export --include-static`
+3. :bash:`impexp:export --excludeDisabledRecords` => :bash:`impexp:export --exclude-disabled-records`
+4. :bash:`impexp:export --excludeHtmlCss` => :bash:`impexp:export --exclude-html-css`
+5. :bash:`impexp:export --saveFilesOutsideExportFile` => :bash:`impexp:export --save-files-outside-export-file`
+6. :bash:`impexp:import --updateRecords` => :bash:`impexp:import --update-records`
+7. :bash:`impexp:import --ignorePid` => :bash:`impexp:import --ignore-pid`
+8. :bash:`impexp:import --forceUid` => :bash:`impexp:import --force-uid`
+9. :bash:`impexp:import --importMode` => :bash:`impexp:import --import-mode`
+10. :bash:`impexp:import --enableLog` => :bash:`impexp:import --enable-log`
+
+.. index:: CLI, NotScanned, ext:impexp

Documentation/Changelog/11.4/Deprecation-94953-EditPanelRelatedFrontendFunctionality.rst

@@ -0,0 +1,71 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94953:
+
+===============================================================
+Deprecation: #94953 - Edit panel related frontend functionality
+===============================================================
+
+See :issue:`94953`
+
+Description
+===========
+
+With the extraction of the "feedit" extension from TYPO3 core in v10 a
+couple of TypoScript related properties have been rendered unused. Extensions
+that provide a frontend editing approach should implement these on their own.
+
+The following TypoScript properties have been marked as deprecated and
+will be removed in TYPO3 v12:
+
+* :typoscript:`stdWrap.editPanel`
+* :typoscript:`stdWrap.editPanel.`
+* :typoscript:`stdWrap.editIcons`
+* :typoscript:`stdWrap.editIcons.`
+* :typoscript:`EDITPANEL` content object
+
+Related PHP code has been marked as deprecated:
+
+* Method :php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->stdWrap_editIcons()` - scanned
+* Method :php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->stdWrap_editPanel()` - scanned
+* Method :php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->editPanel()` - scanned
+* Method :php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->editIcons()` - scanned
+* Method :php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->isDisabled()` - not scanned
+* Class :php:`TYPO3\CMS\Frontend\ContentObject\EditPanelContentObject` - scanned
+* Hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/classes/class.frontendedit.php']` - scanned, logged
+* Property :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController.php->displayEditIcons` - scanned
+* Property :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController.php->displayFieldEditIcons` - scanned
+* Method :php:`TYPO3\CMS\Frontend\Plugin\AbstractPlugin->pi_getEditPanel()` - scanned, logged
+* Method :php:`TYPO3\CMS\Frontend\Plugin\AbstractPlugin->pi_getEditIcon()` - scanned, logged
+* Property :php:`TYPO3\CMS\Frontend\Plugin\AbstractPlugin->pi_EPtemp_cObj` - scanned
+
+
+Impact
+======
+
+Some of the method usages will trigger a PHP :php:`E_USER_DEPRECATED` error upon use. The
+core extension EXT:fluid_styled_content still sets stdWrap.editPanel and
+stdWrap.editIcons properties for content elements, so the known frontend editing
+related extensions EXT:feedit and EXT:frontend_editing will continue to work
+in v11. Those properties will be removed with v12.
+
+
+Affected Installations
+======================
+
+Instances that use frontend editing extensions - most notably EXT:feedit or
+EXT:frontend_editing - may see deprecated functionality being logged. The
+extension scanner will find PHP usages. Using the TypoScript properties is
+not logged.
+
+
+Migration
+=========
+
+Frontend editing related extensions like EXT:feedit and EXT:frontend_editing
+should no longer rely on core provided preparation. The stdWrap functionality
+can be integrated with stdWrap related hooks, the `EDITPANEL` cObj can be registered
+as extension provided content object, which obsoleted the use of the
+:php:`typo3/classes/class.frontendedit.php` hook.
+
+.. index:: Frontend, PHP-API, TypoScript, PartiallyScanned, ext:frontend

Documentation/Changelog/11.4/Deprecation-94956-PublicCObj.rst

@@ -0,0 +1,79 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94956:
+
+==================================
+Deprecation: #94956 - Public $cObj
+==================================
+
+See :issue:`94956`
+
+Description
+===========
+
+Frontend plugins receive an instance of :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer` when
+called via :php:`ContentObjectRenderer->callUserFunction()`. This is
+typically the case for plugins called as :typoscript:`USER` or indirectly
+as :typoscript:`USER_INT` type.
+
+The instance of :php:`ContentObjectRenderer` has previously been set by
+declaring a public (!) property :php:`cObj` in the consuming class.
+
+Handing a :php:`ContentObjectRenderer` instance around this way is hard to
+follow and has thus been deprecated: Declaring :php:`public $cObj` should
+be avoided. Frontend plugins that need the current :php:`ContentObjectRenderer`
+should have a public :php:`setContentObjectRenderer()` method instead.
+
+
+Impact
+======
+
+Declaring :php:`public $cObj` in a class called by
+:php:`ContentObjectRenderer->callUserFunction()` triggers a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Frontend extension classes that neither extend :php:`TYPO3\CMS\Frontend\Plugin\AbstractPlugin`
+("pibase") nor Extbase :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController`
+and have a public property :php:`cObj` are affected.
+
+
+Migration
+=========
+
+When instantiating the frontend plugin, :php:`ContentObjectRenderer->callUserFunction()`
+now checks for a public method :php:`setContentObjectRenderer()` to explicitly set
+an instance of the :php:`ContentObjectRenderer`.
+
+Many plugins may not need this instance at all. If the ContentObjectRenderer instance
+used within the plugin does not rely on further ContentObjectRenderer state, for instance
+if it only calls :php:`stdWrap()` or similar without using state like :typoscript:`LOAD_REGISTER`,
+the :php:`cObj` class property should be avoided and an own instance of  ContentObjectRenderer
+should be created.
+
+Classes that do rely on current ContentObjectRenderer state should adapt their code.
+
+Before::
+
+    class Foo
+    {
+        public $cObj;
+    }
+
+
+After::
+
+    class Foo
+    {
+        protected $cObj;
+
+        public function setContentObjectRenderer(ContentObjectRenderer $cObj): void
+        {
+            $this->cObj = $cObj;
+        }
+    }
+
+
+.. index:: Frontend, PHP-API, NotScanned, ext:frontend

Documentation/Changelog/11.4/Deprecation-94957-TypoScriptFrontendController-cObjectDepthCounter.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94957:
+
+=======================================================================
+Deprecation: #94957 - TypoScriptFrontendController->cObjectDepthCounter
+=======================================================================
+
+See :issue:`94957`
+
+Description
+===========
+
+The :php:`TypoScriptFrontendController` contains a property to prevent endless
+recursion of content objects during frontend rendering. With TypoScript
+becoming less complex, this check becomes obsolete. To reduce dependencies
+between :php:`TypoScriptFrontendController` and :php:`ContentObjectRenderer`,
+the handling has been removed and property :php:`TypoScriptFrontendController->cObjectDepthCounter`
+has been marked as deprecated.
+
+
+Impact
+======
+
+If a TypoScript setup somehow manages to create a recursion, PHP will now stop
+with a fatal PHP nesting level error at some point, instead TYPO3 frontend
+rendering silently stopping.
+
+
+Affected Installations
+======================
+
+Instances using property :php:`TypoScriptFrontendController->cObjectDepthCounter`
+are affected. That property has been handled mostly internally, this case is unlikely.
+The extension scanner will find usages with a weak match.
+
+
+Migration
+=========
+
+Drop usages of property :php:`TypoScriptFrontendController->cObjectDepthCounter`,
+it is unused within TYPO3 v11.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/11.4/Deprecation-94958-ContentObjectRendererProperties.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94958:
+
+======================================================
+Deprecation: #94958 - ContentObjectRenderer properties
+======================================================
+
+See :issue:`94958`
+
+Description
+===========
+
+A couple of outdated and mostly unused properties of class
+:php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer` have been marked
+as deprecated:
+
+* :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->align` - Unused
+* :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->oldData` - Unused
+* :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->alternativeData` - Never set, only output during debug
+* :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->currentRecordTotal` - Set, but never used
+* :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->recordRegister` - Unused
+
+
+Impact
+======
+
+Those properties did not have a purpose. Extensions shouldn't see
+negative impact.
+
+
+Affected Installations
+======================
+
+Instances with extensions that set or read these properties may be affected.
+This is rather unlikely. The extension scanner finds candidates.
+
+
+Migration
+=========
+
+Drop usages. The properties will vanish in v12.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/11.4/Deprecation-94959-ContentObjectRendererConstructorInStandaloneView.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94959:
+
+=========================================================================
+Deprecation: #94959 - ContentObjectRenderer constructor in StandaloneView
+=========================================================================
+
+See :issue:`94959`
+
+Description
+===========
+
+The :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer` constructor
+argument of :php:`TYPO3\CMS\Fluid\View\StandaloneView` has been marked as
+deprecated. The TYPO3 core never used this optional argument and
+it added a hard dependency to Extbase classes from StandaloneView, which should
+be avoided.
+
+The :php:`ContentObjectRenderer` instance within :php:`StandaloneView` has been used to update
+the Extbase :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager` singleton,
+even though Extbase bootstrap already sets the current ContentObjectRenderer to
+:php:`ConfigurationManager`.
+
+
+Impact
+======
+
+Extensions creating instances of :php:`StandaloneView` and handing over an
+instance of :php:`ContentObjectRenderer` as constructor argument will see a PHP :php:`E_USER_DEPRECATED` error raised.
+
+
+Affected Installations
+======================
+
+Most instances are probably not affected by this change since handing over
+the constructor argument is rather unusual.
+
+
+Migration
+=========
+
+Do not hand over an instance of :php:`ContentObjectRenderer` when creating an
+instance of :php:`StandaloneView`.
+
+.. index:: Fluid, PHP-API, NotScanned, ext:fluid

Documentation/Changelog/11.4/Deprecation-94979-UsingCacheManagerOrDatabaseConnectionsDuringTYPO3Bootstrap.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94979:
+
+=======================================================================================
+Deprecation: #94979 - Using CacheManager or Database Connections during TYPO3 bootstrap
+=======================================================================================
+
+See :issue:`94979`
+
+Description
+===========
+
+TYPO3 now triggers a PHP :php:`E_USER_DEPRECATED` error if extension authors
+or site admins have code in their :file:`ext_localconf.php`,
+:file:`Configuration/TCA/*` configuration files or :file:`ext_tables.php`, that
+calls the :php:`\TYPO3\CMS\Core\Cache\CacheManager` or interacts with the database.
+
+This is important for extension authors as TYPO3 will become
+stricter in the future in terms of booting up TYPO3's Core Configuration, making
+typical requests much faster, as all configuration can be cached away. When
+using TYPO3 in a build environment, this will also lead to possibilities to
+pre-warmup caches during the build phase of a new deployment.
+
+
+Impact
+======
+
+Accessing the database and utilizing the Cache Manager in
+these files will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions using Cache Manager
+or Database Connections in their configuration files (see above).
+
+
+Migration
+=========
+
+Use proper places to initialize extensions, and only when
+needed to reduce the general time to boot up TYPO3's configuration.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/11.4/Deprecation-94991-ExtbaseAbstractView.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94991:
+
+==========================================
+Deprecation: #94991 - Extbase AbstractView
+==========================================
+
+See :issue:`94991`
+
+Description
+===========
+
+To simplify and streamline Fluid view related class inheritance,
+the Extbase class :php:`TYPO3\CMS\Extbase\Mvc\View\AbstractView`
+has been marked as deprecated and will be removed in TYPO3 v12.
+
+
+Impact
+======
+
+Extending the class should be avoided. Consuming classes should
+directly implement :php:`TYPO3\CMS\Extbase\Mvc\View\ViewInterface`
+instead.
+
+
+Affected Installations
+======================
+
+Instances with own Extbase view classes that extend :php:`AbstractView`
+are affected, but this is rather uncommon. The extension scanner will
+find class usages as a strong match.
+
+
+Migration
+=========
+
+Affected Extbase view classes should implement :php:`ViewInterface` instead
+and not extend :php:`AbstractView` anymore. The most simple solution is to
+copy the interface implementation from the deprecated :php:`AbstractView` class.
+
+.. index:: Fluid, PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.4/Deprecation-94996-InComposerModeAllExtensionsShouldBeInstalledWithComposer.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94996:
+
+========================================================================================
+Deprecation: #94996 - In Composer Mode, all Extensions should be installed with Composer
+========================================================================================
+
+See :issue:`94996`
+
+Description
+===========
+
+Having extensions within :file:`typo3conf/ext` in Composer mode, which have not
+been installed with Composer, has been marked as deprecated.
+
+TYPO3 Extensions are Composer packages and therefore Composer mechanisms should
+be used to install them properly in the project, and not placed manually in their
+target location :file:`typo3conf/ext`
+
+
+Impact
+======
+
+A PHP :php:`E_USER_DEPRECATED` error is raised for any extension that is not
+installed with Composer, if the instance is composer based.
+
+
+Affected Installations
+======================
+
+Composer based TYPO3 projects, that have extensions directly in :file:`typo3conf/ext`,
+for instance under version control.
+
+
+Migration
+=========
+
+Composer based TYPO3 projects, that have extensions directly in :file:`typo3conf/ext`
+under version control, should migrate them to be installed using the Composer path
+repository mechanism:
+
+
+.. code-block:: json
+
+    {
+        "repositories": [
+            {
+                "type": "path",
+                "url": "./packages/*/"
+            },
+        ],
+        "require": {
+            "my/example-extension": "@dev",
+        }
+    }
+
+
+Now, when `example-extension` is located in :file:`packages/example-extension`, it is picked
+up by composer and symlinked into :file:`typo3conf/ext/example_extension`.
+
+.. index:: CLI, NotScanned, ext:core

Documentation/Changelog/11.4/Deprecation-95003-ExtbaseViewInterfaceCanRender.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95003:
+
+=======================================================
+Deprecation: #95003 - Extbase ViewInterface canRender()
+=======================================================
+
+See :issue:`95003`
+
+Description
+===========
+
+To streamline and simplify Fluid view related classes, the
+Extbase related :php:`TYPO3\CMS\Extbase\Mvc\View\ViewInterface`
+method :php:`canRender()` has been dropped from the interface.
+
+Impact
+======
+
+The method should not be used anymore. Implementations in consuming
+view classes are kept in TYPO3 v11 but have been marked as deprecated and
+trigger a PHP :php:`E_USER_DEPRECATED` error upon usage.
+
+
+Affected Installations
+======================
+
+Method :php:`canRender()` had limited use within Extbase, it is rather
+unlikely many instances with extensions using the method exist. It's
+purpose was to check for Fluid template existence before calling
+:php:`$view->render()`, but all existing view implementations throw an
+exception during :php:`render()` if a template path can't be resolved.
+
+
+Migration
+=========
+
+Do not call :php:`canRender()` on template view instances, but let
+:php:`render()` throw :php:`\TYPO3Fluid\Fluid\View\Exception\InvalidTemplateResourceException` on error
+instead.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.4/Deprecation-95005-ExtbaseEmptyView.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95005:
+
+=======================================
+Deprecation: #95005 - Extbase EmptyView
+=======================================
+
+See :issue:`95005`
+
+Description
+===========
+
+To further clean up and streamline Fluid view related functionality, the
+Extbase related view class :php:`TYPO3\CMS\Extbase\Mvc\View\EmptyView`
+has been marked as deprecated.
+
+
+Impact
+======
+
+Using :php:`EmptyView` has been marked as deprecated and trigger a PHP :php:`E_USER_DEPRECATED` error upon use.
+
+
+Affected Installations
+======================
+
+The class has been unused within TYPO3 core since its introduction in TYPO3 4.5.
+It is rather unlikely instances have extensions using the class. The extension
+scanner finds usages with a strong match.
+
+
+Migration
+=========
+
+If rendering "nothing" by a view instance is needed for whatever reason, the
+same result can be achieved with a :php:`TYPO3\CMS\Fluid\View\StandaloneView`
+view instance by setting :php:`$view->setTemplateSource('')` and calling
+:php:`$view->render()`. But it's of course quicker to simply not render
+anything at all.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.4/Deprecation-95009-PassingTypoScriptConfigurationAsConstructorArgumentToExceptionHandler.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95009:
+
+===================================================================================================
+Deprecation: #95009 - Passing TypoScript configuration as constructor argument to Exception handler
+===================================================================================================
+
+See :issue:`95009`
+
+Description
+===========
+
+With :typoscript:`config.contentObjectExceptionHandler` it's possible to
+adjust the exception handler behavior of the frontend. It's even possible
+to use an own exception handler class. Previously, the TypoScript configuration
+was therefore passed to the exception handler via a constructor argument. This
+has now been deprecated to allow the use of DI.
+
+The configuration will now be passed using the new :php:`setConfiguration()`
+method. This method will be enforced by the :php:`ExceptionHandlerInterface`
+in TYPO3 v12.
+
+Impact
+======
+
+Using a custom exception handler, while not implementing the :php:`setConfiguration()`
+method will trigger a deprecation log entry. The method will be enforced
+in TYPO3 v12.
+
+Affected Installations
+======================
+
+All installations defining a custom exception handler via the TypoScript
+configuration :typoscript:`config.contentObjectExceptionHandler`, while
+not implementing the :php:`setConfiguration()` method.
+
+Migration
+=========
+
+Remove the :php:`$configuration` argument from the constructor of any
+custom exception handler class and implement the :php:`setConfiguration()`
+method instead.
+
+.. index:: Frontend, PHP-API, NotScanned, ext:frontend

Documentation/Changelog/11.4/Deprecation-95011-VariousGlobalJavaScriptFunctionsAndVariables.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95011:
+
+=======================================================================
+Deprecation: #95011 - Various global JavaScript functions and variables
+=======================================================================
+
+See :issue:`95011`
+
+Description
+===========
+
+The following globally available variables in TYPO3 Backend's JavaScript code have been marked as deprecated:
+
+* :js:`top.currentSubScript`
+* :js:`top.currentModuleLoaded`
+* :js:`top.nextLoadModuleUrl`
+
+In addition the global JavaScript function :js:`jump()` has
+been marked as deprecated as well.
+
+This functionality has been around for a very long time, and
+is superseded by TYPO3's Module Menu Component (since 4.5) and the newly introduced Backend Routing Component in JavaScript
+since TYPO3 v11.
+
+
+Impact
+======
+
+The variables will work and be filled as expected in TYPO3 v11, but will not be available anymore in TYPO3 v12.
+
+Calling :js:`jump()` will trigger a JavaScript warning in ones'
+browser console.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions which utilize Backend
+JavaScript and using the legacy functionality, which is highly
+unlikely.
+
+
+Migration
+=========
+
+Use the ModuleMenu JavaScript API or the Router API to find out the current module or go to a specific route:
+
+.. code-block:: js
+
+    const router = document.querySelector('typo3-backend-module-router');
+    router.setAttribute('endpoint', url);
+    router.setAttribute('module', moduleName);
+
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/11.4/Deprecation-95037-RootUidRelatedSettingOfTrees.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95037:
+
+======================================================
+Deprecation: #95037 - rootUid related setting of trees
+======================================================
+
+See :issue:`95037`
+
+Description
+===========
+
+The setting :php:`rootUid` used in FormEngine's :php:`treeConfig` is superseded by
+:php:`startingPoints` and has been marked as deprecated.
+
+In :php:`TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider` the
+following methods have been marked as deprecated:
+
+* :php:`setRootUid()`
+* :php:`getRootUid()`
+
+
+Impact
+======
+
+Using `treeConfig/rootUid` in TCA will trigger a TCA migration to
+`treeConfig/startingPoints` and raise a PHP :php:`E_USER_DEPRECATED` error.
+
+The same applies to the according page TSconfig option.
+
+The extension scanner detects any call to :php:`setRootUid()`
+or :php:`getRootUid()` as weak match.
+
+
+Affected Installations
+======================
+
+All extensions defining `rootUid` in their `TCA` or `TSconfig` are affected.
+Furthermore all extensions directly calling one of the mentioned methods in
+:php:`TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider`.
+
+
+Migration
+=========
+
+The setting `treeConfig/rootUid` can be migrated to `treeConfig/startingPoints`
+passing the value as string, since `treeConfig/startingPoints` takes a
+comma-separated value. The methods :php:`setRootUid()` and :php:`getRootUid()`
+can be replaced by their successors :php:`setStartingPoints()` and
+:php:`getStartingPoints()`.
+
+.. index:: Backend, PartiallyScanned, ext:backend

Documentation/Changelog/11.4/Deprecation-95062-SkipSortingArgumentOfRelationHandler-writeForeignField.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95062:
+
+===================================================================================
+Deprecation: #95062 - $skipSorting argument of RelationHandler->writeForeignField()
+===================================================================================
+
+See :issue:`95062`
+
+Description
+===========
+
+To further clean up :php:`TYPO3\CMS\Core\DataHandling\DataHandler`, the unused
+internal property :php:`callFromImpExp` has been removed. Its single usage has
+been the 4th argument of :php:`TYPO3\CMS\Core\Database\RelationHandler->writeForeignField()`.
+Handing over this argument to :php:`RelationHandler->writeForeignField()` has been
+marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`TYPO3\CMS\Core\Database\RelationHandler->writeForeignField()` with
+4th argument triggers a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+It is unlikely instances contain extensions using the above argument, since
+it carried a core internal information tailored for EXT:impexp specific needs.
+The extension scanner will find usages as weak match.
+
+
+Migration
+=========
+
+No migration available. Consuming extensions should drop that argument.
+Calling RelationHandler->writeForeignField() with non-default true as fourth
+argument skipped some relation-sorting related code, which should be avoided.
+
+.. index:: Database, FullyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-95065-HookExtTablesInclusion-PostProcessing.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95065:
+
+============================================================
+Deprecation: #95065 - Hook extTablesInclusion-PostProcessing
+============================================================
+
+See :issue:`95065`
+
+Description
+===========
+
+The TYPO3 hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['extTablesInclusion-PostProcessing']`
+which is executed after :file:`ext_tables.php` files are included has been marked
+as deprecated.
+
+The accompanied PHP interface for such hooks
+:php:`TYPO3\CMS\Core\Database\TableConfigurationPostProcessingHookInterface` is
+marked as deprecated as well.
+
+
+Impact
+======
+
+If a hook is registered in a TYPO3 installation, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+
+Migration
+=========
+
+Migrate to PSR-14 events, mainly the newly introduced :php:`\TYPO3\CMS\Core\Core\Event\BootCompletedEvent` and
+the existing :php:`\TYPO3\CMS\Core\Configuration\Event\AfterTcaCompilationEvent`
+depending on the use-case.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-95077-FilelistEditIconsHook.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95077-1668719172:
+
+============================================
+Deprecation: #95077 - Filelist editIconsHook
+============================================
+
+See :issue:`95077`
+
+Description
+===========
+
+The TYPO3 hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['fileList']['editIconsHook']`
+which is executed in the :php:`FileList` class to manipulate the icons, used
+for the edit control section in the files and folders listing, has been marked as
+deprecated.
+
+The accompanied PHP interface for such hooks
+:php:`TYPO3\CMS\Filelist\FileListEditIconHookInterface` has been marked
+as deprecated as well.
+
+Impact
+======
+
+If a hook is registered in a TYPO3 installation, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+The extension scanner also detects any usage
+of the deprecated interface as strong, and the definition of the
+hook as weak match.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+Migrate to the newly introduced :php:`\TYPO3\CMS\Filelist\Event\ProcessFileListActionsEvent` PSR-14 event.
+
+.. index:: PHP-API, FullyScanned, ext:filelist

Documentation/Changelog/11.4/Deprecation-95080-FileDumpCheckFileAccessHook.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95077:
+
+===================================================
+Deprecation: #95077 - FileDump CheckFileAccess hook
+===================================================
+
+See :issue:`95077`
+
+Description
+===========
+
+The TYPO3 hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['FileDumpEID.php']['checkFileAccess']`
+which is executed in the :php:`\TYPO3\CMS\Core\Controller\FileDumpController` class, enabling third-party
+code to perform additional access / security checks before dumping the requested
+file, has been marked as deprecated.
+
+The accompanied PHP interface for the hook
+:php:`TYPO3\CMS\Core\Resource\Hook\FileDumpEIDHookInterface` has been marked
+as deprecated as well.
+
+Impact
+======
+
+If a hook is registered in a TYPO3 installation, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+The extension scanner also detects any usage
+of the deprecated interface as strong, and the definition of the
+hook as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+Migrate to the newly introduced :php:`\TYPO3\CMS\Core\Resource\Event\ModifyFileDumpEvent` PSR-14 event.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-95083-BackendToolbarCacheActionsHook.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95083:
+
+=======================================================
+Deprecation: #95083 - Backend toolbar CacheActions hook
+=======================================================
+
+See :issue:`95083`
+
+Description
+===========
+
+The TYPO3 hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['additionalBackendItems']['cacheActions']`
+which can be used to modify the cache actions, shown in the TYPO3 Backend
+top toolbar, has been marked as deprecated.
+
+The accompanied PHP interface for the hook
+:php:`TYPO3\CMS\Backend\Toolbar\ClearCacheActionsHookInterface` has been
+marked as deprecated as well.
+
+Impact
+======
+
+If the hook is registered in a TYPO3 installation, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+The extension scanner also detects any usage
+of the deprecated interface as strong, and the definition of the
+hook as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+Migrate to the newly introduced :php:`\TYPO3\CMS\Backend\Backend\Event\ModifyClearCacheActionsEvent` PSR-14 event.
+
+.. index:: PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.4/Deprecation-95089-ExtendedFileUtilityProcessDataHook.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95089:
+
+==========================================================
+Deprecation: #95089 - ExtendedFileUtility ProcessData hook
+==========================================================
+
+See :issue:`95089`
+
+Description
+===========
+
+The TYPO3 hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_extfilefunc.php']['processData']`
+which can be used to execute additional tasks, after a file operation has
+been performed, has been marked as deprecated.
+
+The accompanied PHP interface for the hook
+:php:`TYPO3\CMS\Core\Utility\File\ExtendedFileUtilityProcessDataHookInterface`
+has been marked as deprecated as well.
+
+Impact
+======
+
+If the hook is registered in a TYPO3 installation, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+The extension scanner also detects any usage
+of the deprecated interface as strong, and the definition of the
+hook as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+Migrate to the newly introduced :php:`AfterFileCommandProcessedEvent` PSR-14 event.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.4/Deprecation-95105-DatabaseRecordListHooks.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-95105:
+
+==============================================
+Deprecation: #95105 - DatabaseRecordList hooks
+==============================================
+
+See :issue:`95105`
+
+Description
+===========
+
+The TYPO3 hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/class.db_list_extra.inc']['actions']`
+which is used in the :php:`DatabaseRecordList` class for modifying the
+behavior of each table listing, has been marked as deprecated.
+
+Using this hook always required to implement the :php:`\TYPO3\CMS\Recordlist\RecordList\RecordListHookInterface`,
+which then required the corresponding hook class to implement four different
+hook methods, even if only one of them was needed.
+
+Furthermore are those methods no longer sufficient since e.g. the "controls"
+and "clip" sections were merged together already. Therefore, also the
+accompanied PHP interface :php:`TYPO3\CMS\Recordlist\RecordList\RecordListHookInterface`
+has been marked as deprecated.
+
+Impact
+======
+
+If the hook is registered in a TYPO3 installation, a PHP :php:`E_USER_DEPRECATED` error is triggered. The extension scanner also detects any usage
+of the deprecated interface as strong, and the definition of the
+hook as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+Migrate to the corresponding RecordList PSR-14 events:
+
+- `\TYPO3\CMS\Recordlist\Event\ModifyRecordListTableActionsEvent`
+- `\TYPO3\CMS\Recordlist\Event\ModifyRecordListHeaderColumnsEvent`
+- `\TYPO3\CMS\Recordlist\Event\ModifyRecordListRecordActionsEvent`
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.4/Feature-71775-HtmlParserAllowsSrcset.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-71775:
+
+==========================================
+Feature: #71775 - HtmlParser allows srcset
+==========================================
+
+See :issue:`71775`
+
+Description
+===========
+
+The :php:`\TYPO3\CMS\Core\Html\HtmlParser` - most commonly used when rendering RTE fields
+in the frontend - now handles the :html:`srcset` attribute.
+
+A casual use case for this are responsive images:
+
+.. code-block:: html
+
+   <picture>
+       <source media="(max-width: 799px)" srcset="small-image.jpg">
+       <source media="(min-width: 800px)" srcset="larger-image.jpg">
+   </picture>
+
+
+Impact
+======
+
+Using :html:`source` tag with :html:`srcset` attribute is allowed and
+:html:`srcset` values are prefixed correctly.
+
+.. index:: Frontend, RTE, ext:core

Documentation/Changelog/11.4/Feature-84115-DoctrineDBAL-NotInSetForExpressions.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84115:
+
+============================================================
+Feature: #84115 - Doctrine DBAL - notInSet() for expressions
+============================================================
+
+See :issue:`84115`
+
+Description
+===========
+
+TYPO3's Database Abstraction Layer supports a wide range of
+cross-RDBMS-functionality to limit SELECT statements via
+the ExpressionBuilder.
+
+When using :php:`\TYPO3\CMS\Core\Database\Query\Expression\ExpressionBuilder`
+for comma-separated lists, the call :php:`inSet()` can be used to detect database rows
+which include a value in a comma-separated list, such as
+:sql:`pages.fe_group` where the UIDs of allowed frontend user groups
+are stored.
+
+The method :php:`notInSet()` has been added to TYPO3's DBAL ExpressionBuilder,
+which works as the opposite functionality:
+"Get all rows where a certain value is NOT in the list of comma-separated values".
+
+
+Impact
+======
+
+It is now possible to use :php:`notInSet()` via Doctrine DBAL
+Expression Builder for SQLite, MySQL/MariaDB, PostgreSQL and MSSQL Backends.
+
+Example:
+
+.. code-block:: php
+
+    $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable('fe_users');
+    $result = $queryBuilder
+        ->select('*')
+        ->from('fe_users')
+        ->where(
+            $queryBuilder->expr()->notInSet('usergroup', '5')
+        )
+        ->execute();
+
+
+This queries all frontend users which do not directly belong
+to usergroup of with uid "5".
+
+Please note that this functionality is for extension authors
+and their usage should be thought-through properly, as queries such as "Show me all results where the usergroup has NO access to" isn't a use-case for `notInSet()`.
+
+.. index:: Database, ext:core

Documentation/Changelog/11.4/Feature-84184-ShowColumnsSelectionInFilelist.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84184:
+
+====================================================
+Feature: #84184 - Show columns selection in filelist
+====================================================
+
+See :issue:`84184`
+
+Description
+===========
+
+The column selector, introduced in :issue:`94218` and improved
+in :issue:`94474`, is now also available in the filelist module.
+
+As already known from the recordlist, it can be used to manage the fields,
+displayed for each file / folder, while containing convenience actions,
+such as "filter", "check all / none" and "toggle selection".
+
+The fields to be selected are a combination of special fields, such as
+`references` or `read/write` permissions, the corresponding `sys_file`
+record fields, as well as all available `sys_file_metadata` fields.
+
+Administrators can manage whether the column selection is available
+for their users with a new User TSconfig option:
+
+.. code-block:: typoscript
+
+   # disable the column selector
+   options.file_list.displayColumnSelector = 0
+
+
+Impact
+======
+
+It's now possible to manage the displayed fields for files / folders
+in the filelist module, using the columns selection component.
+
+.. index:: Backend

Documentation/Changelog/11.4/Feature-84718-AddCLIExportCommandToImpExpExtension.rst

@@ -0,0 +1,64 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84718:
+
+======================================================
+Feature: #84718 - Add CLI export command to EXT:impexp
+======================================================
+
+See :issue:`84718`
+
+Description
+===========
+
+The new CLI command
+
+-  :bash:`impexp:export`
+
+was added as the missing twin of the existing CLI command :bash:`impexp:import`.
+
+The export command can be executed via
+
+.. code-block:: bash
+
+   typo3/sysext/core/bin/typo3 impexp:export [options] [--] [<filename>]
+
+and exports the entire TYPO3 page tree - or parts of it - to a data file of
+format XML or T3D, which can be used for import into any TYPO3 instance or
+as initial page tree of a :ref:`distribution <t3coreapi:distribution>`.
+
+The export can be fine-tuned through the complete set of options already
+available in the export view of the TYPO3 backend:
+
+.. code-block:: bash
+
+   Arguments:
+      filename                           The filename to export to (without file extension)
+
+   Options:
+      --type[=TYPE]                      The file type (xml, t3d, t3d_compressed). [default: "xml"]
+      --pid[=PID]                        The root page of the exported page tree. [default: -1]
+      --levels[=LEVELS]                  The depth of the exported page tree. "-2": "Records on this page", "-1": "Expanded tree", "0": "This page", "1": "1 level down", .. "999": "Infinite levels". [default: 0]
+      --table[=TABLE]                    Include all records of this table. Examples: "_ALL", "tt_content", "sys_file_reference", etc. (multiple values allowed)
+      --record[=RECORD]                  Include this specific record. Pattern is "{table}:{record}". Examples: "tt_content:12", etc. (multiple values allowed)
+      --list[=LIST]                      Include the records of this table and this page. Pattern is "{table}:{pid}". Examples: "sys_language:0", etc. (multiple values allowed)
+      --includeRelated[=INCLUDERELATED]  Include record relations to this table, including the related record. Examples: "_ALL", "sys_category", etc. (multiple values allowed)
+      --includeStatic[=INCLUDESTATIC]    Include record relations to this table, excluding the related record. Examples: "_ALL", "sys_language", etc. (multiple values allowed)
+      --exclude[=EXCLUDE]                Exclude this specific record. Pattern is "{table}:{record}". Examples: "fe_users:3", etc. (multiple values allowed)
+      --excludeDisabledRecords           Exclude records which are handled as disabled by their TCA configuration, e.g. by fields "disabled", "starttime" or "endtime".
+      --excludeHtmlCss                   Exclude referenced HTML and CSS files.
+      --title[=TITLE]                    The meta title of the export.
+      --description[=DESCRIPTION]        The meta description of the export.
+      --notes[=NOTES]                    The meta notes of the export.
+      --dependency[=DEPENDENCY]          This TYPO3 extension is required for the exported records. Examples: "news", "powermail", etc. (multiple values allowed)
+      --saveFilesOutsideExportFile       Save files into separate folder instead of including them into the common export file. Folder name pattern is "{filename}.files".
+
+Impact
+======
+
+Exporting a TYPO3 page tree without time limit is now possible via CLI.
+
+Repeated exports with the same configuration become easily documentable and
+applicable - for example during distribution development.
+
+.. index:: CLI, ext:impexp

Documentation/Changelog/11.4/Feature-90197-IntroduceCacheFlushConsoleCommand.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90197:
+
+=======================================================
+Feature: #90197 - Introduce cache:flush console command
+=======================================================
+
+See :issue:`90197`
+
+Description
+===========
+
+It is now possible to flush TYPO3 caches using the command line.
+
+The administrator can use the following CLI command:
+
+.. code-block:: bash
+
+   ./typo3/sysext/core/bin/typo3 cache:flush
+
+Specific cache groups can be defined via the group option.
+The usage is described as:
+
+.. code-block:: bash
+
+   cache:flush [--group <all|system|di|pages|…>]
+
+All available cache groups can be supplied as option. The command defaults to
+flush all available cache groups as the install tool does.
+
+Extensions that register custom caches may listen to the
+via :php:`TYPO3\CMS\Core\Cache\Event\CacheFlushEvent`, but usually the
+cache flush via CacheManager groups will suffice.
+
+Impact
+======
+
+It is often required to clear caches during deployment of TYPO3 instance
+updates, in order for content changes to become active.
+
+TYPO3 caches can now be flushed in release postparatory steps. The integrator
+may decide to flush all caches (common practice with `EXT:typo3_console`) or
+may alternatively flush selected groups (e.g. 'pages') in case the `cache:warmup`
+(see :issue:`93436`) command is used as companion in release preparatory steps.
+
+Deployment steps could then be:
+
+* Release preparation:
+
+  * git-checkout/rsync your codebase (on CI or on live system)
+  * `composer install` (on CI or on live system)
+  * `vendor/bin/typo3 cache:warmup --group system` (*only* on the live system)
+
+* Change release symlink to the new release folder
+* Release postparation
+
+  * `vendor/bin/typo3 cache:flush --group pages`
+
+.. index:: CLI, ext:core

Documentation/Changelog/11.4/Feature-90336-CKEditorAutolinkingUsesHttpsByDefault.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90336:
+
+============================================================
+Feature: #90336 - CKEditor Autolinking uses https by default
+============================================================
+
+See :issue:`90336`
+
+Description
+===========
+
+TYPO3 ships with a CKEditor plugin called "autolinking", which
+automatically converts typed text within a RTE to an external URL.
+
+When typing `www.typo3.org` this is automatically converted to
+an absolute external link, which previously used `http://` as
+schema.
+
+Nowadays, over 90% of the web is served via the https protocol
+and secure connections via SSL/TLS, where it is safe to
+use secure-by-default links.
+
+When not specifically using a schema as prefix for an autolinking
+URL, CKEditor now uses `https` instead of `http` as schema by default.
+
+
+Impact
+======
+
+When typing a URL like www.typo3.org in the RTE and the autolinking
+plugin is activated, the default schema used is now `https` instead
+of `http` for any new links.
+
+However, it is - as before - fully possible to manually change a
+link to use the `http://` schema instead.
+
+.. index:: RTE, ext:rte_ckeditor

Documentation/Changelog/11.4/Feature-90347-EnableRecursiveTransformationOfPropertiesInJsonView.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90347:
+
+===========================================================================
+Feature: #90347 - Enable recursive transformation of properties in JsonView
+===========================================================================
+
+See :issue:`90347`
+
+Description
+===========
+
+The Extbase :php:`\TYPO3\CMS\Extbase\Mvc\View\JsonView` is now able to resolve
+recursive properties of objects, e.g. directories containing directories or
+comments containing comments as replies.
+
+Examples:
+
+1. This is for 1:1 relations, where a comment has at most 1 comment.
+
+.. code-block:: php
+
+   $configuration = [
+       'comment' => [
+           '_recursive' => ['comment']
+        ]
+   ];
+
+
+2. This is for the more common 1:n relation in which you have lists of sub objects.
+
+.. code-block:: php
+
+   $configuration = [
+       'directories' => [
+           '_descendAll' => [
+               '_recursive' => ['directories']
+           ],
+       ]
+   ];
+
+You can put all the other configuration like :php:`_only` or :php:`_exclude` at the same
+level as :php:`_recursive` and the view will apply this for all levels.
+
+Impact
+======
+
+Developers can now use the :php:`_recursive` property in the :php:`JsonView`
+configuration in order to resolve recursive properties instead of defining each
+level manually.
+
+.. index:: ext:extbase

Documentation/Changelog/11.4/Feature-90548-DownloadMultipleFilesAndFoldersInFilelist.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90548:
+
+=================================================================
+Feature: #90548 - Download multiple files and folders in filelist
+=================================================================
+
+See :issue:`90548`
+
+Description
+===========
+
+From time to time, editors might need to download files and folders,
+which are stored in the TYPO3 installation. Therefore, the filelist
+module has been improved to provide a couple of possibilities for
+downloading the stored files and folders.
+
+The action bar on the top of the listing now features the "Download"
+option. It is shown, as soon as a file or folder is selected. It can
+therefore be used to download a specific selection of files and folders.
+
+The "Download" option has furthermore been added to the context menu as
+well as the secondary menu. Those options can be used to download
+a single file or folder.
+
+Administrators can furthermore specify, which file extensions are allowed
+for their users to be downloaded. Therefore, following user TSconfig is
+available, expecting a comma-separated list of file extensions:
+
+.. code-block:: typoscript
+
+   # Either an allow list
+   options.file_list.fileDownload.allowedFileExtensions = png,svg,pdf
+
+   # or a deny list
+   options.file_list.fileDownload.disallowedFileExtensions = yaml,exe,html
+
+It's also possible to completely disable the file download for users:
+
+.. code-block:: typoscript
+
+    options.file_list.fileDownload.enabled = 0
+
+.. note::
+
+    When downloading folders, all readable subfolders and their files
+    are included in the generated ZIP file as well.
+
+Impact
+======
+
+It's now possible to download files and folders in the filelist module.
+
+.. index:: Backend, ext:filelist

Documentation/Changelog/11.4/Feature-91021-FilterByStageInWorkspacesModule.rst

@@ -0,0 +1,27 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91021:
+
+======================================================
+Feature: #91021 - Filter by stage in Workspaces Module
+======================================================
+
+See :issue:`91021`
+
+Description
+===========
+
+When reviewing staged changes in a larger workspace environment,
+editors who need to review changes or send them to the next
+stage now have an additional filter dropdown in the Workspaces
+module to only show records that are in a specific stage.
+
+
+Impact
+======
+
+A new dropdown to narrow down lot of records has been added
+to the Workspaces administration module, which is automatically
+populated with available stages for the specific workspace.
+
+.. index:: Backend, ext:workspaces

Documentation/Changelog/11.4/Feature-92460-SplitDefaultFromAllLanguagesInPageModule.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-92460:
+
+=================================================================
+Feature: #92460 - Split default from all languages in page module
+=================================================================
+
+See :issue:`92460`
+
+Description
+===========
+
+The view "Languages" in the page module allows to display content elements of
+the default language next to the ones of the selected language.
+
+If the default language is chosen, instead of rendering all content elements
+of all languages, now only the content elements of the default language are
+rendered.
+
+If an editor requires to see all content elements of all languages, the
+option "All languages" can be selected.
+
+
+Impact
+======
+
+Having many languages and many content elements can be a performance issue
+in the page module which is now fixed.
+
+Additionally the language view is now consistent with the column view.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.4/Feature-93197-ResolveCollectionTypesOfNon-persistentObjects.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93197:
+
+====================================================================
+Feature: #93197 - Resolve collection types of non-persistent objects
+====================================================================
+
+See :issue:`93197`
+
+Description
+===========
+
+Collection types are used to define a specific class that should be within
+Extbase's :php:`\TYPO3\CMS\Extbase\Persistence\ObjectStorage` class.
+
+Example:
+
+.. code-block:: php
+
+    /**
+     * @param ObjectStorage<Item> $items
+     */
+    public function setItems(ObjectStorage $items): void
+    {
+        $this->items = $items;
+    }
+
+These docblocks are analyzed so the :php:`PropertyMapper` knows how to map
+incoming requests. This mapping already works for persistent objects
+(domain models). As non-persistent objects are also used for property mapping,
+namely DTOs (data transfer objects), this now works for them, too.
+
+Impact
+======
+
+Developers can use collection types in docblock annotations for non-persistent
+objects. The collection type is considered while property mapping requests.
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/11.4/Feature-93436-IntroduceCacheWarmupConsoleCommand.rst

@@ -0,0 +1,85 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93436:
+
+========================================================
+Feature: #93436 - Introduce cache:warmup console command
+========================================================
+
+See :issue:`93436`
+
+Description
+===========
+
+It is now possible to warmup TYPO3 caches using the command line.
+
+The administrator can use the following CLI command:
+
+.. code-block:: bash
+
+   ./typo3/sysext/core/bin/typo3 cache:warmup
+
+Specific cache groups can be defined via the group option.
+The usage is described as:
+
+.. code-block:: bash
+
+   cache:warmup [--group <all|system|di|pages|…>]
+
+All available cache groups can be supplied as option. The command defaults to
+warm all available cache groups.
+
+Extensions that register custom caches are encouraged to implement cache warmers
+via :php:`TYPO3\CMS\Core\Cache\Event\CacheWarmupEvent`.
+
+Note: TYPO3 frontend caches will not be warmed by TYPO3 core, such functionality
+could be added by third party extensions with the help of
+:php:`TYPO3\CMS\Core\Cache\Event\CacheWarmupEvent`.
+
+Impact
+======
+
+It is common practice to clear all caches during deployment of TYPO3 instance
+updates. This means that the first request after a deployment usually takes
+a major amount of time and blocks other requests due to cache-locks.
+
+TYPO3 caches can now be warmed during deployment in release preparatory steps in
+symlink based deployment/release procedures. This enables fast first requests
+with all (or at least system) caches being prepared and warmed.
+
+Caches are often filesystem relevant (filepaths are calculated into cache
+hashes), therefore cache warmup should only be performed on the live system,
+in the *final* folder of a new release, and ideally before switching
+to that new release (via symlink switch). Note that caches that have be
+pre-created in CI will likely be useless as cache hashes will not match.
+
+To summarize: Cache warmup is to be used during deployment, on the live system
+server, inside the new release folder and before switching the new release live.
+
+Deployment steps are:
+
+* Release preparation:
+
+  * git-checkout/rsync your codebase (on CI or on live system)
+  * `composer install` (on CI or on live system)
+  * `vendor/bin/typo3 cache:warmup --group system` (*only* on the live system)
+
+* Change release symlink to the new release folder
+* Release postparation
+
+  * Clear only the page related caches (e.g. via database truncate or an
+    upcoming `cache:flush` command)
+
+The conceptional idea is to warmup all file-related caches *before* (symlink)
+switching to a new release and to *only* flush database and frontend (shared)
+caches after the symlink switch. Database warmup could be implemented with
+the help of the :php:`TYPO3\CMS\Core\Cache\Event\CacheWarmupEvent` as an
+additionally functionality by third party extensions.
+
+Note that file-related caches (summarized into the group "system") can safely be
+cleared before doing a release switch, as it is recommended to keep file caches
+per release. In other words, share :file:`var/session`, :file:`var/log`,
+:file:`var/lock` and :file:`var/charset` between releases, but keep
+:file:`var/cache` be associated only with one release.
+
+.. index:: CLI, ext:core

Documentation/Changelog/11.4/Feature-94402-GenerateErrorPagesViaTYPO3-internalSubRequest.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94402:
+
+=====================================================================
+Feature: #94402 - Generate error pages via TYPO3-internal sub-request
+=====================================================================
+
+See :issue:`94402`
+
+Description
+===========
+
+Error pages (such as 404 - not found, or 403 - access denied) may now be generated
+via a TYPO3-internal sub-request instead of an external HTTP
+request (cURL over Guzzle).
+
+This feature is disabled by default, as there are some cases where stateful information
+is not correctly reset for the subrequest.  It may be enabled on an experimental
+basis via a feature flag called `subrequestPageErrors` in the "Settings"
+module.
+
+This change will default to enabled in a future version once all stateful services
+are identified and removed.
+
+Impact
+======
+
+Generating error pages internally reduces the server load drastically, and
+solves various issues when dealing with load-balanced systems where the hostname
+of the server might not match the public-facing server ("front server").
+
+However, in some cases there might be problems with third-party extensions
+that override super globals (e.g. :php:`$_GET` and :php:`$_POST`), where the option could be
+disabled.  There are also some remaining cases in core of stateful services that,
+in some configurations, result in incorrect error pages being generated. For that
+reason the feature defaults to disabled for now.
+
+This feature is only relevant for site configurations loading error pages
+from a different Page ID.
+
+.. index:: Frontend, PHP-API, ext:frontend

Documentation/Changelog/11.4/Feature-94406-OverrideFileFolderTCAConfigurationWithTSconfig.rst

@@ -0,0 +1,110 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94406:
+
+=====================================================================
+Feature: #94406 - Override fileFolder TCA configuration with TSconfig
+=====================================================================
+
+See :issue:`94406`
+
+Description
+===========
+
+The special `fileFolder configuration options <https://docs.typo3.org/m/typo3/reference-tca/main/en-us/ColumnsConfig/Type/Select/Properties/FileFolder.html#filefolder>`__
+for TCA columns of type :php:`select` can be used to fill a select field with files
+(images / icons) from a defined folder. This is really handy, e.g. for selecting
+predefined icons from a corporate icon set. However, in installations with
+multiple sites, such icon sets usually differ from site to site.
+
+Therefore, the :php:`fileFolder` configuration can now be overridden with page
+TSconfig, allowing administrators to easily handle those situations by e.g.
+using different folders or allowing different file extensions, per site.
+
+To streamline both, the TCA configuration and the corresponding overrides,
+the :php:`fileFolder` configuration options have been moved into a dedicated sub
+array :php:`fileFolderConfig`, some options have been renamed:
+
+* :php:`fileFolder` option :php:`folder`
+* :php:`fileFolder_extList` to :php:`allowedExtensions`
+* :php:`fileFolder_recursions` to :php:`depth`
+
+A TCA migration wizard is available, showing where adjustments have to take place.
+
+Before:
+
+.. code-block:: php
+
+   'aField' => [
+      'config' => [
+         'type' => 'select',
+         'renderType' => 'selectSingle',
+         'fileFolder' => 'EXT:my_ext/Resources/Public/Icons',
+         'fileFolder_extList' => 'svg',
+         'fileFolder_recursions' => 1,
+      ]
+   ]
+
+After:
+
+.. code-block:: php
+
+   'aField' => [
+      'config' => [
+         'type' => 'select',
+         'renderType' => 'selectSingle',
+         'fileFolderConfig' => [
+            'folder' => 'EXT:styleguide/Resources/Public/Icons',
+            'allowedExtensions' => 'svg',
+            'depth' => 1,
+         ]
+      ]
+   ]
+
+
+Thus, the following TSconfig options can be used to overriding their
+TCA counterpart:
+
+.. code-block:: typoscript
+
+   config.fileFolderConfig.folder
+   config.fileFolderConfig.allowedExtensions
+   config.fileFolderConfig.depth
+
+As already known from TCEFORM, those options can be used on various levels
+
+On table level:
+
+.. code-block:: typoscript
+
+   TCEFORM.myTable.myField.config.fileFolderConfig.folder
+
+On table and record type level:
+
+.. code-block:: typoscript
+
+   TCEFORM.myTable.myFiled.types.myType.config.fileFolderConfig.folder
+
+On flex form field level:
+
+.. code-block:: typoscript
+
+   TCEFORM.myTable.pi_flexform.my_ext_pi1.sDEF.myField.config.fileFolderConfig.folder
+
+.. note::
+
+   Except :typoscript:`config.fileFolderConfig.folder`, the new options can not
+   only be used to override an existing property, but also to define
+   one, which has not yet been configured in TCA.
+
+Impact
+======
+
+It's now possible to override the TCA :php:`fileFolder` configuration options
+with page TSconfig, allowing administrators to manipulate the available
+items on a page basis.
+
+The :php:`fileFolder` TCA configuration is furthermore streamlined and now
+encapsulated in a dedicated sub array :php:`fileFolderConfig`.
+
+.. index:: Backend, TCA, TSConfig, ext:backend

Documentation/Changelog/11.4/Feature-94489-FilterForRedirectsNeverHit.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94489:
+
+================================================
+Feature: #94489 - Filter for redirects never hit
+================================================
+
+See :issue:`94489`
+
+Description
+===========
+
+Since :issue:`89115` TYPO3 is able to automatically create redirects
+whenever an editor changes a slug of a page. This is a really handy feature.
+However on large sites this could quickly lead to a lot of redirects, which
+may will never be used by any website visitor.
+
+To support editors by managing their redirects, a new filter option
+:guilabel:`Never hit` has been added to the Redirects modules' filter.
+Activating this option therefore filters the list for redirects, which
+where never hit before.
+
+.. note::
+
+   The filter option will only be available, if the "Redirects hit count"
+   feature is enabled, see:
+   :doc:`#83677 <../9.1/Feature-83677-GloballyDisableenableRedirectHitStatistics>`.
+
+Impact
+======
+
+A new filter option :guilabel:`Never hit` is available in the Redirects
+module, allowing editors to filter for redirects, which were never hit before.
+
+.. index:: Backend, ext:redirects

Documentation/Changelog/11.4/Feature-94577-ClearIndexed_searchDocumentsWhenContentIsChanged.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94577:
+
+========================================================================
+Feature: #94577 - Clear indexed_search documents when content is changed
+========================================================================
+
+See :issue:`94577`
+
+Description
+===========
+
+A new Extension Configuration setting `deleteFromIndexAfterEditing` has been added
+to the extension `indexed_search`.
+
+If enabled and a page or its content is edited, :php:`DataHandler` triggers a hook
+to remove the page and its content from the search index.
+
+
+Impact
+======
+
+A separate index and clearing it is always a tradeoff between having wrong content
+and no content in the search result. The index is filled by website visitors or bots
+calling the page in the frontend or by using the 3rd party extension crawler_.
+
+If the setting is enabled and the page is not yet re-indexed, **no** content will
+be shown in the search result, no matter if the editor just fixed one tiny typo in a content element.
+
+If the feature flag is disabled, the editor needs to manually clear the index.
+
+.. _crawler: https://extensions.typo3.org/extension/crawler
+
+.. index:: Backend, ext:indexed_search

Documentation/Changelog/11.4/Feature-94590-AllowIconIdentifiersInReportModuleRegistration.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94590:
+
+======================================================================
+Feature: #94590 - Allow icon identifiers in report module registration
+======================================================================
+
+See :issue:`94590`
+
+Description
+===========
+
+To further streamline the usage of the Icon Registry, the reports registration
+array now allows to define icon identifiers for the :php:`icon` key. Absolute
+paths and paths with `EXT:` prefix are still possible.
+
+Example:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_reports']['status'] = [
+       'title' => 'LLL:EXT:reports/Resources/Private/Language/locallang_reports.xlf:status_report_title',
+       'icon' => 'module-reports', // Icon identifiers are now possible here.
+       'description' => 'LLL:EXT:reports/Resources/Private/Language/locallang_reports.xlf:status_report_description',
+       'report' => \TYPO3\CMS\Reports\Report\Status\Status::class
+   ];
+
+Impact
+======
+
+Developers are now able to provide icon identifiers in the reports module
+registration array.
+
+.. index:: Backend, PHP-API, ext:reports

Documentation/Changelog/11.4/Feature-94622-NewTCATypeCategory.rst

@@ -0,0 +1,128 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94622:
+
+=========================================
+Feature: #94622 - New TCA type "category"
+=========================================
+
+See :issue:`94622`
+
+Description
+===========
+
+A new TCA field type called :php:`category` has been added to TYPO3 Core.
+Its main purpose is to simplify the TCA configuration when adding a category
+tree to a record. It therefore supersedes the :php:`\TYPO3\CMS\Core\Category\CategoryRegistry` as well
+as the :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility->makeCategorizable()`, which required
+creating a "TCA overrides" file.
+
+Both, the :php:`CategoryRegistry` as well as
+:php:`ExtensionManagementUtility->makeCategorizable()` are going to be
+deprecated in the future.
+
+While using the new type, TYPO3 takes care of generating the necessary TCA
+configuration and also adds the database column automatically. Developers
+only have to configure the TCA column and add it to the desired record types.
+
+.. code-block:: php
+
+   $GLOBALS['TCA'][$myTable]['columns']['categories'] = [
+      'config' => [
+         'type' => 'category'
+      ]
+   ];
+
+   \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTCAtypes($myTable, 'categories');
+
+The above example does not contain the new option :php:`relationship`
+since the default is :php:`manyToMany`. All possible values are:
+
+* :php:`oneToOne`: Stores the uid of the selected category. When using this
+  relationship, :php:`maxitems=1` will automatically be added to the column configuration
+* :php:`oneToMany`: Stores the uids of selected categories in a comma-separated list
+* :php:`manyToMany` (default): Uses the intermediate table :sql:`sys_category_record_mm`
+  and only stores the categories count on the local side. This is the use case,
+  which was previously accomplished using :php:`ExtensionManagementUtility->makeCategorizable()`.
+
+This means, the new type can not only be used with :php:`relationship=manyToMany` as
+a replacement for :php:`makeCategorizable` but can be used for other use
+cases too. In case a category tree is required, only allowing one category
+to be selected, the necessary configuration reduces to
+
+.. code-block:: php
+
+   $GLOBALS['TCA'][$myTable]['columns']['mainCategory'] = [
+      'config' => [
+         'type' => 'category',
+         'relationship' => 'oneToOne'
+      ]
+   ];
+
+All other relevant options, e.g. :php:`maxitems=1`, are being set automatically.
+
+Besides :php:`type` and :php:`relationship`, following type specific options
+are available:
+
+* :php:`default`
+* :php:`exclusiveKeys`: As known from :php:`renderType=selectTree`
+* :php:`treeConfig`: As known from :php:`renderType=selectTree`
+
+It's possible to use TSconfig options, such as
+:typoscript:`removeItems`. However, adding static items with TSconfig is not
+implemented for this type. For such special cases, please continue using TCA
+type :php:`select`.
+
+The Override matrix - specifying the options which can be overridden in
+TSconfig - is extended for the new type. Following options can be overridden:
+
+* :php:`size`
+* :php:`maxitems`
+* :php:`minitems`
+* :php:`readOnly`
+* :php:`treeConfig`
+
+.. note::
+
+   It's still possible to configure a category tree with :php:`type=select`
+   and :php:`renderType=selectTree`. This configuration will still work, but
+   could in most cases be simplified, using the new :php:`category` TCA type.
+
+Flexform usage
+--------------
+
+It's also possible to use the new type in flexform data structures. However,
+due to some limitations in flexform, the "manyToMany" relationship is not
+supported. Therefore, the default relationship - used if none is defined -
+is "oneToMany". This is anyways the most common use case for flexforms,
+as it's not important to look from the other side "which flexform elements
+reference this category". An example of the "oneToMany" use case is EXT:news,
+which allows to only display news of specific categories in the list view.
+
+.. code-block:: xml
+
+    <T3DataStructure>
+        <ROOT>
+            <TCEforms>
+                <sheetTitle>aTitle</sheetTitle>
+            </TCEforms>
+            <type>array</type>
+            <el>
+                <categories>
+                    <TCEforms>
+                        <config>
+                            <type>category</type>
+                        </config>
+                    </TCEforms>
+                </categories>
+            </el>
+        </ROOT>
+    </T3DataStructure>
+
+Impact
+======
+
+It's now possible to simplify the TCA configuration for category fields,
+using the new TCA type :php:`category`.
+
+.. index:: Backend, TCA, ext:backend

Documentation/Changelog/11.4/Feature-94623-Tt_contentImagesAssetsMediaShowPossibleLocalizationRecords.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94623:
+
+==================================================================================
+Feature: #94623 - tt_content images, assets, media showPossibleLocalizationRecords
+==================================================================================
+
+See :issue:`94623`
+
+Description
+===========
+
+When a default language content element is localized to another language
+in "connected" / "translation" mode (as opposed to "copy"), relations like
+images and assets connected to the default language record are localized as well.
+
+When the default language element is later changed and additional images, assets
+or media relations are added, the localized content element now shows those new
+default language relations as shadowed box and allows to localize them with one click.
+
+
+Impact
+======
+
+This is a usability improvement for editors, who now see which tt_content
+relations of casual elements like "Image" and "Media" are missing when
+editing localizations. They can localize those with one click.
+
+.. index:: Backend, TCA, ext:backend

Documentation/Changelog/11.4/Feature-94653-AutocompleteAttributeForPasswordViewHelper.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94653:
+
+===============================================================
+Feature: #94653 - Autocomplete attribute for PasswordViewHelper
+===============================================================
+
+See :issue:`94653`
+
+Description
+===========
+
+Since password managers are frequently used by end users nowadays,
+a password field can define the :html:`autocomplete` attribute,
+which informs the users' password manager how to fill the corresponding
+field. For example, creating a new password or filling in the current password.
+
+See `MDN Allowing autocomplete`_ for a full list of possible attribute values.
+
+To ease the use for integrators and developers, the attribute can now
+directly be added as tag attribute to the :php:`PasswordViewHelper`.
+
+Example:
+
+.. code-block:: html
+
+   <f:form.password name="newPassword" value="" autocomplete="new-password" />
+
+   <!-- Output -->
+
+   <input type="password" name="myNewPassword" value="" autocomplete="new-password" />
+
+
+Impact
+======
+
+It's now possible to specify the :html:`autocomplete` attribute for the password
+field through the :php:`PasswordViewHelper`.
+
+.. _MDN Allowing autocomplete: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password#allowing_autocomplete
+
+.. index:: Fluid, ext:fluid

Documentation/Changelog/11.4/Feature-94662-AddPlaceholderForSiteConfigurationInForeignTableWhere.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94662:
+
+===============================================================================
+Feature: #94662 - Add placeholder for site configuration in foreign_table_where
+===============================================================================
+
+See :issue:`94662`
+
+Description
+===========
+
+The :php:`foreign_table_where` setting in TCA allows some old marker-based
+placeholder to customize the query. The best place to define site-dependent
+settings is the site configuration, which now can be used within
+:php:`foreign_table_where`.
+
+To access a configuration value the following syntax is available:
+
+* `###SITE:<KEY>###` - <KEY> is your setting name from site config e.g. `###SITE:rootPageId###`
+* `###SITE:<KEY>.<SUBKEY>###` - an array path notation is possible. e.g. `###SITE:mySetting.categoryPid###`
+
+Example:
+--------
+
+.. code-block:: php
+
+    ...
+    'fieldConfiguration' => [
+        'foreign_table_where' => ' AND ({#sys_category}.{#uid} = ###SITE:rootPageId### OR {#sys_category}.{#pid} = ###SITE:mySetting.categoryPid###) ORDER BY {#sys_category}.{#title} ASC',
+    ],
+    ...
+
+.. index:: Backend, FlexForm, TCA, NotScanned, ext:backend

Documentation/Changelog/11.4/Feature-94680-ShowColumnsSelectorFilter.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94680:
+
+==============================================
+Feature: #94680 - Show columns selector filter
+==============================================
+
+See :issue:`94680`
+
+Description
+===========
+
+In :issue:`94474`, the column selector in the record list, formerly known
+as "field selector", got improved by adding a couple of actions, such
+as "check all" and by moving the selection into a modal instead of a dropdown.
+However, since there are tables, e.g. :sql:`pages` or :sql:`tt_content`, which
+contain a lot of columns, it could sometimes still be unnecessarily hard
+to find a specific column in such a list.
+
+Therefore, the columns selectors' action bar has been extended for
+a new filter, which can be used to quickly find the desired column
+in such large lists.
+
+When the filter is active - at least one character was entered - all other
+actions are bound to the current filter result. This means, when using the
+"check all" action, while the list is filtered, the action is only applied
+to the currently visible items. This comes in handy in case a group of
+columns, sharing the same name (e.g. "backend layouts" in :sql:`pages`) should
+be selected.
+
+
+Impact
+======
+
+It's now possible to filter the list of columns in the "Show column selector"
+of the recordlist module.
+
+.. index:: Backend, ext:recordlist

Documentation/Changelog/11.4/Feature-94692-RegisteringIconsViaServiceContainer.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94692-1657826754:
+
+=========================================================
+Feature: #94692 - Registering Icons via Service Container
+=========================================================
+
+See :issue:`94692`
+
+Description
+===========
+
+Extensions can now register their custom icons via
+a configuration file placed in :file:`Configuration/Icons.php` of their
+extension directory, e.g. :file:`typo3conf/ext/my_extension/Configuration/Icons.php`.
+
+Each file needs to return a flat PHP configuration array, with
+custom options used for the IconRegistry to register a new icon.
+
+Example:
+
+.. code-block:: php
+
+    <?php
+    return [
+        'myicon' => [
+            'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
+            'source' => 'EXT:my_extension/Resources/Public/Icons/myicon.svg'
+        ],
+        'anothericon' => [
+            'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
+            'source' => 'EXT:my_extension/Resources/Public/Icons/anothericon.svg'
+        ],
+        ...
+    ];
+
+
+Impact
+======
+
+Using the new approach improves the loading speed of every request
+as the registration can be handled at once and cached
+during warmup of the core caches.
+
+In addition, extension authors' :file:`ext_localconf.php` files are
+drastically reduced, as extension authors have a better overview
+and a better separation of concerns when registering custom
+functionality.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-94741-RegisterSoftReferenceParsersViaDI.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94741:
+
+=======================================================
+Feature: #94741 - Register SoftReference parsers via DI
+=======================================================
+
+See :issue:`94741`
+
+Description
+===========
+
+Parsers for :ref:`soft references <t3coreapi:soft-references>` can now be
+registered via dependency injection in the corresponding
+:file:`Configuration/Services.(yaml|php)` file of your extension. This is done
+by tagging your class with the new tag name :yaml:`softreference.parser` and
+providing the parser key for the attribute :yaml:`parserKey`.
+
+Example:
+
+.. code-block:: yaml
+
+    VENDOR\Extension\SoftReference\YourSoftReferenceParser:
+      tags:
+        - name: softreference.parser
+          parserKey: your_key
+
+In addition, parsers now have to implement
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`.
+This interface describes the :php:`parse()` method, which is very similar to the
+old method :php:`findRef()`. The difference is that :php:`$parserKey` (former
+known as :php:`$spKey`) and :php:`$parameters` (former known as
+:php:`$spParams`) can now be optionally set with the :php:`setParserKey()` method.
+The key can be retrieved with the :php:`getParserKey()` method.
+
+The return type has also been changed to
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserResult`.
+This model holds the former result array key entries :php:`content` and
+:php:`elements` as properties and has appropriate getter methods for them. It
+should be created by its own factory method
+:php:`SoftReferenceParserResult::create()`, which expects both above-mentioned
+arguments to be provided. If the result is empty,
+:php:`SoftReferenceParserResult::createWithoutMatches()` should be used instead.
+
+Impact
+======
+
+Developers can register their user-defined soft reference parsers in their
+:file:`Configuration/Services.(yaml|php)` file. In addition, parser have to
+implement the new interface
+:php:`TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface`.
+
+
+Related
+=======
+
+*  :doc:`RegisterSoftReferenceParsersViaDI (Deprecation) <Deprecation-94741-RegisterSoftReferenceParsersViaDI>`
+*  :doc:`SoftReferenceIndex (Deprecation) <Deprecation-94687-SoftReferenceIndex>`
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-94765-IntroduceShowNewRecordLinkOption.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94765:
+
+====================================================
+Feature: #94765 - Introduce showNewRecordLink option
+====================================================
+
+See :issue:`94765`
+
+Description
+===========
+
+Previously, it was not possible to disable the "new record" link in
+TCA :php:`inline` elements, without simultaneously also disabling either the
+"+" button in each inline records' header (using
+:php:`['appearance']['enabledControls']['new']`) or all other
+"level links" (using :php:`['appearance']['levelLinksPosition'] = 'none'`).
+
+To allow integrators to disable this link without any further side
+effects, the option :php:`showNewRecordLink` has been introduced
+to TCA type :php:`inline`.
+
+With this introduction, the already mentioned
+:php:`['appearance']['enabledControls']['new']` option does from now on
+only manage the display of the "+" button of each inline record and does
+not longer affect the "New record" link.
+
+Furthermore the :php:`['appearance']['levelLinksPosition']` option does
+no longer support `none` as value. This option should only be used to
+position the level links, not to hide them. This can be
+achieved by setting the corresponding link specific options
+:php:`showAllLocalizationLink`, :php:`showSynchronizationLink` and
+:php:`showNewRecordLink` to :php:`false`. A TCA migration is in place,
+replacing all TCA configurations, using the
+:php:`['appearance']['levelLinksPosition']` option with `none` as value
+and showing where code adaptations need to take place.
+
+If not set, the new :php:`showNewRecordLink` option defaults to :php:`true`.
+
+An example to disable the "New record" button:
+
+.. code-block:: php
+
+    'inlineField' => [
+        'label' => 'Inline without New record link',
+        'config' => [
+            'type' => 'inline',
+            'appearance' => [
+                'showNewRecordLink' => false,
+            ],
+        ],
+    ],
+
+Impact
+======
+
+It's now possible to disable the "New record" link of TCA :php:`inline` elements
+without any side effects.
+
+.. index:: TCA, ext:backend

Documentation/Changelog/11.4/Feature-94819-ImprovedWorkspacesModule.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94819:
+
+============================================
+Feature: #94819 - Improved Workspaces module
+============================================
+
+See :issue:`94819`
+
+Description
+===========
+
+The workspaces module has been improved in usability:
+
+For the initial loading of the module, the AJAX request has
+to process less data as all information is already loaded with
+the module.
+
+A loading indicator is now visible during AJAX requests to
+show editors that there is work in progress.
+
+A dropdown is now used to choose between multiple workspaces,
+which is especially useful when having multiple workspaces.
+
+Administrators can edit workspace settings directly
+from the module's docheader area.
+
+
+Impact
+======
+
+The overall user experience has been improved and administrators
+do not need to use the list module to manage workspaces anymore.
+
+.. index:: Backend, ext:workspaces

Documentation/Changelog/11.4/Feature-94889-AddResultOptionToTypolinkReturnLastParameter.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94889:
+
+======================================================================
+Feature: #94889 - Add "result" option to typolink returnLast parameter
+======================================================================
+
+See :issue:`94889`
+
+Description
+===========
+
+This change introduces a new :php:`\TYPO3\CMS\Frontend\Typolink\LinkResult` object along with an
+interface, containing the base result of a generated link by TypoLink.
+
+This object should contain all information needed to put together
+an :html:`<a>` tag or return a URL in the future.
+
+For the time being this new class is used to build links from
+:php:`\TYPO3\CMS\Frontend\Typolink\AbstractTypolinkBuilder` implementations, and in addition
+should be able to be returned fully by :typoscript:`typolink` in the future.
+
+In addition, this object helps to build links needed
+for e.g. JSON responses to contain all information
+of the link to be serialized.
+
+
+Impact
+======
+
+This feature allows user to handle link's data in more consistent way, also
+simplifies typolink handling in different outputs than HTML, like i.e. JSON
+
+.. index:: PHP-API, TypoScript, ext:frontend

Documentation/Changelog/11.4/Feature-94906-MultiRecordSelectionInFilelist.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94906:
+
+====================================================
+Feature: #94906 - Multi record selection in filelist
+====================================================
+
+See :issue:`94906`
+
+Description
+===========
+
+With :issue:`94452` the file list in the file selector has been improved
+by introducing an optimized way of selecting the files to attach to a record.
+
+Those optimizations have now also been added to the filelist module. The
+checkboxes, previously only used for adding files / folders to the
+clipboard, are now always shown in front of each file / folder and are
+now independent of the current clipboard mode. Furthermore, the
+convenience actions such as "check all", "uncheck all" and "toggle
+selection" are now available in the filelist, too.
+
+By decoupling the selection from the clipboard logic, it is
+now possible to directly work with the current selection without the
+need to transfer it to the clipboard first. This means, editing or
+deleting multiple files is now directly possible without any clipboard
+interaction. The available actions appear once an element has been
+selected.
+
+As mentioned above, the "Edit marked" action has been added to the
+filelist, which might already be known from the recordlist module.
+This action allows to edit the :sql:`sys_file_metadata` records of
+all selected files at once.
+
+Impact
+======
+
+Selection of files and folders is now quicker to grasp for editors working
+in the filelist module. It is also possible to directly
+execute actions, e.g. editing metadata of selected files, without
+transferring them to the clipboard first.
+
+.. index:: Backend, ext:filelist

Documentation/Changelog/11.4/Feature-94944-KeyboardShortcutsForMultiRecordSelection.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94944:
+
+===============================================================
+Feature: #94944 - Keyboard shortcuts for multi record selection
+===============================================================
+
+See :issue:`94944`
+
+Description
+===========
+
+To further increase the usability in the Backend, the multi record selection,
+introduced with :issue:`94906`, has been extended for keyboard shortcuts.
+
+The shortcuts can be used in every module, which implements the multi record
+selection. You can recognize this by the dropdown menu in the first header
+column of the record listing.
+
+In such module, when clicking on a checkbox while holding the
+
+* `shift` key: All records in the range of the last clicked checkbox and the current one are checked / unchecked
+
+* `option` (macOS) or `ctrl` (Windows / Linux) key: The current selection is toggled (inverted)
+
+
+Impact
+======
+
+The multi record selection now also features keyboard shortcuts to further
+increase the usability of this component.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.4/Feature-94966-ShowDebuggerInApplicationInformation.rst

@@ -0,0 +1,25 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94966:
+
+==========================================================
+Feature: #94966 - Show debugger in Application Information
+==========================================================
+
+See :issue:`94966`
+
+Description
+===========
+
+The "Application Information" menu is now able to show an enabled debugger and
+its version, if available. Supported debuggers are xdebug and Zend Debugger at
+the moment.
+
+
+Impact
+======
+
+If a debugger is activated and can be determined via :php:`extension_loaded()`,
+the "Application Information" will show such an activated debugger.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.4/Feature-94996-ConsiderAllComposerInstalledExtensionsAsActive.rst

@@ -0,0 +1,101 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94996:
+
+======================================================================
+Feature: #94996 - Consider all Composer installed extensions as active
+======================================================================
+
+See :issue:`94996`
+
+Description
+===========
+
+All TYPO3 extensions installed with Composer are now considered to be active and
+therefore can and will interact with TYPO3 API.
+
+At Composer install time a persistent artifact is created, holding the information
+which extensions are installed and the path where these reside. This makes
+the :file:`typo3conf/PackageStates.php` file obsolete and it is neither created nor
+evaluated anymore.
+
+For Composer based installs the artifact is located at
+:file:`vendor/typo3/PackageArtifact.php`. This file must be deployed
+together with all other Composer dependencies. In a TYPO3v11 sprint this file was located at
+:file:`var/build/PackageArtifact.php` which did need a special handling and caused
+some issues for example on platform.sh, which were solved by storing it in the vendor folder.
+
+Any extension present in the :file:`typo3conf/ext` folder, but not installed by Composer,
+will still be considered and marked as part of TYPO3 packages when executing
+:bash:`composer install`. The only requirement here is, that such extensions need a
+:file:`composer.json` file nonetheless.
+Note this behaviour is deprecated and will be removed with TYPO3 v12.
+
+Because all extensions present in the system are considered to be active,
+the Extension Manager UI is adapted to not allow changing the active state of
+extensions anymore for composer based instances. Respectively the commands
+:bash:`extension:activate` and :bash:`extension:deactivate` are disabled in Composer managed
+systems as well.
+
+A new command :bash:`extension:setup` is introduced, which supersedes both the extension
+manager UI as well as the activate/deactivate commands. It performs all steps that
+were performed during activation and deactivation (the active-state is of course not changed).
+
+With the command :bash:`extension:setup` *all* extensions are set up in terms of
+database schema changes, static data import, distribution files imports, etc.
+As example, requiring an additional extension and then using this command will
+create database tables or additional database fields the extension provides.
+
+Any installed Composer package that defines an `extra.typo3/cms` section in
+their :file:`composer.json` file will be considered a TYPO3 extension and will
+have full access to the TYPO3 API.
+
+However, because these Composer packages reside in the :file:`vendor` folder, they can
+not deliver public resources. This remains exclusive for TYPO3 extensions
+installed into :file:`typo3conf/ext` for now - those composer packages that not only
+have a `extra.typo3/cms` section, but are also of type `typo3-cms-extension`.
+
+Impact
+======
+
+In Composer mode this has the following impact:
+
+The :file:`PackageStates.php` file is completely ignored. When migrating projects that
+still have this file e.g. under version control, it is recommended to remove this file.
+
+Projects with extensions that reside directly in :file:`typo3conf/ext`, and which therefore
+are not installed with Composer, should consider migrating them to a local path repository.
+In any case, such extensions now require to have a :file:`composer.json` file. This file
+can be created by using the according UI in the Extension Manager.
+
+When working on a Composer based project and adding new extensions via the Composer
+cli tool during development, all added extensions are considered active automatically,
+but are not yet set up in terms of database schema changes for example. The TYPO3 cli
+command :bash:`extension:setup` needs to be executed additionally. :bash:`extension:setup` can and
+should also be used, when deploying a TYPO3 project to make sure database schema is up to date.
+
+The Composer root project package will be recognized as a TYPO3 extension as well, if it provides a
+`extra.typo3/cms` section in its `composer.json`, as mentioned above. Because this package,
+like packages in the `vendor` folder isn't accessible by the web server,
+the root package can not deliver public resources as well.
+
+However, when extensions are used as root package for testing (e.g., for running unit,
+functional or integration tests in a CI pipeline) **and** these extensions have files in the `Resources/Public` directory,
+a symlink in the `typo3conf/ext` directory is automatically created.
+Additionally the package path is adapted to be inside `typo3conf/ext`.
+This allows TYPO3 to properly calculate URLs for public resources of this extension.
+
+If the root package isn't of type `typo3-cms-extension` or does not have a `Resources/Public` directory
+the absolute path to the extension remains the original path to the composer root directory
+and no symlink is created.
+
+This special behaviour for root packages of type `typo3-cms-extension`
+is introduced as a temporary fix to ease extension testing. It is explicitly **NOT**
+recommended to use such a setup in production.
+
+The :file:`ext_emconf.php` file of extensions is now obsolete and therefore completely ignored
+in Composer based instances. Make sure the information in the :file:`composer.json` file is in
+sync with the one in your :file:`ext_emconf.php` file in case you want to provide one for
+compatibility with non Composer mode.
+
+.. index:: CLI, ext:core

Documentation/Changelog/11.4/Feature-95034-SelectRowByMouseClick.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95034:
+
+============================================================
+Feature: #95034 - List views: Select a row by clicking on it
+============================================================
+
+See :issue:`95034`
+
+Description
+===========
+
+The multi record selection, introduced in :issue:`94906`, has been
+improved for a convenience method, making the selection of rows
+more pleasant. It's now possible to select a row by
+simply clicking anywhere on it. Certainly, this does not influence
+any other action on this row, e.g. a link or a button. Only if the
+click event is on the row itself, e.g. any empty space, the automatic
+selection is performed.
+
+Besides selecting a single row, also the keyboard actions, introduced
+in :issue:`94944`, can be used while clicking on the row, allowing to
+further optimize workflows.
+
+Impact
+======
+
+It's now possible to select a row by clicking anywhere on it.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.4/Feature-95035-CollapseAllForLargeTrees.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95035:
+
+================================================
+Feature: #95035 - "Collapse all" for large trees
+================================================
+
+See :issue:`95035`
+
+Description
+===========
+
+A new button "Collapse all" is added for all SVG-based trees,
+which is helpful for installations with a lot of pages or folders,
+and editors can quickly get an overview again of the entry points.
+
+The feature collapses all pages / folders inside the tree
+except for the items on the root level.
+
+This feature is now also available in all Record Selector and
+Link Picker with SVG Trees as they all are based on the same
+code base.
+
+
+Impact
+======
+
+A new icon is shown in the Toolbar of all trees to select additional actions.
+
+The "Refresh tree" button is now moved to the additional options
+dropdown as well to clean up the Interface and enhance User Experience.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/11.4/Feature-95037-NewStartingPointsSettingForFormEngineTreeConfig.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95037:
+
+======================================================================
+Feature: #95037 - New startingPoints setting for FormEngine treeConfig
+======================================================================
+
+See :issue:`95037`
+
+Description
+===========
+
+The TCA option :php:`treeConfig` used in :php:`renderType=selectTree` and :php:`type=category` has a new
+setting :php:`startingPoints` that allows to set multiple records as roots for tree
+records.
+
+
+Impact
+======
+
+The setting takes a CSV value, e.g. `2,3,4711`, which takes records of the pids
+`2`, `3` and `4711` into account and creates a tree of these records.
+
+Additionally, each value used in :php:`startingPoints` may be fed from a site
+configuration by using the :php:`###SITE:###` syntax.
+
+Example:
+
+.. code-block:: yaml
+
+   # Site config
+   base: /
+   rootPageId: 1
+   categories:
+      root: 123
+
+
+.. code-block:: php
+
+   // Example TCA config
+   'config' => [
+       'treeConfig' => [
+           'startingPoints' => '1,2,###SITE:categories.root###',
+       ],
+   ],
+
+This will evaluate to :php:`'startingPoints' => '1,2,123'`.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.4/Feature-95044-SupportAutowiredLoggerInterfaceInjection.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95044:
+
+=============================================================
+Feature: #95044 - Support autowired LoggerInterface injection
+=============================================================
+
+See :issue:`95044`
+
+Description
+===========
+
+Logger instances may be required to be available during object
+construction, LoggerAwareInterface isn't an option in that case.
+Therefore :php:`\Psr\Log\LoggerInterface` as constructor argument
+is now autowired (if the service is configured to use autowiring)
+and instantiated with an object-specific logger.
+
+
+Impact
+======
+
+Services are no longer required to use
+:php:`\Psr\Log\LoggerAwareInterface` and :php:`\Psr\Log\LoggerAwareTrait`,
+but can add a constructor argument :php:`\Psr\Log\LoggerInterface` instead.
+
+Example:
+
+.. code-block:: php
+
+    use Psr\Log\LoggerInterface;
+
+    class MyClass {
+        private LoggerInterface $logger;
+
+        public function __construct(LoggerInterface $logger) {
+            $this->logger = $logger;
+        }
+    }
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-95061-AutoCreationOfMMTablesFromTCA.rst

@@ -0,0 +1,84 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95061:
+
+=====================================================
+Feature: #95061 - Auto creation of MM tables from TCA
+=====================================================
+
+See :issue:`95061`
+
+Description
+===========
+
+TCA table column fields that define :php:`['config']['MM']` can omit specification of the
+intermediate mm table layout in :file:`ext_tables.sql`. The TYPO3 database analyzer
+takes care of proper schema definition.
+
+This feature has been implemented to simplify developers life and to enable the TYPO3
+core to handle those schema details since many extensions tend to specify incomplete
+or broken mm table schema definitions when dealing with this complex area.
+
+Extensions are strongly encouraged to drop :file:`ext_tables.sql` :sql:`CREATE TABLE`
+definitions for those intermediate tables referenced by :php:`TCA` table columns. Dropping
+these definitions allows the core to adapt and migrate definitions if needed.
+
+Impact
+======
+
+Extension developers don't need to deal with :file:`ext_tables.sql` definitions of
+"mm" tables anymore. The TYPO3 schema analyzer creates the intermediate schema depending
+on :php:`TCA` field definition. The schema analyzer tries to apply default specifications
+if possible. Single :file:`ext_tables.sql` definitions take precedence, though.
+
+In practice, suppose the "local" side of a mm table is defined as such in TCA:
+
+.. code-block:: php
+
+    ...
+    'columns' => [
+        ...
+        'myField' => [
+            'label' => 'myField',
+            'config' => [
+                'type' => 'group',
+                'foreign_table' => 'tx_myextension_myfield_child',
+                'MM' => 'tx_myextension_myfield_mm',
+            ]
+        ],
+        ...
+    ],
+    ...
+
+Until now, a schema definition similar to this had to be in place in :file:`ext_tables.sql`:
+
+.. code-block:: sql
+
+    CREATE TABLE tx_myextension_myfield_mm (
+        uid_local int(11) DEFAULT '0' NOT NULL,
+        uid_foreign int(11) DEFAULT '0' NOT NULL,
+        sorting int(11) DEFAULT '0' NOT NULL,
+
+        KEY uid_local (uid_local),
+        KEY uid_foreign (uid_foreign)
+    );
+
+This section can and should be dropped. Indicators a schema definition is affected by this:
+
+* A table column TCA config defines :php:`MM` with :php:`type='select'`, :php:`type='group'`
+  or :php:`type='inline'`.
+* The "MM" intermediate table has *no* TCA table definition (!).
+* :file:`ext_tables.sql` specifies a table with fields :sql:`uid_local` and :sql:`uid_foreign`.
+
+The schema analyzer takes care of further possible fields apart from :sql:`uid_local` and
+:sql:`uid_foreign`, like :sql:`sorting`, :sql:`sorting_foreign`, :sql:`tablenames`,
+:sql:`fieldname` and :sql:`uid` if necessary, depending on "local" side of the TCA definition.
+
+In general, in case an extension got that definition right up until now, the schema analyzer
+should not drop or add any additional fields automatically when removing these sections from
+:file:`ext_tables.sql`. Developers are strongly encouraged to drop affected :sql:`CREATE TABLE`
+definitions from :file:`ext_tables.sql` and to verify the install tool schema migrator acts as
+expected. The core takes care of these specifications from now on and may add adaptions or migrations
+to streamline further details in the future.
+
+.. index:: Database, ext:core

Documentation/Changelog/11.4/Feature-95065-NewPSR-14BootCompletedEvent.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95065:
+
+===============================================
+Feature: #95065 - New PSR-14 BootCompletedEvent
+===============================================
+
+See :issue:`95065`
+
+Description
+===========
+
+A new PSR-14 event :php:`\TYPO3\CMS\Core\Core\Event\BootCompletedEvent` has been added to TYPO3
+Core. This event is fired on every request when TYPO3 has been
+fully booted, right after all configuration files have been added.
+
+This new Event complements the :php:`\TYPO3\CMS\Core\Configuration\Event\AfterTcaCompilationEvent` which
+is executed after TCA configuration has been assembled.
+
+Registration of the Event in your extensions' :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+  MyVendor\MyPackage\Bootstrap\MyEventListener:
+    tags:
+      - name: event.listener
+        identifier: 'my-package/my-listener'
+
+.. code-block:: php
+
+    class MyEventListener {
+        public function __invoke(BootCompletedEvent $e): void
+        {
+            // do your magic
+        }
+    }
+
+
+Impact
+======
+
+Use cases for this event is to alter or to boot up extensions'
+code which needs to be executed at any time, and needs
+TYPO3's full configuration including all loaded extensions.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-95068-MultiRecordSelectionInRecordlist.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95068:
+
+======================================================
+Feature: #95068 - Multi record selection in recordlist
+======================================================
+
+See :issue:`95068`
+
+Description
+===========
+
+With :issue:`94906` the multi record selection component has been
+introduced to TYPO3. Next to proper keyboard support, it enables
+editors to easily select multiple records with a couple of convenience
+methods, such as "select all", "toggle selection" or "select range".
+
+This component has now also been added to the :guilabel:`Web > List`
+module. Therefore the "clipboard" column has been removed. All clipboard
+actions, e.g. "paste content", have been moved to the multi record selection
+action bar in the table header. Because the component is not bound to the
+clipboard functionality, editors are now able to perform actions, such
+as editing or deleting multiple records, without moving them to the
+clipboard first.
+
+As already known from other modules, the available actions (edit, copy,
+delete, etc.) are shown in the table header, as soon as one record is
+selected. An exception is the "Edit this field" button, displayed next
+to each column header, which represents a real database field (only in
+the "single table view"). It can be used to edit a single field for all
+displayed records. This button now also respects the current selection,
+making it possible to edit a single field for only a specific selection
+of records.
+
+Manipulating the displayed actions in the table header is still possible
+using the `\TYPO3\CMS\Recordlist\Event\ModifyRecordListTableActionsEvent`
+PSR-14 event.
+
+In case you are still using the TSconfig option
+:typoscript:`showClipControlPanelsDespiteOfCMlayers`, which is rather
+unlikely as it wasn't properly respected in latest versions at all,
+you should remove it now, since it is no longer evaluated due to
+the removal of the clipboard column.
+
+
+Impact
+======
+
+Editing multiple records in the :guilabel:`Web > List` module has been
+improved and is now no longer bound to the clipboard functionality.
+
+Setting the TSconfig option :typoscript:`showClipControlPanelsDespiteOfCMlayers`
+has no effect anymore.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.4/Feature-95077-NewPSR-14ProcessFileListActionsEvent.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95077-1668719172:
+
+========================================================
+Feature: #95077 - New PSR-14 ProcessFileListActionsEvent
+========================================================
+
+See :issue:`95077`
+
+Description
+===========
+
+A new PSR-14 event :php:`\TYPO3\CMS\Core\Configuration\Event\ProcessFileListActionsEvent` has been added to
+TYPO3 Core. This event is fired after generating the actions for the
+files and folders listing in the :guilabel:`File > Filelist` module.
+
+Registration of the Event in your extensions' :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+  MyVendor\MyPackage\FileList\MyEventListener:
+    tags:
+      - name: event.listener
+        identifier: 'my-package/filelist/my-event-listener'
+
+The corresponding event listener class:
+
+.. code-block:: php
+
+    use TYPO3\CMS\Filelist\Event\ProcessFileListActionsEvent;
+
+    class MyEventListener {
+
+        public function __invoke(ProcessFileListActionsEvent $event): void
+        {
+            // do your magic
+        }
+
+    }
+
+Impact
+======
+
+This event can be used to manipulate the icons, used for the edit control
+section in the files and folders listing within the :guilabel:`File > Filelist`
+module.
+
+.. index:: PHP-API, ext:filelist

Documentation/Changelog/11.4/Feature-95079-SupportPHP8StyleChannelAttributeForLoggerInjection.rst

@@ -0,0 +1,85 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95079:
+
+============================================================================
+Feature: #95079 - Support PHP 8 style Channel attribute for logger injection
+============================================================================
+
+See :issue:`95079`
+
+Description
+===========
+
+Services are now able to control the component name that an
+injected logger is created with.
+This allows to group logs of related classes and is basically
+a channel system as often used in monolog.
+
+The :php:`\TYPO3\CMS\Core\Log\Channel` attribute is supported for constructor
+argument injection as a class and parameter specific attribute and for
+:php:`\Psr\Log\LoggerAwareInterface` dependency injection services as a class attribute.
+
+This feature is only available with PHP 8.
+The channel attribute will be gracefully ignored in PHP 7,
+and the classic component name will be used instead.
+
+
+Registration via class attribute for :php:`\Psr\Log\LoggerInterface` injection:
+
+.. code-block:: php
+
+    use Psr\Log\LoggerInterface;
+    use TYPO3\CMS\Core\Log\Channel;
+    #[Channel('security')]
+    class MyClass
+    {
+        private LoggerInterface $logger;
+        public function __construct(LoggerInterface $logger)
+        {
+            $this->logger = $logger;
+            // do your magic
+        }
+    }
+
+Registration via parameter attribute for :php:`LoggerInterface` injection,
+overwrites possible class attributes:
+
+.. code-block:: php
+
+    use Psr\Log\LoggerInterface;
+    use TYPO3\CMS\Core\Log\Channel;
+    class MyClass
+    {
+        private LoggerInterface $logger;
+        public function __construct(
+            #[Channel('security')]
+            LoggerInterface $logger
+        ) {
+            $this->logger = $logger;
+            // do your magic
+        }
+    }
+
+
+Registration via class attribute for :php:`LoggerAwareInterface` services.
+
+.. code-block:: php
+
+    use Psr\Log\LoggerAwareInterface;
+    use Psr\Log\LoggerAwareTrait;
+    use TYPO3\CMS\Core\Log\Channel;
+    #[Channel('security')]
+    class MyClass implements LoggerAwareInterface
+    {
+        use LoggerAwareTrait;
+    }
+
+
+Impact
+======
+
+It is now possible to group several classes into channels, regardless of the
+PHP namespace.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-95080-NewPSR-14ModifyFileDumpEvent.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95077:
+
+================================================
+Feature: #95077 - New PSR-14 ModifyFileDumpEvent
+================================================
+
+See :issue:`95077`
+
+Description
+===========
+
+A new PSR-14 event :php:`\TYPO3\CMS\Core\Resource\Event\ModifyFileDumpEvent`
+has been added to TYPO3 Core. This event is fired in the
+:php:`\TYPO3\CMS\Core\Controller\FileDumpController` and allows extensions
+to perform additional access / security checks before dumping a file. The
+event does not only contain the file to dump but also the PSR-7 Request.
+
+In case the file dump should be rejected, the event has to set a PSR-7
+:php:`\Psr\Http\Message\ResponseInterface`, usually with a `403` status code.
+This will then immediately stop the propagation.
+
+With the new event, it's not only possible to reject the file dump request,
+but also to replace the file, which should be dumped.
+
+Registration of the Event in your extensions' :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+  MyVendor\MyPackage\Resource\MyEventListener:
+    tags:
+      - name: event.listener
+        identifier: 'my-package/resource/my-event-listener'
+
+The corresponding event listener class:
+
+.. code-block:: php
+
+    use TYPO3\CMS\Core\Resource\Event\ModifyFileDumpEvent;
+
+    class MyEventListener {
+
+        public function __invoke(ModifyFileDumpEvent $event): void
+        {
+            // do magic here
+        }
+
+    }
+
+Impact
+======
+
+This event can be used to modify the file dump request, by either
+adding an alternative response or by replacing the file being dumped.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-95083-NewPSR-14ModifyClearCacheActionsEvent.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95083:
+
+=========================================================
+Feature: #95083 - New PSR-14 ModifyClearCacheActionsEvent
+=========================================================
+
+See :issue:`95083`
+
+Description
+===========
+
+A new PSR-14 event :php:`\TYPO3\CMS\Backend\Backend\Event\ModifyClearCacheActionsEvent`
+has been added to TYPO3 Core. This event is fired in the
+:php:`\TYPO3\CMS\Backend\Backend\ToolbarItems\ClearCacheToolbarItem`
+class and allows extensions to modify the clear cache actions, shown
+in the TYPO3 Backend top toolbar.
+
+The event can be used to change or remove existing clear cache
+actions, as well as to add new actions. Therefore the event also
+contains, next to the usual "getter" and "setter", the convenience
+method :php:`add` for the :php:`cacheActions` and
+:php:`cacheActionIdentifiers` arrays.
+
+Registration of the Event in your extensions' :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+  MyVendor\MyPackage\Toolbar\MyEventListener:
+    tags:
+      - name: event.listener
+        identifier: 'my-package/toolbar/my-event-listener'
+
+The corresponding event listener class:
+
+.. code-block:: php
+
+    use TYPO3\CMS\Backend\Backend\Event\ModifyClearCacheActionsEvent;
+
+    class MyEventListener {
+
+        public function __invoke(ModifyClearCacheActionsEvent $event): void
+        {
+            // do magic here
+        }
+
+    }
+
+Impact
+======
+
+This event can be used to modify the clear cache actions, shown in the
+TYPO3 Backend top toolbar.
+
+.. index:: PHP-API, ext:backend

Documentation/Changelog/11.4/Feature-95089-NewPSR-14AfterFileCommandProcessedEvent.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95089:
+
+===========================================================
+Feature: #95089 - New PSR-14 AfterFileCommandProcessedEvent
+===========================================================
+
+See :issue:`95089`
+
+Description
+===========
+
+A new PSR-14 event :php:`\TYPO3\CMS\Core\Resource\Event\AfterFileCommandProcessedEvent`
+has been added to TYPO3 Core. This event is fired in the
+:php:`\TYPO3\CMS\Core\Utility\File\ExtendedFileUtility`
+class and allows extensions to execute additional tasks, after a file
+operation has been performed.
+
+The event features the following methods:
+
+- :php:`getCommand()`: Returns the command array while the array key is the performed action and the value is the command data ("cmdArr")
+- :php:`getResult()`: Returns the operation result, which could e.g. be an uploaded or changed :php:`File` or a :php:`boolean` for the "delete" action
+- :php:`getConflictMode()`: The conflict mode for the performed operation, e.g. "rename" or "cancel"
+
+Registration of the Event in your extensions' :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+  MyVendor\MyPackage\File\MyEventListener:
+    tags:
+      - name: event.listener
+        identifier: 'my-package/file/my-event-listener'
+
+The corresponding event listener class:
+
+.. code-block:: php
+
+    use TYPO3\CMS\Core\Resource\Event\AfterFileCommandProcessedEvent;
+
+    class MyEventListener {
+
+        public function __invoke(AfterFileCommandProcessedEvent $event): void
+        {
+            // do magic here
+        }
+
+    }
+
+Impact
+======
+
+This event can be used to perform additional tasks for specific file commands.
+For example, trigger a custom indexer after a file has been uploaded.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Feature-95105-NewPSR-14DatabaseRecordListEvents.rst

@@ -0,0 +1,133 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-95105:
+
+======================================================
+Feature: #95105 - New PSR-14 DatabaseRecordList events
+======================================================
+
+See :issue:`95105`
+
+Description
+===========
+
+A couple of new PSR-14 events for the :php:`\TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList` class
+have been added to TYPO3 Core. They are mainly a direct replacement for
+the hook methods, defined in the
+:php:`\TYPO3\CMS\Recordlist\RecordList\RecordListHookInterface`, while
+their functionality is improved and extended.
+
+The new events can be used to modify the behaviour of each table listing,
+which means they can be used to either add, change or even remove columns
+and actions.
+
+Following events have been added:
+
+- :php:`\TYPO3\CMS\Recordlist\Event\ModifyRecordListTableActionsEvent`
+- :php:`\TYPO3\CMS\Recordlist\Event\ModifyRecordListHeaderColumnsEvent`
+- :php:`\TYPO3\CMS\Recordlist\Event\ModifyRecordListRecordActionsEvent`
+
+They all behave in the same way. There is always the subject, e.g. the
+record actions or the header columns, together with information like the
+current table, the current :php:`DatabaseRecordList` instance and the
+current record or the record uids. The subject is therefore equipped
+with the usual CRUD methods like :php:`set`, :php:`get` or :php:`remove`. This makes
+working with those values much more pleasant. See the below code examples
+on how those can be used. Some events also feature additional methods
+to influence e.g. the table header attributes or the label, which is
+being displayed in case no actions are available for the current user.
+
+An example registration of the events in your extensions' :file:`Services.yaml`:
+
+.. code-block:: yaml
+
+  MyVendor\MyPackage\RecordList\MyEventListener:
+    tags:
+      - name: event.listener
+        identifier: 'my-package/recordlist/my-event-listener'
+        method: 'modifyRecordActions'
+      - name: event.listener
+        identifier: 'my-package/recordlist/my-event-listener'
+        method: 'modifyHeaderColumns'
+      - name: event.listener
+        identifier: 'my-package/recordlist/my-event-listener'
+        method: 'modifyTableActions'
+
+The corresponding event listener class:
+
+.. code-block:: php
+
+    use Psr\Log\LoggerInterface;
+    use TYPO3\CMS\Recordlist\Event\ModifyRecordListHeaderColumnsEvent;
+    use TYPO3\CMS\Recordlist\Event\ModifyRecordListRecordActionsEvent;
+    use TYPO3\CMS\Recordlist\Event\ModifyRecordListTableActionsEvent;
+
+    class MyEventListener {
+
+        protected LoggerInterface $logger;
+
+        public function __construct(LoggerInterface $logger)
+        {
+            $this->logger = $logger;
+        }
+
+        public function modifyRecordActions(ModifyRecordListRecordActionsEvent $event): void
+        {
+            $currentTable = $event->getTable();
+
+            // Add a custom action for a custom table in the secondary action bar, before the "move" action
+            if ($currentTable === 'my_custom_table' && !$event->hasAction('myAction')) {
+                $event->setAction(
+                    '<button>My Action</button>',
+                    'myAction',
+                    'secondary',
+                    'move'
+                );
+            }
+
+            // Remove the "viewBig" action in case more than 4 actions exist in the group
+            if (count($event->getActionGroup('secondary')) > 4 && $event->hasAction('viewBig')) {
+                $event->removeAction('viewBig');
+            }
+
+            // Move the "delete" action after the "edit" action
+            $event->setAction('', 'delete', 'primary', '', 'edit');
+        }
+
+        public function modifyHeaderColumns(ModifyRecordListHeaderColumnsEvent $event): void
+        {
+            // Change label of "control" column
+            $event->setColumn('Custom Controls', '_CONTROL_');
+
+            // Add a custom class for the table header row
+            $event->setHeaderAttributes(['class' => 'my-custom-class']);
+        }
+
+        public function modifyTableActions(ModifyRecordListTableActionsEvent $event): void
+        {
+            // Remove "edit" action and log, if this failed
+            $actionRemoved = $event->removeAction('unknown');
+            if (!$actionRemoved) {
+                $this->logger->warning('Action "unknown" could not be removed');
+            }
+
+            // Add a custom clipboard action after "copyMarked"
+            $event->setAction('<button>My action</button>', 'myAction', '', 'copyMarked');
+
+            // Set a custom label for the case, no actions are available for the user
+            $event->setNoActionLabel('No actions available due to missing permissions.');
+        }
+
+    }
+
+
+Please have a look at the concrete implementation for a list of all
+available methods and their functionalities.
+
+Impact
+======
+
+The new PSR-14 events can be used to modify various parts within the
+RecordList module in an object-oriented way.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Important-90264-InitializeDatepickerJSInExternalFile.rst

@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _important-90264:
+
+=============================================================
+Important: #90264 - Initialize datepicker JS in external file
+=============================================================
+
+See :issue:`90264`
+
+Description
+===========
+
+The initialization of the datepicker has been moved into an external
+file residing in :file:`EXT:form/Resources/Public/JavaScript/Frontend/DatePicker.js`.
+Some installations might restrict requesting public resources from :file:`/typo3/`.
+Therefore, a new YAML configuration has been introduced:
+
+:yaml:`TYPO3.CMS.Form.prototypes.standard.formElementsDefinition.DatePicker.properties.datePickerInitializationJavaScriptFile`
+
+That way, integrators are able to move the file to a different folder
+which is publicly accessible.
+
+.. index:: ext:form

Documentation/Changelog/11.4/Important-92202-RemoveExcludeFromImportantFields.rst

@@ -0,0 +1,27 @@
+.. include:: /Includes.rst.txt
+
+.. _important-92202:
+
+========================================================
+Important: #92202 - Remove exclude from important fields
+========================================================
+
+See :issue:`92202`
+
+Description
+===========
+
+To simplify the setup of permissions, the following fields are now shown always to every editor:
+
+* Field "colPos" from table "tt_content"
+* Field "slug" from table "pages"
+
+If the fields should be hidden, either the setting :php:`'exclude' => true` can be set in your
+site package extension or the following TsConfig can be used:
+
+.. code-block:: typoscript
+
+    TCEFORM.pages.slug.disabled = 1
+    TCEFORM.tt_content.colPos.disabled = 1
+
+.. index:: Backend, ext:core, TCA

Documentation/Changelog/11.4/Important-94280-MoveContentsOfExtPhpIntoLocalScopes.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94280:
+
+====================================================================
+Important: #94280 - Move contents of ext_*.php into global namespace
+====================================================================
+
+See :issue:`94280`
+
+Description
+===========
+
+When warming up caches, the code of the files :file:`ext_localconf.php` and
+:file:`ext_tables.php` are now scoped into the global namespace.
+
+.. warning::
+
+   The content of such :file:`ext_*.php` files **must not** be wrapped in a
+   local namespace by extension authors. This will result in nested namespaces
+   and therefore cause PHP errors only solvable by clearing the caches via
+   Install Tool!
+
+
+Example code from the cache file:
+
+.. code-block:: php
+
+   /**
+    * Extension: frontend
+    * File: /var/www/html/public/typo3/sysext/frontend/ext_localconf.php
+    */
+
+   namespace {
+       // Content of EXT:frontend/ext_localconf.php
+   }
+
+Having a namespace allows extension authors to import classes by the
+keyword :php:`use`.
+
+Example :file:`ext_localconf.php`:
+
+.. code-block:: php
+
+   <?php
+
+   use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;
+
+   defined('TYPO3') or die();
+
+   ExtensionManagementUtility::addUserTSConfig('
+       options.saveDocView = 1
+       options.saveDocNew = 1
+       options.saveDocNew.pages = 0
+       options.saveDocNew.sys_file = 0
+       options.saveDocNew.sys_file_metadata = 0
+       options.disableDelete.sys_file = 1
+   ');
+
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Important-94615-FluidViewHelpersFlinkexternalAndFuriexternalUseHttpsByDefault.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94615:
+
+==============================================================================================
+Important: #94615 - Fluid view helpers f:link.external and f:uri.external use https by default
+==============================================================================================
+
+See :issue:`94615`
+
+Description
+===========
+
+When using the Fluid view helpers :html:`f:uri.external` or :html:`f:link.external` without
+an explicitly specified scheme, the target link now uses :html:`https` instead of :html:`http`.
+
+Given the following Fluid snippets:
+
+.. code-block:: html
+
+   <f:link.external uri="www.some-domain.tld">some content</f:link.external>
+   <f:uri.external uri="www.some-domain.tld" />
+
+The result before:
+
+.. code-block:: html
+
+   <a href="http://www.some-domain.tld">some content</a>
+   http://www.some-domain.tld
+
+New result:
+
+.. code-block:: html
+
+   <a href="https://www.some-domain.tld">some content</a>
+   https://www.some-domain.tld
+
+If the new default can not be used, the :html:`http` scheme needs to be specified. Examples:
+
+.. code-block:: html
+
+   <f:link.external uri="http://www.some-domain.tld">some content</f:link.external>
+   <f:link.external uri="www.some-domain.tld" defaultScheme="http">some content</f:link.external>
+   <f:uri.external uri="http://www.some-domain.tld" />
+   <f:uri.external uri="www.some-domain.tld" defaultScheme="http" />
+
+
+.. index:: Fluid, ext:fluid

Documentation/Changelog/11.4/Important-94697-QuoteDatabaseIdentifiersWhenUsedInsteadOfGloballyUpfront.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94697:
+
+====================================================================================
+Important: #94697 - Quote database identifiers when used instead of globally upfront
+====================================================================================
+
+See :issue:`94697`
+
+Description
+===========
+
+When using :php:`TCA` keys that contain SQL fragments like :php:`foreign_table_where`,
+:php:`MM_table_where` and :php:`search.andWhere`, it is important to use a special syntax
+for SQL field names to stay DBAL compatible.
+
+See :doc:`#81751 <../8.7.x/Important-81751-DbalCompatibleQuotingInTca>` for details.
+It boils down to: Use :sql:`{#colPos}=0` instead of :sql:`colPos=0` to stay DBAL
+compatible. The core then takes care field names are properly quoted for the
+specific DBMS that is used.
+
+This quoting preparation has been performed during TCA cache warmup until now.
+This had the main disadvantage that this early boostrap step already needs a
+working database connection. The core however plans to introduce features to
+allow cache warmups as separate step in CI/CD systems. Those usually don't have
+the target database available, and in general it's ugly that an early warmup
+needs a database connection.
+
+Therefore, the field name quoting of SQL fragments is now no longer performed
+during TCA cache warmup, but instead directly done in places where those
+TCA keys are used to create the final queries.
+
+Since extensions might rely on identifiers within these settings being properly
+quoted, a feature flag called `runtimeDbQuotingOfTcaConfiguration` is introduced
+to revert to the old behaviour with TYPO3 v11.
+
+Extension authors who access these TCA properties, which is quite unlikely,
+can use the feature flag to support both variants to ensure compatibility
+between TYPO3 v10, v11 and TYPO3 v12.
+
+Starting with TYPO3 v12.0, this feature flag will be enabled at all times.
+
+.. index:: Database, TCA, ext:core

Documentation/Changelog/11.4/Important-94830-UpdateEguliasemail-validator.rst

@@ -0,0 +1,20 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94830:
+
+==================================================
+Important: #94830 - Update egulias/email-validator
+==================================================
+
+See :issue:`94830`
+
+Description
+===========
+
+The package `egulias/email-validator` has been updated from version 2.1.25 to 3.1.1.
+
+The validation of emails which are using edge cases of the RFC might change.
+
+The full changelog is available at https://github.com/egulias/EmailValidator/blob/3.x/CHANGELOG.md
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.4/Important-94876-RemoveNon-XMLTextValidatorFromFormEditor.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94876:
+
+====================================================================
+Important: #94876 - Remove "Non-XML text" validator from form editor
+====================================================================
+
+See :issue:`94876`
+
+Description
+===========
+
+The "Non-XML text" validator has been removed from the UI of the form editor.
+Here's why:
+
+* The validator has a very specific purpose since it is only useful for values
+  which are output in an HTML context without escaping. By default, this is never
+  the case in TYPO3 thanks to the automatic escaping in Fluid.
+* The form editor is meant to be used by editors and integrators where the
+  most use cases involve output of form values within TYPO3 (website / mail). This
+  validator does not serve any purpose then.
+* The form editor should be uncluttered and stripped from too technical and
+  complex concepts which this validator belongs to.
+
+If there are already text validators within a form definition, the UI keeps the
+corresponding validator editors. I.e. the form editor will display them. In newly
+created forms, the text validator can no longer be added by default.
+
+If you want to re-add this validator just extend your own form configuration.
+The following example adds the "Non-XML text" validator to the form element
+`Text`. The path :yaml:`TYPO3.CMS.Form.prototypes.standard.formElementsDefinition.Text.formEditor.editors.900`
+contains the definition for the validators. We are adding the validator with the key
+`100` to not interfere with keys already taken by the core (`10` to `90`).
+
+.. code-block:: yaml
+
+    TYPO3:
+      CMS:
+        Form:
+          prototypes:
+            standard:
+              formElementsDefinition:
+                Text:
+                  formEditor:
+                    editors:
+                      900:
+                        selectOptions:
+                          100:
+                            value: Text
+                            label: formEditor.elements.TextMixin.editor.validators.Text.label
+
+.. index:: Backend, ext:form

Documentation/Changelog/11.4/Important-94889-LinkBuilderbuildNowReturnsArrayLinkResultInterface.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94889:
+
+========================================================================================
+Important: #94889 - AbstractTypoLinkBuilder::build now returns array|LinkResultInterface
+========================================================================================
+
+See :issue:`94889`
+
+Description
+===========
+
+The method signature of :php:`\TYPO3\CMS\Frontend\Typolink\AbstractTypoLinkBuilder` has changed, as
+:php:`array` return type has been removed, thus loosening the inheritance
+criteria for TYPO3 v11.
+
+In TYPO3 v12 :php:`AbstractTypoLinkBuilder` will have a
+:php:`\TYPO3\CMS\Frontend\Typolink\LinkResultInterface` return type.
+
+Extensions using this class can stay compatible with two major TYPO3 LTS
+versions by doing the following:
+
+* Keeping an :php:`array` return type to stay compatible with
+  TYPO3 v10 and TYPO3 v11.
+* Using the :php:`LinkResultInterface` return type to stay compatible with
+  TYPO3 v11 and TYPO3 v12+.
+
+.. index:: Frontend, PHP-API, TypoScript, ext:frontend

Documentation/Changelog/11.4/Important-95647-ComposerInstallationsAndExtensionUsage.rst

@@ -0,0 +1,72 @@
+.. include:: /Includes.rst.txt
+
+.. _important-95647:
+
+==============================================================
+Important: #95647 - Composer installations and extension usage
+==============================================================
+
+See :issue:`95647`
+
+Description
+===========
+
+With :issue:`94996` the behavior for Composer-based installations has changed.
+
+Importance of :file:`ext_emconf.php` file
+-----------------------------------------
+
+The :file:`ext_emconf.php` file which is located in the extensions' base folder,
+is not evaluated anymore in Composer-based installations. This means, the
+ordering of the extensions and their dependencies are now loaded from the
+:file:`composer.json` file, instead of :file:`ext_emconf.php`.
+
+For non-Composer installation ("Classic Mode") the `ext_emconf.php` file is the
+source of truth for required dependencies and the loading order of active
+extensions.
+
+Extension authors should ensure that the information in the :file:`composer.json`
+file is in sync with the one in the extensions' :file:`ext_emconf.php` file.
+This is especially important regarding constraints like `depends` , `conflicts`
+and `suggests`. Use the equivalent settings in :file:`composer.json` `require`,
+`conflict` and `suggest` to set dependencies and ensure a specific loading order.
+
+It is recommended to keep :file:`ext_emconf.php` and :file:`composer.json` in
+any public extension that is published to TYPO3 Extension Repository (TER), and
+to ensure optimal compatibility with Composer-based installations and Classic
+mode.
+
+Removal of :file:`PackageStates.php`
+------------------------------------
+
+The :file:`typo3conf/PackageStates.php` file is not evaluated anymore in
+Composer-based installations. When updating TYPO3 installations that still
+contain this file e.g. under version control, the file can safely be removed.
+
+Use the TYPO3 CLI command :bash:`extension:setup` to set up all extensions
+available in Composer.
+
+Package information (like paths or extension meta data) is still stored in and evaluated from
+a file in Composer's :file:`vendor` folder. This file is written after Composer dumps autoload information.
+Make sure all files from that (:file:`vendor`) folder are transferred during a deployment.
+This means no special action compared to previous TYPO3 versions is required regarding the :file:`vendor` folder
+with TYPO3 11 LTS.
+
+.. Important::
+   TYPO3 version 11.5.0 to 11.5.2 stored package information in :file:`var/build/` folder,
+   which previously required this folder to be transferred as well during a deployment.
+   This is not required any more now. Transferring the :file:`vendor` folder is sufficient now.
+
+All extensions are always active
+--------------------------------
+
+All extensions and their dependant extensions required via Composer in a
+Composer-based TYPO3 installation are **always** activated. It is not possible
+to disable an extension by using the Extension Manager anymore.
+
+The TYPO3 CLI command :bash:`extension:setup` can be used after each
+`composer require` or `composer update` command to update the database schema
+and other important actions usually done when previously activating an extension
+in the Extension Manager.
+
+.. index:: Backend, Frontend, ext:core

Documentation/Changelog/11.4/Index.rst

@@ -0,0 +1,53 @@
+:template: changelogOverview.html
+.. include:: /Includes.rst.txt
+..  _changelog-11-4:
+
+============
+11.4 Changes
+============
+
+**Table of contents**
+
+.. contents::
+   :local:
+   :depth: 1
+
+Breaking Changes
+================
+
+None since TYPO3 v11.0 release.
+
+.. attention::
+
+   After TYPO3 v11.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 v11.0 release on the way to LTS.
+
+Features
+========
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Feature-*
+
+Deprecation
+===========
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Deprecation-*
+
+Important
+=========
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Important-*