TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/10.0/Breaking-21638-LockIPPropertyRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-21638:
+
+======================================================================
+Breaking: #21638 - AbstractUserAuthentication::lockIP property removed
+======================================================================
+
+See :issue:`21638`
+
+Description
+===========
+
+The IP-locking-functionality is extended from IPv4 only to now also support IPv6. A separate IpLocker-functionality was added.
+
+The public property :php:`lockIP` in :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication` is now removed.
+It usually shouldn't have been accessed directly and supported IPv4 only.
+
+
+Impact
+======
+
+Extensions relying on :php:`lockIP` won't be able to perform their task anymore.
+This might for example be the case when :php:`lockIP` was set dynamically, depending on the REMOTE_ADDR.
+
+
+Affected Installations
+======================
+
+Every 3rd party extension depending on the formerly public :php:`lockIP` property is affected.
+
+
+Migration
+=========
+
+Set :php:`lockIP` and :php:`lockIPv6` in :php:`TYPO3_CONF_VARS` - for FE or BE depending on the use case.
+Use the new :php:`\TYPO3\CMS\Core\Authentication\IpLocker` API.
+
+.. index:: Backend, Frontend, LocalConfiguration, NotScanned

Documentation/Changelog/10.0/Breaking-81950-RemoveLeftoverWorkspacesUnpublishingFunctionality.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-81950:
+
+========================================================================
+Breaking: #81950 - Remove leftover workspaces unpublishing functionality
+========================================================================
+
+See :issue:`81950`
+
+Description
+===========
+
+A property within workspaces for "unpublishing" published records has been disabled since TYPO3 4.5.
+
+This functionality allowed to restore a published workspace which was published at a given time, to revert the changes on another
+time, but had side-effects if changes were made between publishing and unpublishing.
+
+However, this functionality was not visible to TYPO3 out of the box, but only available with a possible third-party integration
+since TYPO3 4.5. The feature was therefore removed from TYPO3 Core.
+
+The (hidden) database field :sql:`sys_workspace.unpublish_time` was removed.
+
+
+Impact
+======
+
+Using the functionality will not work anymore, operating on the database with this field will result in a SQL error.
+
+
+Affected Installations
+======================
+
+Any installation using the workspace functionality with automatic publishing and a third-party extension for unpublishing.
+
+
+Migration
+=========
+
+If this feature is required for an installation, the field should be re-added by the third-party extension in TCA (which was missing)
+and the database which was using the functionality. On top, a custom auto-unpublishing CLI command should be created.
+
+.. index:: Database, NotScanned, ext:workspaces

Documentation/Changelog/10.0/Breaking-86862-DefaultLayoutOfExtfluid_styled_contentDoesNotUseSpacelessViewHelperAnymore.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-86862:
+
+=======================================================================================================
+Breaking: #86862 - Default Layout of ext:fluid_styled_content does not use spaceless viewHelper anymore
+=======================================================================================================
+
+See :issue:`86862`
+
+Description
+===========
+
+The default layout file of ext:fluid_styled_content removed all white space characters in the whole output, which led
+to occasional issues with the generated markup. This general removal of whitespace characters has been removed.
+It is in the hand of the integrator to apply white space character removal on their own on sensible places using template override functionality.
+
+
+Impact
+======
+
+Markup of pages rendered using ext:fluid_styled_content will contain more white space characters.
+This might influence the visual output.
+
+
+Affected Installations
+======================
+
+Each instance using ext:fluid_styled_content as rendering template.
+
+
+Migration
+=========
+
+Review and adjust the markup generated for your front end. In case you did not experience any issues before,
+you can override the default template and reintroduce the spaceless viewHelper, or apply it in other sections of the output where it will be helpful.
+
+.. index:: Fluid, Frontend, RTE, NotScanned, ext:fluid_styled_content

Documentation/Changelog/10.0/Breaking-87009-UseMultipleTranslationFilesByDefaultInEXTform.rst

@@ -0,0 +1,82 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87009:
+
+========================================================================
+Breaking: #87009 - Use multiple translation files by default in EXT:form
+========================================================================
+
+See :issue:`87009`
+
+Description
+===========
+
+All :yaml:`translationFile` options in EXT:form setup and form definitions have been renamed to :yaml:`translationFiles`.
+
+The following default translation files are now registered at index :yaml:`10` in all locations:
+
+* :file:`EXT:form/Resources/Private/Language/locallang.xlf`
+* :file:`EXT:form/Resources/Private/Language/Database.xlf`
+
+
+Impact
+======
+
+Extending form setup or form definitions with additional translation files does not require adding the default translation files anymore.
+
+The option :yaml:`translationFile` does not work anymore and must be migrated to :yaml:`translationFiles`.
+
+Opening and saving a form with the form editor once also performs the migration of the corresponding form definition and makes it permanent.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and its :yaml:`translationFile` option.
+
+
+Migration
+=========
+
+In your custom form configuration, migrate the single value :yaml:`translationFile` option to the multi value :yaml:`translationFiles` option.
+
+Given that all default translation files of EXT:form are registered at index :yaml:`10` it is recommended to use a higher index for custom translation files.
+
+Single file
+-----------
+
+Before:
+
+.. code-block:: yaml
+
+   translationFile: path/to/locallang.xlf
+
+After:
+
+.. code-block:: yaml
+
+   translationFiles:
+     20: path/to/locallang.xlf
+
+
+Multiple files
+--------------
+
+Before:
+
+.. code-block:: yaml
+
+   translationFile:
+     10: EXT:form/Resources/Private/Language/locallang.xlf
+     20: path/to/locallang.xlf
+     25: path/to/other/locallang.xlf
+
+After:
+
+.. code-block:: yaml
+
+   translationFiles:
+     20: path/to/locallang.xlf
+     25: path/to/other/locallang.xlf
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/10.0/Breaking-87305-UseConstructorInjectionInDataMapper.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87305:
+
+==========================================================
+Breaking: #87305 - Use constructor injection in DataMapper
+==========================================================
+
+See :issue:`87305`
+
+Description
+===========
+
+Class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper` does no longer use setter injection. Instead, constructor injection is used.
+
+
+Impact
+======
+
+The method signature of the constructor changed. This means:
+
+- The amount of constructor arguments increased
+- The order of arguments possibly changed
+
+
+Affected Installations
+======================
+
+All installations that create instances of the class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper` using :php:`GeneralUtility::makeInstance` or :php:`ObjectManager->get`.
+
+
+Migration
+=========
+
+If possible, do not create instances yourself. Avoid :php:`GeneralUtility::makeInstance` and :php:`ObjectManager->get`. Instead use dependency injection, preferably constructor injection:
+
+.. code-block:: php
+
+   public function __constructor(\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper $object)
+   {
+       $this->property = $object;
+   }
+
+If dependency injection is not possible, check the dependencies and instantiate objects via the object manager:
+
+.. code-block:: php
+
+   $object = $objectManager->get(
+       \TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper::class,
+       $objectManager->get(\TYPO3\CMS\Extbase\Reflection\ReflectionService::class),
+       // ...
+   );
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87511-RemoveNamespacesViewObjectNamePatternProperty.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87511-1668719172:
+
+===================================================================
+Breaking: #87511 - Remove $namespacesViewObjectNamePattern property
+===================================================================
+
+See :issue:`87511`
+
+Description
+===========
+
+Property :php:`$namespacesViewObjectNamePattern` of class
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` has been
+removed without replacement.
+
+Impact
+======
+
+Overriding the property :php:`$namespacesViewObjectNamePattern` in
+controllers that extend :php:`ActionController` will no longer trigger
+the instantiation of another view object, derived from the pattern.
+
+Affected Installations
+======================
+
+All extensions that override the property :php:`$namespacesViewObjectNamePattern`.
+
+Migration
+=========
+
+If an action needs a template object other than the default
+:php:`\TYPO3\CMS\Fluid\View\TemplateView`, the property :php:`$defaultViewObjectName`
+needs to be overridden.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87511-RemoveViewFormatToObjectNameMapProperty.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87511:
+
+=============================================================
+Breaking: #87511 - Remove $viewFormatToObjectNameMap property
+=============================================================
+
+See :issue:`87511`
+
+Description
+===========
+
+Property :php:`$viewFormatToObjectNameMap` of class
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` has been
+removed without replacement.
+
+Impact
+======
+
+Overriding the property :php:`$viewFormatToObjectNameMap` in
+controllers that extend :php:`ActionController` will no longer trigger
+the instantiation of another view object, derived from the mapping.
+
+Affected Installations
+======================
+
+All extensions that override the property :php:`$viewFormatToObjectNameMap`.
+
+Migration
+=========
+
+If an action needs a template object other than the default
+:php:`\TYPO3\CMS\Fluid\View\TemplateView`, the property :php:`$defaultViewObjectName`
+needs to be overridden.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87558-ConsolidateExtbaseCaches.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87558:
+
+=============================================
+Breaking: #87558 - Consolidate extbase caches
+=============================================
+
+See :issue:`87558`
+
+Description
+===========
+
+The caches of extbase have been consolidated as both of them shared the same caching frontend.
+Cache identifiers `extbase_reflection` and `extbase_datamapfactory_datamap` do no longer exist.
+
+A single cache `extbase` is pre-configured and used for class schemata and data maps instead.
+
+
+Impact
+======
+
+Adjusting the cache configuration of either `extbase_reflection`
+or `extbase_datamapfactory_datamap` will no longer have any effect.
+
+The installation may throw an error depending on the php error level configuration, if the no longer existing
+cache keys are written to without initializing them first.
+
+The following global settings do no longer exist:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_reflection']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_datamapfactory_datamap']`
+
+The following code code might throw an error depending on the php error level configuration:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['SYS']['cacheConfigurations']['extbase_reflection']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
+
+
+Affected Installations
+======================
+
+All installations that override the configuration of the caches `extbase_reflection` and `extbase_datamapfactory_datamap`.
+
+
+Migration
+=========
+
+Override new cache `extbase` in the same manner the former caches were overridden.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87567-GlobalVariableTBE_TEMPLATERemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87567:
+
+========================================================
+Breaking: #87567 - Global variable $TBE_TEMPLATE removed
+========================================================
+
+See :issue:`87567`
+
+Description
+===========
+
+The global variable :php:`$GLOBALS[TBE_TEMPLATE]` used in TYPO3 Backend which was available
+for legacy reasons for old backend modules as an instance of :php:`DocumentTemplate` a.k.a. `alt_doc`
+has been removed.
+
+The according PSR-15 middleware, which was marked as internal, is also removed.
+
+
+Impact
+======
+
+Calling any method or property on :php:`$GLOBALS[TBE_TEMPLATE]` will trigger a PHP :php:`E_ERROR` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with older extensions using the global variable.
+
+
+Migration
+=========
+
+Instantiate the :php:`DocumentTemplate` class directly in the controller of the module, or migrate
+to :php:`ModuleTemplate` which is available since TYPO3 v7.
+
+.. index:: PHP-API, FullyScanned, ext:backend

Documentation/Changelog/10.0/Breaking-87583-RemoveObsoleteAPCCacheBackendImplementation.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87583:
+
+===================================================================
+Breaking: #87583 - Remove obsolete APC Cache Backend implementation
+===================================================================
+
+See :issue:`87583`
+
+Description
+===========
+
+The Caching framework backend implementation :php:`TYPO3\CMS\Core\Cache\Backend\ApcBackend` has
+been removed. The APCu PHP extension has superseded in PHP 7.x.
+
+Impact
+======
+
+The PHP APC extension works until PHP 5.x. APCu can be used as "drop-in" replacement since TYPO3 8
+LTS which supports PHP 7.0+.
+
+Affected Installations
+======================
+
+Any installation which has been updated, and any legacy APC cache backend is configured (see
+:file:`LocalConfiguration.php`).
+
+Migration
+=========
+
+Use APCu implementation, which is implemented via :php:`TYPO3\CMS\Core\Cache\Backend\ApcuBackend`
+instead of :php:`TYPO3\CMS\Core\Cache\Backend\ApcBackend` in your caching framework configuration.
+
+Example before:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['backend'] = \TYPO3\CMS\Core\Cache\Backend\ApcBackend::class;`
+
+Example after:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['backend'] = \TYPO3\CMS\Core\Cache\Backend\ApcuBackend::class;`
+
+
+.. index:: Backend, PHP-API, ext:core, NotScanned

Documentation/Changelog/10.0/Breaking-87594-HardenExtbase.rst

@@ -0,0 +1,101 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87594:
+
+=================================
+Breaking: #87594 - Harden extbase
+=================================
+
+See :issue:`87594`
+
+Description
+===========
+
+While hardening Extbase classes, method signatures changed due to an enforced strict type mode and introduced type hints for scalars.
+The change of signatures is considered breaking for the following methods of the following interfaces and their implementations and for the following classes and their derivatives:
+
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::getUid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::setPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::getPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_isNew`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_setProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_getProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_getProperties`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_getCleanProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::getUid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::setPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::getPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_isNew`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_setProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_getProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_getProperties`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_getCleanProperty`
+- :php:`\TYPO3\CMS\Extbase\Service\ImageService::applyProcessingInstructions`
+- :php:`\TYPO3\CMS\Extbase\Service\ImageService::getImageUri`
+- :php:`\TYPO3\CMS\Extbase\Service\ImageService::getImage`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getSupportedSourceTypes()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getSupportedTargetType()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getTargetTypeForSource()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getPriority()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::canConvertFrom()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getSourceChildPropertiesToBeConverted()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getTypeOfChildProperty()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::convertFrom()`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::__construct`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getMessage`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getCode`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getArguments`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getTitle`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::render`
+- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::getContentObject`
+- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::getConfiguration`
+- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::isFeatureEnabled`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::reset()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::build()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::uriFor()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAbsoluteUriScheme()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryStringMethod()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setArgumentPrefix()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setArguments()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setArgumentsToBeExcludedFromQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setCreateAbsoluteUri()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setFormat()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setLinkAccessRestrictedPages()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setNoCache()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setSection()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setTargetPageType()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setTargetPageUid()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setUseCacheHash()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getAddQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getAddQueryStringMethod()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getArguments()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getArgumentsToBeExcludedFromQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getCreateAbsoluteUri()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getFormat()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getLinkAccessRestrictedPages()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getNoCache()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getSection()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getTargetPageUid()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getUseCacheHash()`
+
+
+Impact
+======
+
+PHP might throw a fatal error if the method signature(s) of your implementations/derivatives aren't compatible with the interface(s) and/or parent class(es).
+
+
+Affected Installations
+======================
+
+- All installations that use classes that implement mentioned interfaces and their methods.
+- All installations that use classes that inherit mentioned classes and overwrite their methods.
+
+
+Migration
+=========
+
+Methods need to be adjusted to be compatible with the parent class and/or interface signature.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-87623-ReplaceConfigpersistenceclassesTyposcriptConfiguration.rst

@@ -0,0 +1,100 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87623:
+
+==============================================================================
+Breaking: #87623 - Replace config.persistence.classes typoscript configuration
+==============================================================================
+
+See :issue:`87623`
+
+Description
+===========
+
+The configuration of classes in the context of the Extbase persistence is no longer possible via typoscript.
+All typoscript concerning the configuration of classes in that context needs to be converted to php, residing
+in :file:`EXT:extension/Configuration/Extbase/Persistence/Classes.php`.
+
+
+Impact
+======
+
+Unless converted to php, the configuration in typoscript does no longer have any effect and therefore the following things do no longer work:
+
+- Overwriting table names for models whose table name derived by conventions differ from the desired one.
+- The mapping of database field names to model property names
+- The definition of model sub classes which is necessary for a proper implementation of single table inheritance.
+
+
+Affected Installations
+======================
+
+All installations that configure persistence related classes via typoscript.
+
+
+Migration
+=========
+
+Every extension that used typoscript for such configuration must provide a php configuration class called:
+:file:`EXT:extension/Configuration/Extbase/Persistence/Classes.php`
+
+The migration is best described by an example:
+
+.. code-block:: typoscript
+
+   config.tx_extbase {
+       persistence {
+           classes {
+               TYPO3\CMS\Extbase\Domain\Model\FileMount {
+                  mapping {
+                     tableName = sys_filemounts
+                     columns {
+                        title.mapOnProperty = title
+                        path.mapOnProperty = path
+                        base.mapOnProperty = isAbsolutePath
+                     }
+                  }
+               }
+           }
+       }
+   }
+
+This configuration will look like this, defined in php:
+
+.. code-block:: php
+
+   <?php
+   declare(strict_types = 1);
+
+   return [
+       \TYPO3\CMS\Extbase\Domain\Model\FileMount::class => [
+           'tableName' => 'sys_filemounts',
+           'properties' => [
+               'title' => [
+                   'fieldName' => 'title'
+               ],
+               'path' => [
+                   'fieldName' => 'path'
+               ],
+               'isAbsolutePath' => [
+                   'fieldName' => 'base'
+               ],
+           ],
+       ],
+   ];
+
+A few things are noteworthy here:
+
+- The typoscript node :typoscript:`mapping` has been dropped and all sub nodes like :typoscript:`tableName` and :typoscript:`columns` are now located directly
+  in the top node, i.e. the class name.
+- The mapping of columns changed due to the fact that :typoscript:`mapOnProperty` has been dropped and the mapping direction changed.
+  With typoscript the top nodes were called like the class names which indicates the mapping direction model to table. But
+  then, one had to define a mapping by columns instead of properties, which means, the mapping directions was reversed,
+  forcing you to map database table fields on properties. This was quite confusing and the configuration is now eased as
+  one can always think in the model to table mapping direction.
+- The load order of these files is determined by the load order of extensions. If multiple extensions override mapping
+  configuration of the same extbase domain classes, extension load order should be specified by :file:`ext_emconf.php`
+  constraints or dependencies using the :php:`suggests` or :php:`depends` keywords. See
+  :ref:`ext_emconf.php file<t3coreapi:extension-declaration>` for details.
+
+.. index:: TypoScript, NotScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87627-RemovePropertyExtensionNameOfAbstractController.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87627:
+
+======================================================================
+Breaking: #87627 - Remove Property extensionName of AbstractController
+======================================================================
+
+See :issue:`87627`
+
+Description
+===========
+
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController::$extensionName`
+has been removed and is no longer available in subclasses of
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController`, i.e.
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` and their derivates.
+
+
+Impact
+======
+
+Accessing the missing property :php:`$extensionName` will throw a fatal error.
+
+
+Affected Installations
+======================
+
+All installations that read from :php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController::$extensionName`.
+
+
+Migration
+=========
+
+The extension name is set in and available through the request object that is available in the controller.
+See :php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController::$request` and :php:`\TYPO3\CMS\Extbase\Mvc\Request::getControllerExtensionName()`
+for more information.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87936-TCAForSysHistoryRemoved.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87936:
+
+==============================================
+Breaking: #87936 - TCA for sys_history removed
+==============================================
+
+See :issue:`87936`
+
+Description
+===========
+
+The TCA definition for :sql:`sys_history` database table was removed. It was never shown in TYPO3 Backend,
+and only in use for the BElog module as Extbase Domain Model. However, this relationship between
+logs and sys_history was decoupled in TYP3 v9.0.
+
+The database field :sql:`pid` which was "0" at all times, is now removed.
+
+
+Impact
+======
+
+Accessing :php:`$GLOBALS[TCA][sys_history]` will trigger a PHP :php:`E_WARNING`, and the contents of the array
+are not available anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with extensions accessing the global array by making use of
+:sql:`sys_history`.
+
+
+Migration
+=========
+
+If still needed, an extension should deliver the full TCA definition of :sql:`sys_history`.
+
+.. index:: Database, TCA, FullyScanned, ext:core

Documentation/Changelog/10.0/Breaking-87937-TCAOption_selicon_field_path_removed.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87937:
+
+==========================================================
+Breaking: #87937 - TCA option "selicon_field_path" removed
+==========================================================
+
+See :issue:`87937`
+
+Description
+===========
+
+The TCA option :php:`$GLOBALS['TCA'][$myTable]['ctrl']['selicon_field_path']` was removed.
+
+The option allowed to show icons in select items when using :php:`$myTable` as a foreign table
+in relations, and was bound to using :php:`selicon_field` as a legacy file (:php:`internal_type=file`).
+
+
+Impact
+======
+
+It is now only possible to use :php:`selicon_field` in inline relations towards :php:`sys_file_reference`.
+Setting the :php:`selicon_field_path` has no effect anymore and a PHP :php:`E_USER_DEPRECATED` error will be triggered.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with an extension providing TCA with :php:`selicon_field_path`.
+
+
+Migration
+=========
+
+Remove the option :php:`selicon_field_path` and use an inline relation to file references in :php:`selicon_field` instead.
+
+.. index:: TCA, PartiallyScanned, ext:core

Documentation/Changelog/10.0/Breaking-87957-DoNotMagicallyRegisterValidators.rst

@@ -0,0 +1,164 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87957:
+
+=================================================================================
+Breaking: #87957 - Validators are not registered automatically in Extbase anymore
+=================================================================================
+
+See :issue:`87957`
+
+Description
+===========
+
+There were several validators that Extbase applies automatically. One example are domain validators that are registered
+if created in a specific directory. Another one is the type validator which is created if a validator with a specific
+name exists.
+
+The method :php:`TYPO3\CMS\Extbase\Utility\ClassNamingUtility::translateModelNameToValidatorName` has
+been removed without substitution. This leads to no automatically registered validators anymore.
+
+Domain Validators
+=================
+
+Given that there is a model :php:`\TYPO3\CMS\Extbase\Domain\Model\BackendUser`, extbase searched for a validator named
+:php:`\TYPO3\CMS\Extbase\Domain\Validator\BackendUserValidator`. The `Model` part of the namespace had been replaced
+with `Validator` and another `Validator` string had been added to the actual class name. In this example, `BackendUser`
+has been replaced with `BackendUserValidator`.
+
+If such a validator class existed it had been magically applied and used during the validation of the model.
+
+Example::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Domain\Validator;
+
+   use TYPO3\CMS\Extbase\Validation\Validator;
+
+   class BlogValidator implements ValidatorInterface
+   {
+      public function validate($value);
+      {
+         // ...
+      }
+   }
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use ExtbaseTeam\BlogExample\Domain\Model\Blog;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      public function showAction(Blog $blog)
+      {
+         // ...
+      }
+   }
+
+In this example there is a model validator :php:`ExtbaseTeam\BlogExample\Domain\Validator\BlogValidator` defined for
+model :php:`ExtbaseTeam\BlogExample\Domain\Model\Blog`, which had been automatically registered before calling action
+:php:`ExtbaseTeam\BlogExample\Controller\BlogController::showAction`.
+
+From now on the validator needs to be registered manually.
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use ExtbaseTeam\BlogExample\Domain\Model\Blog;
+   use TYPO3\CMS\Extbase\Annotation as Extbase;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      /**
+       * @Extbase\Validate(param="blog", validator="ExtbaseTeam\BlogExample\Domain\Validator\BlogValidator")
+       */
+      public function showAction(Blog $blog)
+      {
+         // ...
+      }
+   }
+
+
+Type Validators
+===============
+
+Given that there is any kind of simple type param or property that is to be validated, e.g. a property of a model or an
+action method param, extbase tried to apply a validator for that param/property derived from its type. If there was an
+action param of type string, extbase searched for a `StringValidator` in the namespace
+`TYPO3\CMS\Extbase\Validation\Validator`. The :php:`TYPO3\CMS\Extbase\Validation\Validator\StringValidator` does
+actually exist, as well as :php:`TYPO3\CMS\Extbase\Validation\Validator\IntegerValidator` and others.
+
+If a validator for a specific type existed it had been magically applied and used during the validation of models and
+action arguments.
+
+Example:
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      public function showAction(int $blogUid)
+      {
+         // ...
+      }
+   }
+
+In this example there is a simple type param, extbase automatically registered a type validator for. First, `int` had
+been normalized to `integer`, then :php:`ucfirst($type)` had been called, resulting in `Integer` and then extbase looked
+for a :php:`TYPO3\CMS\Extbase\Validation\Validator\IntegerValidator`. As this Validator exists, it had been
+automatically registered.
+
+If this behaviour is desired, the validator needs to be registered manually from now on.
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use TYPO3\CMS\Extbase\Annotation as Extbase;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      /**
+       * @Extbase\Validate(param="blogUid", validator="TYPO3\CMS\Extbase\Validation\Validator\IntegerValidator")
+       */
+      public function showAction(int $blogUid)
+      {
+         // ...
+      }
+   }
+
+
+Impact
+======
+
+With these mentioned validators no longer being applied automatically, developers actively need to apply those
+validators if needed. Most developers might want to register existing domain validators manually while leaving the type
+validators unregistered. This however will vary from project to project.
+
+
+Affected Installations
+======================
+
+All installations that use the extbase validation framework.
+
+
+Migration
+=========
+
+There is no automatic migration. Validators need to be re-applied manually if needed.
+
+.. index:: PHP-API, PartiallyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87989-TCAOptionSetToDefaultOnCopyRemoved.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87989:
+
+========================================================
+Breaking: #87989 - TCA option setToDefaultOnCopy removed
+========================================================
+
+See :issue:`87989`
+
+Description
+===========
+
+The special TCA option :php:`$TCA[$tableName]['ctrl']['setToDefaultOnCopy']` is removed.
+
+It allowed to reset a certain field to its default value when copying a record.
+
+
+Impact
+======
+
+Having the setting set in TCA will trigger a PHP :php:`E_USER_DEPRECATED` error when building TCA.
+
+Copying records with this TCA setting enabled, will now keep the copied state and avoid side-effects.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with active usage of `sys_action` or other extensions using this TCA setting.
+
+
+Migration
+=========
+
+This option was only there for resetting some `sys_action` values to default, which
+can easily be achieved by a hook if needed. If an extension author uses this setting,
+this should be achieved with proper DataHandler hooks.
+
+.. index:: TCA, PartiallyScanned, ext:core

Documentation/Changelog/10.0/Breaking-88129-RenameFeloginFlexformFields.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88129:
+
+==================================================
+Breaking: #88129 - Renamed felogin flexform fields
+==================================================
+
+See :issue:`88129`
+
+Description
+===========
+
+In preparation to :issue:`84262` the felogin flexform field definition has been changed
+and all field names are now prefixed with `settings.`. This has been done to easily access all
+of the flexform values in the later extbase controller via :php:`$this->settings['foo']` and also in
+the fluid templates via :html:`{settings.foo}`.
+
+
+Impact
+======
+
+Any PageTsConfig that overrides felogin flexform fields will be ignored.
+
+
+Affected Installations
+======================
+
+All installations with a felogin plugin need to migrate their flexform database values.
+PageTsConfig that overrides the flexform needs to be adjusted.
+
+
+Migration
+=========
+
+An update wizard is provided to easily update all used felogin plugins. To migrate the flexform values, execute
+`Migrate felogin plugins to use prefixed flexform keys`.
+
+All PageTsConfig that overrides felogin flexform fields e.g. :typoscript:`TCEFORM.tt_content.pi_flexform.login.sDEF.showForgotPassword.disabled = 1`
+needs to add the `settings.` prefix to the keys.
+Note the escaping backslash! :typoscript:`TCEFORM.tt_content.pi_flexform.login.sDEF.settings\.showForgotPassword.disabled = 1`.
+
+.. index:: FlexForm, NotScanned, ext:felogin

Documentation/Changelog/10.0/Breaking-88143-Version-relatedDatabaseFieldT3ver_idRemoved.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88143:
+
+====================================================================
+Breaking: #88143 - Version-related database field "t3ver_id" removed
+====================================================================
+
+See :issue:`88143`
+
+Description
+===========
+
+The database field for all workspace-enabled database tables :sql:`t3ver_id` is removed. It previously
+contained an incrementing numeric value when using incrementing versioning - the versioning concept
+which was in place before Workspaces were introduced in TYPO3 v4.0.
+
+Since the legacy versioning was removed in TYPO3 v9, the field is removed and not automatically
+created for new installations anymore.
+
+
+Impact
+======
+
+Creating SQL statements in custom extensions explicitly selecting this field will result in SQL
+errors.
+
+In addition, when upgrading TYPO3 to v10.0 this field will be removed by the Database Analyzer
+Tool in the Install Tool for all TYPO3 core database tables and extensions using the automatic
+creation of database fields.
+
+
+Affected Installations
+======================
+
+All installations with custom extensions explicitly requesting this field.
+
+
+Migration
+=========
+
+Search in any extension in `typo3conf/ext` for :sql:`t3ver_id` to see any usages, and remove the field
+from any queries, database definitions in :file:`ext_tables.sql` files.
+
+.. index:: Database, NotScanned, ext:workspaces

Documentation/Changelog/10.0/Breaking-88182-JsfuncInlineJsHasBeenDropped.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88182:
+
+====================================================
+Breaking: #88182 - jsfunc.inline.js has been dropped
+====================================================
+
+See :issue:`88182`
+
+Description
+===========
+
+The JavaScript file :file:`jsfunc.inline.js` which was responsible for FormEngine's subcomponent IRRE has been
+superseded by the rewritten :php:`TYPO3\CMS\Backend\Form\Container\InlineControlContainer` component.
+
+
+Impact
+======
+
+Requesting the file :file:`typo3/sysext/backend/Resources/Public/JavaScript/jsfunc.inline.js` will cause a 404 error.
+Calling any method of the global :js:`inline` object will throw an error since the object doesn't exist anymore.
+
+
+Affected Installations
+======================
+
+All installations of TYPO3 are affected.
+
+
+Migration
+=========
+
+There is no migration available in most cases, since the :php:`TYPO3\CMS\Backend\Form\Container\InlineControlContainer` component is now event-driven.
+
+One exception is the former :js:`inline.delayedImportElement()` method, since this part is now based on
+`postMessage`. For this approach, a small helper utility :js:`TYPO3/CMS/Backend/Utility/MessageUtility` has
+been added.
+
+See the example for a possible migration:
+
+.. code-block:: javascript
+
+   // Previous code from DragUploader
+   window.inline.delayedImportElement(
+       irre_object,
+       'sys_file',
+       file.uid,
+       'file',
+   );
+
+   // New code
+   require(['TYPO3/CMS/Backend/Utility/MessageUtility'], function(MessageUtility) {
+       const message = {
+           objectGroup: irre_object,
+           table: 'sys_file',
+           uid: file.uid,
+       };
+       MessageUtility.send(message);
+   });
+
+The :js:`MessageUtility.send()` method automatically gets the current domain of the request and attaches it to
+the postMessage. :js:`MessageUtility.verifyOrigin()` must be used to check whether the incoming request was sent
+by the current TYPO3 backend to avoid possible security issues.
+
+.. index:: Backend, JavaScript, TCA, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88366-RemovedCf_PrefixOfCacheTables.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88366:
+
+=================================================
+Breaking: #88366 - Removed prefix of cache tables
+=================================================
+
+See :issue:`88366`
+
+Description
+===========
+
+In addition, when the Typo3DatabaseBackend now accesses and creates tables without the ``cf_``
+prefix ("cf" = Caching Framework), so caches in the database are simply called `cache_rootline`
+for instance.
+
+
+Impact
+======
+
+Accessing the database tables directly with a ``cf_`` prefix will not work on the TYPO3 managed
+cache tables.
+
+
+Affected Installations
+======================
+
+Any TYPO3 instance using the Caching Framework with a Typo3DatabaseBackend.
+
+
+Migration
+=========
+
+Use the Caching Framework directly.
+
+In addition, run through the Database Table Analyzer of the Configuration module to
+re-create any database tables of the Caching Framework.
+
+.. index:: Database, NotScanned, ext:core

Documentation/Changelog/10.0/Breaking-88376-RemovedObsoletePageNotFound_handlingSettings.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88376:
+
+====================================================================
+Breaking: #88376 - Removed obsolete "pageNotFound_handling" settings
+====================================================================
+
+See :issue:`88376`
+
+Description
+===========
+
+The following global TYPO3 settings, usually set within :file:`LocalConfiguration.php` have been removed:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling_statheader']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling_accessdeniedheader']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageUnavailable_handling']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageUnavailable_handling_statheader']`
+
+These settings are effectively replaced by the error handling of the newly introduced Site Handling
+which is more flexible and robust, and is used instead of these options when Site Handling was
+enabled in TYPO3 v9. For TYPO3 v10 Site Handling is a requirement, making these options useless.
+
+
+Impact
+======
+
+Setting any of the options will have no effect any more. Executing the Silent Upgrade Wizard
+will remove the settings automatically.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations having these settings overridden in :file:`LocalConfiguration.php`
+file of an installation.
+
+
+Migration
+=========
+
+Access the install tool to automatically update the :file:`LocalConfiguration.php` file and remove the
+settings.
+
+Ensure to set up Site Handling with proper error handlers. Avoid accessing these settings but
+rather use the available :php:`TYPO3\CMS\Frontend\Controller\ErrorController` class, when trying to manually trigger a 404/500
+in the Frontend (e.g. custom plugin) instead.
+
+.. index:: Frontend, LocalConfiguration, PartiallyScanned, ext:frontend

Documentation/Changelog/10.0/Breaking-88411-TBE_EDITORtypo3formRemoved.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88411:
+
+===============================================
+Breaking: #88411 - TBE_EDITOR.typo3form removed
+===============================================
+
+See :issue:`88411`
+
+Description
+===========
+
+The global object :js:`TBE_EDITOR.typo3form` and its backward layers :js:`typo3FormFieldSet` and :js:`typo3FormFieldGet`
+have been removed.
+
+
+Impact
+======
+
+Any extension relying on this code will not work anymore.
+
+
+Affected Installations
+======================
+
+All installations using the removed code are affected.
+
+
+Migration
+=========
+
+No direct migration possible. Refer to the FormEngine JavaScript API.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88427-JsfuncevalfieldjsHasBeenRemoved.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88427:
+
+=======================================================
+Breaking: #88427 - jsfunc.evalfield.js has been removed
+=======================================================
+
+See :issue:`88427`
+
+Description
+===========
+
+The file :file:`jsfunc.evalfield.js`, responsible for form value evaluation and validation, has been removed. This job is
+now done by :js:`TYPO3/CMS/Backend/FormEngineValidation` since TYPO3 7.4.
+
+
+Impact
+======
+
+Extensions still relying on this file and its API will not work anymore.
+
+
+Affected Installations
+======================
+
+All installations with third party extensions using this API are affected.
+
+
+Migration
+=========
+
+In most cases no migration is necessary, unless this API is used in a custom built form. In such case, migrate to
+FormEngine API to automatically use the new API.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88458-RemovedFrontendTrackUserFtuFunctionality.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88458:
+
+==================================================================
+Breaking: #88458 - Removed Frontend Track User "ftu" functionality
+==================================================================
+
+See :issue:`88458`
+
+Description
+===========
+
+The "ftu" feature, used to transfer sessions via GET parameter, has been removed.
+
+The implementation and the functionality exposed some security concerns, if enabled via TypoScript
+:typoscript:`config.ftu` as sessions could have been taken over by link sharing, although this was mitigated
+in the past by a security change.
+
+
+Impact
+======
+
+The following public properties now trigger PHP :php:`E_WARNING` when accessed:
+
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->get_name`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->getFallBack`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->getMethodEnabled`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->get_URL_ID`
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->getMethodUrlIdToken`
+
+The TypoScript setting :typoscript:`config.ftu` has no effect anymore.
+
+The global configuration setting :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['get_url_id_token']` is not
+set anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using the :typoscript:`config.ftu` functionality.
+
+
+Migration
+=========
+
+Remove any usages to the properties or options, and use a custom session handling without
+handing over Session IDs in plaintext via GET parameters. Suggested alternatives for instance are
+JWT payloads or OTP links for starting a session.
+
+For cookie-less session handling, a custom functionality depending on the use-case has to be
+implemented as TYPO3 extension.
+
+.. index:: Frontend, LocalConfiguration, PHP-API, TypoScript, PartiallyScanned

Documentation/Changelog/10.0/Breaking-88496-MethodGetSwitchableControllerActionsHasBeenRemoved.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88496:
+
+=========================================================================
+Breaking: #88496 - Method getSwitchableControllerActions has been removed
+=========================================================================
+
+See :issue:`88496`
+
+Description
+===========
+
+The abstract method :php:`\TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager::getSwitchableControllerActions`
+has been removed in favor of :php:`\TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager::getControllerConfiguration`.
+While the method name changes, the expected implemented functionality stays the same.
+
+
+Impact
+======
+
+Method :php:`getSwitchableControllerActions` will no longer be called. Instead :php:`getControllerConfiguration` is expected
+to be implemented by classes that extend :php:`TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager`.
+
+
+Affected Installations
+======================
+
+All installations that have custom configuration managers that extend :php:`TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager`.
+
+
+Migration
+=========
+
+Rename method :php:`getSwitchableControllerActions` to :php:`getControllerConfiguration` to be TYPO3 >= 10 compatible.
+
+To stay compatible with both version 10 and lower, simply implement both methods and call :php:`getSwitchableControllerActions` from within :php:`getControllerConfiguration`.
+
+Example::
+
+   protected function getSwitchableControllerActions($extensionName, $pluginName)
+   {
+       return $this->getControllerConfiguration($extensionName, $pluginName);
+   }
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-88498-GlobalDataForTimeTrackerStatisticsRemoved.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88498:
+
+=================================================================
+Breaking: #88498 - Global data for TimeTracker statistics removed
+=================================================================
+
+See :issue:`88498`
+
+Description
+===========
+
+The TimeTracker used some global variables to store :php:`microtime()` when a Frontend request was started
+and ended, as information for the Admin Panel and as HTTP Header, if debug mode is enabled for Frontend.
+
+This information is now encapsulated within the TimeTracker object, making the following global variables
+obsolete:
+
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_start']`
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_end']`
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_BE_USER_start']`
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_BE_USER_end']`
+
+This also results in having :php:`$GLOBALS['TYPO3_MISC']` to not be set anymore.
+
+
+Impact
+======
+
+Accessing the global variables will trigger a PHP :php:`E_WARNING` error, as they do not exist anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with an extension working with any of the global variables.
+
+
+Migration
+=========
+
+Remove the usages and either use the newly introduced :php:`TimeTracker->finish()` to calculate data, or set
+your own variables, if microtime is needed.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Breaking-88500-RTEImageHandlingFunctionalityDropped.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88500:
+
+===========================================================
+Breaking: #88500 - RTE image handling functionality dropped
+===========================================================
+
+See :issue:`88500`
+
+Description
+===========
+
+With the replacement of CKEditor as RTE instead of RTEHtmlArea in TYPO3 v8, the native
+and very incomplete functionality of having images within the RTE was unused.
+
+It is still possible to use HTMLArea in further versions (if adopted), however the
+handling of images is removed.
+
+This includes:
+
+* RTE processing mode ("ts_images")
+* SoftReference Index for handling inline images
+* Removed public method :php:`ImportExport->getRTEoriginalFilename()`
+* Removed public method :php:`RteHtmlParser->TS_images_rte()`
+* Removed CLI command "cleanup:rteimages" and relevant command class
+* The configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['RTE_imageStorageDir']`
+
+
+Impact
+======
+
+Images within an RTE field are not processed at all anymore, not part of the CLI.
+
+Calling the CLI script, using the PHP methods or the PHP CLI command class directly
+within PHP, will result in a PHP :php:`E_ERROR` error.
+
+Accessing the configuration option will trigger a PHP :php:`E_NOTICE` error, as it is
+silently removed, if customary set in :file:`LocalConfiguration.php`.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using images within CKEditor (with plugins) or still
+using RTEHtmlArea.
+
+Any TYPO3 installation triggering the CLI command, handling RTE images via EXT:impexp
+or directly handling functionality from the CLI command PHP class.
+
+
+Migration
+=========
+
+If necessary, it is recommended to add this functionality to a custom extension
+where this functionality can live on. It is important however, that most of the
+added functionality of TYPO3 in the last years was not supported (image cropping
+inside RTE was not possible via the Image Cropper of FAL).
+
+It is recommended to move all images within an RTE to proper relations, or to
+use extensions like `rte_ckeditor_image` from https://extensions.typo3.org.
+
+If any fork of RTEHtmlArea is still used in TYPO3 v10.0, the image functionality for
+SoftRefParser, CLI command and the processing mode should be added there.
+
+.. index:: CLI, PHP-API, RTE, PartiallyScanned

Documentation/Changelog/10.0/Breaking-88525-RemoveCreateDirsDirectiveOfExtensionInstallationEm_confphp.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88525:
+
+========================================================================================
+Breaking: #88525 - Remove "createDirs" directive of extension installation / em_conf.php
+========================================================================================
+
+See :issue:`88525`
+
+Description
+===========
+
+Every TYPO3 extension has a file called :file`ext_emconf.php` where important information regarding
+dependencies, current version and loading order are stored.
+
+The directive :php:`createDirs` that was responsible to create a list of folders in the file structure
+during extension installation has been dropped.
+
+The option was available before any File Abstraction Layer. As the :file:`uploads/` folder is not
+created by default by TYPO3 anymore, this directive is not supported anymore as well, as TYPO3 strives
+to support unified file handling for content files, volatile files (file uploads within :file:`typo3temp/var/`)
+or within Extensions directly. The Environment API, introduced in TYPO3 v9, should support for PHP-based
+APIs to choose / create a correct folder location.
+
+
+Impact
+======
+
+Extensions having this directive set will not have this folder available at installation time
+of the extension. The folder will not be created for newly installed extensions, existing extensions
+when upgrading from previous TYPO3 versions, will continue to exist.
+
+
+Affected Installations
+======================
+
+Any TYPO3 extension having this property within :file:`ext_emconf.php` set.
+
+
+Migration
+=========
+
+When an extension supports TYPO3 v10+ only, this directive can be removed.
+
+If an extension needs a special directory, this should be created via PHP when it is needed
+via e.g. :php:`GeneralUtility::mkdir_deep()`.
+
+.. index:: PHP-API, NotScanned, ext:extensionmanager

Documentation/Changelog/10.0/Breaking-88527-OverridingCustomValuesInUserAuthenticationDerivatives.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88527:
+
+==============================================================================
+Breaking: #88527 - Overriding custom values in User Authentication derivatives
+==============================================================================
+
+See :issue:`88527`
+
+Description
+===========
+
+Due to some restructuring of :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication` and its direct sub-classes
+:php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication` (a.k.a. :php:`$BE_USER`) and :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication`,
+various settings are now directly initiated and set in the respective constructor of each PHP class.
+
+Following this, the properties :php:`sessionTimeout`, :php:`gc_time` and :php:`sessionDataLifetime` are set already
+when the constructor is called. Before this was the case when :php:`start()` was called.
+
+In addition, the property :php:`loginType` must be set for any subclass on instantiation. Previously
+this was possible to be set just before :php:`start()` was called.
+
+The previous behavior allowed to override certain parameters to be evaluated just before :php:`start()`.
+
+
+Impact
+======
+
+Setting any global variables between the constructor method and :php:`start()` will have no effect, as
+this is transferred and evaluated at the public properties already when the constructor is called.
+
+Subclassing :php:`AbstractUserAuthentication` without setting :php:`loginType` will trigger an exception
+on instantiation.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation where a custom UserAuthentication instantiation or sub-class is in place, and the setting
+order was changed between calling the constructor and the method :php:`start()`, which is considered a very rare case.
+
+
+Migration
+=========
+
+Consider using a proper subclass and a custom constructor method, or set all properties properly before
+the constructor is called (default values of class members).
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88540-ChangedRequestWorkflowForFrontendRequests.rst

@@ -0,0 +1,106 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88540:
+
+=================================================================
+Breaking: #88540 - Changed Request Workflow for Frontend Requests
+=================================================================
+
+See :issue:`88540`
+
+Description
+===========
+
+The "Frontend Request Workflow" is the PHP code responsible for
+setting up various functionality when the TYPO3 Frontend (= rendering of the website)
+is booted and the content is built. This includes Login/Permission Check, resolving
+the current site + language, and checking the page + rootline, then
+parsing TypoScript, which will then lead to building content (or taken from
+cache), until the actual output is returned.
+
+Since TYPO3 v9, this is all built via PSR-15 middlewares, the PSR-15 Request Handler,
+and the global TypoScriptFrontendController (TSFE).
+
+For TYPO3 v10.0, various changes were made in order to separate concerns / logic
+from each other, allowing to easily exchange certain components with
+other / extended functionality.
+
+The following changes have been made:
+
+Storing session data from a Frontend User Session / Anonymous session is now triggered within the Frontend User
+(`typo3/cms-frontend/authentication`) Middleware, at a later point - once the page was generated. Up until TYPO3 v9, this
+was part of the RequestHandler logic right after content was put together. This was due to legacy reasons of the
+previous hook execution order.
+
+Resolving the actual site - that is the site configuration plus the language - now happens before Frontend
+and Backend User Authentication. This is important to understand to be able to define further settings within
+Site Handling configuration in the future. Site and Site Language Resolving is now 100% independent of any permission
+settings. Evaluating if a language is active is evaluated separately.
+
+Backend User Authentication (:php:`$BE_USER`) is now started before Frontend User Authentication (`fe_user`), previously
+this was the other way around. Frontend Users are now stored in the request object via the `frontend.user` attribute,
+instead of :php:`$TSFE->fe_user`, until :php:`$TSFE` is instantiated.
+
+Once all site + permission/authentication functionality has been set up, Routing now tries to detect
+the target page ID and the URL parameters (`PageResolver` middleware) and evaluates the result, so-called
+"Page Arguments" directly afterwards (`PageArgumentValidator` middleware). This effectively validates the cHash
+logic.
+
+All of the mentioned parts above do not depend on :php:`TSFE` anymore. In fact, they are 100% independent of
+any TSFE-related code. :php:`TSFE` is instantiated after all site resolving, authentication, page resolving and argument
+validation is done.
+
+The new request workflow looks like this (simplified):
+
+#. Evaluation of Normalized Parameters (a.k.a. :php:`getIndpEnv`) & Evaluation of "Maintenance Mode" functionality
+#. Handling registered eID scripts depending on GET parameter `eID`
+#. Resolving Site configuration and Language from URL if possible
+#. Resolving logged-in Backend User Authentication for previewing hidden pages or languages
+#. Authentication of Website Users ("Frontend Users")
+#. Executing various static routes and redirect functionality
+#. Resolving Target Page ID and URL parameters based on Routing, Validation of Page Arguments based on "cHash"
+#. Setting up global :php:`$TSFE` object, injecting previously resolved settings into TSFE.
+#. Resolving the Rootline for the page
+#. Parsing and Evaluation of TypoScript Instructions to render the page content
+#. Build the content (cached / uncached)
+#. Return the Response (PSR-7) to the base application and output headers + content.
+
+In addition, :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` now expects the following constructor arguments:
+
+#. Context API object (previously a copy of :php:`$TYPO3_CONF_VARS`, until TYPO3 v8, then, unused)
+#. :php:`TYPO3\CMS\Core\Site\Entity\SiteInterface` object (previously the Page ID)
+#. :php:`TYPO3\CMS\Core\Site\Entity\SiteLanguage` object (previously the Page Type)
+#. :php:`TYPO3\CMS\Core\Routing\PageArguments` object (previously the no_cache GET parameter)
+#. :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication` object (previously the cHash parameter)
+
+Impact
+======
+
+Hooks that depend on certain functionality being made before or after a hook is
+called will likely have a different behavior when a Frontend Session is used within Hooks.
+
+Anything related to regular plugins / content / TypoScript is not affected.
+
+
+Affected Installations
+======================
+
+Any hooks from third party extensions that run
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_eofe']`
+and depend on the frontend session data being written.
+
+Any TYPO3 extensions using middlewares in the frontend.
+
+Migration
+=========
+
+Consider using a PSR-15 middleware instead of using a hook, or explicitly call :php:`storeSessionData()` within
+the PHP hook if necessary.
+
+If an existing middleware was used, ensure that it's loaded in TYPO3 v10 at the proper location, as the
+`typo3-cms/frontend/tsfe` middleware is loaded at a very late point.
+
+Ensure to use proper objects for the constructor arguments on :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` when instantiating
+the object on your own.
+
+.. index:: Frontend, PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88564-PageTSconfigSettingTSFEconstantsRemoved.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88564:
+
+================================================================
+Breaking: #88564 - PageTSconfig setting "TSFE.constants" removed
+================================================================
+
+See :issue:`88564`
+
+Description
+===========
+
+The PageTSconfig / UserTSconfig :typoscript:`TSFE.constants`, which allowed to override settings constants
+on a per-tree level page was introduced in TYPO3 at the very beginning, long before TSconfig had conditions.
+
+It was used to share TypoScript-based configuration between frontend / backend, and on a per-page/tree level.
+
+However, this has been superseded for a long time by using proper configuration files which
+can be loaded at any time, for example when :file:`ext_localconf.php` of an extension is loaded.
+
+Therefore, the option has been removed.
+
+
+Impact
+======
+
+Setting :typoscript:`TSFE.constants` in PageTSconfig or UserTSconfig has no effect, as it is not evaluated
+anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using :typoscript:`TSFE.constants` in their PageTSconfig.
+
+
+Migration
+=========
+
+It is recommended to include TypoScript conditions in setup/constants, also since constants+setup
+are evaluated in Backend context for Extbase modules. This option is not needed anymore and
+can be substituted by simple constants in `sys_template` or any Extension inclusion files as well.
+
+.. index:: TSConfig, NotScanned

Documentation/Changelog/10.0/Breaking-88574-4thParameterOfPageRepository-enableFieldsRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88574:
+
+========================================================================
+Breaking: #88574 - 4th parameter of PageRepository->enableFields removed
+========================================================================
+
+See :issue:`88574`
+
+Description
+===========
+
+The fourth parameter of :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository->enableFields()` was meant to filter out versioned records
+which are in Live Workspace (versioning, not workspaces). Although the method has largely been superseded
+with Doctrine DBAL's Restrictions, it is still used in some places.
+
+With the introduction of the Context API, new PageRepository instances can be created to fetch multiple variants
+of certain aspects, instead of modifying existing public properties. Therefore the fourth argument has been removed.
+
+
+Impact
+======
+
+Calling the method above with the fourth parameter set to true has no effect anymore, and will
+trigger a PHP :PHP:`E_NOTICE` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation dealing with non-workspace versioning in Frontend requests with third-party extension
+still relying on non-workspace versioning.
+
+
+Migration
+=========
+
+The fourth parameter on any method call can be removed (if set to "false"), or should be replaced with a
+separate instance of :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository` with a custom Context.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/10.0/Breaking-88583-DatabaseFieldSys_languagestatic_lang_isocodeRemoved.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88583:
+
+==========================================================================
+Breaking: #88583 - Database field sys_language.static_lang_isocode removed
+==========================================================================
+
+See :issue:`88583`
+
+Description
+===========
+
+The database field :sql:`static_lang_isocode` is a reference to a language within the third-party
+extension `static_info_tables`. This was tightly coupled to TYPO3 Core until Site Handling was
+introduced to add meaning and meta-data to a language on a per-site level.
+
+The field is not in use by the TYPO3 Core anymore, so the database definition is removed as well.
+
+
+Impact
+======
+
+Migrating to TYPO3 v10.0 will remove the field in the Database Analyzer.
+
+
+Affected Installations
+======================
+
+Multilingual TYPO3 installations without the TYPO3 Extension `static_info_tables` but with usages of the
+database field, which is very unlikely.
+
+
+Migration
+=========
+
+The field can safely be removed in the Database Analyzer if it is not used by an extension.
+
+If the field is still needed, it is recommended to install the extension `static_info_tables`.
+
+If the data from the database field is used, it is recommended to fetch all metadata for a language
+via the Site Configuration and the `SiteLanguage` API instead.
+
+.. index:: Database, NotScanned

Documentation/Changelog/10.0/Breaking-88638-StreamlinedSoftRefParserReferenceLookup.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88638:
+
+=============================================================
+Breaking: #88638 - Streamlined SoftRefParser reference lookup
+=============================================================
+
+See :issue:`88638`
+
+Description
+===========
+
+The Soft Reference Parser is a registry to allow to find parsers (PHP Objects),
+for a given Parser Type (images, internal links, email links) to keep track of
+referenced records within arbitrary data (e.g. RTE text-fields).
+
+Parsers can be added or overridden via the hook registry
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser'][$parserType]`.
+
+Previously, the API method for fetching the proper parsers
+:php:`TYPO3\CMS\Backend\Utility\BackendUtility::softRefParserObj()` kept a runtime cache of created objects
+per type within a global PHP array (:php:`T3_VAR`). This allowed to create objects
+only once, even if there are multiple necessary parts required.
+
+TYPO3's Core SoftRefParser does not keep any state, but the class now has a
+:php:`SingletonInterface`, which means that the object is now a re-used object
+as before.
+
+
+Impact
+======
+
+Calling the SoftRefParser factory method does not keep state of the parser
+objects via :php:`$GLOBALS['T3_VAR']['softRefParser']` anymore.
+
+Instead, :php:`SingletonInterface` is recommended for re-using SoftRefParser objects
+if they need to keep state.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions that use the API with custom parsers,
+or the global variable directly.
+
+
+Migration
+=========
+
+Replace the global variable access via the API call to :php:`TYPO3\CMS\Backend\Utility\BackendUtility`, if this
+is applicable.
+
+If a custom parser is in use, it is recommended to evaluate whether it contains
+re-usable data and switch to :php:`SingletonInterface` instead.
+
+.. index:: Backend, FullyScanned

Documentation/Changelog/10.0/Breaking-88640-DatabaseFieldSys_templatenextLevelAndTypoScriptSublevel-InheritanceRemoved.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88640:
+
+========================================================================================================
+Breaking: #88640 - Database field "sys_template.nextLevel" and TypoScript sublevel - inheritance removed
+========================================================================================================
+
+See :issue:`88640`
+
+Description
+===========
+
+The database field :sql:`nextLevel` of the database table :sql:`sys_template` where TypoScript configuration
+is stored, has been removed.
+
+The field :sql:`nextLevel` was introduced in TYPO3 v3.x before TypoScript could be imported from
+external files.
+
+Nowadays, TypoScript conditions should be used much more instead of this :sql:`nextLevel` feature,
+which is kind of a pseudo-condition.
+
+
+Impact
+======
+
+The database field is removed, and not evaluated anymore in TypoScript compilation.
+
+Requesting the database field in custom database queries will result in an SQL error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations that have :sql:`sys_template` records with this flag activated,
+or querying this database field in third-party extensions.
+
+
+Migration
+=========
+
+Check for existing :sql:`sys_template` records having this flag activated by executing
+this SQL command:
+
+:sql:`SELECT * FROM sys_template WHERE nextLevel>0 AND deleted=0;`
+
+before updating TYPO3 Core.
+
+Replace the sys_template record (the uid of the record is stored in the "nextLevel" field) with a condition e.g. :typoscript:`[tree.level > 1]` to add TypoScript for subpages.
+
+.. index:: Database, NotScanned

Documentation/Changelog/10.0/Breaking-88643-RemovedSwiftmailerswiftmailerDependency.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88643:
+
+=============================================================
+Breaking: #88643 - Removed swiftmailer/swiftmailer dependency
+=============================================================
+
+See :issue:`88643`
+
+Description
+===========
+
+TYPO3's dependency swiftmailer has been removed in favor of new symfony-based
+components "mime" and "mailer".
+
+This means that all SwiftMailer-related PHP code has been removed.
+
+
+Impact
+======
+
+Custom SwiftMailer plugins or transports cannot be used without further
+migration anymore and will result in a fatal :php:`E_ERROR`.
+
+Using SwiftMailer-specific API by using TYPO3's :php:`TYPO3\CMS\Core\Mail\MailMessage` class might result
+in fatal :php:`E_ERROR` when sending out emails.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extension sending out emails or extending
+TYPO3's email sending capabilities.
+
+
+Migration
+=========
+
+Search the third-party extensions' code for occurrences of MailMessage or
+parts starting with `\Swift_` and migrate to symfony/mime or symfony/mailer
+APIs, which are included in TYPO3 v10.0.
+
+If required, SwiftMailer code can be installed via composer (when running TYPO3 via composer)
+via `composer require swiftmailer/swiftmailer`.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/10.0/Breaking-88646-RemovedInheritanceOfAbstractServiceFromAbstractAuthenticationService.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88646:
+
+============================================================================================
+Breaking: #88646 - Removed inheritance of AbstractService from AbstractAuthenticationService
+============================================================================================
+
+See :issue:`88646`
+
+Description
+===========
+
+The PHP :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService` class is used for any kind of Authentication
+or Authorization towards Backend Users and Frontend Users.
+
+It was previously based on :php:`TYPO3\CMS\Core\Service\AbstractService` for any kind of Service API, which
+also includes manipulating files and execution of external applications, which is
+there for legacy reasons since TYPO3 3.x, where the Service API via :php:`GeneralUtility::makeInstanceService` was added.
+
+In order to refactor the Authentication API, the :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService`
+class does not inherit from :php:`TYPO3\CMS\Core\Service\AbstractService` anymore. Instead, the most required
+methods for executing a service is added to the Abstract class directly.
+
+
+Impact
+======
+
+Any calls or checks on the :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService` class or methods, properties or constants that reside within
+:php:`TYPO3\CMS\Core\Service\AbstractService` will result in PHP :php:`E_ERROR` or :php:`E_WARNING`.
+
+Since :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService` is used for most custom Authentication APIs,
+this could affect some of the hooks or custom authentication providers available.
+
+
+Affected Installations
+======================
+
+TYPO3 installations that have custom Authentication providers for frontend or backend
+users / groups - e.g. LDAP or Two-Factor-Authentication.
+
+
+Migration
+=========
+
+If your custom Authentication Service extends from :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService`
+but requires methods or properties from :php:`TYPO3\CMS\Core\Service\AbstractService`, ensure to copy over the
+necessary methods/properties/constants into your custom Authentication provider.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88657-PopupConfigurationInFormEngineDropped.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88657:
+
+============================================================
+Breaking: #88657 - Popup configuration in FormEngine dropped
+============================================================
+
+See :issue:`88657`
+
+Description
+===========
+
+The options :typoscript:`options.popupWindowSize` and :typoscript:`options.rte.popupWindowSize` used to configure popup sizes have been
+removed.
+
+
+Impact
+======
+
+These options are not evaluated anymore.
+
+
+Affected Installations
+======================
+
+All installations using 3rd party extensions relying on the options are affected.
+
+
+Migration
+=========
+
+In most cases it's fine to remove the configuration.
+
+In the unlikely case one is negatively affected by this change, fetch the configuration from backend user's TSConfig and
+use it where it is required.
+
+.. index:: Backend, RTE, TSConfig, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88660-GLOBALST3_VARRemoved.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88660:
+
+===========================================
+Breaking: #88660 - $GLOBALS[T3_VAR] removed
+===========================================
+
+See :issue:`88660`
+
+Description
+===========
+
+The global variable :php:`$GLOBALS['T3_VAR']` previously used to hold global state for special
+use cases - previously used within Service API via :php:`GeneralUtility::makeInstanceService()`
+and to magically inject special hard-coded local indexed search files, has been removed.
+
+The overall goal of TYPO3's application is to not keep any state within global variables, and
+the :php:`T3_VAR` ("TYPO3 Various") has not been actively used for that anymore since TYPO3 6.0, and
+has been kept only for backwards-compatibility of the existing solutions.
+
+The initialization of the global variable during TYPO3 Bootstrap, any usages of :php:`T3_VAR`,
+especially within "indexed search" has been removed.
+
+
+Impact
+======
+
+Accessing :php:`$GLOBALS['T3_VAR']` is fully custom and not evaluated by TYPO3 Core anymore.
+
+Using the variable to modify any global state for e.g. Indexed Search's indexer via
+:php:`$GLOBALS['T3_VAR']['ext']['indexed_search']['indexLocalFiles']` is not respected anymore
+and has no effect.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions or code within :file:`AdditionalConfiguration.php`
+that actively set or read values from the global variable.
+
+
+Migration
+=========
+
+Use your own custom global namespace to identify that your specific extension code has nothing
+to do with TYPO3's legacy work.
+
+Use specific hooks for indexing local files used by download extensions in conjunction with
+Indexed Search.
+
+.. index:: PHP-API, FullyScanned, ext:indexed_search

Documentation/Changelog/10.0/Breaking-88667-RemovedAdditionalJavaScriptSubmitFromFormEngine.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88667:
+
+=====================================================================
+Breaking: #88667 - Removed additionalJavaScriptSubmit from FormEngine
+=====================================================================
+
+See :issue:`88667`
+
+Description
+===========
+
+FormEngine had the feature to add additional submit handlers via the option :php:`additionalJavaScriptSubmit`, that can
+be set by form element renderables. TYPO3 uses RequireJS and a rewritten FormEngine since version 7, the property
+:php:`additionalJavaScriptSubmit` has been removed.
+
+Additional, functions of :js:`TBE_EDITOR` that are associated with that feature (namely :js:`addActionChecks`) were removed as well.
+
+
+Impact
+======
+
+The option has no effect anymore, the code won't get executed at all.
+
+
+Affected Installations
+======================
+
+All 3rd-party extensions using this option are affected.
+
+
+Migration
+=========
+
+It is possible to create and register an AMD module.
+
+.. code-block:: php
+
+   $resultArray['requireJsModules'][] = 'TYPO3/CMS/MyExtension/SubmitHandler';
+
+
+.. code-block:: javascript
+
+   // typo3conf/ext/my_extension/Resources/Public/JavaScript/SubmitHandler.js
+   define(['TYPO3/CMS/Backend/DocumentSaveActions'], function (DocumentSaveActions) {
+     DocumentSaveActions.getInstance().addPreSubmitCallback(function (e) {
+       // e is the submit event
+       // Do stuff here
+
+       // e.stopPropagation() stops the execution chain
+     });
+   });
+
+
+.. index:: Backend, JavaScript, PHP-API, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88669-FormEngineFormDataProviderParentPageTcaRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88669:
+
+======================================================================
+Breaking: #88669 - FormEngine FormDataProvider "parentPageTca" removed
+======================================================================
+
+See :issue:`88669`
+
+Description
+===========
+
+FormEngine added :php:`parentPageTca` by default to the result object. It was added in TYPO3 v7 during
+refactoring, but already commented that it wasn't used at all in Core, and might not be necessary.
+
+It contained a copy of :php:`$GLOBALS['TCA']['pages']`, which can be obtained directly as well.
+
+The DataProvider and the value within the result key has been removed.
+
+
+Impact
+======
+
+When accessing the :php:`parentPageTca` key within a FormDataProvider or Node (FormEngine-related only),
+a PHP notice is given due to a non-existing array key.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom FormDataProviders for FormEngine relying on the "parentPageTca"
+DataProvider, which is highly unlikely.
+
+
+Migration
+=========
+
+Instead of accessing :php:`$result['parentPageTca']` within a custom FormDataProvider or FormRenderNode,
+:php:`$GLOBALS['TCA']['pages']` can be accessed directly.
+
+.. index:: TCA, NotScanned

Documentation/Changelog/10.0/Breaking-88681-ImportOfPHPFilesInImportExportFilesRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88681:
+
+=====================================================================
+Breaking: #88681 - Import of PHP files in Import/Export files removed
+=====================================================================
+
+See :issue:`88681`
+
+Description
+===========
+
+Importing XML data via EXT:impexp previously allowed to import PHP files for Administrators
+in TYPO3 Backend. This by-pass functionality is removed, and the configured File Deny Pattern
+now applies for all imports in order to streamline import functionality with other file
+operations within TYPO3 Core.
+
+
+Impact
+======
+
+Importing XML files with embedded PHP files via EXT:impexp will trigger an import error and disallow
+the import of the file.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations using the data importer that use import files with included PHP files.
+
+
+Migration
+=========
+
+Ensure to include PHP files into a custom local extension, as importing PHP code is highly
+discouraged - even for administrators.
+
+.. index:: PHP-API, NotScanned, ext:impexp

Documentation/Changelog/10.0/Breaking-88687-ConfigureExtbaseRequestHandlersViaPHP.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88687:
+
+=============================================================
+Breaking: #88687 - Configure extbase request handlers via PHP
+=============================================================
+
+See :issue:`88687`
+
+Description
+===========
+
+The configuration of extbase request handlers is no longer possible via typoscript.
+All typoscript concerning the configuration of request handlers needs to be converted to php, residing
+in :file:`EXT:Configuration/Extbase/RequestHandlers.php`.
+
+
+Impact
+======
+
+Unless converted to php, the configuration in typoscript does no longer have any effect and therefore the registration
+of request handlers will no longer work.
+
+
+Affected Installations
+======================
+
+All installations that configure request handlers via typoscript.
+
+
+Migration
+=========
+
+Every extension that used typoscript for such configuration must provide a php configuration class called:
+:file:`EXT:Configuration/Extbase/RequestHandlers.php`
+
+The migration is best described by an example:
+
+.. code-block:: typoscript
+
+   config.tx_extbase {
+       mvc {
+           requestHandlers {
+               Vendor\Extension\Mvc\Web\FrontendRequestHandler = Vendor\Extension\Mvc\Web\FrontendRequestHandler
+           }
+       }
+   }
+
+This configuration will look like this, defined in php:
+
+.. code-block:: php
+
+   <?php
+   declare(strict_types = 1);
+
+   return [
+       \Vendor\Extension\Mvc\Web\FrontendRequestHandler::class,
+   ];
+
+.. warning::
+
+   With typoscript it was possible to override request handlers, registered by extensions loaded before the current one.
+   This also included core extensions. This approach has been bad practice because suitable request handlers are chosen
+   by their ability to handle a request and their priority. The evaluation of priorities could have been bypassed by
+   overriding keys of the configuration. This is no longer possible as request handler configuration files can only
+   add possible request handlers. Hence the omitted keys in the configuration array.
+
+.. index:: TypoScript, NotScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-88706-StreamlineFeloginLocallangKeys.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88706:
+
+====================================================
+Breaking: #88706 - Streamline felogin locallang keys
+====================================================
+
+See :issue:`88706`
+
+Description
+===========
+
+Remove  `ll_` prefixes from translation keys in :file:`ext:felogin/Resources/private/Language/locallang.xlf` so that they share the same identifiers with the flexform settings.
+
+
+Impact
+======
+
+Breaks installations that override ext:felogin language keys that are prefixed with `ll_`.
+
+
+Affected Installations
+======================
+
+Only installations that override one of the following keys via TypoScript are affected.
+
+Keys:
+
+- `ll_welcome_header`
+- `ll_welcome_message`
+- `ll_logout_header`
+- `ll_logout_message`
+- `ll_error_header`
+- `ll_error_message`
+- `ll_success_header`
+- `ll_success_message`
+- `ll_status_header`
+- `ll_status_message`
+- `ll_change_password_header`
+- `ll_change_password_message`
+- `ll_change_password_nolinkprefix_message`
+- `ll_change_password_notvalid_message`
+- `ll_change_password_notequal_message`
+- `ll_change_password_tooshort_message`
+- `ll_change_password_done_message`
+- `ll_forgot_header`
+- `ll_forgot_email_password`
+- `ll_forgot_email_nopassword`
+- `ll_forgot_validate_reset_password`
+- `ll_forgot_message`
+- `ll_forgot_message_emailSent`
+- `ll_forgot_reset_message`
+- `ll_forgot_reset_message_emailSent`
+- `ll_forgot_reset_message_error`
+- `ll_forgot_header_backToLogin`
+- `ll_enter_your_data`
+
+
+Migration
+=========
+
+Remove the `ll_` prefix from the key.
+
+.. index:: Frontend, NotScanned, ext:felogin

Documentation/Changelog/10.0/Breaking-88724-RemoveSuperfluousMethodsOfLocalizationRedirect.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88724:
+
+=====================================================================
+Breaking: #88724 - Remove superfluous methods of localizationRedirect
+=====================================================================
+
+See :issue:`88724`
+
+Description
+===========
+
+The method :php:`localizationRedirect` in PageLayoutView, DatabaseRecordList and EditDocumentController were almost equal.
+The usage has been streamlined and the methods in PageLayoutView and DatabaseRecordList have been removed.
+
+
+Impact
+======
+
+Calling the routes `web_layout` or `web_list` with parameter `justLocalized` will not redirect to the translated record anymore.
+Calling :php:`TYPO3\CMS\Backend\View\PageLayoutView->localizationRedirect` or :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList->localizationRedirect`
+will result in a fatal :php:`E_ERROR`.
+
+
+Migration
+=========
+
+Use route `record_edit` instead of `web_layout` or `web_list`. Set as additional parameter `returnUrl` to the url to the certain module.
+Use :php:`TYPO3\CMS\Backend\Controller\EditDocumentController->localizationRedirect` instead of
+:php:`TYPO3\CMS\Backend\View\PageLayoutView->localizationRedirect` or :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88741-CHashCalculationInIndexedSearchRemoved.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88741:
+
+==============================================================
+Breaking: #88741 - cHash calculation in indexed search removed
+==============================================================
+
+See :issue:`88741`
+
+Description
+===========
+
+When indexing a page, the indexer of `Indexed search` previously kept the used cHash and the
+used "cHashParams" for storing search entries. This is not necessary anymore, as Site Handling now
+contains the relevant arguments already in the search entry as well. This can be removed now.
+
+In addition, when setting up an Indexing configuration, the option to respect cHash is removed,
+as this is done automatically when needed.
+
+The public property :php:`TYPO3\CMS\IndexedSearch\Indexer->cHashParams` has been removed.
+
+The sixth method argument of :php:`TYPO3\CMS\IndexedSearch\Indexer->backend_initIndexer()`
+has been removed.
+
+The following database fields are unused and have been removed:
+
+* :sql:`index_config.chashcalc`
+* :sql:`index_phash.cHashParams`
+
+The database field :sql:`index_debug.debuginfo` now contains data stored in a JSON-formatted string
+instead of a serialized PHP string.
+
+
+Impact
+======
+
+Manual database queries accessing the database fields will result in SQL errors.
+
+In addition, accessing the removed property or using the sixth argument of the changed public method
+will have no effect anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using Indexed Search and custom configuration or extending functionality
+of Indexed Search.
+
+
+Migration
+=========
+
+No migration needed, as everything works as before. The data is now stored in
+the database field as JSON-encoded string `index_phash.static_page_arguments`.
+
+In case of using debug information for Indexed Search (index with enabled debug information),
+where data was previously stored in `index_debug.debuginfo` as serialized PHP string,
+indexing needs to be rebuilt, but only to render the debug information properly in the TYPO3 Backend
+module. If debug information is not enabled, re-indexing is not necessary.
+
+.. index:: Database, PHP-API, PartiallyScanned, ext:indexed_search

Documentation/Changelog/10.0/Breaking-88744-DatabaseFieldsRelatedToCSSStyledContentRemoved.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88744:
+
+========================================================================
+Breaking: #88744 - Database fields related to CSS Styled Content removed
+========================================================================
+
+See :issue:`88744`
+
+Description
+===========
+
+CSS Styled Content was superseded with Fluid Styled Content in TYPO3 v7, and support was dropped
+with TYPO3 v9. TYPO3 Core still shipped with some database fields that were kept to easy
+manual migration for specific values in these fields.
+
+These database fields within the database table :sql:`tt_content` have been removed.
+
+* :sql:`tt_content.spaceBefore` (now used via space_before_class)
+* :sql:`tt_content.spaceAfter` (now used via space_after_class)
+
+
+Impact
+======
+
+Accessing the database fields with a custom SQL query will result in SQL errors or empty values.
+
+
+Affected Installations
+======================
+
+TYPO3 installations from earlier TYPO3 versions (prior to v8) that still have CSS Styled Content
+in use or adopted to migrate the fields to still render via CSS Styled Content.
+
+Additionally, TYPO3 installations that mis-used the database fields for other purposes but
+still rely on the presence of the database fields.
+
+
+Migration
+=========
+
+If the database fields still contain value that hasn't been migrated, it is possible to re-add
+these database fields in a custom extension.
+
+It is recommended to switch to Fluid Styled Content rendering or custom content types with
+custom additional fields.
+
+.. index:: Database, Frontend, NotScanned, ext:frontend

Documentation/Changelog/10.0/Breaking-88755-RemovePOSTOptionFromTypolinkaddQueryStringmethod.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88755:
+
+=========================================================================
+Breaking: #88755 - Remove POST option from typolink.addQueryString.method
+=========================================================================
+
+See :issue:`88755`
+
+Description
+===========
+
+Setting :typoscript:`addQueryString.method` of typolink could be used like shown below in order to transform
+HTTP POST parameters into according GET parameters.
+
+.. code-block:: typoscript
+
+   typolink {
+     parameter = 123
+     addQueryString = 1
+     addQueryString.method = POST
+   }
+
+In terms of correctly using HTTP verbs it's bad practise in general to treat GET and POST equally, besides that
+documentation already mentioned potential side-effects like accidentally exposing sensitive data submitted via
+POST to proxies or log files.
+
+That's why values :typoscript:`POST`, :typoscript:`GET,POST` and :typoscript:`POST,GET` are not allowed anymore
+for :typoscript:`typolink.addQueryString.method`. Maintaining functionality - if required at all - has to be done
+using domain specific logic in according controllers or middleware implementations.
+
+
+Impact
+======
+
+* using :typoscript:`GET,POST`, :typoscript:`POST,GET` or :typoscript:`POST` will trigger an :php:`E_USER_WARNING`
+* using :typoscript:`GET,POST` or :typoscript:`POST,GET` will fall back to :typoscript:`GET`
+* using :typoscript:`POST` will be ignored and an empty result
+
+In a consequence only query parameters submitted via HTTP GET are taken into account, parameters of HTTP POST
+body are ignored.
+
+
+Affected Installations
+======================
+
+* TypoScript defining :typoscript:`typolink.addQueryString.method` with values mentioned in previous section
+* invocations of :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryStringMethod()` with values
+  mentioned in previous section
+* as an effect Fluid view helpers forwarding this information to
+  :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryStringMethod()` are affected -
+  argument :php:`addQueryStringMethod` is affected in view helper of TYPO3 core like shown below
+  + :html:`<f:form ... addQueryStringMethod="POST">`
+  + :html:`<f:link.action addQueryStringMethod="POST">`
+  + :html:`<f:link.page ... addQueryStringMethod="POST">`
+  + :html:`<f:link.typolink addQueryStringMethod="POST">`
+  + :html:`<f:uri.action ... addQueryStringMethod="POST">`
+  + :html:`<f:uri.page ... addQueryStringMethod="POST">`
+  + :html:`<f:uri.typolink addQueryStringMethod="POST">`
+  + :html:`<f:widget.uri ... addQueryStringMethod="POST">`
+  + :html:`<f:widget.link addQueryStringMethod="POST">`
+  + :html:`<f:widget.paginate ... configuration="{addQueryStringMethod: 'POST'}">`
+
+
+Migration
+=========
+
+* change to mentioned assignments in TypoScript, Fluid templates or PHP code to :typoscript:`GET`
+* analyse and try to understand whether :typoscript:`POST` is still required or could be substituted
+
+
+.. index:: Backend, Fluid, Frontend, PHP-API, TypoScript, NotScanned

Documentation/Changelog/10.0/Breaking-88758-SelectiveConcatenationOfCSSFilesInResourceCompressorRemoved.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88758:
+
+=====================================================================================
+Breaking: #88758 - Selective Concatenation of CSS files in ResourceCompressor removed
+=====================================================================================
+
+See :issue:`88758`
+
+Description
+===========
+
+:php:`TYPO3\CMS\Core\Resource\ResourceCompressor`, used to merge and compress CSS and JS files, has had an option to only
+merge CSS files from selected folders. This was used to limit CSS files of skins for TYPO3
+Backend files.
+
+The functionality has been removed, as all added CSS files are now merged into one file.
+
+As TYPO3 Frontend and TypoScript has a much more flexible system for adding CSS files,
+which should be concatenated, this change does not affect TYPO3 API of Frontend Requests.
+
+
+Impact
+======
+
+Calling :php:`TYPO3\CMS\Core\Resource\ResourceCompressor->concatenateCssFiles()` with a second argument has no effect anymore.
+
+Adding CSS files manually in TYPO3 Backend via custom extensions will now automatically be merged
+with the loaded CSS styles of :php:`$TBE_STYLES` skin.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions adding third-party CSS files in the TYPO3 Backend,
+or extensions using :php:`TYPO3\CMS\Core\Resource\ResourceCompressor` directly.
+
+
+Migration
+=========
+
+None, as it is considered to be useful to have one larger CSS file for TYPO3 Backend.
+
+If necessary, add a CSS file manually via PageRenderer API which should be excluded from Concatenation.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Breaking-88772-JavaScriptScriptTagsOmitTypetextjavascriptInHTML5.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88772:
+
+============================================================================
+Breaking: #88772 - JavaScript script tags omit type=text/javascript in HTML5
+============================================================================
+
+See :issue:`88772`
+
+Description
+===========
+
+When rendering HTML5 output, :html:`<script>` tags do not the additional attribute :html:`type=text/javascript`
+anymore as it is considered optional, and if none given, modern browsers fall back to this type
+already.
+
+See the official W3C definition here: https://www.w3.org/TR/html52/semantics-scripting.html#element-attrdef-script-type
+
+For this reason, all of TYPO3's Backend (which is rendering HTML5) and Installer do not include
+this optional attribute in :html:`<script>` tags anymore.
+
+For TYPO3 Frontend rendering, the attribute is omitted when having no doctype or HTML5 as doctype
+configured (via TypoScript :typoscript:`config.doctype = html5`). This leads to a minimal smaller
+HTML document submitted to the client.
+
+For any XHTML or HTML4-based website, the attribute is still added.
+
+
+Impact
+======
+
+TYPO3's Frontend rendering does not render :html:`type=text/javascript` anymore in :html:`<script>` tags when
+rendering a HTML5 output, unless explicitly specified.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation running a HTML5-based frontend output.
+
+
+Migration
+=========
+
+As all modern browsers do not need this tag, and the specification says it's optional, there is
+no migration needed at all.
+
+If still requested by a specific project, it can be added via:
+
+.. code-block:: javascript
+
+   page.includeJS.myfile = EXT:site_mysite/Resources/Public/JavaScript/myfile.js
+   page.includeJS.myfile.type = text/javascript
+
+.. index:: Frontend, TypoScript, NotScanned

Documentation/Changelog/10.0/Breaking-88779-RecordListRemoveUnusedCode.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88779:
+
+=================================================
+Breaking: #88779 - RecordList: Remove unused code
+=================================================
+
+See :issue:`88779`
+
+Description
+===========
+
+The following public properties have been removed from :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`:
+
+* :php:`modSharedTSconfig`
+* :php:`no_noWrap`
+* :php:`setLMargin`
+* :php:`JScode`
+* :php:`leftMargin`
+
+The following public methods have been removed from :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`:
+
+* :php:`getButtons`
+* :php:`thumbCode`
+* :php:`requestUri`
+* :php:`writeTop`
+* :php:`fwd_rwd_nav`
+* :php:`fwd_rwd_HTML`
+
+
+Impact
+======
+
+Calling one of the mentioned methods will trigger a fatal :php:`E_ERROR`.
+
+
+Migration
+=========
+
+Use :php:`BackendUtility::thumbCode` instead of :php:`thumbCode`. Use :php:`listURL` instead of :php:`requestUri`.
+
+.. index:: PHP-API, FullyScanned, ext:recordlist

Documentation/Changelog/10.0/Breaking-88799-IntroducedPSR-3CompatibleLoggingAPI.rst

@@ -0,0 +1,80 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88799:
+
+==========================================================
+Breaking: #88799 - Introduced PSR-3 compatible Logging API
+==========================================================
+
+See :issue:`88799`
+
+Description
+===========
+
+With the adaption of the PSR-3 standard some PHP code had to be changed in order to reach compliance.
+The key difference is that log levels are now represented by strings rather than numbers. Note that the order
+of log levels is not affected and stays the same.
+
+The breaking changes mostly affect internal functionality and should not apply to third-party extensions.
+
+
+Impact
+======
+
+The class :php:`\TYPO3\CMS\Core\Log\LogLevel` now extends from the PSR-3 base class and therefore inherits the new definition
+of the log levels (`EMERGENCY` to `DEBUG`) based on string values.
+
+The signatures of following methods have been adjusted to accept the new :php:`LogLevel::*` constants:
+
+* :php:`\TYPO3\CMS\Core\Log\Logger::addWriter`
+* :php:`\TYPO3\CMS\Core\Log\Logger::addProcessor`
+
+The internal storage of the log level inside :php:`\TYPO3\CMS\Core\Log\LogRecord` has been adjusted, consequently the methods
+
+* :php:`setLevel()` and
+* :php:`getLevel()`
+
+respectively accept and return :php:`string` values now.
+
+In case you have configured own logger or log targets, you have to adjust the integer level and use strings.
+
+Example:
+
+.. code-block:: php
+
+   # old configuration
+   $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['writerConfiguration'] = [
+      7 => [
+         \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
+            'logFile' => 'typo3temp/var/log/core.log'
+         ]
+      ],
+   ];
+
+   # new configuration
+   $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['writerConfiguration'] = [
+      'debug' => [
+         \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
+            'logFile' => 'typo3temp/var/log/core.log'
+         ]
+      ],
+   ];
+
+In case you have used the constants like :php:`LogLevel::DEBUG` you are fine and your config will work like before.
+
+
+Affected Installations
+======================
+
+Any installation using third-party extensions interacting with the internals of the Logging API.
+
+
+Migration
+=========
+
+There are two easy ways to convert the integer to the string representation and vice versa:
+
+- Convert from integer to string: :php:`$logLevel = LogLevel::getInternalName($logLevelAsNumber)`
+- Convert from string to integer: :php:`$logLevelAsNumber = LogLevel::normalizeLevel($logLevel)`
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/10.0/Deprecation-80420-EmailFinisherSingleAddressOptions.rst

@@ -0,0 +1,157 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-80420:
+
+==========================================================
+Deprecation: #80420 - EmailFinisher single address options
+==========================================================
+
+See :issue:`80420`
+
+Description
+===========
+
+The :php:`EmailFinisher` of EXT:form has options to set multiple recipients for :code:`To`, :code:`CC` and :code:`BCC`.
+For consistency reasons and to limit the number of choices, resulting in easier configuration, the single value configuration options
+have will be removed in favour for their respective multi value variants.
+
+For this reason, the following options have been marked as deprecated and will be removed in TYPO3 11.0:
+
+* :yaml:`recipientAddress`
+* :yaml:`recipientName`
+* :yaml:`replyToAddress`
+* :yaml:`carbonCopyAddress`
+* :yaml:`blindCarbonCopyAddress`
+
+If any of these options are used, their values will be automatically migrated to their replacements.
+
+Opening and saving a form with the form editor once also performs this migration and makes it permanent.
+
+
+Impact
+======
+
+Any of these options will no longer work in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and its :php:`EmailFinisher`.
+
+
+Migration
+=========
+
+All single value options must be migrated to their list value successors.
+
+
+Multiple Recipients
+-------------------
+
+Change :yaml:`recipientAddress` and :yaml:`recipientName` to :yaml:`recipients`.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         recipientAddress: to@example.org
+         recipientName: 'To Example'
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         recipients:
+           to@example.org: 'To Example'
+
+
+Multiple Reply-To Recipients
+----------------------------
+
+Change :yaml:`replyToAddress` to :yaml:`replyToRecipients`. Additionally this allows for setting the name of a Reply-To recipient.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         replyToAddress: rt@example.org
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         replyToRecipients:
+           rt@example.org@example.org: 'Reply-To Example'
+
+
+Multiple Carbon Copy (CC) Recipients
+------------------------------------
+
+Change :yaml:`carbonCopyAddress` to :yaml:`carbonCopyRecipients`. Additionally this allows for setting the name of a CC recipient.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         carbonCopyAddress: cc@example.org
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         carbonCopyRecipients:
+           cc@example.org: 'CC Example'
+
+
+Multiple Blind Carbon Copy (BCC) Recipients
+-------------------------------------------
+
+Change :yaml:`blindCarbonCopyAddress` to :yaml:`blindCarbonCopyRecipients`. Additionally this allows for setting the name of a BCC recipient.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         blindCarbonCopyAddress: bcc@example.org
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         blindCarbonCopyRecipients:
+           bcc@example.org: 'BCC Example'
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/10.0/Deprecation-82669-StreamlineBackendRoutePathInconsistencies.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-82669:
+
+===================================================================
+Deprecation: #82669 - Streamline Backend route path inconsistencies
+===================================================================
+
+See :issue:`82669`
+
+Description
+===========
+
+When registering Backend modules, it is already possible to define a custom route path, via the :php:`path`
+option in the module configuration section within :file:`ext_tables.php`.
+
+Backend Routes to modules without path configurations are now named using the pattern
+"/module/<main-module-name>/<submodule-name>" e.g. `/module/web/ts`.
+
+Old route paths for modules are called "/web/ts/" will still work but are discouraged to use.
+
+
+Impact
+======
+
+Creating modules without a defined "path" option will now have two path routes available to be
+resolved, whereas the old path will be removed in TYPO3 v10.0.
+
+
+Affected Installations
+======================
+
+Any installation using TYPO3 Backend Links via :php:`TYPO3\CMS\Backend\Routing\UriBuilder->buildUriFromRoutePath()` in custom extensions.
+
+
+Migration
+=========
+
+TYPO3 Backend Links via :php:`TYPO3\CMS\Backend\Routing\UriBuilder->buildUriFromRoutePath()` should be used with the new module name as
+described above.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-85895-DeprecateFile_getMetaData.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85895:
+
+====================================================
+Deprecation: #85895 - Deprecate File::_getMetaData()
+====================================================
+
+See :issue:`85895`
+
+Description
+===========
+
+The internal method :php:`TYPO3\CMS\Core\Resource\File::_getMetaData()` which is used to fetch meta data of a file
+has been marked as deprecated. This method has been superseded by the :php:`TYPO3\CMS\Core\Resource\MetaDataAspect`.
+
+
+Impact
+======
+
+Using this method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any 3rd party extension calling :php:`:php:`TYPO3\CMS\Core\Resource\File::_getMetaData()` is affected.
+
+
+Migration
+=========
+
+To fetch the meta data, call :php:`$fileObject->getMetaData()->get()` instead.
+
+.. index:: FAL, PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-87200-EmailFinisherFormatContants.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87200-1668719172:
+
+======================================================
+Deprecation: #87200 - EmailFinisher FORMAT_* constants
+======================================================
+
+See :issue:`87200`
+
+Description
+===========
+
+The constants
+
+* :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::FORMAT_PLAINTEXT` and
+* :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::FORMAT_HTML`
+
+have been marked as deprecated and will be removed in TYPO3 11.0.
+
+
+Impact
+======
+
+Accessing these constants will lead to a fatal :php:`E_ERROR` in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and directly access these constants.
+
+
+Migration
+=========
+
+Do not use these constants anymore.
+
+.. index:: PHP-API, FullyScanned, ext:form

Documentation/Changelog/10.0/Deprecation-87200-EmailFinisherFormatOption.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87200:
+
+===================================================
+Deprecation: #87200 - EmailFinisher "format" option
+===================================================
+
+See :issue:`87200`
+
+Description
+===========
+
+The :yaml:`format` option of the :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher` has been marked as deprecated and
+will be removed in TYPO3 11.0. It is replaced by the new :yaml:`addHtmlPart` option which can be used to disable HTML
+and enforce plaintext-only mails. If set, mails will contain a plaintext and HTML part, otherwise only a plaintext part.
+
+If the :yaml:`format` option is used, its value will be automatically migrated to :yaml:`addHtmlPart`:
+
+* :yaml:`format: html` becomes :yaml:`addHtmlPart: true`
+* :yaml:`format: plaintext` becomes :yaml:`addHtmlPart: false`
+* a missing :yaml:`format` becomes :yaml:`addHtmlPart: true`
+
+Opening and saving a form with the form editor once also performs this migration and makes it permanent.
+
+
+Impact
+======
+
+The :yaml:`format` option will no longer work in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and its :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher`.
+
+
+Migration
+=========
+
+Replace :yaml:`format: html` with :yaml:`addHtmlPart: true`.
+
+Replace :yaml:`format: plaintext` with :yaml:`addHtmlPart: false`.
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/10.0/Deprecation-87305-UseConstructorInjectionInDataMapper.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87305:
+
+=============================================================
+Deprecation: #87305 - Use constructor injection in DataMapper
+=============================================================
+
+See :issue:`87305`
+
+Description
+===========
+
+The 8th argument (:php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface`) of method
+:php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper->__construct` has been marked as deprecated.
+
+
+Impact
+======
+
+Instantiating objects along with that argument will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that create instances of the class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper` while providing the 8th argument.
+
+
+Migration
+=========
+
+Instantiate the object without the 8th argument and use :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper->setQuery` if needed.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87332-AvoidRuntimeReflectionCallsInObjectAccess.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87332:
+
+====================================================================
+Deprecation: #87332 - Avoid runtime reflection calls in ObjectAccess
+====================================================================
+
+See :issue:`87332`
+
+Description
+===========
+
+Class :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess` uses reflection to make non public properties gettable and settable.
+This behaviour is triggered by setting the argument :php:`$forceDirectAccess` of methods
+
+* :php:`getProperty`
+* :php:`getPropertyInternal`
+* :php:`setProperty`
+
+to :php:`true`. Triggering this behaviour has been marked as deprecated and will be removed in TYPO3 11.0.
+
+Method :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName` has been marked as deprecated and will be removed in TYPO3 11.0.
+
+
+Impact
+======
+
+1) Accessing non public properties via the mentioned methods will no longer work in TYPO3 11.0.
+
+2) Calling :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName` will no longer work in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+1) All installations that use the mentioned methods with argument :php:`$forceDirectAccess` set to :php:`true`.
+
+2) All installations that call :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName`.
+
+
+Migration
+=========
+
+1) Make sure the affected property is accessible by either making it public or providing getters/hassers/issers or setters
+(:php:`getProperty()`, :php:`hasProperty()`, :php:`isProperty()`, :php:`setProperty()`).
+
+2) Build setter names manually: :php:`$setterMethodName = 'set' . ucfirst($propertyName);`
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87550-UseControllerClassesWhenRegisteringPluginsmodules.rst

@@ -0,0 +1,92 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87550:
+
+=============================================================================
+Deprecation: #87550 - Use controller classes when registering plugins/modules
+=============================================================================
+
+See :issue:`87550`
+
+Description
+===========
+
+Configuring plugins and modules via the following methods has changed in two important ways.
+
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin`
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule`
+
+Both methods expect you to provide the argument :php:`$extensionName` and :php:`$controllerActions`.
+:php:`configurePlugin` also allows the argument :php:`$nonCacheableControllerActions`.
+
+The first important change targets the :php:`$extensionName` argument.
+During the switch from underscore class names :php:`Tx_Extbase_Foo_Bar` to actual namespaced classes
+:php:`TYPO3\CMS\Extbase\Foo\Bar`, a vendor `TYPO3\CMS` has been introduced which had to be respected
+during the configuration of plugins. To make that possible the argument :php:`$extensionName` has been
+prepended with the vendor name, concatenated with dots.
+
+.. code-block:: php
+
+   <?php
+
+   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
+       'TYPO3.CMS.Form', // $extensionName
+       'Formframework',
+       ['FormFrontend' => 'render, perform'],
+       ['FormFrontend' => 'perform'],
+       \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT
+   );
+
+Setting the vendor name is now deprecated and must be omitted. Instead, the vendor name will be derived
+from the controller class namespace, which leads to the second important change.
+
+Both arguments :php:`$controllerActions` and :php:`$nonCacheableControllerActions` used controller aliases as
+array keys. The alias was the controller class name without the namespace and without the :php:`Controller`
+suffix. There were a lot of conventions and a custom autoloader mechanism before the introduction
+of the composer autoloader, which made it necessary to put controllers in a specific directory and to name
+the controller accordingly. As this is no longer the case, there is no need to guess the controller class name
+any longer. Instead, the configuration/registration is now done with fully qualified controller class names.
+
+.. code-block:: php
+
+   <?php
+
+   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
+       'Form',
+       'Formframework',
+       [\TYPO3\CMS\Form\Controller\FormFrontendController::class => 'render, perform'],
+       [\TYPO3\CMS\Form\Controller\FormFrontendController::class => 'perform'],
+       \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT
+   );
+
+Conclusion
+==========
+
+The following things have been marked as deprecated:
+
+* Prepend the :php:`$extensionName` argument with a vendor name.
+* Using controller aliases as array keys in both arguments :php:`$controllerActions` and :php:`$nonCacheableControllerActions`.
+
+
+Impact
+======
+
+Using the deprecated syntax will trigger PHP :php:`E_USER_DEPRECATED` errors and will stop working in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations that use these methods:
+
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin`
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule`
+
+
+Migration
+=========
+
+* Omit the vendor name in argument :php:`$extensionName`
+* Use fully qualified class names as array keys in arguments :php:`$controllerActions` and :php:`$nonCacheableControllerActions`
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87613-DeprecateTYPO3CMSExtbaseUtilityTypeHandlingUtilityhex2bin.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87613:
+
+============================================================================================
+Deprecation: #87613 - Deprecate \\TYPO3\\CMS\\Extbase\\Utility\\TypeHandlingUtility::hex2bin
+============================================================================================
+
+See :issue:`87613`
+
+Description
+===========
+
+:php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin` has been marked as deprecated and will be removed in TYPO3 11.0.
+
+
+Impact
+======
+
+Calling :php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin` will trigger PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that call :php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin`.
+
+
+Migration
+=========
+
+Use the native php function :php:`hex2bin` instead.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87882-FileRelatedControllersMovedToEXTfilelist.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87882:
+
+====================================================================
+Deprecation: #87882 - File related controllers moved to EXT:filelist
+====================================================================
+
+See :issue:`87882`
+
+Description
+===========
+
+The following controllers have been moved to extension `filelist` as they are part of
+the filelist feature set:
+
+* :php:`CreateFolderController`
+* :php:`EditFileController`
+* :php:`FileUploadController`
+* :php:`RenameFileController`
+* :php:`ReplaceFileController`
+
+
+Impact
+======
+
+The namespace changed from :php:`TYPO3\CMS\Backend\Controller\File` to :php:`TYPO3\CMS\Filelist\Controller\File`. Using
+the old controllers will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Installations accessing any of the above controllers.
+
+
+Migration
+=========
+
+When wanting to use any of the functionality in these controllers, you should build your own controllers as they are
+internal and might change at any time. Use the TYPO3 file abstraction layer as API and add your own functionality on top
+of it with an own controller instead of reusing these.
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:filelist

Documentation/Changelog/10.0/Deprecation-87894-GeneralUtilityidnaEncode.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87894:
+
+================================================
+Deprecation: #87894 - GeneralUtility::idnaEncode
+================================================
+
+See :issue:`87894`
+
+Description
+===========
+
+PHP has the native function :php:`idn_to_ascii($domain, IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46)` for converting UTF-8 based domains to ascii-based ("punicode")
+which is available in all supported PHP versions using :php:`"symfony/polyfill-intl-idn"`.
+
+For this reason the method :php:`GeneralUtility::idnaEncode()` has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`GeneralUtility::idnaEncode()` directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extensions calling this method.
+
+
+Migration
+=========
+
+Use :php:`idn_to_ascii($domain, IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46);` instead.
+
+Please be aware that contrary to :php:`GeneralUtility::idnaEncode()` the native PHP function only works on domain names, not email addresses or
+similar. In order to encode email addresses split the address at the last :php:`'@'` and use :php:`idn_to_ascii()` on that last part.
+Also, if there is an error in converting a string, a bool :php:`false` is returned.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88366-DefaultCachingFrameworkCacheNamesChanged.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88366:
+
+===================================================================
+Deprecation: #88366 - Default caching framework cache names changed
+===================================================================
+
+See :issue:`88366`
+
+Description
+===========
+
+TYPO3's internal Caching Framework has several caches already shipped with TYPO3 Core.
+
+The caches have been renamed for convenience and for newcomers to overcome another "speciality"
+of TYPO3 which was due to legacy and integration reasons back in TYPO3 4.3 when the Caching
+Framework was introduced.
+
+The following caches have been renamed:
+
+* `cache_core` => `core`
+* `cache_hash` => `hash`
+* `cache_pages` => `pages`
+* `cache_pagesection` => `pagesection`
+* `cache_runtime` => `runtime`
+* `cache_rootline` => `rootline`
+* `cache_imagesizes` => `imagesizes`
+
+The caches should now be accessed via :php:`$cacheManager->getCache('core')` instead of
+:php:`$cacheManager->getCache('cache_core')` - without the ``cache_`` prefix.
+
+In addition, when the DatabaseBackend cache is used, the database tables do not have the :sql:`cf_`
+prefix anymore, making it clearer for integrators and developers what the caches mean.
+
+
+Impact
+======
+
+When accessing the cache with a "cache" prefix, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+
+
+Affected Installations
+======================
+
+Any TYPO3 extension using the caching framework with the ``cache_`` prefix.
+
+
+Migration
+=========
+
+Remove the ``cache_`` prefix from the callers code.
+
+In addition, run through the Database Table Analyzer of the Configuration module to
+re-create any database tables of the Caching Framework.
+
+.. index:: Database, LocalConfiguration, NotScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88406-SetCacheHashnoCacheHashOptionsInViewHelpersAndUriBuilder.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88406:
+
+====================================================================================
+Deprecation: #88406 - setCacheHash/noCacheHash options in ViewHelpers and UriBuilder
+====================================================================================
+
+See :issue:`88406`
+
+Description
+===========
+
+Various Fluid ViewHelpers regarding linking have arguments similar to:
+
+* :php:`useCacheHash`
+* :php:`noCacheHash`
+
+which are not evaluated anymore.
+
+Extbase's UriBuilder has the following options that have no effect anymore since the Site
+Handling concept automatically detects when to a cHash argument is necessary:
+
+* :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->setUseCacheHash()`
+* :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->getUseCacheHash()`
+
+Impact
+======
+
+Calling the UriBuilder methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Using the arguments :php:`noCacheHash`/:php:`useCacheHash` in the following ViewHelpers will
+trigger a PHP :php:`E_USER_DEPRECATED` error:
+
+* :html:`f:form`
+* :html:`f:link.action`
+* :html:`f:link.page`
+* :html:`f:link.typolink`
+* :html:`f:uri.action`
+* :html:`f:uri.page`
+* :html:`f:uri.typolink`
+* :html:`f:widget.link`
+* :html:`f:widget.uri`
+
+If the underlying TypoLink logic is accessed directly, it will trigger a PHP :php:`E_USER_DEPRECATED` error
+if :typoscript:`.useCacheHash` is set - without any effect either.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with custom templates setting this argument in Fluid or extensions
+using Extbase's UriBuilder in a custom fashion.
+
+
+Migration
+=========
+
+Remove any usages within the Fluid templates or Extension code.
+
+.. index:: Fluid, PHP-API, TypoScript, PartiallyScanned

Documentation/Changelog/10.0/Deprecation-88428-ToprawurlencodeAndTopstr_replace.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88428:
+
+==========================================================
+Deprecation: #88428 - top.rawurlencode and top.str_replace
+==========================================================
+
+See :issue:`88428`
+
+Description
+===========
+
+The global JavaScript functions :js:`top.rawurlencode()` and :js:`top.str_replace()` have been marked as deprecated.
+
+
+Impact
+======
+
+Calling any of these two functions will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All installations using third party extensions with these functions are affected.
+
+
+Migration
+=========
+
+For :js:`top.rawurlencode()` it's safe to use native JavaScript function :js:`encodeURIComponent()` instead. The only
+difference is that this function does not escape asterisk characters, which may be additionally achieved via
+:js:`encodeURIComponent('*my_string*').replace(/\*/g, '%2A')`.
+
+For :js:`top.str_replace()` consider using JavaScript's string function `.replace()` instead.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88432-ReplacedMd5jsWithAnAMDModule.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88432:
+
+========================================================
+Deprecation: #88432 - Replaced md5.js with an AMD module
+========================================================
+
+See :issue:`88432`
+
+Description
+===========
+
+The file :file:`md5.js` used to generate a MD5 hash in JavaScript has been marked as deprecated and replaced by an AMD module
+:js:`TYPO3/CMS/Backend/Hashing/Md5`.
+
+
+Impact
+======
+
+Using the global function `MD5()` will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All installations using third party extensions that use :js:`MD5()` of :file:`md5.js` are affected.
+
+
+Migration
+=========
+
+Load the AMD module :js:`TYPO3/CMS/Backend/Hashing/Md5` via RequireJS as `Md5` and call :js:`Md5.hash()` instead.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88433-DeprecateTopopenUrlInWindow.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88433:
+
+===================================================
+Deprecation: #88433 - Deprecate top.openUrlInWindow
+===================================================
+
+See :issue:`88433`
+
+Description
+===========
+
+The global JavaScript function :js:`top.openUrlInWindow()` has been marked as deprecated. This method was used to open
+links in a full size popup.
+
+
+Impact
+======
+
+Calling this function will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All installations using third party extensions that use :js:`top.openUrlInWindow()` are affected.
+
+
+Migration
+=========
+
+Instead of using this method, consider using plain HTML and open the link in a new tab:
+:html:`<a href="/path/to/my/document", target="_blank">Linked content</a>`
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88473-TypoScriptFrontendController-settingLocale.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88473:
+
+=================================================================
+Deprecation: #88473 - TypoScriptFrontendController->settingLocale
+=================================================================
+
+See :issue:`88473`
+
+Description
+===========
+
+Due to Site Handling, setting the locale information (:php:`setlocale`) can be handled
+much earlier without any dependencies on the global :php:`TSFE` object.
+
+The functionality of the method :php:`TypoScriptFrontendController->settingLocale()` has
+been moved into :php:`Locales::setSystemLocaleFromSiteLanguage()`. The former method
+has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`TypoScriptFrontendController->settingLocale()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third party extension booting up a custom Frontend system and
+explicitly calling the method.
+
+
+Migration
+=========
+
+Migrate the existing PHP code to :php:`Locales::setSystemLocaleFromSiteLanguage()` or ensure
+that the SiteResolver middleware for Frontend Requests is executed where the locale is now
+set automatically.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88499-BackendUtilitygetViewDomain.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88499:
+
+===================================================
+Deprecation: #88499 - BackendUtility::getViewDomain
+===================================================
+
+See :issue:`88499`
+
+Description
+===========
+
+The static method :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getViewDomain()` has been marked
+as deprecated, as it has been superseded by directly using the PageRouter of Site Handling.
+
+Site Handling allows to generate proper frontend preview URLs the same way as TYPO3 Core does in
+all other places, by calling the PageRouter of a Site object directly, so the workarounds are not
+necessary anymore, making this method obsolete.
+
+
+Impact
+======
+
+Calling :php:`BackendUtility::getViewDomain()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations with custom extensions that call this method.
+
+
+Migration
+=========
+
+Substitute the method by directly detecting a site based on a given Page ID in the TYPO3 Backend.
+Call the :php:`getRouter()` method on this Site object to create proper links to pages in TYPO3 Frontend.
+
+Example with additional GET parameters:
+
+.. code-block:: php
+
+    $site = GeneralUtility::makeInstance(SiteFinder::class)->getSiteByPageId($pageId);
+    $url = $site->getRouter()->generateUri($pageId, ['type' => 13]);
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88554-DeprecatedMethodsInVersionNumberUtility.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88554:
+
+================================================================
+Deprecation: #88554 - Deprecated methods in VersionNumberUtility
+================================================================
+
+See :issue:`88554`
+
+Description
+===========
+
+The following methods of :php:`\TYPO3\CMS\Core\Utility\VersionNumberUtility` have been marked as deprecated and will be removed in
+TYPO3 11.0:
+
+* :php:`convertIntegerToVersionNumber`
+* :php:`splitVersionRange`
+* :php:`raiseVersionNumber`
+
+
+Impact
+======
+
+Calling the methods :php:`convertIntegerToVersionNumber`, :php:`splitVersionRange` or :php:`raiseVersionNumber` of
+:php:\TYPO3\CMS\Core\Utility\VersionNumberUtility` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that call the mentioned methods.
+
+
+Migration
+=========
+
+Implement the methods in your custom code.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88559-TSFE-sys_language_isocode.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88559:
+
+=================================================
+Deprecation: #88559 - $TSFE->sys_language_isocode
+=================================================
+
+See :issue:`88559`
+
+Description
+===========
+
+The public property :php:`TypoScriptFrontendController->sys_language_isocode`
+has set the equivalent of :php:`TYPO3\CMS\Core\Site\Entity\SiteLanguage->getTwoLetterIsoCode()` since the introduction
+of Site Handling in TYPO3 v9.
+
+As all code should switch to Site Handling, this property can be accessed via
+the current site language as well, making this property obsolete.
+
+The property has been marked as deprecated.
+
+
+Impact
+======
+
+Setting or fetching this property will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third party extension accessing this property,
+or via TypoScript :typoscript:`TSFE:sys_language_isocode`.
+
+
+Migration
+=========
+
+Access the property via :php:`SiteLanguage->getTwoLetterIsoCode()`
+and :typoscript:`sitelanguage:twoLetterIsoCode` instead.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88567-GLOBALS_LOCAL_LANG.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88567:
+
+============================================
+Deprecation: #88567 - $GLOBALS['LOCAL_LANG']
+============================================
+
+See :issue:`88567`
+
+Description
+===========
+
+The global array :php:`$GLOBALS['LOCAL_LANG']` contains all labels from language
+files that were loaded "globally". However, instead of having this in global
+scope, it is more feasible to have it scoped to the actual :php:`LanguageService`
+that loaded this data, in order to allow various language functionality in the
+same PHP process without having to deal with global variables.
+
+For this reason, it is discouraged to use :php:`$GLOBALS['LOCAL_LANG']`
+but instead rely on :php:`LanguageService->includeLLfile()` which returns
+the actual values as well, but only the ones loaded from this instance.
+
+Since an instance of :php:`TYPO3\CMS\Core\Localization\LanguageService` is usually available via `$GLOBALS['LANG']` the
+labels are accessible within PHP anyways.
+
+Due to this change, the second and third arguments of :php:`LanguageService->includeLLFile()` have been marked as deprecated.
+
+
+Impact
+======
+
+Calling the method above with an explicit second and/or third argument will
+trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extensions using
+:php:`$GLOBALS['LOCAL_LANG']` or the mentioned method with more than one argument,
+which is very unlikely.
+
+
+Migration
+=========
+
+Use the return value of :php:`LanguageService->includeLLFile()` and remove
+the second and third arguments to work with label files.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88569-LocalesinitializeInFavorOfRegularSingletonInstance.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88569:
+
+==================================================================================
+Deprecation: #88569 - Locales::initialize() in favor of regular singleton instance
+==================================================================================
+
+See :issue:`88569`
+
+Description
+===========
+
+The method :php:`TYPO3\CMS\Core\Localization\Locales::initialize()` has been marked as deprecated.
+It was a workaround to re-initialize the Singleton Instance of the PHP class :php:`Locales` for user-defined locales, which were
+loaded by an extensions' :file:`ext_localconf.php`.
+
+:php:`Locales` is now initialized only when needed, and not during the early bootstrap process,
+making this functionality obsolete, as this is taken care of within the regular constructor.
+
+
+Impact
+======
+
+Calling :php:`TYPO3\CMS\Core\Localization\Locales::initialize()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third-party extension calling :php:`Locales::initialize()` directly.
+
+
+Migration
+=========
+
+Replace the function call by a regular :php:`GeneralUtility::makeInstance(Locales::class);`
+or use Dependency Injection (Constructor Injection or ObjectManager) to fetch an instance of
+the :php:`Locales` class.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88651-ReplaceTYPO3CMSBackendSplitButtonsWithTYPO3CMSBackendDocumentSaveActions.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88651:
+
+=======================================================================================================
+Deprecation: #88651 - Replace TYPO3/CMS/Backend/SplitButtons with TYPO3/CMS/Backend/DocumentSaveActions
+=======================================================================================================
+
+See :issue:`88651`
+
+Description
+===========
+
+Since FormEngine doesn't use split buttons anymore with TYPO3 v9, the JavaScript module
+:js:`TYPO3/CMS/Backend/SplitButtons` has been replaced with :js:`TYPO3/CMS/Backend/DocumentSaveActions`.
+
+
+Impact
+======
+
+Loading :js:`TYPO3/CMS/Backend/SplitButtons` will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions using :js:`TYPO3/CMS/Backend/SplitButtons` are affected.
+
+
+Migration
+=========
+
+Use :js:`TYPO3/CMS/Backend/DocumentSaveActions` instead. Since the module is a singleton, the instance can be fetched by
+calling :js:`DocumentSaveActions.getInstance()`.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88662-DeprecatedBackendRouteXMOD_tximpexp.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88662:
+
+============================================================
+Deprecation: #88662 - Deprecated backend route xMOD_tximpexp
+============================================================
+
+See :issue:`88662`
+
+Description
+===========
+
+The route identifier :php:`xMOD_tximpexp` (route `record/importexport`) pointing to
+:php:`ImportExportController::mainAction` has been marked as deprecated. The class was previously responsible to handle
+either the export or the import process, controlled by a query parameter.
+
+
+Impact
+======
+
+Calling the route will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All 3rd-party extensions using the route :php:`xMOD_tximpexp` are affected.
+
+
+Migration
+=========
+
+Depending on the task, either use :php:`tx_impexp_export` or :php:`tx_impexp_import`. Additionally, remove any
+`tx_impexp[action]` query parameter.
+
+.. index:: Backend, NotScanned, ext:impexp

Documentation/Changelog/10.0/Deprecation-88746-PageRepositoryPHPClassMovedFromFrontendToCoreExtension.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88746:
+
+====================================================================================
+Deprecation: #88746 - PageRepository PHP class moved from Frontend to Core Extension
+====================================================================================
+
+See :issue:`88746`
+
+Description
+===========
+
+In previous TYPO3 versions, accessing records was mixed between Frontend (handled by PageRepository)
+and Backend (handled by static methods in BackendUtility). In TYPO3 v9, the Context API was introduced
+and PageRepository now acts as a strong database accessor which is not bound to Frontend anymore,
+at all.
+
+In addition, various places of the backend also used PageRepository already, which violated the
+separation of packages, as TYPO3 Core aims to strictly separate Frontend and Backend application
+code.
+
+In the case of PageRepository, the code is used by both applications, and is therefore moved
+to Core system extension (EXT:core), and renamed to :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository`.
+
+Until TYPO3 v9, it was placed in :php:`TYPO3\CMS\Frontend\Page\PageRepository`.
+
+In addition, all interface'd hooks are moved to EXT:core as well with the same PHP namespace.
+
+
+Impact
+======
+
+A class alias was introduced which does not trigger any deprecations, so both variants
+still work as before, however it is recommended to rename any calls to the PHP class.
+
+No other functionality was changed.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with custom PHP extensions accessing PageRepository directly.
+
+
+Migration
+=========
+
+Replace any PHP references of :php:`TYPO3\CMS\Frontend\Page\PageRepository`
+to :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository` in any custom PHP code.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/10.0/Deprecation-88792-ForceTemplateParsingInTSFEAndTemplateService.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88792:
+
+======================================================================
+Deprecation: #88792 - forceTemplateParsing in TSFE and TemplateService
+======================================================================
+
+See :issue:`88792`
+
+Description
+===========
+
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::forceTemplateParsing` and
+* :php:`TYPO3\CMS\Core\TypoScript\TemplateService::forceTemplateParsing`
+
+have been marked as deprecated and replaced by Context API.
+
+
+Impact
+======
+
+Setting either :php:`forceTemplateParsing` of :php:`TypoScriptFrontendController` or :php:`TemplateService`
+will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations setting or reading :php:`$TSFE->forceTemplateParsing` or :php:`TemplateService->forceTemplateParsing`.
+
+
+Migration
+=========
+
+Use the Context API ::
+
+   GeneralUtility::makeInstance(Context::class)->getPropertyFromAspect('typoscript', 'forcedTemplateParsing');
+   $context->setAspect('typoscript', GeneralUtility::makeInstance(TypoScriptAspect::class, true));
+
+.. index:: Frontend, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88807-AdminPanelInitializableInterfaceHasBeenDeprecated.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88807:
+
+===========================================================================
+Deprecation: #88807 - AdminPanel InitializableInterface has been deprecated
+===========================================================================
+
+See :issue:`88807`
+
+Description
+===========
+
+`\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface` has been deprecated in favor of the newly
+introduced `\TYPO3\CMS\Adminpanel\ModuleApi\RequestEnricherInterface`.
+
+
+Impact
+======
+
+Using `\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface` will trigger a deprecation message.
+
+
+Affected Installations
+======================
+
+All instances that use `\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface` are affected.
+
+
+Migration
+=========
+
+Switch to `\TYPO3\CMS\Adminpanel\ModuleApi\RequestEnricherInterface` instead:
+
+- change method name `initializeModule` to `enrich`
+- change return value to return an instance of
+  :php:`\Psr\Http\Message\ServerRequestInterface`
+
+.. index:: Frontend, PHP-API, PartiallyScanned, ext:adminpanel

Documentation/Changelog/10.0/Feature-21638-IntroducedIpLockingForIpv6.rst

@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-21638:
+
+================================================
+Feature: #21638 - Introduced IP locking for IPv6
+================================================
+
+See :issue:`21638`
+
+Description
+===========
+
+The IP-locking functionality has been extended to support IPv6 now as well.
+This security feature enables binding of a user session (Backend or Frontend) to an IP address or a part of it.
+
+The available configuration options with their default values for IP-locking are:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['FE']['lockIP'] = 2;
+   $GLOBALS['TYPO3_CONF_VARS']['FE']['lockIPv6'] = 2;
+
+   $GLOBALS['TYPO3_CONF_VARS']['BE']['lockIP'] = 4;
+   $GLOBALS['TYPO3_CONF_VARS']['BE']['lockIPv6'] = 2;
+
+The configuration can be changed via the Admin Tools -> Settings menu.
+The exact meaning of the numbers used for the configuration are documented there.
+
+Code-wise a separate IpLocker class :php:`\TYPO3\CMS\Core\Authentication\IpLocker` has been added, which takes care of the IP-locking for both IP versions.
+
+.. index:: Backend, Frontend, LocalConfiguration

Documentation/Changelog/10.0/Feature-56213-AllowSortingFilelistByFileMetadataTitle.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-56213:
+
+===================================================================
+Feature: #56213 - Allow sorting file list by file meta data "title"
+===================================================================
+
+See :issue:`56213`
+
+Description
+===========
+
+The possibility to sort files by their meta data title in the "File Links" content element has been introduced.
+The title attribute is part of the base metadata table and therefor available in all TYPO3 installations.
+
+If you need further FAL fields to sort by, extend the TCA of tt_content field :php:`filelink_sorting` and add
+metadata fields as options to choose from.
+
+For example add the following in :file:`TCA/Overrides/tt_content.php`::
+
+   $GLOBALS['TCA']['tt_content']['columns']['filelink_sorting']['config']['items'][] = ['Sort by alternative Text', 'alternative'];
+
+Or use Page TSConfig :typoscript:`TCEFORM.tt_content.filelink_sorting.addItems.alternative = sort by "Alternative" metadata field`.
+
+
+Impact
+======
+
+The filelinks content element has a new option for sorting "by file metadata title" which can be chosen in
+the drop down when creating the element.
+
+.. index:: Backend, TCA, ext:frontend

Documentation/Changelog/10.0/Feature-78432-AddLogMessageForSwitchUserAction.rst

@@ -0,0 +1,18 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-78432:
+
+==========================================================
+Feature: #78432 - Add log message for "Switch User action"
+==========================================================
+
+See :issue:`78432`
+
+Description
+===========
+
+If an admin user switches to another be_user account via the "Switch User" action in the "Backend users" module, the action is now logged to the sys_log.
+
+`User admin switched to user editor (be_users:2)`
+
+.. index:: Backend, ext:beuser

Documentation/Changelog/10.0/Feature-80420-AllowMultipleRecipientsInEmailFinisher.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-80420:
+
+=============================================================
+Feature: #80420 - Allow multiple recipients in email finisher
+=============================================================
+
+See :issue:`80420`
+
+Description
+===========
+
+Mails sent by the :php:`EmailFinisher` of EXT:form can now have multiple recipients. For this the following new finisher options have been added:
+
+* :yaml:`recipients` (:code:`To`)
+* :yaml:`replyToRecipients` (:code:`Reply-To`)
+* :yaml:`carbonCopyRecipients` (:code:`CC`)
+* :yaml:`blindCarbonCopyRecipients` (:code:`BCC`)
+
+These options must contain a YAML hash with email addresses as keys and recipient names as values:
+
+.. code-block:: yaml
+
+   recipients:
+     first@example.org: First Recipient
+     second@example.org: Second Recipient
+
+Additionally this now allows for setting the name of a CC and BCC recipient:
+
+.. code-block:: yaml
+
+   carbonCopyRecipients:
+     firstCC@example.org: First CC Recipient
+
+The form editor in the backend module provides a visual UI to enter an arbitrary amount of recipients.
+
+
+Impact
+======
+
+Mails sent by EXT:form can be sent to multiple recipients, optionally via CC or BCC. Replies can be sent to multiple recipients.
+
+.. index:: ext:form

Documentation/Changelog/10.0/Feature-83734-AddSupportForCurrentPageInConfigcache.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-83734:
+
+==============================================================
+Feature: #83734 - Add support for current page in config.cache
+==============================================================
+
+See :issue:`83734`
+
+Description
+===========
+
+When using the TypoScript property :typoscript:`config.cache`, it is possible to define a configuration that
+affects all pages via:
+
+.. code-block:: typoscript
+
+   config.cache.all = fe_users:2
+
+However such configurations always depend on a precise page where to look up records.
+A common scenario is to have records stored in each page itself.
+Thus, the syntax with the keyword "current" is now possible:
+
+.. code-block:: typoscript
+
+   config.cache.all = fe_users:current
+
+where :typoscript:`current` is dynamically replaced by the current Page ID.
+
+
+Impact
+======
+
+When using :typoscript:`current` inside the :typoscript:`config.cache` TypoScript property, it is now replaced with
+the current Page ID.
+
+.. index:: TypoScript

Documentation/Changelog/10.0/Feature-84112-SymfonyDependencyInjectionForCoreAndExtbase.rst

@@ -0,0 +1,218 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84112:
+
+===================================================================
+Feature: #84112 - Symfony dependency injection for core and extbase
+===================================================================
+
+See :issue:`84112`
+
+Description
+===========
+
+The PHP library `symfony/dependency-injection` has been integrated and is used
+to manage system wide dependency management and injection for classes.
+With the integration provided in TYPO3 the symfony dependency injection container
+features support for Extbase and non-Extbase classes and is thus intended to
+replace the Extbase dependency injection container and object manager.
+The symfony container implements :php:`\Psr\Container\ContainerInterface`
+as specified by PSR-11. This interface should be used when requiring access
+to the container.
+Therefore :php:`\TYPO3\CMS\Extbase\Object\ObjectManager` now resorts to this
+new dependency injection container and prioritizes its entries over classical
+Extbase dependency injection (which is still available), also
+:php:`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance()` has been adapted
+to retrieve instances from the container, if possible.
+
+Classes should be adapted to avoid both, :php:`ObjectManager` and
+:php:`GeneralUtility::makeInstance()` whenever possible.
+Service dependencies should be injected via constructor injection or
+setter methods (inject methods as in Extbase are supported).
+
+Configuration
+^^^^^^^^^^^^^
+
+Extensions are encouraged to configure their classes to make use of the new
+dependency injection. A symfony flavored yaml (or, for advanced functionality,
+php) service configuration file may be used to do so. That means symfony
+dependency injection is not applied automatically, extensions need to
+define the desired dependency injection strategies. Extensions that do not
+configure dependency injection will keep working – the legacy instance
+management in :php:`\TYPO3\CMS\Extbase\Object\ObjectManager` and
+:php:`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance()` is
+still available.
+
+Whenever service configuration or class dependencies change, the core cache needs
+to be flushed to rebuild the compiled symfony container.
+
+Autowiring
+----------
+
+A :file:`Configuration/Services.yaml` which uses autowiring pretty much
+reflects the current feature set of Extbase DI. The configuration looks like:
+
+.. code-block:: yaml
+
+    # Configuration/Services.yaml
+    services:
+      _defaults:
+        autowire: true
+        autoconfigure: true
+        public: false
+
+      Your\Namespace\:
+        resource: '../Classes/*'
+
+Extensions which have used Extbase dependency injection in the past, will want
+to enable :yaml:`autowire` for a smooth migration. :yaml:`autowire: true` instructs symfony
+to calculate the required dependencies from type declarations of the constructor
+and inject methods. This calculation yields to a service initialization recipe
+which is cached in php code (in TYPO3 core cache).
+Note: An extension doesn't need to use autowiring, it is free to manually
+wire dependencies in the service configuration file.
+
+It is suggested to enable :yaml:`autoconfigure: true` as this will automatically
+add symfony service tags based on implemented interfaces or base classes.
+An Example: autoconfiguration ensured that classes which implement
+:php:`\TYPO3\CMS\Core\SingletonInterface` will be publicly available from the
+symfony container (which is required for legacy singleton lookups through
+:php:`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance()`).
+
+:yaml:`public: false` is a performance optimization and is therefore suggested to be
+enabled in extensions (symfony does not enable this by default for backwards
+compatibility reasons only). This settings controls which services are available
+through :php:`\Psr\Container\ContainerInterface->get()`. Services that need to be public
+(e.g. Singletons, because they need to be shared with legacy code that uses
+:php:`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance()`, or Extbase controllers)
+will be marked public automatically due to :yaml:`autoconfigure: true` by custom
+TYPO3 provided symfony compiler passes.
+
+
+Manual wiring
+-------------
+
+Manual dependency wiring and service configuration can be used instead of
+autowiring (it can actually be combined). This speeds up container compilation
+and allows for custom service configuration/wiring. It has the drawback of
+having to write some boilerplate.
+
+.. code-block:: yaml
+
+    # Configuration/Services.yaml
+    services:
+      _defaults:
+        autoconfigure: false
+        public: false
+
+      Your\Namespace\Service\ExampleService:
+       # mark public – means this service should be accessible from $container->get()
+       # and (often more important), both GeneralUtility::makeInstance() and the Extbase
+       # ObjectManager will be able to use the Symfony DI managed service
+       public: true
+       # Defining a service to be shared is equal to TYPO3's SingletonInterface behaviour
+       shared: true
+       # Configure constructor arguments
+       arguments:
+         $siteConfiguration: '@TYPO3\CMS\Core\Configuration\SiteConfiguration'
+
+      # Example Extbase controller
+      Your\Namespace\Controller\ExampleController:
+       # mark public to be dispatchable
+       public: true
+       # Defining to be a prototype, as Extbase controllers are stateful (i. e. could not be defined as singleton)
+       shared: false
+       # Configure constructor arguments
+       arguments:
+         $exampleService: '@Your\Namespace\Service\ExampleService'
+
+
+For more information please refer to the official documentation:
+https://symfony.com/doc/4.3/service_container.html
+
+
+Advanced functionality
+----------------------
+
+Container compilation and configuration can be enhanced using
+a callback function returned from :file:`Configuration/Services.php`.
+Here is an example: Given an interface :php:`MyCustomInterface`,
+you can automatically add a symfony tag for (autoconfigured) services that
+implement this interface. A compiler pass can use that tag and configure
+autoregistration into a registry service :php:`MyRegistry`.
+
+.. code-block:: php
+
+    # Configuration/Services.php
+    <?php
+    declare(strict_types = 1);
+    namespace Your\Namespace;
+
+    use Symfony\Component\DependencyInjection\ContainerBuilder;
+    use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
+
+    return function (ContainerConfigurator $container, ContainerBuilder $containerBuilder) {
+        $containerBuilder->registerForAutoconfiguration(MyCustomInterface::class)->addTag('my.custom.interface');
+
+        $containerBuilder->addCompilerPass(new DependencyInjection\MyCustomPass('my.custom.interface'));
+    };
+
+.. code-block:: php
+
+    # Classes/DependencyInjection/MyCustomPass.php
+    <?php
+    declare(strict_types = 1);
+    namespace Your\Namespace\DependencyInjection;
+
+    use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
+    use Symfony\Component\DependencyInjection\ContainerBuilder;
+    use Your\Namespace\MyRegistry;
+
+    final class MyCustomPass implements CompilerPassInterface
+    {
+        public function process(ContainerBuilder $container)
+        {
+            $myRegistry = $container->findDefinition(MyRegistry::class);
+
+            foreach ($container->findTaggedServiceIds('my.custom.interface') as $id => $tags) {
+                $definition = $container->findDefinition($id);
+                if (!$definition->isAutoconfigured() || $definition->isAbstract()) {
+                    continue;
+                }
+
+                // Services that implement MyCustomInterface need to be public,
+                // to be lazy loadable by the registry via $container->get()
+                $container->findDefinition($id)->setPublic(true);
+                // Add a method call to the registry class to the (auto-generated) factory for
+                // the registry service.
+                // This supersedes explicit registrations in ext_localconf.php (which're
+                // still possible and can be combined with this autoconfiguration).
+                $myRegistry->addMethodCall('registerMyCustomInterfaceImplementation', [$id]);
+            }
+        }
+    }
+
+Impact
+======
+
+* Symfony automatically resolves interfaces to classes when only one class
+  implementing an interface is available. Otherwise an explicit alias is required.
+  That means you SHOULD define an alias for interface to class mappings where
+  the implementation currently defaults to the interface minus the trailing Interface
+  suffix (which is the default for Extbase).
+
+* Dependency Injection can be added to constructors of existing services
+  without being breaking. :php:`GeneralUtility::makeInstance(ServiceName::class)`
+  will keep working,  as :php:`makeInstance` has been adapted to resort to the
+  symfony container.
+
+* Cyclic dependencies are not supported with Symfony DI (Extbase DI did so).
+
+* Prototypes/Data classes (non singletons, e.g. models) that need both,
+  runtime constructor arguments (as passed to
+  :php:`\TYPO3\CMS\Extbase\Object\ObjectManager->get()`) and injected dependencies
+  are not supported in :php:`\Psr\Container\ContainerInterface->get()`.
+  It is suggested to switch to factories or stick with the object manager for now.
+
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.0/Feature-84757-DoubleClickInStructureTreeChangesLabel.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84757:
+
+==============================================================
+Feature: #84757 - Double click in structure tree changes label
+==============================================================
+
+See :issue:`84757`
+
+Description
+===========
+
+Functionality to change the labels of form elements via double click
+in the form editor element tree has been added to allow quick changes
+of labels.
+
+Impact
+======
+
+The label of a form element can be edited by double clicking on the title in the structure tree.
+
+.. index:: ext:form

Documentation/Changelog/10.0/Feature-85569-ShowSchedulerInformationsInTheSystemInformationToolbar.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85569:
+
+==============================================================================
+Feature: #85569 - Show scheduler information in the system information toolbar
+==============================================================================
+
+See :issue:`85569`
+
+Description
+===========
+
+The system information toolbar now shows useful information about the TYPO3 scheduler system extension.
+
+The following information can be gathered quickly via the toolbar:
+
+Warning if the scheduler execution seems not to be configured correctly
+
+Important information about the last successfully executed scheduler run
+
+* the start date
+* the start time
+* the duration (in minutes)
+* the execution type (automatically/CLI or manually/via backend), a manual execution highlights the text
+
+Impact
+======
+
+The mentioned scheduler specific information is added to the system information toolbar, if the system extension
+`scheduler` is active and if there are any tasks configured at all.
+
+.. index:: Backend, ext:scheduler

Documentation/Changelog/10.0/Feature-85607-NewThumbnailViewHelperToRenderThumbnailsDeferred.rst

@@ -0,0 +1,28 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85607:
+
+=======================================================================
+Feature: #85607 - New ThumbnailViewHelper to render thumbnails deferred
+=======================================================================
+
+See :issue:`85607`
+
+Description
+===========
+
+A new ViewHelper for the backend to render thumbnails deferred was introduced.
+
+The :php:`\TYPO3\CMS\Backend\ViewHelpers\ThumbnailViewHelper` extends the :php:`ImageViewHelper` and generates the image tag with the special URI.
+
+..  code-block:: html
+
+    <be:thumbnail image="{file.resource}" width="{thumbnail.width}" height="{thumbnail.height}" />
+
+
+Impact
+======
+
+Thumbnails do not block the rendering of a page, because the processing runs an extra http request.
+
+.. index:: Backend, Fluid, ext:backend

Documentation/Changelog/10.0/Feature-86629-ImplementLinkHandlerForTelephoneNumbers.rst

@@ -0,0 +1,20 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86629:
+
+=============================================================
+Feature: #86629 - Implement LinkHandler for telephone numbers
+=============================================================
+
+See :issue:`86629`
+
+Description
+===========
+
+A new phone number link handler has been added.
+
+With this new link handler you can set links in a new tab in the link browser to phone numbers using the `tel:` protocol.
+
+A valid phone number consists of only numbers and the + character.
+
+.. index:: Backend, Frontend

Documentation/Changelog/10.0/Feature-86964-AllowGettingClassPropertyDefaultValue.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86964:
+
+============================================================
+Feature: #86964 - Allow getting class property default value
+============================================================
+
+See :issue:`86964`
+
+Description
+===========
+
+It is now possible to get the default value of a class property when using the :php:`TYPO3\CMS\Extbase\Reflection\ReflectionService`.
+
+.. code-block:: php
+
+    class MyClass
+    {
+        public $myProperty = 'foo';
+    }
+
+    $property = GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\Reflection\ReflectionService::class)
+        ->getClassSchema(MyClass::class)
+        ->getProperty('myProperty');
+
+    $defaultValue = $property->getDefaultValue(); // "foo"
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/10.0/Feature-87200-SendPlaintextAndHTMLMailsInEmailFinisher.rst

@@ -0,0 +1,25 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87200:
+
+================================================================
+Feature: #87200 - Send plaintext and HTML mails in EmailFinisher
+================================================================
+
+See :issue:`87200`
+
+Description
+===========
+
+The :php:`EmailFinisher` of EXT:form now sends mails with a plaintext and an HTML part.
+A new option :yaml:`addHtmlPart` has been added to configure if a HTML part should be added to mails.
+
+
+Impact
+======
+
+Mails now contain both plaintext and HTML parts to support a wider audience.
+
+Enforcing a plaintext-only mail increases reception and security.
+
+.. index:: ext:form

Documentation/Changelog/10.0/Feature-87433-AddChangefreqAndPriority.rst

@@ -0,0 +1,81 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87433:
+
+=============================================================
+Feature: #87433 - Add changefreq and priority for XML sitemap
+=============================================================
+
+See :issue:`87433`
+
+Description
+===========
+
+Sitemap.xml files may contain a change frequency and a priority for entries.
+
+Change frequencies define how often each page is approximately updated and hence how often it should be
+revisited (for example: News in an archive are "never" updated, while your home page might get "weekly" updates).
+
+Priority allows you to define how important the page is compared to other pages on your site. The priority is stated
+in a value from 0 to 1. Your most important pages can get an higher priority as other pages. This value does not
+affect how important your pages are compared to pages of other websites.
+
+This feature allows to define the properties :typoscript:`changefreq` and :typoscript:`priority` for sitemap entries in TYPO3.
+
+The properties :typoscript:`changefreq` and :typoscript:`priority` of pages can be controlled via page properties.
+For records, the settings can be defined in TypoScript by mapping the properties to fields of the record by
+using the options :typoscript:`changeFreqField` and :typoscript:`priorityField`. :typoscript:`changeFreqField` needs to point to a field containing
+string values (see :typoscript:`pages` definition of field :typoscript:`sitemap_changefreq`), :typoscript:`priorityField` needs to point to a field with
+a decimal value between 0 and 1.
+
+
+.. code-block:: typoscript
+
+   plugin.tx_seo {
+      config {
+         xmlSitemap {
+            sitemaps {
+               <unique key> {
+                  provider = TYPO3\CMS\Seo\XmlSitemap\RecordsXmlSitemapDataProvider
+                  config {
+                     table = news_table
+                     sortField = sorting
+                     lastModifiedField = tstamp
+                     changeFreqField = news_changefreq
+                     priorityField = news_priority
+                     additionalWhere = AND (no_index = 0 OR no_follow = 0)
+                     pid = <page id('s) containing news records>
+                     url {
+                        pageId = <your detail page id>
+                        fieldToParameterMap {
+                           uid = tx_extension_pi1[news]
+                        }
+                        additionalGetParameters {
+                           tx_extension_pi1.controller = News
+                           tx_extension_pi1.action = detail
+                        }
+                     }
+                  }
+               }
+            }
+         }
+      }
+   }
+
+
+Impact
+======
+
+Two new fields are available in the page properties: `sitemap_priority` (decimal) and `sitemap_changefreq` (list of values, for example "weekly", "daily", "never").
+
+Two new TypoScript options for the :typoscript:`RecordsXmlSitemapDataProvider` have been introduced:
+:typoscript:`changeFreqField` and :typoscript:`priorityField`.
+
+All pages and records get a priority of 0.5 by default.
+
+.. attention::
+
+   Both priority and change frequency does have no impact on your rankings. These options only gives hints to search engines
+   in which order and how often you would like a crawler to visit your pages.
+
+.. index:: ext:seo, Frontend, TypoScript

Documentation/Changelog/10.0/Feature-87457-UseSymfonyproperty-infoToGatherDocBlockInformation.rst

@@ -0,0 +1,58 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87457:
+
+===========================================================================
+Feature: #87457 - Use symfony/property-info to gather doc block information
+===========================================================================
+
+See :issue:`87457`
+
+Description
+===========
+
+The use of `symfony/property-info` enables us to resolve non fully qualified class names.
+
+This is now possible:
+
+.. code-block:: php
+
+   use TYPO3\CMS\Extbase\Persistence\ObjectStorage;
+   use ExtbaseTeam\BlogExample\Domain\Model\Comment;
+
+   class Post
+   {
+       /*
+        * @var ObjectStorage<Comment>
+        */
+       public $comments;
+   }
+
+Important:
+This only works in extbase models as the reflection
+costs are high and the information is only needed
+in this case.
+
+The non fully qualified class name is now also
+supported for injection properties, although it is
+still recommended to avoid injection properties in
+favor of injection methods or constructor injection.
+
+Example:
+
+.. code-block:: php
+
+   use TYPO3\CMS\Extbase\Annotation as Extbase;
+   use TYPO3\CMS\Extbase\Configuration\ConfigurationManager;
+
+   class Service
+   {
+       /*
+        * @Extbase\Inject
+        * @var ConfigurationManager
+        */
+       public $configurationManager;
+   }
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/10.0/Feature-87665-IntroduceBitSetClass.rst

@@ -0,0 +1,89 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87665:
+
+========================================
+Feature: #87665 - Introduce BitSet class
+========================================
+
+See :issue:`87665`
+
+Description
+===========
+
+To efficiently handle boolean flags, bit sets can be used. Therefore a new class :php:`\TYPO3\CMS\Core\Type\BitSet` has been introduced.
+The bit set can be used standalone and accessed from the outside but it can also be used to create specific BitSet classes that extend the BitSet class.
+
+The functionality is best described by an example:
+
+::
+
+   <?php
+   declare(strict_types = 1);
+
+   define('PERMISSIONS_NONE', 0b0); // 0
+   define('PERMISSIONS_PAGE_SHOW', 0b1); // 1
+   define('PERMISSIONS_PAGE_EDIT', 0b10); // 2
+   define('PERMISSIONS_PAGE_DELETE', 0b100); // 4
+   define('PERMISSIONS_PAGE_NEW', 0b1000); // 8
+   define('PERMISSIONS_CONTENT_EDIT', 0b10000); // 16
+   define('PERMISSIONS_ALL', 0b11111); // 31
+
+   $bitSet = new \TYPO3\CMS\Core\Type\BitSet(PERMISSIONS_PAGE_SHOW | PERMISSIONS_PAGE_NEW);
+   $bitSet->get(PERMISSIONS_PAGE_SHOW); // true
+   $bitSet->get(PERMISSIONS_CONTENT_EDIT); // false
+
+Another example shows how to possibly extend the :php:`\TYPO3\CMS\Core\Type\BitSet` class.
+
+::
+
+   <?php
+   declare(strict_types = 1);
+
+   class Permissions extends \TYPO3\CMS\Core\Type\BitSet
+   {
+       public const NONE = 0b0; // 0
+       public const PAGE_SHOW = 0b1; // 1
+       public const PAGE_EDIT = 0b10; // 2
+       public const PAGE_DELETE = 0b100; // 4
+       public const PAGE_NEW = 0b1000; // 8
+       public const CONTENT_EDIT = 0b10000; // 16
+       public const ALL = 0b11111; // 31
+
+       /**
+        * @param int $permission
+        * @return bool
+        */
+       public function hasPermission(int $permission): bool
+       {
+           return $this->get($permission);
+       }
+
+       /**
+        * @return bool
+        */
+       public function hasAllPermissions(): bool
+       {
+           return $this->get(static::ALL);
+       }
+
+       /**
+        * @param int $permission
+        */
+       public function allow(int $permission): void
+       {
+           $this->set($permission);
+       }
+   }
+
+   $permissions = new Permissions(Permissions::PAGE_SHOW | Permissions::PAGE_NEW);
+   $permissions->hasPermission(Permissions::PAGE_SHOW); // true
+   $permissions->hasPermission(Permissions::CONTENT_EDIT); // false
+
+
+Impact
+======
+
+This class may come in handy in all situations where boolean flags need to be managed in an efficient way.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.0/Feature-87726-ExtendFrontendLoginControllerHookToValidatePassword.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87726:
+
+==========================================================================
+Feature: #87726 - Extend FrontendLoginController Hook to validate password
+==========================================================================
+
+See :issue:`87726`
+
+Description
+===========
+
+The Hook :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed']` is extended to validate the given password.
+In the Hook you can set a custom validation message.
+
+
+Impact
+======
+
+You can now use the hook via:
+
+.. code-block:: php
+
+    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed'][] = \Your\Namespace\Hooks\MyBeautifulHook::class . '->passwordChanged';
+
+Example implementation:
+-----------------------
+
+.. code-block:: php
+
+    public function passwordChanged(array &$params)
+    {
+        if($params['newPasswordUnencrypted']==='password'){
+            $params['passwordValid']=FALSE;
+            $params['passwordInvalidMessage']='<p class="text-danger">Do not use password as password</p>';
+        }
+    }
+
+.. index:: Frontend, ext:felogin, PHP-API

Documentation/Changelog/10.0/Feature-88643-NewMailAPIBasedOnSymfonymailerAndSymfonymime.rst

@@ -0,0 +1,84 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88643:
+
+=======================================================================
+Feature: #88643 - New Mail API based on symfony/mailer and symfony/mime
+=======================================================================
+
+See :issue:`88643`
+
+Description
+===========
+
+TYPO3 has relied on the third-party dependency "SwiftMailer" for a long time.
+
+However, the library has been superseded by the author in favor of new, more modern
+libraries "symfony/mailer" for sending emails and "symfony/mime" for creating email
+messages.
+
+TYPO3 has replaced swiftmailer with the symfony components.
+
+The new component does not handle the regular PHP function :php:`mail()`, which
+has been declared unsafe in various scenarios, anymore. Instead it is recommended
+to switch to `sendmail` or `smtp`, which can be configured within the TYPO3
+Install Tool or the Settings module for System Maintainers under "Presets" => "Mail".
+
+All existing installations which still configure ``mail`` are migrated to ``sendmail``
+by automatically detecting the sendmail path by checking PHP.ini settings, but
+should be reviewed on update.
+
+In addition, the MailMessage API to create Email messages now inherits from
+:php:`Symfony\Mail\Email` instead of :php:`Swift_Message`, and adds certain shortcuts
+and more flexibility, but is also stricter in validation.
+
+Especially custom extensions using the MailMessage API need to be evaluated,
+as it is not possible anymore to add multiple email addresses as a simple associative
+array but rather an Address object from "symfony/mime" is required.
+
+All existing Swiftmailer-based transports which TYPO3 supports natively have been
+replaced by Symfony-based transport APIs.
+
+Spool-based transports are still experimental, as it might be replaced by a native
+Symfony component as well.
+
+
+Impact
+======
+
+The MailMessage API now has more possibilities to add multi-part files and attachments,
+for use in third-party extensions, but some APIs might be adapted.
+
+See the documentation of the Symfony components (https://symfony.com/doc/current/mailer.html)
+for further details on how to use the new Email class where TYPO3's MailMessage
+class extends from.
+
+An example implementation within a third-party extension:
+
+.. code-block:: php
+
+    $email = GeneralUtility::makeInstance(MailMessage::class)
+         ->to(new Address('kasperYYYY@typo3.org'), new Address('benni@typo3.org', 'Benni Mack'))
+         ->subject('This is an example email')
+         ->text('This is the plain-text variant')
+         ->html('<h4>Hello Benni.</h4><p>Enjoy a HTML-readable email. <marquee>We love TYPO3</marquee>.</p>');
+
+    $email->send();
+
+It is however also possible to re-use a Mailer instance, also adding custom Mailer
+settings via a custom Transport for special cases.
+
+.. code-block:: php
+
+    $mailer = GeneralUtility::makeInstance(Mailer::class)
+
+    $email = GeneralUtility::makeInstance(MailMessage::class)
+         ->to(new Address('kasperYYYY@typo3.org'), new Address('benni@typo3.org', 'Benni Mack'))
+         ->subject('This is an example email')
+         ->text('This is the plain-text variant')
+         ->html('<h4>Hello Benni.</h4><p>Enjoy a HTML-readable email. <marquee>We love TYPO3</marquee>.</p>');
+
+    // Send the email via the Mailer instance
+    $mailer->send($email);
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.0/Feature-88648-DefineTwitterCardTypeInPageProperties.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88648:
+
+==========================================================
+Feature: #88648 - Set Twitter Card Type in page properties
+==========================================================
+
+See :issue:`88648`
+
+Description
+===========
+
+It is now possible to select the type of Twitter Card to be shown when a page is shared
+on Twitter. This option will render the :html:`twitter:card` meta tag in frontend.
+
+Impact
+======
+
+If you manually changed the value of the :html:`twitter:card` by for example TypoScript and you
+want to override the value of the page properties, you have to use the replace option to
+override this value from the page properties.
+
+Example:
+
+.. code-block:: typoscript
+
+  page {
+    meta {
+      twitter:card = summary_large_image
+      twitter:card.replace = 1
+    }
+  }
+
+
+.. index:: ext:seo, Frontend, TypoScript

Documentation/Changelog/10.0/Feature-88770-PSR-14BasedEventDispatcher.rst

@@ -0,0 +1,131 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88770:
+
+==============================================
+Feature: #88770 - PSR-14 based EventDispatcher
+==============================================
+
+See :issue:`88770`
+
+Description
+===========
+
+A new EventDispatcher system is added to extend TYPO3's Core behaviour via PHP code. In the past,
+this was done via Extbase's SignalSlot and TYPO3's custom hook system. The new EventDispatcher
+system is a fully capable replacement for new code in TYPO3, as well as a possibility to
+migrate away from previous TYPO3 solutions.
+
+PSR-14 [https://www.php-fig.org/psr/psr-14/] is a lean solution that builds upon wide-spread
+solutions for hooking into existing PHP code (Frameworks, CMS and the like).
+
+PSR-14 consists of four components:
+
+1. An `EventDispatcher` object that is used to trigger an Event. TYPO3 has a custom EventDispatcher
+implementation for now, however all EventDispatchers of all frameworks are implementing
+:php:`Psr\EventDispatcher\EventDispatcherInterface` thus it is possible to replace the event
+dispatcher with another. The EventDispatcher's main method :php:`dispatch()` is called in TYPO3 Core
+or extensions, that receives a PHP object and is then handed to all available listeners.
+
+2. A `ListenerProvider` object that contains all listeners which have been registered for all events.
+TYPO3 has a custom ListenerProvider that collects all listeners during compile time. This component
+is not exposed outside of TYPO3's Core Framework.
+
+3. Various `Event` objects. An event object can be any PHP object and is called from TYPO3 Core or
+an extension ("Emitter") containing all information to be transported to the listeners. By default,
+all registered listeners get triggered by an Event, however, if an Event has the interface
+:php:`Psr\EventDispatcher\StoppableEventInterface` implemented, a listener can stop further execution
+of other event listeners. This is especially useful if the listeners are candidates to provide information
+to the emitter. This allows to finish event dispatching, once this information has been acquired.
+
+If an event can be modified, appropriate methods should be available, although due to PHP's
+nature of handling objects and the PSR-14 Listener signature, it cannot be guaranteed to be immutable.
+
+4. Listeners: Extensions and PHP packages can add listeners that are registered. They are usually
+associated to Event objects by the name of the event (FQCN) to be listened on. It is the task of
+the `ListenerProvider` to provide configuration mechanisms to represent this relationship.
+
+The main benefits of the EventDispatcher approach over Hooks and Extbase's SignalSlot Dispatcher
+is an implementation which helps extension authors to better understand the possibilities
+by having a strongly typed system based on PHP. In addition, it serves as a bridge to also
+incorporate other Events provided by frameworks that support PSR-14.
+
+
+Impact
+======
+
+TYPO3's EventDispatcher serves as the basis to replace all Signal/Slots and hooks in the future,
+however for the time being, hooks and registered Slots work the same way as before, unless migrated
+to an EventDispatcher-like code, whereas a PHP :php:`E_USER_DEPRECATED` error can be triggered.
+
+Some hooks / signal/slots might not be replaced 1:1 to EventDispatcher, but rather superseded with
+a more robust or future-proof API.
+
+Registration:
+
+If an extension author wants to provide a custom Event Listener, an according entry with the tag
+`event.listener` can be added to the `Configuration/Services.yaml` file of that extension.
+
+Example:
+
+.. code-block:: yaml
+
+   services:
+     MyCompany\MyPackage\EventListener\NullMailer:
+       tags:
+         - name: event.listener
+           identifier: 'myListener'
+           event: TYPO3\CMS\Core\Mail\Event\AfterMailerInitializationEvent
+           before: 'redirects, anotherIdentifier'
+
+
+The tag name `event.listener` identifies that a listener should be registered.
+
+The custom PHP class :php:`MyCompany\MyPackage\EventListener\NullMailer` serves as the listener,
+whereas the `identifier` is a common name so orderings can be built upon the identifier,
+the optional `before` and `after` attributes allow for custom sorting against `identifier`.
+
+The `event` attribute is the FQCN of the Event object.
+
+If no attribute `method` is given, the class is treated as Invokable, thus `__invoke` method is called.
+
+An example listener, which hooks into the Mailer API to modify Mailer settings to not send any emails,
+could look like this:
+
+.. code-block:: php
+
+   namespace MyCompany\MyPackage\EventListener;
+   use TYPO3\CMS\Core\Mail\Event\AfterMailerInitializationEvent;
+
+   class NullMailer
+   {
+       public function __invoke(AfterMailerInitializationEvent $event): void
+       {
+           $event->getMailer()->injectMailSettings(['transport' => 'null']);
+       }
+   }
+
+An extension can define multiple listeners.
+
+Once the emitter is triggering an Event, this listener is called automatically. Be sure
+to inspect the Event PHP class to fully understand the capabilities provided by an Event.
+
+Best Practices:
+
+1. When configuring Listeners, it is recommended to add one Listener class per Event type, and
+have it called via `__invoke()`.
+
+2. When creating a new Event PHP class, it is recommended to add a `Event` suffix to the PHP class,
+and to move it into an appropriate folder e.g. `Classes/Database/Event` to easily discover
+Events provided by a package. Be careful about the context that should be exposed.
+
+3. Emitters (TYPO3 Core or Extension Authors) should always use Dependency Injection to receive the
+EventDispatcher object as a constructor argument, where possible, by adding a type declaration
+for :php:`Psr\EventDispatcher\EventDispatcherInterface`.
+
+Any kind of Event provided by TYPO3 Core falls under TYPO3's Core API deprecation policy, except
+for its constructor arguments, which may vary. Events that should only be used within TYPO3 Core,
+are marked as `@internal`, just like other non-API parts of TYPO3, but `@internal` Events will be
+avoided whenever technically possible.
+
+.. index:: PHP-API, ext:core