TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/10.1/Deprecation-88787-BackendUtilityEditOnClick.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88787:
+
+=================================================
+Deprecation: #88787 - BackendUtility::editOnClick
+=================================================
+
+See :issue:`88787`
+
+Description
+===========
+
+The method :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick()`
+used to generate JavaScript `onclick` targets to
+:php:`\TYPO3\CMS\Backend\Controller\EditDocumentController` has been marked as deprecated.
+
+
+Impact
+======
+
+Using this method will trigger PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations with extensions using :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick()` are affected.
+
+
+Migration
+=========
+
+Migrate the method to use the :php:`\TYPO3\CMS\Backend\Routing\UriBuilder` API and attach the parameters manually.
+
+Example:
+
+.. code-block:: php
+
+   // Previous
+   $old = BackendUtility::editOnClick($params);
+
+   // Migrated
+   $uriBuilder = GeneralUtility::makeInstance(UriBuilder::class);
+
+   // Variant 1
+   $params = '&edit[pages][' . $pid . ']=new&returnNewPageId=1';
+   $migrated = $uriBuilder->buildUriFromRoute('record_edit') . $params
+       . '&returnUrl=' . rawurlencode(GeneralUtility::getIndpEnv('REQUEST_URI'));
+
+   // Variant 2
+   $params = [
+       'edit' => [
+           'pages' => [
+               $pid => 'new',
+           ],
+        ],
+        'returnNewPageId' => 1,
+        'returnUrl' => GeneralUtility::getIndpEnv('REQUEST_URI'),
+   ];
+   $migrated = (string)$uriBuilder->buildUriFromRoute('record_edit', params);
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/10.1/Deprecation-88839-CLILowlevelRequestHandlers.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88839:
+
+===================================================
+Deprecation: #88839 - CLI lowlevel request handlers
+===================================================
+
+See :issue:`88839`
+
+Description
+===========
+
+The interface :php:`\TYPO3\CMS\Core\Console\RequestHandlerInterface`
+and the class :php:`\TYPO3\CMS\Core\Console\CommandRequestHandler` have been introduced in TYPO3 v7 to streamline
+various entry points for CLI-related functionality. Back then, there were Extbase command requests and
+`CommandLineController` entry points.
+
+With TYPO3 v10, the only way to handle CLI commands is via the :php:`\TYPO3\CMS\Core\Console\CommandApplication` class which is
+a wrapper around Symfony Console. All logic is now located in the Application, and thus, the interface and
+the class have been marked as deprecated.
+
+
+Impact
+======
+
+When instantiating the CLI :php:`\TYPO3\CMS\Core\Console\RequestHandler` class,
+a PHP :php:`E_USER_DEPRECATED` error will be triggered.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation having custom CLI request handlers wrapped via the interface or extending the
+CLI request handler class.
+
+
+Migration
+=========
+
+Switch to a Symfony Command or provide a custom CLI entry point.
+
+.. index:: CLI, PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.1/Deprecation-88850-ContentObjectRendererSendNotifyEmail.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88850:
+
+============================================================
+Deprecation: #88850 - ContentObjectRenderer::sendNotifyEmail
+============================================================
+
+See :issue:`88850`
+
+Description
+===========
+
+The method :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer::sendNotifyEmail()`
+which has been used to send mails has been marked as deprecated.
+
+
+Impact
+======
+
+Using this method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions calling
+:php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer::sendNotifyEmail()` are affected.
+
+
+Migration
+=========
+
+To send a mail, use the :php:`\TYPO3\CMS\Core\Mail\MailMessage`-API
+
+.. code-block:: php
+
+    $email = GeneralUtility::makeInstance(MailMessage::class)
+         ->to(new Address('katy@domain.tld'), new Address('john@domain.tld', 'John Doe'))
+         ->subject('This is an example email')
+         ->text('This is the plain-text variant')
+         ->html('<h4>Hello John.</h4><p>Enjoy a HTML-readable email. <marquee>We love TYPO3</marquee>.</p>');
+
+    $email->send();
+
+.. index:: PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/10.1/Deprecation-88854-JumpExtOfRecordListController.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88854:
+
+=======================================================
+Deprecation: #88854 - jumpExt() of RecordListController
+=======================================================
+
+See :issue:`88854`
+
+Description
+===========
+
+The JavaScript function :js:`jumpExt()` used to modify URLs by attaching `returnUrl` and `anchors`
+arguments have been marked as deprecated.
+
+Impact
+======
+
+Calling :js:`jumpExt()` will trigger a deprecation warning in the browser console.
+
+
+Affected Installations
+======================
+
+All third party extensions using :js:`jumpExt()` are affected.
+
+
+Migration
+=========
+
+It is only possible to call this function via hooks. To migrate this call, append a `returnUrl` argument to the URL if
+required and move the URL to the :html:`href` argument of the button the function was attached to.
+
+.. index:: Backend, JavaScript, PHP-API, NotScanned, ext:backend

Documentation/Changelog/10.1/Deprecation-88854-T3_THIS_LOCATION.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88854-1668719172:
+
+======================================
+Deprecation: #88854 - T3_THIS_LOCATION
+======================================
+
+See :issue:`88854`
+
+Description
+===========
+
+The global JavaScript variable :js:`T3_THIS_LOCATION` containing the URL to the current document (if not modified) has
+been marked as deprecated.
+
+
+Impact
+======
+
+Since this is a global JavaScript variable, no proper deprecation layer applies and thus no deprecation notice is rendered.
+
+Some PHP API uses :js:`T3_THIS_LOCATION`
+(e.g. :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getLinkToDataHandlerAction()` with second argument being `-1`)
+which has been marked as deprecated as well.
+
+
+Affected Installations
+======================
+
+All third party extensions using :js:`T3_THIS_LOCATION` are affected.
+
+
+Migration
+=========
+
+When generating URLs containing a `returnUrl` (a common use-case for :js:`T3_THIS_LOCATION`),
+consider using either :php:`rawurldecode(GeneralUtility::getIndpEnv('REQUEST_URI'))`
+or :php:`normalizedParams` in the PSR-7 ServerRequest object:
+:php:`$request->getAttribute('normalizedParams')->getRequestUri()`.
+
+In general, :js:`onclick` handlers doing a redirect are considered bad practice.
+Use HTML's :html:`href` attribute and attach custom click handlers, if necessary.
+
+.. index:: Backend, JavaScript, PHP-API, NotScanned, ext:backend

Documentation/Changelog/10.1/Deprecation-88862-T3_RETURN_URL.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88862:
+
+===================================
+Deprecation: #88862 - T3_RETURN_URL
+===================================
+
+See :issue:`88862`
+
+Description
+===========
+
+The JavaScript variable :js:`T3_RETURN_URL` holding the returnUrl sent with the current request either via `GET` or
+`POST` has been marked as deprecated.
+
+
+Impact
+======
+
+Since this is a global JavaScript variable, no proper deprecation layer applies and thus no deprecation notice is
+rendered.
+
+
+Affected Installations
+======================
+
+All third party extensions using :js:`T3_RETURN_URL` are affected.
+
+
+Migration
+=========
+
+Get the submitted returnUrl by using PHP:
+
+.. code-block:: php
+
+   // Variant 1
+   $returnUrl = GeneralUtility::sanitizeLocalUrl(GeneralUtility::_GP('returnUrl'));
+
+   // Variant 2
+   $returnUrl = $request->getParsedBody()['returnUrl'] ?? $request->getQueryParams()['returnUrl'] ?? '';
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.1/Deprecation-88995-CallingRegisterPluginWithVendorName.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88995:
+
+=============================================================
+Deprecation: #88995 - Calling registerPlugin with vendor name
+=============================================================
+
+See :issue:`88995`
+
+Description
+===========
+
+The first parameter :php:`$extensionName` of method :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin`
+used to contain the vendor name in the past.
+
+.. code-block:: php
+
+   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin(
+       'TYPO3.CMS.Form',
+       'Formframework',
+       'Form',
+       'content-form',
+   );
+
+As the vendor name does not have any effect at all, it's usage has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`registerPlugin()` with first parameter containing dots (considered to be the full vendor) name will trigger a PHP :php:`E_USER_DEPRECATED` error.
+As of TYPO3 v11 using the vendor name along with the extension name will lead to a wrong registration of plugins.
+
+
+Affected Installations
+======================
+
+All installations that add the vendor name to the first parameter :php:`$extensionName`
+of method :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin()` are affected.
+
+
+Migration
+=========
+
+Just use the extension name like in this example.
+
+.. code-block:: php
+
+   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin(
+       'Form',
+       'Formframework',
+       'Form',
+       'content-form',
+   );
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/10.1/Deprecation-89001-InternalPublicTSFEProperties.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89001:
+
+=====================================================
+Deprecation: #89001 - Internal public TSFE properties
+=====================================================
+
+See :issue:`89001`
+
+Description
+===========
+
+The following properties of the :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` class have been marked as deprecated:
+
+* :php:`cHash_array`
+* :php:`cHash`
+* :php:`domainStartPage`
+
+The properties are now built into proper arguments of the PHP objects
+:php:`\TYPO3\CMS\Core\Site\Entity\Site`
+and :php:`\TYPO3\CMS\Core\Routing\PageArguments`.
+
+This follows the pattern of not accessing these properties through
+the global :php:`TSFE` object directly anymore.
+
+
+Impact
+======
+
+Accessing these properties directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions or TypoScript directly
+accessing these properties.
+
+
+Migration
+=========
+
+Use the properties of :php:`Site` and :php:`PageArguments` instead:
+
+* :php:`\TYPO3\CMS\Core\Site\Entity\Site->getRootPageId()` (e.g. via :php:`$request->getAttribute('site')`)
+* :php:`\TYPO3\CMS\Core\Routing\PageArguments->getArguments()['cHash']` (e.g. via :php:`$request->getAttribute('routing')`)
+
+Please note that accessing these variables should be avoided via the :php:`TSFE` context.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/10.1/Deprecation-89033-JumpToUrl.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89033:
+
+===============================
+Deprecation: #89033 - jumpToUrl
+===============================
+
+See :issue:`89033`
+
+Description
+===========
+
+The JavaScript function :js:`jumpToUrl()` which is widely used in TYPO3 has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :js:`jumpToUrl()` will cause a deprecation entry in the browser's console.
+
+
+Affected Installations
+======================
+
+Extensions using :js:`jumpToUrl()` implementation are affected.
+
+
+Migration
+=========
+
+Since :js:`jumpToUrl()` triggers a redirect only, it's safe to either use :js:`window.location.href = 'link/to/my/module';`
+or use the link in combination with plain HTML as in :html:`<a href="link/to/my/module">my link</a>`.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.1/Deprecation-89037-DeprecatedLocallangXmlParser.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89037:
+
+===================================================
+Deprecation: #89037 - Deprecated LocallangXmlParser
+===================================================
+
+See :issue:`89037`
+
+Description
+===========
+
+The :php:`\TYPO3\CMS\Core\Localization\Parser\LocallangXmlParser` has been used to parse localization files based on the custom ll-XML format ("ll" refers to "locallang").
+Since TYPO3 version 4.6 XLIFF is being used and therefore the previous support for locallang-XML files has been marked as deprecated.
+
+Impact
+======
+
+Calling :php:`\TYPO3\CMS\Core\Localization\Parser\LocallangXmlParser` or using locallang-XML files will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Affected Installations
+======================
+
+All installations using extensions using ll-XML localization files.
+
+
+Migration
+=========
+
+Migrate all XML files to the XLIFF standard.
+
+.. index:: Backend, Frontend, FullyScanned, ext:core

Documentation/Changelog/10.1/Deprecation-89127-CleanupRecordHistoryHandling.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89127:
+
+====================================================
+Deprecation: #89127 - Cleanup RecordHistory handling
+====================================================
+
+See :issue:`89127`
+
+
+Description
+===========
+
+The following properties of the :php:`\TYPO3\CMS\Backend\History\RecordHistory` class have been marked as deprecated:
+
+* :php:`changeLog`
+* :php:`lastHistoryEntry`
+
+The properties are now protected and have a public getter function.
+
+The following public methods of the :php:`\TYPO3\CMS\Backend\History\RecordHistory` class have changed visibility from public to protected:
+
+* :php:`getHistoryEntry()`
+* :php:`getHistoryData()`
+
+The following methods of the :php:`\TYPO3\CMS\Backend\History\RecordHistory` class have been marked as deprecated:
+
+* :php:`createChangeLog()`, use :php:`getChangeLog()` instead
+* :php:`shouldPerformRollback()`
+* :php:`getElementData()`, use :php:`getElementInformation()` instead
+* :php:`performRollback()`, use :php:`RecordHistoryRollback::performRollback()` instead
+* :php:`createMultipleDiff()`, use :php:`getDiff()` instead
+* :php:`setLastHistoryEntry()`, use :php:`setLastHistoryEntryNumber()` instead
+
+
+Impact
+======
+
+Accessing these properties and methods directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions or TypoScript directly
+accessing these properties and methods.
+
+
+Migration
+=========
+
+Use the mentioned alternative methods and new classes.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/10.1/Deprecation-89215-JQueryClearable.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89215:
+
+======================================
+Deprecation: #89215 - jQuery.clearable
+======================================
+
+See :issue:`89215`
+
+Description
+===========
+
+The jQuery plugin :js:`jquery.clearable` that provides a button to clear an input field has been marked as deprecated.
+
+
+Impact
+======
+
+Using :js:`jquery.clearable` will trigger a deprecation warning in the browser's console.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions using :js:`jquery.clearable` are affected.
+
+
+Migration
+=========
+
+Import the module :js:`TYPO3/CMS/Backend/Input/Clearable` and use the method :js:`clearable()` on a native :js:`HTMLInputElement`.
+
+Example code:
+
+.. code-block:: js
+
+   require(['TYPO3/CMS/Backend/Input/Clearable'], function() {
+     const inputField = document.querySelector('#some-input');
+     if (inputField !== null) {
+       inputField.clearable();
+     }
+
+     const clearables = Array.from(document.querySelectorAll('.t3js-clearable')).filter(inputElement => {
+       // Filter input fields being a date time picker and a color picker
+       return !inputElement.classList.contains('t3js-datetimepicker') && !inputElement.classList.contains('t3js-color-picker');
+     });
+     clearables.forEach(clearableField => clearableField.clearable());
+  });
+
+The method also accepts an :js:`options` object, allowing to set a :js:`onClear` callback. The callback receives the input field as an argument the clearing was applied to.
+
+Example code:
+
+.. code-block:: js
+
+   const inputField = document.querySelector('#some-input');
+   if (inputField !== null) {
+     inputField.clearable({
+       onClear: function (input) {
+         input.closest('form').submit();
+       }
+     });
+   }
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.1/Feature-78488-AddRelNoreferrerToExternalLinks.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-78488:
+
+========================================================
+Feature: #78488 - Add rel="noreferrer" to external links
+========================================================
+
+See :issue:`78488`
+
+Description
+===========
+
+All links processed by :typoscript:`typolink` with external links opening in a new window have been extended to contain
+:html:`rel="noreferrer"`.
+
+Links opening in a new window are defined as those having an attribute :html:`target` which is either not empty,
+:html:`_self`, :html:`_top` or :html:`_parent`.
+
+..  note::
+
+    Initially this feature added :html:`rel="noopener noreferrer`. However :html:`noreferrer` also
+    implies the property :html:`noopener`. Therefore, the latter was removed.
+
+
+Impact
+======
+
+This property improves the security of the site:
+
+:html:`noreferrer`
+   This property prevents the browser, when navigating to another page, to send the page address, or any other value,
+   as referrer in according HTTP header. :html:`noreferrer` also implies the property :html:`noopener`, which instructs
+   the browser to open the link without granting the new browsing context access to the document that opened it.
+
+
+.. index:: Frontend

Documentation/Changelog/10.1/Feature-84250-SeparatelyEnableDisableAddMediaByURLAndSelectUploadFiles.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84250:
+
+============================================================================================
+Feature: #84250 - Separately enable / disable "Add media by URL" and "Select & upload files"
+============================================================================================
+
+See :issue:`84250`
+
+Description
+===========
+
+A new appearance property "fileByUrlAllowed" is used to separately enable / disable the buttons "Add media by URL" and "Select & upload files".
+
+*  :php:`fileUploadAllowed = false` now only hides the button "Select & upload files".
+*  :php:`fileByUrlAllowed = false` now hides the button "Add media by URL".
+
+If "elementBrowserType" is set to "file" both values are true by default.
+
+Example
+
+.. code-block:: php
+
+   $GLOBALS['TCA']['pages']['columns']['media']['config']['appearance'] = [
+      'fileUploadAllowed' => false,
+      'fileByUrlAllowed' => false,
+   ];
+
+This will suppress both buttons and only leave "Create new relation".
+
+Impact
+======
+
+Users have to use the new appearance property "fileByUrlAllowed" to hide the button "Add media by URL"
+
+.. index:: Backend, TCA, ext:backend

Documentation/Changelog/10.1/Feature-85918-HideInMenuShowInMenuEntryForPagesInContextMenu.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85918:
+
+=============================================================================
+Feature: #85918 - Hide in menu / Show in menu entry for pages in context menu
+=============================================================================
+
+See :issue:`85918`
+
+Description
+===========
+
+A new entry has been added to the context menu. It enables editors to toggle the
+`hide in menu` / `show in menu` flag without opening page properties.
+
+Find it as a child entry of `More Actions`.
+
+Removing the entry from the menu is possible via User TSconfig with the following setting:
+
+:typoscript:`options.contextMenu.table.pages.tree.disableItems = hideInMenus,showInMenus`
+
+
+Impact
+======
+
+Editors will save some clicks when arranging menu structures.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/10.1/Feature-86670-MakeDefaultActionInDragUploaderAdjustable.rst

@@ -0,0 +1,28 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-86670:
+
+================================================================
+Feature: #86670 - Make default action in DragUploader adjustable
+================================================================
+
+See :issue:`86670`
+
+Description
+===========
+
+It is now possible to configure the default action for DragUploader in the file list module using User TSConfig.
+
+.. code-block:: typoscript
+
+   # Set default to replace:
+   options.file_list.uploader.defaultAction = replace
+
+   # Set default to rename:
+   options.file_list.uploader.defaultAction = rename
+
+   # Set default to cancel (cancel is also the default and set the option to skip):
+   options.file_list.uploader.defaultAction = cancel
+
+
+.. index:: Backend, TSConfig, ext:filelist

Documentation/Changelog/10.1/Feature-87525-AddApi1OptionInVimeoRenderer.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87525:
+
+===================================================
+Feature: #87525 - Add api=1 option in VimeoRenderer
+===================================================
+
+See :issue:`87525`
+
+Description
+===========
+
+The parameter api=1 in Vimeo video urls allows API interactions with the video player,
+for example adding a button to interact with a video on your page.
+The configuration now allows setting this parameter when rendering Vimeo videos in TYPO3.
+
+Impact
+======
+
+Setting the parameter :typoscript:`api = 1` either in TypoScript or Fluid will append :html:`api=1` to the Vimeo video URL.
+
+Usage
+=====
+
+Set the parameter via TypoScript for EXT:fluid_styled_content by using:
+
+.. code-block:: typoscript
+
+   lib.contentElement.settings.media.additionalConfig.api = 1
+
+When using Fluid use the Fluid media ViewHelper and :html:`additionalConfig` to set the argument:
+
+.. code-block:: html
+
+   <f:media
+         file="{file}"
+         alt="{file.properties.alternative}"
+         title="{file.properties.title}"
+         additionalConfig="{api: 1}"
+   />
+
+
+.. index:: Fluid, TypoScript, ext:fluid_styled_content

Documentation/Changelog/10.1/Feature-88318-DisplayApplicationContextInCLI.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88318:
+
+====================================================
+Feature: #88318 - Display Application Context in CLI
+====================================================
+
+See :issue:`88318`
+
+Description
+===========
+
+The current Application Context is now shown next to the TYPO3 version number in CLI requests.
+This makes it easier to check if the correct context is provided.
+
+Output example:
+
+.. code-block:: none
+
+   TYPO3 CMS 10.1.0-dev (Application Context: Development/Docker)
+
+.. index:: CLI, ext:core

Documentation/Changelog/10.1/Feature-88441-ShowConfigurationOfUSER_INTObjectsInAdminpanel.rst

@@ -0,0 +1,17 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88441:
+
+======================================================================
+Feature: #88441 - Show configuration of USER_INT objects in adminpanel
+======================================================================
+
+See :issue:`88441`
+
+Description
+===========
+
+A new panel "USER_INT" is introduced in the info module of the admin panel,
+which lists the basic configuration of each :typoscript:`USER_INT` present on the current page.
+
+.. index:: ext:adminpanel

Documentation/Changelog/10.1/Feature-88602-AllowAdditionalFileProcessors.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88602:
+
+==============================================================
+Feature: #88602 - Allow registering additional file processors
+==============================================================
+
+See :issue:`88602`
+
+Description
+===========
+
+Registering additional file processors has been introduced.
+New processors need to implement the interface :php:`\TYPO3\CMS\Core\Resource\Processing\ProcessorInterface`.
+
+To register a new processor, add the following code to :file:`ext_localconf.php`
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SYS']['fal']['processors']['MyNewImageProcessor'] = [
+       'className' => \Vendor\ExtensionName\Resource\Processing\MyNewImageProcessor::class,
+       'before' => ['LocalImageProcessor']
+   ];
+
+To order the processors, use `before` and `after` statements. TYPO3 will process the file
+with the first processor that is able to process a given task.
+
+Impact
+======
+
+Developers are now able to provide their own file processing. By providing priorities, the processor ending up handling
+the file can be determined on a fine granular level including a fallback.
+
+Examples for custom implementations might be:
+
+* add a watermark to each image of type png
+* compress uploaded pdf files into zip archives
+* store images that should be cropped at a separate position in the target storage
+
+.. index:: Backend, ext:core, FAL

Documentation/Changelog/10.1/Feature-88742-ImportYamlFilesRelativeToTheCurrentYamlFile.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88742:
+
+=====================================================================
+Feature: #88742 - Import Yaml files relative to the current yaml file
+=====================================================================
+
+See :issue:`88742`
+
+Description
+===========
+
+The configuration language YAML (Yet Another Markup Language) is used to configure rich-text editor
+configuration, Form Framework form definitions, and site handling configuration files.
+
+TYPO3's internal YAML loader has a special handling for cascading and including other YAML files
+into the loaded resource via the following syntax:
+
+.. code-block:: yaml
+
+   imports:
+     - { resource: "EXT:rte_ckeditor/Configuration/RTE/Processing.yaml" }
+
+   another:
+     option: true
+
+
+However, the reference to the file was usually handled by referencing other resources in
+extensions as in :yaml:`EXT:my_extension/Configuration/MyConfig.yaml`.
+
+This is now optimized to allow imported resources to include files relative
+to the current YAML file:
+
+.. code-block:: yaml
+
+   imports:
+     - { resource: "misc/my_options.yaml" }
+     - { resource: "../path/to/something/within/the/project-folder/generic.yaml" }
+
+   another:
+     option: true
+
+
+Impact
+======
+
+Especially when using advanced site handling with multiple sites and similar configuration, it is now
+possible to have one base configuration file that is referenced by the specific site configuration files
+allowing to keep common config in a single place.
+
+.. index:: PHP-API, RTE

Documentation/Changelog/10.1/Feature-88805-AddTypeToTYPO3CMSCoreDatabaseQueryQueryBuilderset.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88805:
+
+====================================================================================
+Feature: #88805 - Add type to \\TYPO3\\CMS\\Core\\Database\\Query\\QueryBuilder::set
+====================================================================================
+
+See :issue:`88805`
+
+Description
+===========
+
+:php:`TYPO3\CMS\Core\Database\Query\QueryBuilder::set()` accepts as additional fourth parameter
+a type the query value should be casted to when third parameter (:php:`createNamedParameter`)
+is :php:`true`. Per default string (:php:`\PDO::PARAM_STR`) is used.
+
+Impact
+======
+
+Type safe query parameter setting is now also possible via :php:`set()`.
+
+Example:
+
+.. code-block:: php
+
+   $queryBuilder->set($fieldName, $fieldValue, true, \PDO::PARAM_INT);
+
+ensures :php:`$fieldValue` is handled as integer type in the resulting database query.
+
+.. index:: Database, ext:core

Documentation/Changelog/10.1/Feature-88871-RequestFactoryRespectsGuzzleMiddlewareHandlerConfigurationFromTYPO3_CONF_VARS.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88871:
+
+=============================================================
+Feature: #88871 - Handle middleware handler in RequestFactory
+=============================================================
+
+See :issue:`88871`
+
+Description
+===========
+
+Guzzle offers the possibility to register custom middleware handlers during the client initialization.
+With this feature it is now possible to define those custom handlers in :php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler']` as an array.
+The :php:`\TYPO3\CMS\Core\Http\RequestFactory` builds a handler stack based on the
+:php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler']` array and injects it into the created client.
+
+Impact
+======
+
+The default handler stack (guzzle defaults) will be extended and not overwritten.
+
+Example:
+--------
+
+.. code-block:: php
+
+   # Add custom middleware to default Guzzle handler stack
+   $GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler'][] =
+      (\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\ACME\Middleware\Guzzle\CustomMiddleware::class))->handler();
+   $GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler'][] =
+      (\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\ACME\Middleware\Guzzle\SecondCustomMiddleware::class))->handler();
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.1/Feature-88907-AlwaysEnableFilterInSelectMultipleSideBySideFields.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88907:
+
+=========================================================================
+Feature: #88907 - Always enable filter in SelectMultipleSideBySide fields
+=========================================================================
+
+See :issue:`88907`
+
+Description
+===========
+
+The filter functionality of fields :php:`type = select` with :php:`renderType = selectMultipleSideBySide`
+is always enabled now.
+
+
+Impact
+======
+
+Before:
+
+.. code-block:: php
+
+   'tsconfig_includes' => [
+      'label' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_tca.xlf:pages.tsconfig_includes',
+      'config' => [
+         'type' => 'select',
+         'renderType' => 'selectMultipleSideBySide',
+         'size' => 10,
+         'items' => [],
+         'enableMultiSelectFilterTextfield' => true,
+         'softref' => 'ext_fileref'
+      ]
+   ],
+
+Now just omit the line :php:`'enableMultiSelectFilterTextfield' => true`, the behaviour will stay the same.
+
+A migration wizard is available that removes the option from your TCA and leaves a message where code
+adaption has to take place.
+
+.. index:: Backend, TCA, ext:core

Documentation/Changelog/10.1/Feature-89010-IntroduceSiteConfigForDistributionPackages.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89010:
+
+========================================================================
+Feature: #89010 - Introduce Site Configuration for Distribution Packages
+========================================================================
+
+See :issue:`89010`
+
+Description
+===========
+
+Distributions or site packages are designed to deliver a full blown TYPO3 instance with all necessary data and assets
+to have a functional installation after the package has been activated.
+The import of a distribution can now ship the config file (or many, if this is required).
+
+Similar to assets, that are moved to :file:`fileadmin` ready for use, site configurations are moved into the config folder.
+
+Impact
+======
+
+Distributions can now ship their own site configuration files.
+
+Example:
+--------
+
+Into the distribution package :file:`Initialisation/Site` folder, put a folder with the site identifier as name, containing the
+:file:`config.yaml`.
+Each folder will be moved into the target position upon extension activation.
+
+If a folder with the same name already exists, the file will *not* be overridden. In this case no change is made to the existing configuration.
+
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.1/Feature-89018-ProvideImplementationForPSR-17HTTPMessageFactories.rst

@@ -0,0 +1,83 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89018:
+
+==========================================================================
+Feature: #89018 - Provide implementation for PSR-17 HTTP Message Factories
+==========================================================================
+
+See :issue:`89018`
+
+Description
+===========
+
+Support for PSR-17_ HTTP Message Factories has been added.
+
+PSR-17 HTTP Factories are intended to be used by PSR-15_ request handlers in order to create PSR-7_
+compatible message objects.
+
+PSR-17 consists of six factory interfaces:
+
+- :php:`\Psr\Http\Message\RequestFactoryInterface`
+- :php:`\Psr\Http\Message\ResponseFactoryInterface`
+- :php:`\Psr\Http\Message\ServerRequestFactoryInterface`
+- :php:`\Psr\Http\Message\StreamFactoryInterface`
+- :php:`\Psr\Http\Message\UploadedFileFactoryInterface`
+- :php:`\Psr\Http\Message\UriFactoryInterface`
+
+Request handlers shall use dependency injection to use any of the available PSR-17 HTTP Factory interfaces.
+
+
+Impact
+======
+
+PSR-17 HTTP Factory interfaces are provided by `psr/http-factory` and should be used as
+dependencies for PSR-15 request handlers or services that need to create PSR-7 message objects.
+
+It is discouraged to explicitly create PSR-7 instances of classes from the :php:`\TYPO3\CMS\Core\Http`
+namespace (they are not public API). Use type declarations against PSR-17 HTTP Message Factory interfaces
+and dependency injection instead.
+
+Example usage
+-------------
+
+A middleware that needs to send a JSON response when a certain condition is met, uses the
+PSR-17 response factory interface (the concrete TYPO3 implementation is injected as constructor
+dependency) to create a new PSR-7 response object:
+
+.. code-block:: php
+
+    use Psr\Http\Message\ResponseFactoryInterface;
+    use Psr\Http\Message\ResponseInterface;
+    use Psr\Http\Message\ServerRequestInterface;
+    use Psr\Http\Server\MiddlewareInterface;
+    use Psr\Http\Server\RequestHandlerInterface;
+
+    class StatusCheckMiddleware implements MiddlewareInterface
+    {
+        /** @var ResponseFactoryInterface */
+        private $responseFactory;
+
+        public function __construct(ResponseFactoryInterface $responseFactory)
+        {
+            $this->responseFactory = $responseFactory;
+        }
+
+        public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
+        {
+            if ($request->getRequestTarget() === '/check') {
+                $data = ['status' => 'ok'];
+                $response = $this->responseFactory->createResponse()
+                    ->withHeader('Content-Type', 'application/json; charset=utf-8');
+                $response->getBody()->write(json_encode($data));
+                return $response;
+            }
+            return $handler->handle($request);
+        }
+    }
+
+.. _PSR-17: https://www.php-fig.org/psr/psr-17/
+.. _PSR-15: https://www.php-fig.org/psr/psr-15/
+.. _PSR-7: https://www.php-fig.org/psr/psr-7/
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.1/Feature-89054-ProvideCoreCacheFrontendsViaDependencyInjection.rst

@@ -0,0 +1,89 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89054:
+
+=======================================================================
+Feature: #89054 - Provide core cache frontends via dependency injection
+=======================================================================
+
+See :issue:`89054`
+
+Description
+===========
+
+With TYPO3 v10.0 dependency injection has been introduced. To work with
+the cache, currently only the :php:`\TYPO3\CMS\Core\Cache\CacheManager` is available as a service within
+the dependency injection container. To foster the „Inversion of Control“ pattern,
+the instances of :php:`\TYPO3\CMS\Core\Cache\Frontend\FrontendInterface` should
+be injected to the objects rather than using the :php:`\TYPO3\CMS\Core\Cache\CacheManager`.
+
+Classes should be adapted to avoid :php:`\TYPO3\CMS\Core\Cache\CacheManager` whenever possible.
+
+The TYPO3 core provides all core caches as dependency injection services.
+The name of the service follows the scheme :php:`cache.[CONFIGURATION NAME]`.
+E.g. the core cache frontend will have the service id :php:`cache.core`.
+
+Third party extensions are encouraged to do the same and provide a :php:`cache.my_cache`
+service in :file:`Configuration/Services.yaml` for cache configuration they define
+in :file:`ext_localconf.php`.
+
+Usage
+=====
+
+Given a class needs the "my_cache" cache Frontend, then the code before TYPO3 v10.1
+looked like the following example:
+
+.. code-block:: php
+
+   class MyClass
+   {
+       /**
+        * @var TYPO3\CMS\Core\Cache\Frontend\FrontendInterface
+        */
+       private $cache;
+
+       public function __construct()
+       {
+           $cacheManager = GeneralUtility::makeInstance(CacheManager::class);
+           $this->cache = $cacheManager->getCache('my_cache');
+       }
+   }
+
+The instance of :php:`\TYPO3\CMS\Core\Cache\Frontend\FrontendInterface` was retrieved by creating an instance
+of :php:`\TYPO3\CMS\Core\Cache\CacheManager` and then by calling the :php:`getCache()` method.
+
+To inject the cache directly, the class needs to be changed as follows. The instance
+of :php:`\TYPO3\CMS\Core\Cache\Frontend\FrontendInterface` will be passed as an argument to the constructor.
+
+.. code-block:: php
+
+   class MyClass
+   {
+       /**
+        * @var TYPO3\CMS\Core\Cache\Frontend\FrontendInterface
+        */
+       private $cache;
+
+       public function __construct(FrontendInterface $cache)
+       {
+           $this->cache = $cache;
+       }
+   }
+
+Since the auto-wiring feature of the dependency injection container cannot detect,
+which cache configuration should be used for the :php:`$cache` argument, the container
+service configuration needs to be extended as well:
+
+.. code-block:: yaml
+
+    services:
+      cache.my_cache:
+        class: TYPO3\CMS\Core\Cache\Frontend\FrontendInterface
+        factory: ['@TYPO3\CMS\Core\Cache\CacheManager', 'getCache']
+        arguments: ['my_cache']
+
+      MyClass:
+        arguments:
+          $cache: '@cache.my_cache'
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.1/Feature-89061-IntroduceNotificationActions.rst

@@ -0,0 +1,95 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89061:
+
+================================================
+Feature: #89061 - Introduce Notification Actions
+================================================
+
+See :issue:`89061`
+
+Description
+===========
+
+Notifications rendered by the :js:`TYPO3/CMS/Backend/Notification` module are now able to render action buttons. Each
+notification method (:js:`info()`, :js:`success()` etc) accepts an array of actions, each action is described by a
+:js:`label` and a pre-defined action type, containing a callback.
+
+However, notifications flagged with a duration will still disappear, unless an action is taken.
+
+.. important::
+
+   Such tasks must **never** be mandatory to be executed. This API is meant to suggest certain actions without enforcing
+   them. If a user is supposed to take immediate actions consider using modals instead.
+
+
+Example:
+
+.. code-block:: js
+
+   require([
+     'TYPO3/CMS/Backend/ActionButton/ImmediateAction',
+     'TYPO3/CMS/Backend/ActionButton/DeferredAction',
+     'TYPO3/CMS/Backend/Notification'
+   ], function(ImmediateAction, DeferredAction, Notification) {
+     const immediateActionCallback = new ImmediateAction(function () { /* your action code */ });
+     Notification.info(
+       'Great! We are almost done here...',
+       'Common default settings have been applied based on your previous input.',
+       0,
+       [
+         {label: 'Show settings', action: immediateActionCallback}
+       ]
+     );
+   });
+
+
+ImmediateAction
+---------------
+
+An action of type :js:`ImmediateAction` (:js:`TYPO3/CMS/Backend/ActionButtons/ImmediateAction`) is executed directly on
+click and closes the notification. This action type is suitable for e.g. linking to a backend module.
+
+The class accepts a callback method executing very simple logic.
+
+Example:
+
+.. code-block:: js
+
+   const immediateActionCallback = new ImmediateAction(function () {
+     require(['TYPO3/CMS/Backend/ModuleMenu'], function (ModuleMenu) {
+       ModuleMenu.App.showModule('web_layout');
+     });
+   });
+
+
+DeferredAction
+--------------
+
+An action of type :js:`DeferredAction` (:js:`TYPO3/CMS/Backend/ActionButtons/DeferredAction`) is recommended when a
+long-lasting task is executed, e.g. an AJAX request.
+
+This class accepts a callback method which must return either a resolved or rejected promise.
+
+The :js:`DeferredAction` replaces the action button with a spinner icon to indicate a task will take some time. It's
+still possible to dismiss a notification, which will **not** stop the execution.
+
+Example:
+
+.. code-block:: js
+
+   const deferredActionCallback = new DeferredAction(function () {
+     const myAction = async function() {
+       return await 'something';
+     }
+
+     return myAction();
+   });
+
+   const anotherDeferredActionCallback = new DeferredAction(function () {
+     // do some old-fashioned jQuery stuff
+     return Promise.resolve($.ajax(/* AJAX configuration */));
+   });
+
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/10.1/Feature-89090-ReportsForConflictingRedirects.rst

@@ -0,0 +1,26 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89090:
+
+===================================================
+Feature: #89090 - Reports for conflicting redirects
+===================================================
+
+See :issue:`89090`
+
+Description
+===========
+
+A new Symfony command has been introduced that detects redirects that conflict with pages. The command is marked as
+schedulable, thus it can be created as a scheduler task.
+
+
+Impact
+======
+
+If EXT:scheduler and EXT:reports are installed, the redirect status may be checked and presented as an additional report.
+
+The command may be executed via CLI by invoking `./typo3/sysext/core/bin/typo3 redirects:checkintegrity`. The command
+accepts the option `--site` which takes a site identifier to take the pages of that site into consideration only.
+
+.. index:: Backend, CLI, ext:redirects

Documentation/Changelog/10.1/Feature-89115-Auto-createRedirectsOnSlugChanges.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89115:
+
+=======================================================================
+Feature: #89115 - Auto slug update and redirect creation on slug change
+=======================================================================
+
+See :issue:`89115`
+
+Description
+===========
+
+If EXT:redirects is installed and a slug is updated by a backend user,
+a redirect from the old URL to the new URL will be created.
+All sub pages are checked too and the slugs will be updated.
+
+After the creation of the redirects a notification will be shown to the user.
+
+The notification contains two possible actions:
+
+* revert the complete slug update and remove the redirects
+* or only remove the redirects
+
+This new behaviour can be configured by site configuration (Example for your :file:`config.yaml`):
+
+.. code-block:: yaml
+
+   settings:
+      redirects:
+        # Automatically update slugs of all sub pages
+        # (default: true)
+        autoUpdateSlugs: true
+        # Automatically create redirects for pages with a new slug (works only in LIVE workspace)
+        # (default: true)
+        autoCreateRedirects: true
+        # Time To Live in days for redirect records to be created - `0` disables TTL, no expiration
+        # (default: 0)
+        redirectTTL: 30
+        # HTTP status code for the redirect, see
+        # https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections#Temporary_redirections
+        # (default: 307)
+        httpStatusCode: 307
+
+.. note::
+
+   No redirects are generated for workspace versions in the TYPO3 backend.
+   :yaml:`settings.redirect.autoCreateRedirects` is internally disabled in this case.
+
+.. attention::
+
+   This API is considered experimental and may change anytime until declared being stable.
+   For example there exists plans for moving the settings out of the :file:`config.yaml` file.
+
+.. index:: Backend, ext:redirects

Documentation/Changelog/10.1/Feature-89142-CreateSiteConfigurationIfPageIsCreatedOnRootLevel.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89142:
+
+============================================================================
+Feature: #89142 - Create site configuration if page is created on root level
+============================================================================
+
+See :issue:`89142`
+
+Description
+===========
+
+When creating a typical new page on the root level of a TYPO3 installation, a new site configuration is now
+automatically created as well. This makes it easier to work with multi-sites and get a basic configuration set up
+more quickly than before.
+
+Under the hood, a new :php:`DataHandler` hook checks for new pages being one of the following page types:
+
+* Default pages
+* Links
+* Shortcuts
+
+The entry point consists of the current domain where the configuration has been created, plus a short identifier using
+the page uid and the prefix "site", e.g. `https://example.com/site-42`.
+
+The identifier of the site uses the entry point without the domain, and a MD5 hash of the page id to avoid potential
+conflicts for existing site configurations. An identifier may look like `site-42-a1d0c6e83f`.
+
+Impact
+======
+
+A new site configuration with a pre-defined identifier, entry point and a default language gets created automatically.
+
+Ideally, there are no scenarios anymore where a site needs to be created after a first page is created, avoiding
+any issues related to Slug handling for root pages, which are always set to `/` by default.
+
+.. index:: Backend, ext:core

Documentation/Changelog/10.1/Feature-89143-AllowRollbackForASetOfRecordHistoryEntries.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89143:
+
+====================================================================
+Feature: #89143 - Allow rollback for a set of record history entries
+====================================================================
+
+See :issue:`89143`
+
+Description
+===========
+
+To allow rollbacks for a set of record history entries, it is now possible to add a correlationId
+while creating the RecordHistory entry. The correlationId should be an UUID but could also be any
+string which is useful to identify a set of entries.
+
+To use this feature, an additional parameter :php:`$correlationId` has been added to the following methods of
+:php:`\TYPO3\CMS\Core\DataHandling\History\RecordHistoryStore`:
+
+* :php:`addRecord(string $table, int $uid, array $payload, CorrelationId $correlationId = null)`
+* :php:`modifyRecord(string $table, int $uid, array $payload, CorrelationId $correlationId = null)`
+* :php:`deleteRecord(string $table, int $uid, CorrelationId $correlationId = null)`
+* :php:`undeleteRecord(string $table, int $uid, CorrelationId $correlationId = null)`
+* :php:`moveRecord(string $table, int $uid, array $payload, CorrelationId $correlationId = null)`
+
+To resolve all entries for a given :php:`$correlationId` a new method has been added to the
+:php:`\TYPO3\CMS\Core\DataHandling\History\RecordHistory` class:
+
+* :php:`\TYPO3\CMS\Core\DataHandling\History\RecordHistory::findEventsForCorrelation(string $correlationId): array`
+
+
+.. index:: Backend, PHP-API, ext:backend

Documentation/Changelog/10.1/Feature-89150-AddEventsBeforeAndAfterRollbackOfRecordHistoryEntries.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89150:
+
+================================================================================
+Feature: #89150 - Add events before and after rollback of record history entries
+================================================================================
+
+See :issue:`89150`
+
+Description
+===========
+
+Two new events have been introduced into record history that will be dispatched before and after a revert action.
+
+* :php:`\TYPO3\CMS\Backend\History\Event\BeforeHistoryRollbackStartEvent` before the rollback starts
+* :php:`\TYPO3\CMS\Backend\History\Event\AfterHistoryRollbackFinishedEvent` after the rollback finished
+
+Both events resolve some information about the :php:`RecordHistory` item:
+
+* :php:`getRecordHistoryRollback()` returns the :php:`\TYPO3\CMS\Backend\History\RecordHistoryRollback` object
+* :php:`getRollbackFields()` returns a string with the rollback fields
+* :php:`getDiff()` returns an array with the differences
+* :php:`getBackendUserAuthentication()` returns a :php:`\TYPO3\CMS\Backend\BackendUserAuthentication` object, which is used for this rollback operation
+
+Additionally the :php:`\TYPO3\CMS\Backend\History\Event\AfterHistoryRollbackFinishedEvent` gets the DataHandler input data:
+
+* :php:`getDataHandlerInput()` returns an array with the :php:`DataHandler` instructions.
+
+.. index:: Backend, PHP-API, ext:backend

Documentation/Changelog/10.1/Feature-89216-PSR-18HTTPClientImplementation.rst

@@ -0,0 +1,111 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89216:
+
+===================================================
+Feature: #89216 - PSR-18 HTTP Client Implementation
+===================================================
+
+See :issue:`89216`
+
+Description
+===========
+
+Support for PSR-18_ HTTP Client has been added.
+
+PSR-18 HTTP Client is intended to be used by PSR-15_ request handlers in order to perform HTTP
+requests based on PSR-7_ message objects without relying on a specific HTTP client implementation.
+
+PSR-18 consists of a client interfaces and three exception interfaces:
+
+- :php:`\Psr\Http\Client\ClientInterface`
+- :php:`\Psr\Http\Client\ClientExceptionInterface`
+- :php:`\Psr\Http\Client\NetworkExceptionInterface`
+- :php:`\Psr\Http\Client\RequestExceptionInterface`
+
+Request handlers shall use dependency injection to retrieve the concrete implementation
+of the PSR-18 HTTP client interface :php:`\Psr\Http\Client\ClientInterface`.
+
+
+Impact
+======
+
+The PSR-18 HTTP Client interface is provided by `psr/http-client` and may be used as
+dependency for services in order to perform HTTP requests using PSR-7 request objects.
+PSR-7 request objects can be created with the PSR-17_ Request Factory interface.
+
+Note: This does not replace the currently available Guzzle wrapper
+:php:`\TYPO3\CMS\Core\Http\RequestFactory->request()`, but is available as a framework
+agnostic, more generic alternative. The PSR-18 interface does not allow to pass request
+specific guzzle options. But global options defined in :php:`$GLOBALS['TYPO3_CONF_VARS']['HTTP']`
+are taken into account as GuzzleHTTP is used as backend for this PSR-18 implementation.
+The concrete implementations is internal and will be replaced by a native guzzle PSR-18
+implementation once it is available.
+
+Example usage
+-------------
+
+A middleware might need to request an external service in order to transform the response
+into a new response. The PSR-18 HTTP client interface is used to perform the external
+HTTP request. The PSR-17 Request Factory Interface is used to create the HTTP request that
+the PSR-18 HTTP Client expects. The PSR-7 Response Factory is then used to create a new
+response to be returned to the user. All off these interface implementations are injected
+as constructor dependencies:
+
+.. code-block:: php
+
+    use Psr\Http\Client\ClientInterface;
+    use Psr\Http\Message\RequestFactoryInterface;
+    use Psr\Http\Message\ResponseFactoryInterface;
+    use Psr\Http\Message\ResponseInterface;
+    use Psr\Http\Message\ServerRequestInterface;
+    use Psr\Http\Server\MiddlewareInterface;
+    use Psr\Http\Server\RequestHandlerInterface;
+
+    class ExampleMiddleware implements MiddlewareInterface
+    {
+        /** @var ResponseFactory */
+        private $responseFactory;
+
+        /** @var RequestFactory */
+        private $requestFactory;
+
+        /** @var ClientInterface */
+        private $client;
+
+        public function __construct(
+            ResponseFactoryInterface $responseFactory,
+            RequestFactoryInterface $requestFactory,
+            ClientInterface $client
+        ) {
+            $this->responseFactory = $responseFactory;
+            $this->requestFactory = $requestFactory;
+            $this->client = $client;
+        }
+
+        public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
+        {
+            if ($request->getRequestTarget() === '/example') {
+                $req = $this->requestFactory->createRequest('GET', 'https://api.external.app/endpoint.json')
+                // Perform HTTP request
+                $res = $this->client->sendRequest($req);
+                // Process data
+                $data = [
+                    'content' => json_decode((string)$res->getBody());
+                ];
+                $response = $this->responseFactory->createResponse()
+                    ->withHeader('Content-Type', 'application/json; charset=utf-8');
+                $response->getBody()->write(json_encode($data));
+                return $response;
+            }
+            return $handler->handle($request);
+        }
+    }
+
+
+.. _PSR-18: https://www.php-fig.org/psr/psr-18/
+.. _PSR-17: https://www.php-fig.org/psr/psr-17/
+.. _PSR-15: https://www.php-fig.org/psr/psr-15/
+.. _PSR-7: https://www.php-fig.org/psr/psr-7/
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.1/Feature-89227-AskForEmailAddressWhileInstallingTYPO3.rst

@@ -0,0 +1,22 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89227:
+
+==============================================================
+Feature: #89227 - Ask for email address while installing TYPO3
+==============================================================
+
+See :issue:`89227`
+
+Description
+===========
+
+It is now possible to enter an email address for the first admin user while installing TYPO3.
+
+Within the install process, an admin user will be created by entering a username and password.
+The user is asked for the email address as well, so this can be used
+later on to e.g. notify the admin if somebody logged-in (Warning email address).
+
+This will also work in the install tool Maintenance module "Create Administrative User" card.
+
+.. index:: Backend, ext:install

Documentation/Changelog/10.1/Feature-89229-CachePresetForSettingsInMaintenanceArea.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89229:
+
+===============================================================
+Feature: #89229 - Cache Preset for Settings in Maintenance Area
+===============================================================
+
+See :issue:`89229`
+
+Description
+===========
+
+The maintenance area available in TYPO3 Backend under "Admin Tools" => "Settings" now also allows to quickly switch
+between Cache Backends for the Caching Framework.
+
+This allows to select different settings without having to manually modify the :file:`LocalConfiguration.php` file.
+
+
+Impact
+======
+
+Depending on a server setup, it might be easier to quickly see differences when running on a distributed Database system
+(not localhost) or on a distributed file system to choose between caching options.
+
+In addition, the most common caches are explained in what is stored there. Further configuration can be applied by
+manually modifying the :file:`LocalConfiguration.php` settings file.
+
+.. index:: LocalConfiguration, ext:core

Documentation/Changelog/10.1/Feature-89244-BroadcastChannels.rst

@@ -0,0 +1,99 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89244:
+
+==================================================
+Feature: #89244 - Broadcast Channels and Messaging
+==================================================
+
+See :issue:`89244`
+
+Description
+===========
+
+It is now possible to send broadcast messages from anywhere in TYPO3 that are listened to via JavaScript.
+
+.. warning::
+
+   This API is considered internal and may change anytime until declared being stable.
+
+
+Send a message
+--------------
+
+Any backend module may send a message using the :js:`TYPO3/CMS/Backend/BroadcastService` module.
+The payload of such message is an object that consists at least of the following properties:
+
+* :js:`componentName` - the name of the component that sends the message (e.g. extension name)
+* :js:`eventName` - the event name used to identify the message
+
+A message may contain any other property as necessary. The final event name to listen is a composition of "typo3", the
+component name and the event name, e.g. `typo3:my_extension:my_event`.
+
+.. attention::
+
+   Since a polyfill is in place to add support for Microsoft Edge, the payload must contain JSON-serializable content
+   only.
+
+
+To send a message, the :js:`post()` method has to be used.
+
+Example code:
+
+.. code-block:: js
+
+   require(['TYPO3/CMS/Backend/BroadcastService'], function (BroadcastService) {
+     const payload = {
+       componentName: 'my_extension',
+       eventName: 'my_event',
+       hello: 'world',
+       foo: ['bar', 'baz']
+     };
+
+     BroadcastService.post(payload);
+   });
+
+
+Receive a message
+-----------------
+
+To receive and thus react on a message, an event handler needs to be registered that listens to the composed event
+name (e.g. `typo3:my_component:my_event`) sent to :js:`document`.
+
+The event itself contains a property called `detail` **excluding** the component name and event name.
+
+Example code:
+
+.. code-block:: js
+
+   define([], function() {
+      document.addEventListener('typo3:my_component:my_event', (e) => eventHandler(e.detail));
+
+      function eventHandler(detail) {
+        console.log(detail); // contains 'hello' and 'foo' as sent in the payload
+      }
+   });
+
+
+Hook into :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/backend.php']['constructPostProcess']` to load a custom
+:php:`BackendController` hook that loads the event handler, e.g. via RequireJS.
+
+Example code:
+
+.. code-block:: php
+
+   // ext_localconf.php
+   $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/backend.php']['constructPostProcess'][]
+       = \Vendor\MyExtension\Hooks\BackendControllerHook::class . '->registerClientSideEventHandler';
+
+   // Classes/Hooks/BackendControllerHook.php
+   class BackendControllerHook
+   {
+       public function registerClientSideEventHandler(): void
+       {
+           $pageRenderer = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Page\PageRenderer::class);
+           $pageRenderer->loadRequireJsModule('TYPO3/CMS/MyExtension/EventHandler');
+       }
+    }
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/10.1/Feature-89292-AddSupportForRecordHistoryCorrelationIdsToDataHandler.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89292:
+
+==============================================================================
+Feature: #89292 - Add support for RecordHistory correlationId's to DataHandler
+==============================================================================
+
+See :issue:`89292`
+
+Description
+===========
+
+With :issue:`89143` a new feature for correlation ids in :php:`\TYPO3\CMS\Backend\History\RecordHistory` was introduced.
+:php:`DataHandler` now also supports this feature by setting the :php:`$correlationId` with its instance.
+
+.. code-block:: php
+
+   $correlationId = CorrelationId::forSubject(
+       md5(StringUtility::getUniqueId('slug_'))
+   );
+   $data['pages'][$uid]['slug'] = $newSlug;
+   // create new DataHandler instance
+   $dataHandler = GeneralUtility::makeInstance(DataHandler::class);
+   $dataHandler->start($data, []);
+   // DataHandler::start assigns internal correlation id scope
+   // which will be overridden in this example by the next line
+   $dataHandler->setCorrelationId($correlationId);
+   // actually process and persist data
+   $dataHandler->process_datamap();
+
+After this DataHandler operation, the created RecordHistory entry contains the :php:`$correlationId`.
+
+:php:`CorrelationId` model requires mandatory :php:`$subject` and allows optional :php:`$aspects` which
+can be serialized into string like e.g. `0400$12ae0b042a5d75e3f2744f4b3faf8068/5d8e6e70/slug`
+
+* `0400$` is a flag prefix containing an internal version number for possible schema validations
+* `12ae0b042a5d75e3f2744f4b3faf8068` is a unique subject
+* `/5d8e6e70/slug` are aspects, separated by slashes
+
+.. index:: Backend, Database, PHP-API, ext:core

Documentation/Changelog/10.1/Feature-9070-AllowTranslationOfIndexConfigurationTitles.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-9070:
+
+================================================================
+Feature: #9070 - Allow translation of index configuration titles
+================================================================
+
+See :issue:`9070`
+
+Description
+===========
+
+Indexed search plugin allows to select specifically which index configuration to be queried from in the specific form,
+where a dropdown shows all possible indexing configurations.
+
+
+Impact
+======
+
+It is now possible to add a label for each configuration via TypoScript in each language.
+
+.. code-block:: typoscript
+
+   plugin.tx_indexedsearch.settings._LOCAL_LANG {
+      de.indexingConfigurations.13 = Mein Titel in Deutsch für Konfiguration 13
+      de.indexingConfigurationHeader.13 = Alle Ergebnisse für Konfiguration 13
+   }
+
+.. index:: Backend, ext:indexed_search

Documentation/Changelog/10.1/Important-89001-TSFE-createHashBase.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _important-89001:
+
+========================================
+Important: #89001 - TSFE->createHashBase
+========================================
+
+See :issue:`89001`
+
+Description
+===========
+
+The method :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->createHashBase()`
+calculates all components that are relevant for a specific cached version of a page.
+
+With TYPO3 v10.1, the keys in :php:`$hashParameters` used for calculating the hash have been modified:
+
+- `gr_list` has been replaced by `groupIds` but contains the same values
+- `cHash` has been replaced by `dynamicArguments` but contains the same values
+- `domainStartPage` has been replaced by `site` (identifier of the site)
+
+.. index:: Frontend, PHP-API, ext:frontend

Documentation/Changelog/10.1/Important-89122-UnifiedEvaluationOfVersionedRecordsInWorkspaces.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _important-89122:
+
+=========================================================================
+Important: #89122 - Unified evaluation of versioned records in workspaces
+=========================================================================
+
+See :issue:`89122`
+
+Description
+===========
+
+TYPO3 Core handled the result of database queries in a lot of different ways to filter out workspace records.
+In previous versions, where versioned records without workspaces (incremental versions) was supported, the main
+identifier was always to check for records that are "Offline" - by checking via the "pid" field of database records,
+that they are set to "-1".
+
+With workspaces, there are other, better ways to identify versioned via the following fields:
+
+- t3ver_state (what kind of versioned record it is - new version, moved record, deleted version)
+- t3ver_oid (if the versioned record points to a live record)
+- t3ver_wsid (the workspace ID, a relation to a sys_workspace record)
+
+The "pid" field was kept as misuse, but fine for most of the database queries. With the unified database abstraction
+layer based on Doctrine DBAL and enriched via Query Restrictions, TYPO3 Core now checks for t3ver_state, t3ver_wsid
+and t3ver_oid to identify versioned records.
+
+This is already achieved with any database query by using the WorkspaceRestrictions in place. Extension authors
+should use Doctrine DBAL and apply workspace restrictions by default.
+
+If this is not possible when building custom queries without restrictions, it is recommended to check for:
+
+- t3ver_oid>0 = identifying a versioned record that has a counterpart in the live workspace
+- t3ver_wsid=13 - identifying a versioned record or placeholder that resides in a specific workspace (in this case "13")
+- t3ver_state IN (0,-1) AND t3ver_wsid IN (0,13) - to fetch records including "new record" placeholders
+
+Checking for "pid = -1" is not recommended anymore - using the restrictions and custom query information can be
+used in previous TYPO3 versions already.
+
+
+.. index:: Database, ext:workspaces

Documentation/Changelog/10.1/Index.rst

@@ -0,0 +1,53 @@
+:template: changelogOverview.html
+.. include:: /Includes.rst.txt
+..  _changelog-10-1:
+
+10.1 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-*