TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/10.2/Deprecation-85592-DeprecatedSiteTitleConfiguration.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85592:
+
+=========================================================
+Deprecation: #85592 - Deprecated site title configuration
+=========================================================
+
+See :issue:`85592`
+
+Description
+===========
+
+Defining the site title in the sys_template record (`sys_template.sitetitle` field) has been deprecated and should not be
+used any longer. This field (database and TCA) will be removed in v11.
+
+
+Impact
+======
+
+The field will be removed in version 11. In version 10 the site title in the sys_template will be used as a
+fallback when no Site title is set in the site configuration.
+
+
+Affected Installations
+======================
+
+Instances defining the site title in the sys_template record.
+
+
+Migration
+=========
+
+Copy the site title to the new available field in the site module language configuration.
+
+.. index:: Frontend, NotScanned

Documentation/Changelog/10.2/Deprecation-88238-AllowedMimeTypesOfFileUploadAndImageUpload.rst

@@ -0,0 +1,99 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88238:
+
+======================================================================
+Deprecation: #88238 - Allowed MIME types of FileUpload and ImageUpload
+======================================================================
+
+See :issue:`88238`
+
+Description
+===========
+
+The predefined :yaml:`allowedMimeTypes` of the :yaml:`FileUpload` and :yaml:`ImageUpload` form elements are deprecated and should not be relied on any longer. These will be removed in TYPO3v11.
+
+The "form" extension setup did contain some predefined MIME types for the elements :yaml:`FileUpload` and :yaml:`ImageUpload`:
+
+.. code-block:: yaml
+
+   TYPO3:
+     CMS:
+       Form:
+         prototypes:
+           standard:
+             formElementsDefinition:
+               FileUpload:
+                 properties:
+                   allowedMIMETypes: ['application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'application/vnd.oasis.opendocument.text', 'application/pdf']
+
+               ImageUpload:
+                 properties:
+                   allowedMIMETypes: ['image/jpeg', 'image/png', 'image/bmp']
+
+
+Predefined values like this are used as starting values while the form element is created and later on, values from the form definition are merged.
+
+Thus, a form definition like this:
+
+.. code-block:: yaml
+
+   type: Form
+   identifier: test-1
+   label: test
+   prototypeName: standard
+   renderables:
+     -
+       type: Page
+       identifier: page-1
+       label: Step
+       renderables:
+         -
+           type: FileUpload
+           identifier: fileupload-1
+           label: 'File upload'
+           properties:
+             saveToFileMount: '1:/user_upload/'
+             allowedMIMETypes:
+               - application/pdf
+
+
+... resulted in a final form element definition like this:
+
+.. code-block:: yaml
+
+        type: FileUpload
+        identifier: fileupload-1
+        label: 'File upload'
+        properties:
+          saveToFileMount: '1:/user_upload/'
+          allowedMIMETypes:
+            - application/msword
+            - application/vnd.openxmlformats-officedocument.wordprocessingml.document
+            - application/vnd.oasis.opendocument.text
+            - application/pdf
+
+
+The expected behavior was that only files of type :code:`application/pdf` are accepted, but actually all preconfigured MIME types within the ext:form setup were also valid.
+
+To make the MIME type validation of :yaml:`FileUpload` and :yaml:`ImageUpload` more strict, the preconfigured MIME types have been deprecated and will be removed in TYPO3v11.
+
+
+Impact
+======
+
+The predefined MIME types will be removed in version 11. In version 10 the feature toggle :code:`form.legacyUploadMimeTypes` can be disabled to enforce the new behavior.
+
+
+Affected Installations
+======================
+
+Instances which use the "form" extension with :yaml:`FileUpload` or :yaml:`ImageUpload` form elements.
+
+
+Migration
+=========
+
+Explicitly list all valid MIME types in :yaml:`allowedMimeTypes` within your form definition. Afterwards disable the :code:`form.legacyUploadMimeTypes` feature flag.
+
+.. index:: Frontend, NotScanned, ext:form

Documentation/Changelog/10.2/Deprecation-89331-FormEngineLegacyFunctions.rst

@@ -0,0 +1,81 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89331:
+
+=================================================
+Deprecation: #89331 - FormEngine legacy functions
+=================================================
+
+See :issue:`89331`
+
+Description
+===========
+
+The FormEngine supports global callback functions executed on certain interactions. Such functions were overridden and
+spread through some extensions which are not related to FormEngine at all.
+
+These functions have been marked as deprecated:
+
+* :js:`setFormValueOpenBrowser()`
+* :js:`setFormValueFromBrowseWin()`
+* :js:`setHiddenFromList()`
+* :js:`setFormValueManipulate()`
+* :js:`setFormValue_getFObj()`
+
+The function :js:`setFormValueFromBrowseWin()` is also called by `ElementBrowser`. Extensions not related to FormEngine
+are able to override this function and inject custom handling. This approach has been marked as deprecated as well.
+
+
+Impact
+======
+
+Calling a deprecated function will trigger a warning in the browser console.
+
+
+Affected Installations
+======================
+
+All installations using 3rd party extensions calling any of these deprecated functions are affected.
+
+
+Migration
+=========
+
+Some functions can be used in FormEngine context only from now on. Load the module `TYPO3/CMS/Backend/FormEngine` and
+use the according replacements:
+
+* :js:`setFormValueOpenBrowser()` - use :js:`FormEngine.openPopupWindow()` instead
+* :js:`setFormValueFromBrowseWin()` - use :js:`FormEngine.setSelectOptionFromExternalSource()` instead
+* :js:`setHiddenFromList()` - use :js:`FormEngine.updateHiddenFieldValueFromSelect()` instead
+* :js:`setFormValueManipulate()` - no replacement, this is internal logic for form controls separated into according modules
+* :js:`setFormValue_getFObj()` - use :js:`FormEngine.getFormElement()` instead
+
+If :js:`setFormValueFromBrowseWin()` is not used within a FormEngine context, it is possible to listen to the
+:js:`message` event.
+
+Example code:
+
+.. code-block:: js
+
+   require(['TYPO3/CMS/Backend/Utility/MessageUtility'], function (MessageUtility) {
+     window.addEventListener('message', function (e) {
+       // MessageUtility.MessageUtility is correct as this is not an AMD module
+       if (!MessageUtility.MessageUtility.verifyOrigin(e.origin)) {
+         throw 'Denied message sent by ' + e.origin;
+       }
+
+       if (typeof e.data.fieldName === 'undefined') {
+         throw 'fieldName not defined in message';
+       }
+
+       if (typeof e.data.value === 'undefined') {
+         throw 'value not defined in message';
+       }
+
+       const result = e.data.value.split('_');
+       const field = <HTMLInputElement>document.querySelector('input[name="' + e.data.fieldName + '"]');
+       field.value = result[1];
+     });
+   }
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.2/Deprecation-89468-DeprecateInjectionOfEnvironmentServiceInWebRequest.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89468:
+
+==============================================================================
+Deprecation: #89468 - Deprecate injection of EnvironmentService in Web Request
+==============================================================================
+
+See :issue:`89468`
+
+Description
+===========
+
+The EnvironmentService is not needed any longer in the Web
+Request of Extbase, therefore the property and the injection
+method of said property have been marked as deprecated.
+
+
+Impact
+======
+
+As of TYPO3 11.0, the property :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response::$environmentService` will no longer exist. If the
+environment service is needed in a subclass of :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response`, it needs to be injected
+manually.
+
+
+Affected Installations
+======================
+
+All installations that implement subclasses of :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response` and expect an instance of the
+:php:`EnvironmentService` to be injected into :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response::$environmentService`.
+
+
+Migration
+=========
+
+The environment service needs to be injected manually in the subclass.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/10.2/Deprecation-89554-DeprecateTYPO3CMSExtbaseMvcControllerAbstractController.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89554:
+
+==========================================================================================
+Deprecation: #89554 - Deprecate \\TYPO3\\CMS\\Extbase\\Mvc\\Controller\\AbstractController
+==========================================================================================
+
+See :issue:`89554`
+
+Description
+===========
+
+The class :php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController` has been marked as deprecated.
+
+The :php:`AbstractController` is an internal class which never really had any functionality besides
+providing some basic methods for the :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController`. Therefore
+and in order to streamline the codebase of extbase, the :php:`AbstractController` will be removed
+with TYPO3 11.0.
+
+
+Impact
+======
+
+As all functionality of the :php:`AbstractController` has been moved to the :php:`ActionController` there is no impact
+for extbase extensions that used and extended the :php:`ActionController`.
+
+
+Affected Installations
+======================
+
+Installations that extended the :php:`AbstractController` directly.
+
+
+Migration
+=========
+
+Extend the :php:`ActionController`.
+
+
+.. index:: PHP-API, PartiallyScanned, ext:extbase

Documentation/Changelog/10.2/Deprecation-89577-FALSignalSlotHandlingMigratedToPSR-14Events.rst

@@ -0,0 +1,83 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89577:
+
+=======================================================================
+Deprecation: #89577 - FAL SignalSlot handling migrated to PSR-14 events
+=======================================================================
+
+See :issue:`89577`
+
+Description
+===========
+
+Within the File Abstraction Layer, all "Signals" of Extbase's SignalSlot dispatcher have been migrated to PSR-14 events.
+
+For this reason, all FAL-related Signals have been migrated to PSR-14 event listeners which are prioritized as the
+first listener to be executed when an Event is fired.
+
+The following interface has been deprecated and will be removed in TYPO3 v11:
+
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface`
+
+The following constants have been deprecated and will be removed in TYPO3 v11:
+
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface::SIGNAL_PreProcessStorage`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface::SIGNAL_PostProcessStorage`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileCreate`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileReplace`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileSetContents`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileCreate`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileReplace`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileSetContents`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreGeneratePublicUrl`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_SanitizeFileName`
+- :php:`\TYPO3\CMS\Core\Resource\Service\FileProcessingService::SIGNAL_PreFileProcess`
+- :php:`\TYPO3\CMS\Core\Resource\Service\FileProcessingService::SIGNAL_PostFileProcess`
+
+Impact
+======
+
+Calling the Signals still works as before, without any deprecation message triggered in order to still be fully working.
+However, they will likely be removed and stop working in TYPO3 v11.0.
+
+All interfaces and constants which only existed for Signal-Slot related handling have been marked as deprecated.
+The ExtensionScanner will detect any usages of the PHP symbols.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions that hook into FAL-related functionality, e.g. "secure downloads" extension.
+
+
+Migration
+=========
+
+It is highly recommended to use the PSR-14 events and create custom event listeners and not depend on Signals to be
+executed in FAL anymore.
+
+See all core examples, read the documentation about PSR-14 events and investigate especially the :php:`SlotReplacement`
+PHP class on what can listened and modified.
+
+.. index:: FAL, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/10.2/Deprecation-89579-ServiceChainsRequireAnArrayForExcludedServiceKeys.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89579:
+
+==============================================================================
+Deprecation: #89579 - ServiceChains require an array for excluded Service keys
+==============================================================================
+
+See :issue:`89579`
+
+Description
+===========
+
+The Service API within :php:`GeneralUtility::makeInstanceService()` and
+:php:`ExtensionManagementUtility::findService()` has a third argument called
+:php:`$excludeServiceKeys` which is used for skipping certain services when
+using a chain.
+
+The third argument could previously be a comma-separated list
+or an array. The argument now requires an array for consistency
+and performance reasons.
+
+Handing in comma-separated value strings is deprecated and will
+be removed in TYPO3 v11.0.
+
+
+Impact
+======
+
+Calling any of the methods above with a non-array as third argument
+will trigger a deprecation notice.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with custom extensions using the Service API
+directly. Extensions that ship a custom authentication provider
+are not affected.
+
+
+Migration
+=========
+
+Ensure to hand in an array as third argument.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/10.2/Deprecation-89631-UseEnvironmentAPIToFetchApplicationContext.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89631:
+
+======================================================================
+Deprecation: #89631 - Use Environment API to fetch application context
+======================================================================
+
+See :issue:`89631`
+
+Description
+===========
+
+The Environment API, introduced in TYPO3 v9.3, allows access to the current Application Context (Production, Testing or Development).
+
+The method :php:`GeneralUtility::getApplicationContext()` has been deprecated, as the same information is now available in :php:`TYPO3\CMS\Core\Core\Environment::getContext()`.
+
+
+Impact
+======
+
+Calling the GeneralUtility method will trigger a PHP deprecation warning.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third-party extension calling the method directly.
+
+
+Migration
+=========
+
+Use the Environment API call and substitute the method directly.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.2/Deprecation-89718-LegacyPageTSconfigParsingLowlevelAPI.rst

@@ -0,0 +1,74 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89718:
+
+==============================================================
+Deprecation: #89718 - Legacy PageTSconfig parsing lowlevel API
+==============================================================
+
+See :issue:`89718`
+
+Description
+===========
+
+Two new PHP API classes for retrieving and parsing TsConfig are
+introduced:
+
+- :php:`TYPO3\CMS\Core\Configuration\Loader\PageTsConfigLoader`
+- :php:`TYPO3\CMS\Core\Configuration\Parser\PageTsConfigParser`
+
+As this API is more consistent, and flexible, as well as agnostic
+of the current Context of backend or frontend, the following
+functionality has been marked as deprecated:
+
+- :php:`TYPO3\CMS\Core\Configuration\TsConfigParser`
+- :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getRawPagesTSconfig()`
+
+
+Impact
+======
+
+Instantiating the PHP class or the mentioned PHP method will trigger
+a deprecation message.
+
+
+Affected Installations
+======================
+
+TYPO3 Installations with extensions using the lowlevel API for handling PageTSconfig.
+
+
+Migration
+=========
+
+Loading and parsing PageTSconfig on a low-level should be done via the new PHP classes:
+
+- :php:`TYPO3\CMS\Core\Configuration\Loader\PageTsConfigLoader`
+- :php:`TYPO3\CMS\Core\Configuration\Parser\PageTsConfigParser`
+
+Usages for fetching all available PageTS of a page/rootline in one large string:
+
+.. code-block:: php
+
+   $loader = GeneralUtility::makeInstance(PageTsConfigLoader::class);
+   $tsConfigString = $loader->load($rootLine);
+
+
+The string is parsed (and conditions are applied) with the Parser:
+
+.. code-block:: php
+
+      $parser = GeneralUtility::makeInstance(
+       PageTsConfigParser::class,
+       $typoScriptParser,
+       $hashCache
+   );
+   $pagesTSconfig = $parser->parse(
+       $tsConfigString,
+       $conditionMatcher
+   );
+
+Extension developers should rely on this syntax rather than
+on :php:`$GLOBALS['TSFE']->getPagesTSconfig()` or :php:`BackendUtility::getPagesTsConfig()`, or the deprecated method / class.
+
+.. index:: PHP-API, TSConfig, FullyScanned, ext:core

Documentation/Changelog/10.2/Deprecation-89722-GMENU_LAYERSRelatedPropertyTSFE-divSection.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89722:
+
+====================================================================
+Deprecation: #89722 - GMENU_LAYERS related property TSFE->divSection
+====================================================================
+
+See :issue:`89722`
+
+Description
+===========
+
+The public PHP property :php:`TypoScriptFrontendController->divSection` has been marked as deprecated. This was used in prior
+TYPO3 versions to add dynamic JavaScript related to GMENU_LAYERS
+functionality which was removed with previous TYPO3 versions, making
+this property only produce unnecessary overhead in frontend rendering.
+
+
+Impact
+======
+
+Accessing or setting this property will trigger a deprecation notice.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions explicitly accessing this property, which is highly unlikely as this property is very lowlevel.
+
+
+Migration
+=========
+
+If there is a need to add JavaScript within uncached content, use
+:php:`$GLOBALS['TSFE']->additionalHeaderData[]` instead.
+
+.. index:: Frontend, FullyScanned, ext:frontend

Documentation/Changelog/10.2/Deprecation-89733-SignalSlotsInCoreExtensionMigratedToPSR-14Events.rst

@@ -0,0 +1,84 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89733:
+
+==============================================================================
+Deprecation: #89733 - Signal Slots in Core Extension migrated to PSR-14 events
+==============================================================================
+
+See :issue:`89733`
+
+Description
+===========
+
+The following Signal Slots have been replaced by new PSR-14 events
+which can be used as 1:1 equivalents:
+
+- :php:`TYPO3\CMS\Backend\Backend\ToolbarItems\SystemInformationToolbarItem::getSystemInformation`
+- :php:`TYPO3\CMS\Backend\Backend\ToolbarItems\SystemInformationToolbarItem::loadMessages`
+- :php:`TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::getPageRenderer`
+- :php:`TYPO3\CMS\Backend\Controller\EditDocumentController::preInitAfter`
+- :php:`TYPO3\CMS\Backend\Controller\EditDocumentController::initAfter`
+- :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfigPreInclude`
+- :php:`TYPO3\CMS\Beuser\Controller\BackendUserController::switchUser`
+- :php:`TYPO3\CMS\Core\Database\SoftReferenceIndex::setTypoLinkPartsElement`
+- :php:`TYPO3\CMS\Core\Database\ReferenceIndex::shouldExcludeTableFromReferenceIndex`
+- :php:`TYPO3\CMS\Core\Imaging\IconFactory::buildIconForResourceSignal`
+- :php:`TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider::PostProcessTreeData`
+- :php:`TYPO3\CMS\Core\Utility\ExtensionManagementUtility::tcaIsBeingBuilt`
+- :php:`TYPO3\CMS\Impexp\Utility\ImportExportUtility::afterImportExportInitialisation`
+- :php:`TYPO3\CMS\Install\Service\SqlExpectedSchemaService::tablesDefinitionIsBeingBuilt`
+- :php:`TYPO3\CMS\Lang\Service\TranslationService::postProcessMirrorUrl`
+- :php:`TYPO3\CMS\Linkvalidator\LinkAnalyzer::beforeAnalyzeRecord`
+- :php:`TYPO3\CMS\Seo\Canonical\CanonicalGenerator::beforeGeneratingCanonical`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss`
+
+In addition, the following public constants, marking a signal name, are deprecated:
+
+- :php:`TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider::SIGNAL_PostProcessTreeData`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss`
+
+Impact
+======
+
+Using the mentioned signals will trigger a deprecation warning.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using these signals.
+
+Migration
+=========
+
+Use the new PSR-14 alternatives:
+
+- :php:`TYPO3\CMS\Backend\Authentication\Event\SwitchUserEvent`
+- :php:`TYPO3\CMS\Backend\Backend\Event\SystemInformationToolbarCollectorEvent`
+- :php:`TYPO3\CMS\Backend\Controller\Event\BeforeFormEnginePageInitializedEvent`
+- :php:`TYPO3\CMS\Backend\Controller\Event\AfterFormEnginePageInitializedEvent`
+- :php:`TYPO3\CMS\Backend\LoginProvider\Event\ModifyPageLayoutOnLoginProviderSelectionEvent`
+- :php:`TYPO3\CMS\Core\Imaging\Event\ModifyIconForResourcePropertiesEvent`
+- :php:`TYPO3\CMS\Core\DataHandling\Event\IsTableExcludedFromReferenceIndexEvent`
+- :php:`TYPO3\CMS\Core\DataHandling\Event\AppendLinkHandlerElementsEvent`
+- :php:`TYPO3\CMS\Core\Configuration\Event\AfterTcaCompilationEvent`
+- :php:`TYPO3\CMS\Core\Database\Event\AlterTableDefinitionStatementsEvent`
+- :php:`TYPO3\CMS\Core\Tree\Event\ModifyTreeDataEvent`
+- :php:`TYPO3\CMS\Core\Configuration\Event\ModifyLoadedPageTsConfigEvent`
+- :php:`TYPO3\CMS\Impexp\Event\BeforeImportEvent`
+- :php:`TYPO3\CMS\Install\Service\Event\ModifyLanguagePackRemoteBaseUrlEvent`
+- :php:`TYPO3\CMS\Linkvalidator\Event\BeforeRecordIsAnalyzedEvent`
+- :php:`TYPO3\CMS\Seo\Event\ModifyUrlForCanonicalTagEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\AfterCompiledCacheableDataForWorkspaceEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\AfterDataGeneratedForWorkspaceEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\GetVersionedDataEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\SortVersionedDataEvent`
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.2/Deprecation-89742-FormMixins.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89742:
+
+=================================
+Deprecation: #89742 - Form mixins
+=================================
+
+See :issue:`89742`
+
+Description
+===========
+
+All mixins in the "form" extension have been deprecated and should not be used anymore. This affects all inheritances from :yaml:`TYPO3.CMS.Form.mixins.*`.
+
+The mixins have been deprecated with TYPO3v10 and will be removed with TYPO3v11.
+
+
+Impact
+======
+
+Form setup inheriting mixins from :yaml:`TYPO3.CMS.Form.mixins.*` will trigger a deprecation warning in TYPO3v10.
+
+With TYPO3v11 these mixins will be removed which will lead to an error.
+
+
+Affected Installations
+======================
+
+Instances using the "form" extension and inheriting from :yaml:`TYPO3.CMS.Form.mixins.*` in their form setup.
+
+
+Migration
+=========
+
+Embed the essential parts from :yaml:`TYPO3.CMS.Form.mixins.*` or migrate them to custom mixins.
+
+.. index:: Backend, Frontend, NotScanned, ext:form

Documentation/Changelog/10.2/Deprecation-89756-BackendUtilityTYPO3_copyRightNotice.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89756:
+
+===========================================================
+Deprecation: #89756 - BackendUtility::TYPO3_copyRightNotice
+===========================================================
+
+See :issue:`89756`
+
+Description
+===========
+
+The PHP method :php:`TYPO3\CMS\Backend\Utility\BackendUtility::TYPO3_copyRightNotice` that is
+used to display information about the warranty and copyright of the product, e.g. used in the
+login screen, has been superseded by a new API :php:`TYPO3\CMS\Core\Information\Typo3Information`.
+
+The existing static method has been marked as deprecated.
+
+
+Impact
+======
+
+Calling the method will trigger a deprecation warning, but work as
+before until TYPO3 v11.0.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions explicitly calling this
+method. Run the Extension Scanner in the "Upgrade" module to see
+if you are affected.
+
+
+Migration
+=========
+
+Use the new :php:`Typo3Information` PHP class, and its method :php:`getCopyrightNotice()` which will return the same output.
+
+.. index:: PHP-API, FullyScanned, ext:backend

Documentation/Changelog/10.2/Feature-79445-AddMultistepWizard.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-79445:
+
+======================================
+Feature: #79445 - Add Multistep Wizard
+======================================
+
+See :issue:`79445`
+
+Description
+===========
+
+Based on a concept - which has been created during the TYPO3 UX week - a new JavaScript module :js:`MultiStepWizard` has been introduced.
+
+Compared to the existing :js:`Wizard` - which is currently in use e.g. when translating content or creating a new form - the following changes have been implemented:
+
+* Navigation to previous steps is possible.
+* Instead of labeling steps with just a numerical indicator (like "Step x of y") steps can have descriptive labels like "Start" or "Finish!".
+* The structure of the configuration has been optimized.
+
+Code examples:
+
+.. code-block:: js
+
+   // Show/ hide the wizard
+   MultiStepWizard.show();
+   MultiStepWizard.dismiss();
+
+   // Add a slide to the wizard
+   MultiStepWizard.addSlide(
+       identifier,
+       stepTitle,
+       content,
+       severity,
+       progressBarTitle,
+       function() {
+       ...
+       }
+   );
+
+   // Lock/ unlock navigation buttons
+   MultiStepWizard.lockNextStep();
+   MultiStepWizard.unlockNextStep();
+   MultiStepWizard.lockPrevStep();
+   MultiStepWizard.unlockPrevStep();
+
+
+Impact
+======
+
+Developers can provide editors with a vastly enhanced wizard. The UI and UX of the wizard have been improved big time.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/10.2/Feature-79445-ImproveFormCreationWizard.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-79445-1668719171:
+
+==============================================
+Feature: #79445 - Improve form creation wizard
+==============================================
+
+See :issue:`79445`
+
+Description
+===========
+
+Based on a concept - which has been created during the TYPO3 UX week - the form creation wizard has been improved
+greatly. This results in a vast enhancement of the user experience. In detail the following changes have been
+implemented:
+
+* The user interface has been visually refurbished and rearranged.
+* Step 3 has been removed, it just confirmed the successful form creation.
+* Previous steps are now accessible.
+* Steps now have descriptive labels like "Start" or "Finish!".
+
+This is achieved with the new JavaScript module :js:`MultiStepWizard`.
+
+
+Impact
+======
+
+Editors will find a vastly enhanced form creation wizard. The UI and UX of the wizard have been improved big time.
+
+.. index:: Backend, ext:form

Documentation/Changelog/10.2/Feature-82706-RenderFieldsetLabelsInFormTemplates.rst

@@ -0,0 +1,28 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-82706:
+
+==========================================================
+Feature: #82706 - Render fieldset labels in form templates
+==========================================================
+
+See :issue:`82706`
+
+Description
+===========
+
+The section element :yaml:`Fieldset` is now accessible in templates of the "form" extension and can be used to add more structure.
+
+By default this affects the :yaml:`SummaryPage` form element as well as the :yaml:`EmailToReceiver` / :yaml:`EmailToSender` finishers.
+
+A common use case are two fieldsets for a delivery and a billing address where the fields within the fieldset are usually named the same. Till now, the default mail sent by the "form" extension would e.g. show "Street" twice without giving a hint about the context. Now the fieldset label is rendered in between to separate those fields.
+
+
+Impact
+======
+
+The summary page of the "form" extension and mails now show fieldset labels as separators.
+
+Custom templates have access to the fieldset element for rendering.
+
+.. index:: Frontend, ext:form

Documentation/Changelog/10.2/Feature-84203-UnifyFormSetupYAMLLoading.rst

@@ -0,0 +1,26 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84203:
+
+===============================================
+Feature: #84203 - Unify form setup YAML loading
+===============================================
+
+See :issue:`84203`
+
+Description
+===========
+
+Form setup files of the "form" extension now make use of the TYPO3 core YAML file loader. This allows
+using the known TYPO3 core features:
+
+* import of other YAML files via :yaml:`imports` directive
+* replacement of :yaml:`%placeholders%`
+
+
+Impact
+======
+
+Form setups can now be structured more freely by splitting logical parts into separate files.
+
+.. index:: Backend, Frontend, ext:form

Documentation/Changelog/10.2/Feature-84713-AccessSingleFormValuesInTemplates.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84713:
+
+========================================================
+Feature: #84713 - Access single values in form templates
+========================================================
+
+See :issue:`84713`
+
+Description
+===========
+
+It is now possible to access single form values in templates of the "form" extension. For this a new :php:`RenderFormValueViewHelper` has been added which complements the existing :php:`RenderAllFormValuesViewHelper`.
+
+The :php:`RenderFormValueViewHelper` accepts a single form element and renders it exactly like the :php:`RenderAllFormValuesViewHelper` used to do within its internal traversal of renderable elements:
+
+To make it possible to access single form elements, a new method :php:`FormDefinition::getElements()` has been added. This method returns an array containing all elements in the form with their identifiers as keys.
+
+Viewhelper usage in mail templates:
+
+.. code-block:: html
+
+   <p>The following message was just sent by <b><formvh:renderFormValue renderable="{form.formDefinition.elements.name}" as="formValue">{formValue.processedValue}</formvh:renderFormValue><b>:</p>
+
+   <blockquote>
+      <formvh:renderFormValue renderable="{form.formDefinition.elements.message}" as="formValue">
+         {formValue.processedValue}
+      </formvh:renderFormValue>
+   </blockquote>
+
+See which elements are accessible in mail templates:
+
+.. code-block:: html
+
+   <f:debug>{form.formDefinition.elements}</f:debug>
+
+Viewhelper usage in the `SummaryPage` partial:
+
+.. code-block:: html
+
+   <p>The following message was just sent by <b><formvh:renderFormValue renderable="{page.rootForm.elements.name}" as="formValue">{formValue.processedValue}</formvh:renderFormValue><b>:</p>
+
+   <blockquote>
+      <formvh:renderFormValue renderable="{page.rootForm.elements.message}" as="formValue">
+         {formValue.processedValue}
+      </formvh:renderFormValue>
+   </blockquote>
+
+See which elements are accessible in the `SummaryPage` partial:
+
+.. code-block:: html
+
+   <f:debug>{page.rootForm.elements}</f:debug>
+
+.. attention::
+   The form elements are accessed differently depending on the kind of template.
+   In mail templates `{form.formDefinition.elements}` is used,
+   in the `SummaryPage` partial `{page.rootForm.elements}` is used.
+
+Impact
+======
+
+Form values can now be placed freely in Fluid templates of the "form" extension instead of being bound to traverse all form values and skip rendering.
+
+.. index:: Fluid, Frontend, ext:form

Documentation/Changelog/10.2/Feature-84990-AddEventForCheckingExternalLinksInRTE.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84990-1668719171:
+
+==============================================================
+Feature: #84990 - Add event for checking external links in RTE
+==============================================================
+
+See :issue:`84990`
+
+Description
+===========
+
+A new PSR-14-based event :php:`TYPO3\CMS\Core\Html\Event\BrokenLinkAnalysisEvent`
+can be used to get information about broken links set in the rich text editor (RTE).
+
+Up until now, TYPO3 only displayed page links with extra markup (yellow background with red
+border) if a link would point to an internal page which does not exist anymore.
+
+This was previously checked internally in RTE, and is now moved to an Event Listener to make
+this check more flexible and interchangeable.
+
+The procedure for marking the broken links in the RTE is as follow:
+
+#. RTE content is fetched from the database. Before it is displayed in
+   the edit form, RTE transformations are performed.
+#. The transformation function parses the text and detects links.
+#. For each link, a new PSR-14 event is dispatched.
+#. If a listener is attached, it may set the link as broken and will set
+   the link as "checked".
+#. If a link is detected as broken, RTE will mark it as broken.
+
+An implementation for external and page links is now supplied by the system
+extension linkvalidator. External links are currently checked using the existing
+`tx_linkvalidator_links` table.
+
+Other extensions can use the event to override the default behaviour.
+
+
+Impact
+======
+
+The behaviour for page links stays the same - they are also marked if
+they do not exist anymore - however, marking the links is now unified and only available
+when the system extension `linkvalidator` is installed.
+
+If linkvalidator is installed and regularly crawls for broken links, broken external links
+will be marked as well.
+
+If linkvalidator is used, it is recommended to use the scheduler to regularly crawl for broken links.
+
+
+.. index:: RTE, ext:linkvalidator

Documentation/Changelog/10.2/Feature-84990-MarkBrokenFileLinksInRTE.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84990:
+
+===============================================
+Feature: #84990 - Mark broken file links in RTE
+===============================================
+
+See :issue:`84990`
+
+Description
+===========
+
+Links to files that were detected as broken by the system extension
+`linkvalidator` are now marked accordingly in the RTE via
+:php:`TYPO3\CMS\Core\Html\Event\BrokenLinkAnalysisEvent`.
+
+Those links are now marked with extra markup (yellow background with
+red border) in RTE.
+
+The procedure for marking the broken links in the RTE is as follow:
+
+#. RTE content is fetched from the database. Before it is displayed in
+   the edit form, RTE transformations are performed.
+#. The transformation function parses the text and detects links.
+#. For each link, a new PSR-14 event is dispatched.
+#. If a listener is attached, it may set the link as broken and will set
+   the link as "checked".
+#. If a link is detected as broken, RTE will mark it as broken.
+
+The implementation for checking file links is supplied by the system
+extension `linkvalidator`.
+
+Other extensions can use the event to override the default behaviour.
+
+
+Impact
+======
+
+The behaviour stays the same as before unless the system extension `linkvalidator`
+is installed.
+
+If `linkvalidator` is installed and regularly checks for broken file links, those
+links will be marked in the RTE.
+
+If `linkvalidator` is used, it is recommended to use the scheduler to regularly
+check for broken links.
+
+
+.. index:: RTE, ext:linkvalidator

Documentation/Changelog/10.2/Feature-85592-AddSiteTitleConfigurationToSitesModule.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85592:
+
+==============================================================
+Feature: #85592 - Add site title configuration to sites module
+==============================================================
+
+See :issue:`85592`
+
+Description
+===========
+
+The site title can now be configured within the sites module instead of using the field in the system template record.
+This allows now a different site title per language.
+
+This site title will be used for the page title as well as for future schema.org integrations.
+
+
+Impact
+======
+
+The new way allows now to have a different site title per language.
+
+The old way using the system template record has been deprecated and will be removed in TYPO3 v11. When you have set
+the site title in your site configuration, it will take precedence over your TypoScript setting. Overriding your
+site title with a TypoScript extension template is not possible anymore when using the site configuration.
+
+.. index:: Backend, Frontend

Documentation/Changelog/10.2/Feature-86759-SupportNomoduleAttributeForJavaScriptIncludes.rst

@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86759:
+
+====================================================================
+Feature: #86759 - Support nomodule attribute for JavaScript includes
+====================================================================
+
+See :issue:`86759`
+
+Description
+===========
+
+When including JavaScript files in TypoScript, the HTML5 attribute :html:`nomodule` is now
+supported.
+
+See https://html.spec.whatwg.org/multipage/scripting.html#attr-script-nomodule
+
+.. code-block:: typoscript
+
+   page.includeJSFooter.file = path/to/file.js
+   page.includeJSFooter.file.nomodule = 1
+
+.. index:: TypoScript

Documentation/Changelog/10.2/Feature-86818-ReintroduceKeyboardAccessibleVersionOfThePagetree.rst

@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86818:
+
+=========================================================================
+Feature: #86818 - Reintroduce keyboard accessible version of the pagetree
+=========================================================================
+
+See :issue:`86818`
+
+Description
+===========
+
+This feature makes the pagetree focusable via keyboard using the tab key. Now it is also possible to use
+arrows, home and end keys in order to navigate through the pagetree. Besides that, using enter and
+space keys will open the page in the according content area.
+
+Of course, it is still possible to use both mouse and keyboard navigation.
+
+This change follows the best practices as described in WAI-ARIA Authoring Practices 1.1,
+see the `W3 document`_ for further reading.
+
+.. _W3 document: https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard-interaction-22
+
+Impact
+======
+
+Added :html:`tabindex`, :html:`role`, :html:`aria-*` and :html:`id` attributes to pagetree elements
+as advised in WAI-ARIA Authoring Practices 1.1. Screenreaders are now able to recognize the pagetree as
+tree element.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/10.2/Feature-86918-AddAdditionalConfigurationForExternalLinkTypesInLinkvalidator.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86918:
+
+=======================================================================================
+Feature: #86918 - Add additional configuration for external link types in Linkvalidator
+=======================================================================================
+
+See :issue:`86918`
+
+Description
+===========
+
+Additional configuration is added for crawling external links:
+
+.. code-block:: typoscript
+
+    mod.linkvalidator {
+
+        linktypesConfig {
+           external {
+
+              # User-Agent string is filled with information about the crawling site
+              httpAgentName = TYPO3 Linkvalidator
+              httpAgentUrl =
+              httpAgentEmail =
+
+              headers {
+              }
+
+              method = HEAD
+
+              range = 0-4048
+           }
+        }
+
+For a description of the fields, see the linkvalidator documentation:
+https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us//Configuration/Index.html
+
+It is recommended to fill out `httpAgentUrl` and `httpAgentEmail` so that the User-Agent
+string is filled for crawling external URLs.
+
+For headers, method and range it is recommended to stick with the default values.
+
+Impact
+======
+
+It is possible to configure information for the 'User-Agent' string as is customary
+for crawlers.
+
+The settings 'headers', 'method' and 'range' are advanced settings. They can be used to
+optimize the crawling.
+
+Recommendation
+==============
+
+Set the settings httpAgentUrl and httpAgentEmail. Details can be found in the
+linkvalidator documentation.
+
+
+
+.. index:: ext:linkvalidator

Documentation/Changelog/10.2/Feature-86967-AllowFetchingUidOfALazyLoadingProxyWithoutLoadingTheObjectFirst.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86967:
+
+===========================================================================================
+Feature: #86967 - Allow fetching uid of a LazyLoadingProxy without loading the object first
+===========================================================================================
+
+See :issue:`86967`
+
+Description
+===========
+
+A method :php:`getUid()` has been added to class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyLoadingProxy` which
+allows for fetching the uid of the proxied object without fetching the object data itself from the database.
+
+Impact
+======
+
+The method :php:`getUid()` can be used to fetch the uid of objects for a quick comparison with other objects of the same
+type which increases the performance of such comparisons a lot.
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/10.2/Feature-87798-ProvideAWayToSortFormListsInExtform.rst

@@ -0,0 +1,68 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87798:
+
+==============================================================
+Feature: #87798 - Provide a way to sort form lists in ext:form
+==============================================================
+
+See :issue:`87798`
+
+Description
+===========
+
+Forms in ext:form were previously not sorted in any manner,
+but just outputted in the order they were read from the filesystem's directories.
+
+Forms can now be sorted by multiple keys in either ascending or descending order.
+Two new settings were introduced: ``sortByKeys`` and ``sortAscending``.
+
+Here is an example configuration,
+that will sort forms by their name first and by their file uid second:
+
+.. code-block:: yaml
+
+   TYPO3:
+        CMS:
+          Form:
+            persistenceManager:
+              sortByKeys: ['name', 'fileUid']
+              sortAscending: true
+
+Valid keys, by which the forms can be sorted, are:
+
+``name``
+   The forms name.
+
+``identifier``
+   The filename.
+
+``fileUid``
+   The files uid.
+
+``persistenceIdentifier``
+   The files location.
+
+   Example: ``1:/form_definitions/contact.form.yaml``
+
+``readOnly``
+   Is the form readonly?
+
+``removable``
+   Is the form removable?
+
+``location``
+   Either `storage` or `extension`
+
+``invalid``
+   Does the form have an error?
+
+Impact
+======
+
+Forms will now initially be sorted by their name first and their file uid second in an ascending order.
+This affects both the form list shown in the form module as well as the ordering of the available select options when creating a new form content element.
+
+To change the sorting, you can override the configuration via YAML as described by the example above.
+
+.. index:: Backend, ext:form

Documentation/Changelog/10.2/Feature-88102-FrontendLoginViaFluidAndExtbase.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88102:
+
+===========================================================
+Feature: #88102 - Frontend Login Form Via Fluid And Extbase
+===========================================================
+
+See :issue:`88102`
+
+Description
+===========
+
+The system extension "felogin" now has two plugins. The original plugin which was built via the "PiBase" Plugin
+Framework and Marker-based templates continues to work, but is superseded with a new Extbase- and Fluid-based plugin,
+allowing to customize templates just like any other modern plugin.
+
+A new feature toggle is introduced to switch between the "PiBase" plugin and the Extbase plugin, which can be switched
+in the Install Tool. For existing installations, the default "PiBased" plugin is activated.
+
+Migration
+=========
+
+To migrate existing Frontend Login Form plugins an update wizard called "Migrate felogin plugins to use extbase CType"
+is provided. The wizard can also be used to switch back from the Extbase version to PiBase.
+
+When using extbase, fluid templates are used to display the depending content. These can be overridden via TypoScript
+for customization. All existing templates are found in
+
+EXT:felogin/Resources/Private/Templates/{Login,PasswordRecovery}
+
+Examples
+========
+
+Overriding Templates:
+All templates are now fluid based, which means they can be overridden by other extensions via typoscript. For example:
+
+To overwrite the :php:`\TYPO3\CMS\FrontendLogin\Controller\LoginController::loginAction()` template with an own one
+located in :file:`EXT:my_extension/Resources/Private/Templates/Felogin/Login/Login.html`, the following config will do
+the trick.
+
+.. code-block:: typoscript
+
+   plugin.tx_felogin_login {
+     view {
+       templateRootPaths {
+         10 = EXT:my_extension/Resources/Private/Templates/Felogin/
+       }
+     }
+   }
+
+.. index:: Frontend, LocalConfiguration, ext:felogin

Documentation/Changelog/10.2/Feature-88110-FeloginExtbasePasswordRecovery.rst

@@ -0,0 +1,100 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88110:
+
+===================================================
+Feature: #88110 - Felogin extbase password recovery
+===================================================
+
+See :issue:`88110`
+
+Description
+===========
+
+As part of the felogin extbase plugin, a password recovery form has been added.
+
+FE users are able to request a password change via email. A mail with a forgot hash will be send to the requesting user.
+If that hash is found valid a reset password form is shown. If all validators are met the users password will be updated.
+
+There is a way to define and override default validators. Configured as default are two validators: NotEmptyValidator and StringLengthValidator.
+
+They can be overridden by overwriting :typoscript:`plugin.tx_felogin_login.settings.passwordValidators`.
+Default is as follows:
+
+.. code-block:: typoscript
+
+   passwordValidators {
+      10 = TYPO3\CMS\Extbase\Validation\Validator\NotEmptyValidator
+      20 {
+         className = TYPO3\CMS\Extbase\Validation\Validator\StringLengthValidator
+         options {
+            minimum = {$styles.content.loginform.newPasswordMinLength}
+         }
+      }
+   }
+
+A custom configuration could look like this:
+
+.. code-block:: typoscript
+
+   passwordValidators {
+      10 = TYPO3\CMS\Extbase\Validation\Validator\AlphanumericValidator
+      20 {
+         className = TYPO3\CMS\Extbase\Validation\Validator\StringLengthValidator
+         options {
+            minimum = {$styles.content.loginform.newPasswordMinLength}
+            maximum = 32
+         }
+      }
+      30 = \Vendor\MyExt\Validation\Validator\MyCustomPasswordPolicyValidator
+   }
+
+Felogin uses FluidMail. The email_templateName variable in TypoScript is mandatory. Depending on the configuration of
+$GLOBALS['TYPO3_CONF_VARS']['MAIL']['format'] the template has to exist as an HTML file, txt file or both. The template
+files have to be placed in the same folder.
+The template paths can be configured via TypoScript. These paths can either be added to the paths configured in
+$GLOBALS['TYPO3_CONF_VARS']['MAIL'] or replace them.
+
+The template paths configuration can be extended as follows:
+
+.. code-block:: typoscript
+
+   plugin.tx_felogin_login {
+     settings {
+       email {
+         templateName = MyRecoveryEmailTemplateName
+
+         layoutRootPaths {
+            30 = EXT:myext/Resources/Private/Layouts/Email/
+         }
+         templateRootPaths {
+           30 = EXT:myext/Resources/Private/Templates/Email/
+         }
+         partialRootPaths {
+           30 = EXT:myext/Resources/Private/Partials/Email/
+         }
+       }
+     }
+   }
+
+To overwrite the template path configuration provided by felogin, it has to be as follows:
+
+.. code-block:: typoscript
+
+   plugin.tx_felogin_login {
+     settings {
+       email{
+         templateRootPaths {
+           20 = EXT:myext/Resources/Private/Templates/Email/
+         }
+       }
+     }
+   }
+
+
+Impact
+======
+
+No direct impact. Only used, if feature toggle "felogin.extbase" is explicitly turned on.
+
+.. index:: Database, FlexForm, Fluid, Frontend, TypoScript, ext:felogin

Documentation/Changelog/10.2/Feature-88238-FeatureToggleFormlegacyUploadMimeTypes.rst

@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88238:
+
+===========================================================
+Feature: #88238 - FeatureToggle: form.legacyUploadMimeTypes
+===========================================================
+
+See :issue:`88238`
+
+Description
+===========
+
+The feature toggle :code:`form.legacyUploadMimeTypes` makes it possible to enable some predefined :yaml:`allowedMimeTypes` in :yaml:`FileUpload` and :yaml:`ImageUpload` form elements.
+
+These MIME types are enabled through this feature toggle by default as of TYPO3v10 and will be removed completely in TYPO3v11.
+
+
+Impact
+======
+
+Full control over file upload MIME type validation can be achieved by disabling this flag and explicitly listing all allowed MIME types.
+
+.. index:: Frontend, ext:form

Documentation/Changelog/10.2/Feature-88902-FeatureSwitchRedirectAndStaticRoutesMiddlewaresCanBeReordered.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88902:
+
+=========================================================================================
+Feature: #88902 - Feature Switch: Redirect and Base Redirect Middlewares can be reordered
+=========================================================================================
+
+See :issue:`88902`
+
+Description
+===========
+
+A new feature switch :php:`rearrangedRedirectMiddlewares` has been introduced to rearrange the middlewares
+:php:`typo3/cms-redirects/redirecthandler` and :php:`typo3/cms-frontend/base-redirect-resolver`. If enabled, the
+middlewares are executed in reversed order, so the :php:`typo3/cms-redirects/redirecthandler` comes first.
+
+The new ordering aims to be a better default shipped by the TYPO3 core but might still need adjustment due to specific
+configuration setups.
+
+The feature switch is turned off by default to assure a non-breaking behaviour.
+
+Impact
+======
+
+If turned on, the new ordering has the following implications:
+
+By putting the :php:`typo3/cms-frontend/base-redirect-resolver` last, redirects are always resolved even if no
+configured base URL was requested. In most cases this is considered to be a bugfix. However, redirect behavior might
+change.
+
+Custom middlewares that have been put in between the two above mentioned middlewares most likely will lead to a circular
+dependency exception now. Such custom middlewares have to be revisited and registered differently.
+
+.. index:: Frontend, NotScanned, ext:redirects

Documentation/Changelog/10.2/Feature-88950-AddStoreSessionArgumentToWidgetViewHelpers.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88950:
+
+===================================================================
+Feature: #88950 - Add "storeSession" argument to Widget ViewHelpers
+===================================================================
+
+See :issue:`88950`
+
+Description
+===========
+
+Widget ViewHelpers, by default, can store the widgets session in the database by utilizing a cookie.
+In frontend context this would automatically create a ``fe_typo_user`` cookie when,
+for instance, the :html:`<f:widget.autocomplete>` ViewHelper is used.
+
+As this is not always a desired behaviour (gdpr),
+a boolean argument ``storeSession`` has been added to :php:`\TYPO3\CMS\Fluid\Core\Widget\AbstractWidgetViewHelper`,
+which defaults to true and can be used to disable session storage for this ViewHelper.
+
+This will automatically create a ``fe_typo_user`` cookie in the frontend:
+
+..  code-block:: html
+
+    <f:widget.autocomplete for="name" objects="{posts}" searchProperty="author" />
+
+This will not create a cookie in frontend:
+
+..  code-block:: html
+
+    <f:widget.autocomplete for="name" objects="{posts}" searchProperty="author" storeSession="false" />
+
+Impact
+======
+
+The default value of the property `storeSession` is set to `true`,
+so no changes need to be done in existing implementations of Widget ViewHelpers.
+
+.. index:: Fluid, ext:fluid

Documentation/Changelog/10.2/Feature-89171-AddedPossibilityToHaveMultipleSitemaps.rst

@@ -0,0 +1,79 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89171:
+
+=============================================================
+Feature: #89171 - Added possibility to have multiple sitemaps
+=============================================================
+
+See :issue:`89171`
+
+Description
+===========
+
+You can now also create multiple different sitemaps. This can be handy for situations, where
+different target systems need them in different format or order. (e.g. Google News Sitemaps)
+
+The syntax looks like this:
+
+.. code-block:: typoscript
+
+   plugin.tx_seo {
+      config {
+         <sitemapType> {
+            sitemaps {
+               <unique key> {
+                  provider = TYPO3\CMS\Seo\XmlSitemap\RecordsXmlSitemapDataProvider
+                  config {
+                     ...
+                  }
+               }
+            }
+         }
+      }
+   }
+
+Example:
+
+.. code-block:: typoscript
+
+   seo_googlenews < seo_sitemap
+   seo_googlenews.typeNum = 1571859552
+   seo_googlenews.10.sitemapType = googleNewsSitemap
+
+   plugin.tx_seo {
+       config {
+           xmlSitemap {
+               sitemaps {
+                   news {
+                       provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider
+                       config {
+                           ...
+                       }
+                   }
+               }
+           }
+           googleNewsSitemap {
+               sitemaps {
+                   news {
+                       provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider
+                       config {
+                           googleNews = 1
+                           ...
+                           template = GoogleNewsXmlSitemap.html
+                       }
+                   }
+               }
+           }
+       }
+   }
+
+
+
+Impact
+======
+
+As it only gives the possibility to add multiple sitemaps, it won't affect any installation unless you add more sitemaps
+yourself.
+
+.. index:: ext:seo

Documentation/Changelog/10.2/Feature-89398-SupportForEnvironmentVariablesInImportsInSiteConfigurations.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89398:
+
+=====================================================================================
+Feature: #89398 - Support for environment variables in imports in site configurations
+=====================================================================================
+
+See :issue:`89398`
+
+Description
+===========
+
+Environment variables are now resolved in imports of site configuration YAML files.
+
+Example:
+
+.. code-block:: yaml
+
+   imports:
+     -
+       resource: 'Env_%env("foo")%.yaml'
+
+
+Impact
+======
+
+It is now possible to use environment variables in imports of site configuration yaml files.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/10.2/Feature-89458-ShowLinkToOnlineDocsInExtensionManager.rst

@@ -0,0 +1,28 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89458:
+
+===============================================================
+Feature: #89458 - Show link to online docs in extension manager
+===============================================================
+
+See :issue:`89458`
+
+Description
+===========
+
+The export of extensions provided by https://extensions.typo3.org has been extended with the link
+to the documentation of an extension. This link is now shown in all lists of extensions as well
+as the detail view of extensions in the extension manager.
+
+It is recommended that extension authors add documentation for their extensions on docs.typo3.org.
+
+However, if an extension provides an external documentation source, the custom link takes precedence
+over any existing documentation at docs.typo3.org.
+
+Impact
+======
+
+Extension documentation links are now available in the extension manager.
+
+.. index:: Backend, ext:extensionmanager

Documentation/Changelog/10.2/Feature-89526-FeatureFlagBetaTranslationServer.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89526-1668719171:
+
+====================================================
+Feature: #89526 - FeatureFlag: betaTranslationServer
+====================================================
+
+See :issue:`89526`
+
+Description
+===========
+
+The feature switch `betaTranslationServer` makes it possible for installations to fetch translations from the new translation server (beta status).
+The new translation server is building labels from Crowdin (https://crowdin.com/project/typo3-cms) instead of the current translation server based on Pootle (https://translation.typo3.org/).
+
+The integration is currently work in progress but will be finished before the LTS release of version 10.
+Once the work has been stabilized and tested well, the feature flag will be removed for 10 and backported for 9.
+
+If you are interested in this topic, join the Crowdin Initiative. All information can be found at https://typo3.org/community/teams/typo3-development/initiatives/localization-with-crowdin/.
+
+
+Impact
+======
+
+Be aware that using this translation server is currently experimental. This means:
+
+- Translations are incomplete and might be removed and added anytime
+- Translations of community extensions are currently not available
+
+.. index:: Backend, Frontend, ext:core

Documentation/Changelog/10.2/Feature-89577-NewPSR-14BasedEventsForFileAbstractionLayer.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89577:
+
+====================================================================
+Feature: #89577 - New PSR-14 based events for File Abstraction Layer
+====================================================================
+
+See :issue:`89577`
+
+Description
+===========
+
+The following new PSR-14 based Events have been introduced:
+
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileAddedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileAddedToIndexEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileContentsSetEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileCopiedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileCreatedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileDeletedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileMarkedAsMissingEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileMetaDataCreatedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileMetaDataDeletedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileMetaDataUpdatedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileMovedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileProcessingEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileRemovedFromIndexEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileRenamedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileReplacedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFileUpdatedInIndexEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFolderAddedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFolderCopiedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFolderDeletedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFolderMovedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterFolderRenamedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\AfterResourceStorageInitializationEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileAddedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileContentsSetEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileCopiedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileCreatedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileDeletedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileMovedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileProcessingEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileRenamedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFileReplacedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFolderAddedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFolderCopiedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFolderDeletedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFolderMovedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeFolderRenamedEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\BeforeResourceStorageInitializationEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\EnrichFileMetaDataEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\GeneratePublicUrlForResourceEvent`
+- :php:`\TYPO3\CMS\Core\Classes\Resource\Event\SanitizeFileNameEvent`
+
+They replace the existing Extbase Signal Slots in the File Abstraction Layer.
+
+Impact
+======
+
+All existing signals and their registered slots will work exactly the same as before, however
+it is highly encouraged to migrate to the new PSR-14 based events.
+
+In addition, all Core hooks using these events have been migrated to new PSR-14 events,
+all new Events have a description when to use them and what the benefits are.
+
+The Event `AfterFileCopiedEvent` in addition also contains the newly created File
+object.
+
+Have a look at the new PHP classes to understand the Events and to learn more about PSR-14.
+
+.. index:: FAL, PHP-API, ext:core

Documentation/Changelog/10.2/Feature-89603-IntroduceNativePaginationForLists.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89603:
+
+=======================================================
+Feature: #89603 - Introduce native pagination for lists
+=======================================================
+
+See :issue:`89603`
+
+Description
+===========
+
+The TYPO3 core provides an interface to implement the native pagination of lists like arrays or
+query results of Extbase.
+
+The foundation of that new interface :php:`\TYPO3\CMS\Core\Pagination\PaginatorInterface` is that
+it's type agnostic. It means, that it doesn't define the type of paginatable objects. It's up to the
+concrete implementations to enable pagination for specific types. The interface only forces you to
+reduce the incoming list of items to an :php:`iterable` sub set of items.
+
+Along with that interface, an abstract paginator class :php:`\TYPO3\CMS\Core\Pagination\AbstractPaginator`
+has been created that implements the base pagination logic for any kind of :php:`Countable` set of
+items while it leaves the processing of items to the concrete paginator class.
+
+
+Impact
+======
+
+Two concrete paginators have been introduced. One for :php:`array` and one for
+:php:`\TYPO3\CMS\Extbase\Persistence\QueryResultInterface` objects.
+
+The introduction of this native support for the pagination of lists enables the creation of a new
+paginate ViewHelper that is type agnostic.
+
+Code-Example for the :php:`ArrayPaginator`:
+
+.. code-block:: php
+
+   // use TYPO3\CMS\Core\Pagination\ArrayPaginator;
+   // use TYPO3\CMS\Core\Pagination\SimplePagination;
+
+   $itemsToBePaginated = ['apple', 'banana', 'strawberry', 'raspberry', 'ananas'];
+   $itemsPerPage = 2;
+   $currentPageNumber = 3;
+
+   $paginator = new ArrayPaginator($itemsToBePaginated, $currentPageNumber, $itemsPerPage);
+   $paginator->getNumberOfPages(); // returns 3
+   $paginator->getCurrentPageNumber(); // returns 3, basically just returns the input value
+   $paginator->getKeyOfFirstPaginatedItem(); // returns 4
+   $paginator->getKeyOfLastPaginatedItem(); // returns 4
+
+   $pagination = new SimplePagination($paginator);
+   $pagination->getAllPageNumbers(); // returns [1, 2, 3]
+   $pagination->getPreviousPageNumber(); // returns 2
+   $pagination->getNextPageNumber(); // returns null
+
+   // …
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.2/Feature-89718-UnifiedPHPAPIForLoadingPageTSconfig.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89718:
+
+==========================================================
+Feature: #89718 - Unified PHP API for loading PageTSconfig
+==========================================================
+
+See :issue:`89718`
+
+Description
+===========
+
+Most parts of TYPO3 Core share duplicate or similar functionality in
+Frontend or Backend context. One of that is the loading and parsing
+of PageTSconfig, the configuration syntax for various places in
+TYPO3 Backend, which can also be used to define Backend Layouts.
+
+In order to streamline this functionality, the loading process of
+gathering all data from a rootline of a page is now simplified in
+a new :php:`PageTsLoader` PHP class.
+
+Additionally, parsing, and additional matching against conditions,
+which was added later-on in 2009 and put on top, is now separated
+properly, building a truly separation of concerns for compiling
+and parsing TSconfig. This is put in the :php:`PageTsConfigParser` PHP class.
+
+
+Impact
+======
+
+When there is the necessity for fetching and loading PageTSconfig,
+it is recommended for extension developers to make use of both new
+PHP classes:
+
+- :php:`TYPO3\CMS\Core\Configuration\Loader\PageTsConfigLoader`
+- :php:`TYPO3\CMS\Core\Configuration\Parser\PageTsConfigParser`
+
+Usages for fetching all available PageTS in one large string (not parsed yet)::
+
+    $loader = GeneralUtility::makeInstance(PageTsConfigLoader::class);
+    $tsConfigString = $loader->load($rootLine);
+
+
+The string can then be put in proper TSconfig array syntax::
+
+            $parser = GeneralUtility::makeInstance(
+                PageTsConfigParser::class,
+                $typoScriptParser,
+                $hashCache
+            );
+            $pagesTSconfig = $parser->parse(
+                $tsConfigString,
+                $conditionMatcher
+            );
+
+Extension developers should rely on this syntax rather than
+on :php:`$GLOBALS['TSFE']->getPagesTSconfig()` or :php:`BackendUtility::getPagesTsConfig()`.
+
+.. index:: PHP-API, TSConfig, ext:core

Documentation/Changelog/10.2/Feature-89733-NewPSR-14EventsForExistingSignalSlotsInCoreExtension.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89733:
+
+===============================================================================
+Feature: #89733 - New PSR-14 events for existing Signal Slots in Core Extension
+===============================================================================
+
+See :issue:`89733`
+
+Description
+===========
+
+PSR-14 EventDispatching allows for TYPO3 Extensions or PHP packages to extend TYPO3 Core functionality in an exchangeable way.
+
+The following new PSR-14 events have been introduced:
+
+- :php:`TYPO3\CMS\Backend\Authentication\Event\SwitchUserEvent`
+- :php:`TYPO3\CMS\Backend\Backend\Event\SystemInformationToolbarCollectorEvent`
+- :php:`TYPO3\CMS\Backend\Controller\Event\BeforeFormEnginePageInitializedEvent`
+- :php:`TYPO3\CMS\Backend\Controller\Event\AfterFormEnginePageInitializedEvent`
+- :php:`TYPO3\CMS\Backend\LoginProvider\Event\ModifyPageLayoutOnLoginProviderSelectionEvent`
+- :php:`TYPO3\CMS\Core\Imaging\Event\ModifyIconForResourcePropertiesEvent`
+- :php:`TYPO3\CMS\Core\DataHandling\Event\IsTableExcludedFromReferenceIndexEvent`
+- :php:`TYPO3\CMS\Core\DataHandling\Event\AppendLinkHandlerElementsEvent`
+- :php:`TYPO3\CMS\Core\Configuration\Event\AfterTcaCompilationEvent`
+- :php:`TYPO3\CMS\Core\Database\Event\AlterTableDefinitionStatementsEvent`
+- :php:`TYPO3\CMS\Core\Tree\Event\ModifyTreeDataEvent`
+- :php:`TYPO3\CMS\Core\Configuration\Event\ModifyLoadedPageTsConfigEvent`
+- :php:`TYPO3\CMS\Impexp\Event\BeforeImportEvent`
+- :php:`TYPO3\CMS\Install\Service\Event\ModifyLanguagePackRemoteBaseUrlEvent`
+- :php:`TYPO3\CMS\Linkvalidator\Event\BeforeRecordIsAnalyzedEvent`
+- :php:`TYPO3\CMS\Seo\Event\ModifyUrlForCanonicalTagEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\AfterCompiledCacheableDataForWorkspaceEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\AfterDataGeneratedForWorkspaceEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\GetVersionedDataEvent`
+- :php:`TYPO3\CMS\Workspaces\Event\SortVersionedDataEvent`
+
+They replace the existing Extbase-based Signal Slots
+
+- :php:`TYPO3\CMS\Backend\Backend\ToolbarItems\SystemInformationToolbarItem::getSystemInformation`
+- :php:`TYPO3\CMS\Backend\Backend\ToolbarItems\SystemInformationToolbarItem::loadMessages`
+- :php:`TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::getPageRenderer`
+- :php:`TYPO3\CMS\Backend\Controller\EditDocumentController::preInitAfter`
+- :php:`TYPO3\CMS\Backend\Controller\EditDocumentController::initAfter`
+- :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfigPreInclude`
+- :php:`TYPO3\CMS\Beuser\Controller\BackendUserController::switchUser`
+- :php:`TYPO3\CMS\Core\Database\SoftReferenceIndex::setTypoLinkPartsElement`
+- :php:`TYPO3\CMS\Core\Database\ReferenceIndex::shouldExcludeTableFromReferenceIndex`
+- :php:`TYPO3\CMS\Core\Imaging\IconFactory::buildIconForResourceSignal`
+- :php:`TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider::PostProcessTreeData`
+- :php:`TYPO3\CMS\Core\Utility\ExtensionManagementUtility::tcaIsBeingBuilt`
+- :php:`TYPO3\CMS\Impexp\Utility\ImportExportUtility::afterImportExportInitialisation`
+- :php:`TYPO3\CMS\Install\Service\SqlExpectedSchemaService::tablesDefinitionIsBeingBuilt`
+- :php:`TYPO3\CMS\Lang\Service\TranslationService::postProcessMirrorUrl`
+- :php:`TYPO3\CMS\Linkvalidator\LinkAnalyzer::beforeAnalyzeRecord`
+- :php:`TYPO3\CMS\Seo\Canonical\CanonicalGenerator::beforeGeneratingCanonical`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss`
+- :php:`TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss`
+
+
+Impact
+======
+
+It is now possible to add listeners to the new PSR-14 Events which
+define a clear API what can be read or modified.
+
+The listeners can be added to the :file:`Configuration/Services.yaml` as
+it is done in TYPO3's shipped extensions as well.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.2/Feature-89746-CustomIconForRecordBrowserButtonInForms.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89746:
+
+================================================================
+Feature: #89746 - Custom icon for record browser button in forms
+================================================================
+
+See :issue:`89746`
+
+Description
+===========
+
+The record browser is used in form definitions e.g. to configure the :yaml:`ContentElement` element or the :yaml:`Redirect` finisher.
+
+The icons of the buttons which trigger the record browser are now configurable using the new option :yaml:`iconIdentifier`:
+
+.. code-block:: yaml
+
+   TYPO3:
+     CMS:
+       Form:
+         prototypes:
+           standard:
+             formElementsDefinition:
+               ContentElement:
+                 formEditor:
+                   editors:
+                     # ...
+                     300:
+                       identifier: contentElement
+                       # ...
+                       browsableType: tt_content
+                       iconIdentifier: mimetypes-x-content-text
+                       propertyPath: properties.contentElementUid
+                       # ...
+
+
+Impact
+======
+
+The icons for the record browser button can now be customized.
+
+.. index:: Backend, ext:form

Documentation/Changelog/10.2/Feature-89747-CustomTablesWithRecordBrowserInForms.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89747:
+
+============================================================
+Feature: #89747 - Custom tables with record browser in forms
+============================================================
+
+See :issue:`89747`
+
+Description
+===========
+
+The record browser in forms now accepts arbitrary custom tables if configured accordingly.
+
+The option :yaml:`browsableType` of the :yaml:`Inspector-Typo3WinBrowserEditor` can be set to an arbitrary table:
+
+.. code-block:: yaml
+
+   TYPO3:
+     CMS:
+       Form:
+         prototypes:
+           standard:
+             formElementsDefinition:
+               MyCustomElement:
+                 formEditor:
+                   editors:
+                     # ...
+                     300:
+                       identifier: myRecord
+                       # ...
+                       browsableType: tx_myext_mytable
+                       propertyPath: properties.myRecordUid
+                       # ...
+
+Similar to the :yaml:`ContentElement` form element custom logic must be added in the matching frontend partial to actually display something for the selected record.
+
+
+Impact
+======
+
+Form definitions can be set up to allow editors the selection of arbitrary database records and then render them using custom logic.
+
+.. index:: Backend, ext:form

Documentation/Changelog/10.2/Important-84221-RestructuringOfFormSetup.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _important-84221:
+
+===============================================
+Important: #84221 - Restructuring of form setup
+===============================================
+
+See :issue:`84221`
+
+Description
+===========
+
+The setup of the "form" extension has been restructured. Till now the following files were used:
+
+* :file:`BaseSetup.yaml`: setup shared in all contexts
+* :file:`FormEditorSetup.yaml`: setup of the Form Editor backend module
+* :file:`FormEngineSetup.yaml`: setup of the Form plugin flexForm configuration
+
+From now on only a single file is used:
+
+* :file:`FormSetup.yaml`: basic setup including imports of the configuration for validators, form
+  elements and finishers.
+
+All previously used inheritances and mixins have been resolved which makes it very easy to
+understand the entire configuration.
+
+Consequently the entries in :typoscript:`yamlConfigurations` have changed:
+
+* :typoscript:`10` is now :file:`FormSetup.yaml`
+* :typoscript:`20` and :typoscript:`30` have been dropped
+
+Customizations of those entries must be adjusted accordingly.
+
+.. index:: Backend, FlexForm, Frontend, TypoScript, ext:form

Documentation/Changelog/10.2/Important-87518-UsePreparedStatementsForPdo_mysqlPerDefault.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _important-87518-1668719171:
+
+=====================================================================
+Important: #87518 - Use prepared statements for pdo_mysql per default
+=====================================================================
+
+See :issue:`87518`
+
+Description
+===========
+
+Before this adaption, the `pdo_mysql` driver used emulated prepared statements per default.
+With that, all returned values of a query were strings.
+
+With this change the behavior changes to use the actual prepared statements,
+which return native data types. Thus, if a column is defined as INTEGER,
+the returned value in PHP will also be an INTEGER.
+
+It is possible to deactivate this feature as follows:
+
+You need to "overwrite" the option to set `PDO::ATTR_EMULATE_PREPARES`
+(reference: https://www.php.net/manual/en/pdo.setattribute.php) in your database connection:
+
+.. code-block:: php
+
+   'Connections' => [
+       'Default' => [
+           'dbname' => 'some_database_name',
+           'driver' => 'pdo_mysql',
+           'driverOptions' => [
+               \PDO::ATTR_EMULATE_PREPARES => true
+            ],
+           'password' => 's0meS3curePW!',
+           'user' => 'someUser',
+       ],
+   ],
+
+.. index:: Database, ext:core

Documentation/Changelog/10.2/Important-88655-ChangedLoadingOrderOfRTEConfiguration.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _important-88655:
+
+==============================================================
+Important: #88655 - Changed loading order of RTE Configuration
+==============================================================
+
+See :issue:`88655`
+
+Description
+===========
+
+The order in which RTE Configuration is loaded has been changed.
+
+The new order is:
+
+#. preset defined for a specific field via PageTS
+
+#. richtextConfiguration defined for a specific field via TCA
+
+#. general preset defined via PageTS
+
+#. default
+
+This results in a change if you were used to using :typoscript:`RTE.default.preset` to overwrite _all_ RTE
+configuration presets - as those with specific configuration in TCA now use their specific settings
+instead of falling back to the default. Please make sure, that this new behavior is fitting for your
+use cases.
+
+If you are an extension author and you want your RTE fields to use the systems default configuration
+(the one configured for the complete web site) please do not set a specific preset for your fields.
+If you as an extension author want to provide a specific preset - for example because you are
+providing a custom parseFunc - set the property `richtextConfiguration` in TCA.
+
+If an extension provides a custom preset for a specific field and you as an integrator want to
+override that configuration (for example to use "your" default), set it specifically for that field
+in TSConfig or overwrite the TCA configuration.
+
+For example:
+
+If the blog extension configures `'richtextConfiguration' => 'blog'` for the tag description and
+you want the tag description to use the default preset, set
+:typoscript:`RTE.config.tx_blog_domain_model_tag.content.types.text.preset = default`.
+
+.. index:: RTE, TCA, TSConfig, ext:core

Documentation/Changelog/10.2/Important-89645-RemovedSystemLogOptions.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _important-89645:
+
+=============================================
+Important: #89645 - Removed systemLog options
+=============================================
+
+See :issue:`89645`
+
+Description
+===========
+
+The systemLog API has been changed in TYPO3 v9.0 to use the Logging API as a breaking change. The relevant systemLog
+options have been kept in TYPO3 v9 for backwards-compatibility of existing extensions, however have no use in TYPO3 v10
+anymore.
+
+The affected options are:
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['systemLog']`
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['systemLogLevel']`
+
+Impact
+======
+
+The options have been removed from the TYPO3's default configuration. When the options have been set, they are
+automatically removed in TYPO3 v10.0 when accessing the Install Tool or System Maintenance area.
+
+For extension authors, the Logging API should be used starting with TYPO3 v9. The usage of the systemLog options
+should then be removed from the extensions' code.
+
+.. index:: LocalConfiguration, FullyScanned, ext:core

Documentation/Changelog/10.2/Important-89764-IncompatibleEnvironmentRelatedDependencyInjectionServicesHaveBeenRemoved.rst

@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+.. _important-89764:
+
+====================================================================================================
+Important: #89764 - Incompatible environment related dependency injection services have been removed
+====================================================================================================
+
+See :issue:`89764`
+
+Description
+===========
+
+TYPO3 added support for Symfony 5.0 `symfony/dependency-injection:5` and
+therefore had to drop non-object services.
+
+Affected dependency injection services are the following boolean services:
+
+- env.is_unix
+- env.is_windows
+- env.is_cli
+- env.is_composer_mode
+
+The services variables can be substituted by using dynamic Symfony
+environment parameters:
+
+- "%env(TYPO3:isUnix)%"
+- "%env(TYPO3:isWindows)%"
+- "%env(TYPO3:isCli)%"
+- "%env(TYPO3:isComposerMode)%"
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.2/Index.rst

@@ -0,0 +1,53 @@
+:template: changelogOverview.html
+.. include:: /Includes.rst.txt
+..  _changelog-10-2:
+
+10.2 Changes
+=============
+
+**Table of contents**
+
+.. contents::
+   :local:
+   :depth: 1
+
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+None since TYPO3 v10.0 release.
+
+.. attention::
+
+   After TYPO3 v10.0, only new functionality with a solid migration path can be added on top,
+   with aiming for as little as possible breaking changes after the initial v10.0 release on the way to LTS.
+
+Features
+^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Feature-*
+
+Deprecation
+^^^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Deprecation-*
+
+Important
+^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Important-*