TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/11.3/Deprecation-91806-BackendUtilityViewOnClick.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-91806:
+
+================================================
+Deprecation: #91806 - BackendUtility viewOnClick
+================================================
+
+See :issue:`91806`
+
+Description
+===========
+
+Method :php:`BackendUtility::viewOnClick()` is discouraged to be used
+due to its inline JavaScript and has been deprecated now.
+
+
+Impact
+======
+
+Using the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extensions calling this static method will be affected. The extension
+scanner will find usages as strong match.
+
+
+Migration
+=========
+
+The :php:`\TYPO3\CMS\Backend\Routing\PreviewUriBuilder` should be used
+instead as described in
+:doc:`/Changelog/11.0/Important-91123-AvoidUsingBackendUtilityViewOnClick`.
+
+.. index:: Backend, JavaScript, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.3/Deprecation-94058-JavaScriptGoToModule.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94058:
+
+=============================================
+Deprecation: #94058 - JavaScript goToModule()
+=============================================
+
+See :issue:`94058`
+
+Description
+===========
+
+One of the most prominent inline JavaScript functions
+:js:`goToModule()` has been deprecated in favor of a streamlined
+ActionHandler API for JavaScript.
+
+
+Impact
+======
+
+When using the internal backend module entry objects via `setOnClick` and
+`getOnClick` methods, PHP deprecation warnings are now triggered.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions referencing these methods.
+
+
+Migration
+=========
+
+Use the following HTML code to replace the inline :js:`goToModule()`
+call to for example link to the page module:
+
+..  code-block:: html
+
+    <a href="#"
+       data-dispatch-action="TYPO3.ModuleMenu.showModule"
+       data-dispatch-args-list="web_layout"
+    >
+       Go to page module
+    </a>
+
+Inside actual JavaScript code, you can replace calls to :js:`goToModule()`
+(or :js:`top.goToModule()`) like this:
+
+..  code-block:: js
+    :caption: Example for TYPO3 v12+
+
+    // Utilize imports rather than straight usage of TYPO3.ModuleMenu.App.showModule()
+    import ModuleMenu from '@typo3/backend/module-menu.js';
+
+    ModuleMenu.App.showModule('web_layout')
+
+..  code-block:: js
+    :caption: Example for TYPO3 v11
+
+    TYPO3.ModuleMenu.App.showModule('web_layout')
+
+.. index:: JavaScript, FullyScanned, ext:backend

Documentation/Changelog/11.3/Deprecation-94115-ParameterTypeEvaluationViaDocBlockComments.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94115:
+
+=====================================================================
+Deprecation: #94115 - Parameter type evaluation via DocBlock comments
+=====================================================================
+
+See :issue:`94115`
+
+Description
+===========
+
+Extbase had a long support for detecting the actual
+target type of a method argument by parsing the DocBlock
+annotations like
+
+.. code-block:: php
+
+   /**
+    * @param \MyVendor\MyExtension\MyModel $item
+    */
+   public function myAction($item);
+
+However, since PHP 7 supports to define the target type
+by specifying the type directly in the language, which is
+much faster, the "legacy" way of handling type detection for
+arguments are marked as deprecated.
+
+
+Impact
+======
+
+When a DocBlock annotation like :php:`@param \MyClass $item` is added, but
+the actual type is not added to the method argument via native PHP type
+declarations, a deprecation message is now triggered.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom Extbase extensions which
+were never upgraded to support latest PHP language constructs.
+
+
+Migration
+=========
+
+Use native PHP type declarations instead - this can be achieved since TYPO3 v10:
+
+.. code-block:: php
+
+   public function myAction(\MyVendor\MyExtension\MyModel $item);
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94137-SwitchBehaviorOfArrayUtilityarrayDiffAssocRecursive.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94137:
+
+================================================================================
+Deprecation: #94137 - Switch behavior of ArrayUtility::arrayDiffAssocRecursive()
+================================================================================
+
+See :issue:`94137`
+
+Description
+===========
+
+Despite its name, the method
+:php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()`
+mimics the behavior of :php:`array_diff_key()` and not of
+:php:`array_diff_assoc()`.
+
+
+Impact
+======
+
+The method has been adjusted to act like :php:`array_diff_assoc()`. As this is
+considered being a breaking change, the behavior must be enabled explicitly by
+passing a third parameter :php:`$useArrayDiffAssocBehavior` being true. If the
+argument is either omitted or :php:`false`, the old behavior is kept but a
+deprecation warning will be thrown.
+
+
+Affected Installations
+======================
+
+Every 3rd party extension using
+:php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()`
+without its third argument being :php:`true` is affected.
+
+
+Migration
+=========
+
+To keep the previous :php:`array_diff_key()` based behavior, use the introduced
+method :php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffKeyRecursive()`.
+To make use of the :php:`array_diff_assoc()` based behavior, which will become
+the default behavior in TYPO3 v12, pass :php:`true` as the third argument.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94165-SysLanguageDatabaseTable.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94165:
+
+========================================
+Deprecation: #94165 - sys_language table
+========================================
+
+See :issue:`94165`
+
+Description
+===========
+
+Since the introduction of site handling back in TYPO3 v9, available
+languages and their associated information, for example locale, ISO code or the
+navigation title are configured in the site configurations. As a consequence,
+the :sql:`sys_language` table just duplicated this information and is therefore
+now deprecated.
+
+The Core internally does not longer rely on this table but fetches
+necessary information from the site languages instead. This means, there
+won't be any relation to the :sql:`sys_language` table, which allows to
+define any kind of "ID" for the :php:`languageField` field of records, which
+is usually :sql:`sys_language_uid`.
+
+Also the site languages, used in site configurations, are now completely
+independent of any :sql:`sys_language` record. Previously, when using the
+site module to create or edit a site configuration, site languages could
+only be added when a corresponding :sql:`sys_language` record existed.
+This has now changed. The site configurations' `languages` field now
+features a :guilabel:`Create new language` button, which allows to create a new
+site language for this site configuration. Such newly created site
+language will then also be available in the selector box of all other
+site configurations. The ID for a new site language is always created
+automatically (auto-increment). When selecting this site language in
+another site configuration, most of the fields will now be prefilled.
+
+.. note::
+
+   When creating the first site configuration of a new installation, the
+   languages selector box is empty, as new languages must be created via
+   the :guilabel:`Create new language` button first. However, a default
+   language (ID=0) record will always be added automatically.
+
+Impact
+======
+
+Currently there is no direct impact. However, if your code relies on TYPO3
+processing :sql:`sys_language`, you might have to adapt those places to use
+site languages instead.
+
+Affected Installations
+======================
+
+All installations which rely on TYPO3 processing the :sql:`sys_language`
+table. For example for fetching available languages and their related
+information.
+
+Migration
+=========
+
+Adapt your code to always use site languages for fetching and processing
+language related information.
+
+For example, use the new TCA type `language`, introduced in :issue:`57082`,
+instead of :php:`foreign_table => sys_language` for selecting a records'
+language.
+
+.. index:: Database, TCA, NotScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94193-PublicUrlWithRelativePathsInFALAPI.rst

@@ -0,0 +1,83 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94193:
+
+================================================================
+Deprecation: #94193 - Public URLs with relative paths in FAL API
+================================================================
+
+See :issue:`94193`
+
+Description
+===========
+
+The public FAL API for accessing the public url of a FAL object,
+for example :php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`, previously allowed to
+retrieve the relative path instead of the absolute path. This could
+be achieved by setting :php:`$relativeToCurrentScript` to :php:`true`
+while calling :php:`getPublicUrl()`.
+
+FAL is only able to build relative links for local drivers. Other drivers
+would still return the absolute URL, which has often led to unexpected
+side effects.
+
+Since both, frontend (site handling) and backend (url routing) are meanwhile
+fully capable of supporting absolute URLs, :php:`$relativeToCurrentScript`
+is now deprecated and will be removed in TYPO3 v12.
+
+This also affects the :php:`isRelativeToCurrentScript()` method in the
+:php:`GeneratePublicUrlForResourceEvent` event, as well as the
+:php:`OnlineMediaHelperInterface`.
+
+Impact
+======
+
+Calling :php:`getPublicUrl()` on a FAL object, for example
+:php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`, with :php:`$relativeToCurrentScript`
+set to :php:`true`
+will trigger a PHP :php:`E_USER_DEPRECATED` error. The extension scanner
+will detect such calls.
+
+Accessing :php:`isRelativeToCurrentScript()` on
+:php:`GeneratePublicUrlForResourceEvent` will trigger a PHP
+:php:`E_USER_DEPRECATED` error. The extension scanner will detect
+such calls.
+
+Manually calling :php:`getPublicUrl()` on an :php:`OnlineMediaHelper`,
+for example :php:`YoutubeHelper`, will not trigger a PHP :php:`E_USER_DEPRECATED`
+error, but the extension scanner will detect such calls.
+
+Affected Installations
+======================
+
+All installations which set :php:`$relativeToCurrentScript` to :php:`true`
+when calling :php:`getPublicUrl()` on a FAL object, for example
+:php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`.
+
+All installations which manually call :php:`getPublicUrl()` on an
+:php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelper`,
+for example :php:`\TYPO3\CMS\Core\Resource\Rendering\YoutubeRenderer`.
+
+All installation which access :php:`isRelativeToCurrentScript()` on the
+:php:`\TYPO3\CMS\Core\Resource\Event\GeneratePublicUrlForResourceEvent` event.
+
+Migration
+=========
+
+Remove the :php:`$relativeToCurrentScript` parameter from all calls to
+:php:`getPublicUrl()` on FAL objects, for example
+:php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`.
+
+Remove the :php:`$relativeToCurrentScript` parameter from all manual calls
+to :php:`getPublicUrl()` on a
+:php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelper`,
+for example :php:`\TYPO3\CMS\Core\Resource\Rendering\YoutubeRenderer`.
+
+Remove all calls to
+:php:`\TYPO3\CMS\Core\Resource\Event\GeneratePublicUrlForResourceEvent->isRelativeToCurrentScript()`.
+
+.. index:: FAL, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94209-BackendModuleLayoutViewHelpers.rst

@@ -0,0 +1,77 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94209:
+
+======================================================
+Deprecation: #94209 - Backend ModuleLayout ViewHelpers
+======================================================
+
+See :issue:`94209`
+
+Description
+===========
+
+The following Fluid ViewHelpers have been deprecated:
+
+*  :html:`be:moduleLayout`
+*  :html:`be:moduleLayout.menu`
+*  :html:`be:moduleLayout.menuItem`
+*  :html:`be:moduleLayout.button.linkButton`
+*  :html:`be:moduleLayout.button.shortcutButton`
+
+These ViewHelpers partially mimic their counterparts of the PHP based
+:php:`ModuleTemplate` API. They were previously used in backend modules
+when the 'doc header' handling was done in Fluid.
+
+The ViewHelpers however relied on knowledge that shouldn't be the scope
+of a view component, especially variables like the current action
+and controller had to be assigned to the view in many cases.
+
+Additionally, those ViewHelpers were only a sub set of the ModuleTemplate
+functionality and created a second API for the same problem domain and
+various scenarios like good shortcut implementation and main drop down
+state were hard to solve when using these ViewHelpers.
+
+
+Impact
+======
+
+Using these ViewHelpers will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Some extensions with backend modules may use these ViewHelpers. Searching
+templates for string :php:`be:moduleLayout` should reveal usages. Extensions
+extending the PHP classes are found by the extension scanner as a weak match.
+
+
+Migration
+=========
+
+In general, extensions using these ViewHelpers should switch to using the
+PHP API based on class :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate`,
+usually initialized by class
+:php:`\TYPO3\CMS\Backend\Template\ModuleTemplateFactory` instead.
+All Core extensions that render backend
+modules provide usage examples and the fluent API is quite straight
+forward.
+
+Using the :html:`be:moduleLayout` ViewHelper always rendered FlashMessages
+from the queue :php:`'extbase.flashmessages.' . $pluginNamespace` on top of the
+content area. You can either use the :html:`f:flashMessages` ViewHelper
+or :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate::setFlashMessageQueue()`
+as replacements.
+
+For Extbase base backend modules, the 'doc header' should be handled within
+controller actions, while the module body is rendered
+by the Fluid view component.
+
+In case an extension heavily relies on the deprecated ViewHelpers and the
+functionality should be kept with as little work as possible, the easiest
+way is of course to simply copy the according ViewHelpers to the extension
+directly and to just adapt the namespace in templates accordingly.
+
+
+.. index:: Backend, Fluid, PartiallyScanned, ext:backend

Documentation/Changelog/11.3/Deprecation-94223-ExtbaseRequest-getBaseUri.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94223:
+
+===================================================
+Deprecation: #94223 - Extbase Request->getBaseUri()
+===================================================
+
+See :issue:`94223`
+
+Description
+===========
+
+To further prepare Extbase towards PSR-7 compatible requests, the
+Extbase :php:`TYPO3\CMS\Extbase\Mvc\Request` has to be streamlined.
+
+Method :php:`getBaseUri()` has been deprecated and shouldn't be
+used any longer.
+
+
+Impact
+======
+
+Using the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+This getter is probably used rather seldom in extensions since both
+frontend and backend take care of base URI's in many cases already.
+The extension scanner will find remaining usages.
+
+
+Migration
+=========
+
+When :php:`getBaseUri()` is called in extensions, it is most likely
+in a view related component. Since Fluid ViewHelpers currently still
+don't receive an instance of the native PSR-7 request (which will change),
+a typical substitution of this getter looks like this for now:
+
+.. code-block:: php
+
+    // @todo Adapt this example as soon as ViewHelpers receive a ServerRequestInterface
+    $request = $GLOBALS['TYPO3_REQUEST'];
+    $normalizedParams = $request->getAttribute('normalizedParams');
+    $baseUri = $normalizedParams->getSiteUrl();
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94225-FbecontainerViewHelper.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94225:
+
+===============================================
+Deprecation: #94225 - f:be.container ViewHelper
+===============================================
+
+See :issue:`94225`
+
+Description
+===========
+
+The :html:`<f:be.container>` ViewHelper has been deprecated.
+
+This backend-module-related ViewHelper was pretty useless since
+it mostly provides the same functionality as :html:`<f:be.pageRenderer>`,
+with the additional opportunity to render an empty doc header.
+
+
+Impact
+======
+
+Using the ViewHelper in Fluid templates will trigger a PHP
+:php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+The limited functionality of the ViewHelper likely leads to little
+usage numbers.
+Searching extensions for the string html:`<f:be.container>` should
+reveal any usages.
+
+
+Migration
+=========
+
+When this ViewHelper is used to register additional backend module
+resources like CSS or JavaScript, :html:`<f:be.pageRenderer>` can be
+used as drop-in replacement.
+
+If the ViewHelper is used to additionally render an empty ModuleTemplate,
+this part should be moved to a controller instead. Simple example for an
+extbase controller:
+
+.. code-block:: php
+
+    $moduleTemplate->setContent($view->render());
+    return $this->htmlResponse($moduleTemplate->renderContent());
+
+In case your controller does not extend :php:`ActionController`, use
+the PSR-17 interfaces for generating the response:
+
+.. code-block:: php
+
+    $moduleTemplate->setContent($view->render());
+    return $this->responseFactory->createResponse()
+        ->withHeader('Content-Type', 'text/html; charset=utf-8')
+        ->withBody($this->streamFactory->createStream($moduleTemplate->renderContent());
+
+.. index:: Backend, Fluid, NotScanned, ext:fluid

Documentation/Changelog/11.3/Deprecation-94227-FbaseViewHelper.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94227:
+
+=======================================
+Deprecation: #94227 - f:base ViewHelper
+=======================================
+
+See :issue:`94227`
+
+Description
+===========
+
+The :html:`<f:base>`  ViewHelper isn't suitable in almost all use cases
+and has been deprecated: In most cases the :php:`PageRenderer` takes care of the
+main :html:`<head>` markup, directly, or indirectly via TypoScript :html:`config.baseURL`.
+
+
+Impact
+======
+
+Using the ViewHelper in Fluid templates will log a deprecation warning
+and the ViewHelper will be dropped with v12.
+
+
+Affected Installations
+======================
+
+The limited use of the ViewHelper likely leads to little usage numbers.
+Searching extensions for the string html:`<f:base>` should
+reveal any usages.
+
+
+Migration
+=========
+
+The easiest solution is to simply copy PHP class
+:php:`TYPO3\CMS\Fluid\ViewHelpers\BaseViewHelper` to the consuming extension,
+giving the ViewHelper a happy life in an extension specific namespace.
+
+
+.. index:: Fluid, NotScanned, ext:fluid

Documentation/Changelog/11.3/Deprecation-94228-DeprecateExtbaseRequestGetRequestUri.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94228:
+
+=====================================================
+Deprecation: #94228 - Extbase request getRequestUri()
+=====================================================
+
+See :issue:`94228`
+
+Description
+===========
+
+To further prepare Extbase towards PSR-7 compatible requests, the
+Extbase :php:`TYPO3\CMS\Extbase\Mvc\Request` has to be streamlined.
+
+Method :php:`getRequestUri()` has been deprecated and shouldn't be
+used any longer.
+
+
+Impact
+======
+
+Using the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extbase based extensions may use this method. The extension scanner
+will find usages as weak match.
+
+
+Migration
+=========
+
+When :php:`getRequestUri()` is called in extensions, the same information
+can be retrieved from the native PSR-7 request. At the moment, this is usually
+only available using :php:`$GLOBALS['TYPO3_REQUEST']`, but this will change
+when the Extbase request is compatible with PSR-7 ServerRequestInterface.
+A substitution looks like this for now:
+
+.. code-block:: php
+
+    // @todo Adapt this example as soon as Extbase Request implements ServerRequestInterface
+    $request = $GLOBALS['TYPO3_REQUEST'];
+    $normalizedParams = $request->getAttribute('normalizedParams');
+    $requestUrl = $normalizedParams->getRequestUrl();
+
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94231-DeprecateExtbaseInvalidRequestMethodException.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94231:
+
+===========================================================
+Deprecation: #94231 - Extbase InvalidRequestMethodException
+===========================================================
+
+See :issue:`94231`
+
+Description
+===========
+
+To further prepare towards PSR-7 Requests in Extbase, the
+:php:`TYPO3\CMS\Extbase\Mvc\Request` has to be streamlined.
+
+Therefore, the internal method :php:`setMethod()` has been removed.
+This method previously threw the :php:`InvalidRequestMethodException`.
+Since this was the only usage and the exception is not used within
+TYPO3 / Extbase anymore, the exception is deprecated.
+
+Impact
+======
+
+Using :php:`TYPO3\CMS\Extbase\Mvc\Exception\InvalidRequestMethodException`
+in custom extension code is discouraged since it will be removed with TYPO3
+v12 and is also no longer thrown by TYPO3.
+
+Affected Installations
+======================
+
+Extbase based extensions may manually throw or catch
+:php:`TYPO3\CMS\Extbase\Mvc\Exception\InvalidRequestMethodException`.
+The extension scanner will find those usages.
+
+Migration
+=========
+
+All usages of :php:`TYPO3\CMS\Extbase\Mvc\Exception\InvalidRequestMethodException`
+in custom extension code, which is very unlikely, have to be replaced with a
+custom exception, if needed at all.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94252-DeprecatedGeneralUtilitycompileSelectedGetVarsFromArray.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94252:
+
+=====================================================================
+Deprecation: #94252 - GeneralUtility::compileSelectedGetVarsFromArray
+=====================================================================
+
+See :issue:`94252`
+
+Description
+===========
+
+In our effort to reduce usages of :php:`GeneralUtility::_GP()`, the
+:php:`GeneralUtility` method :php:`compileSelectedGetVarsFromArray` is
+deprecated, since it internally calls :php:`GeneralUtility::_GP()` instead
+of accessing the PSR-7 Request. The method was furthermore only used once
+in the Core since it's internal logic can easily be implemented on a case
+by case basis.
+
+Impact
+======
+
+Using the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All TYPO3 installations calling this method in custom code are affected.
+The extension scanner will find such usages as strong match.
+
+
+Migration
+=========
+
+Usages of the method in custom extension code have to be replaced
+with a custom implementations, preferably using the PSR-7 Request.
+
+See: :php:`\TYPO3\CMS\Backend\Controller\EditDocumentController->compileStoreData()`
+for an example on how such migration could look like.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94272-DeprecatedApplication-runCallback.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94272:
+
+===============================================
+Deprecation: #94272 - Application->run callback
+===============================================
+
+See :issue:`94272`
+
+Description
+===========
+
+Since the introduction of the :php:`\TYPO3\CMS\Core\Core\ApplicationInterface`
+in :issue:`67808` (TYPO3 v7), which serves as a wrapper for setting up the bootstrap and
+calling the request, it was possible to run either the console, the frontend
+or the backend by calling :php:`run()` on the corresponding Application class.
+
+The :php:`run()` method also featured the possibility to provide a :php:`callback`
+as first argument. This was mainly introduced, since no proper solution for
+sub requests existed at that time. Since :issue:`83725`, the callback is not
+longer necessary as such functionality can be handled by a PSR-15
+middleware.
+
+Therefore, the :php:`$execute` argument of :php:`ApplicationInterface->run()`
+has been deprecated and will be removed in v12.
+
+Impact
+======
+
+Calling :php:`\TYPO3\CMS\Core\Core\ApplicationInterface->run()` with the
+first argument :php:`$execute` set, triggers a PHP :php:`E_USER_DEPRECATED` error.
+
+Affected Installations
+======================
+
+All installations which manually call
+:php:`\TYPO3\CMS\Core\Core\ApplicationInterface->run()`,
+while providing a callback as first argument. The extension scanner
+will find those usages as weak match.
+
+Migration
+=========
+
+Instances with extensions calling
+:php:`\TYPO3\CMS\Core\Core\ApplicationInterface->run()` with a callback
+as first argument need to be adapted. If possible use PSR-15 middlewares
+instead.
+
+Console commands do not feature PSR-15 middlewares. Therefore, the callback
+has to be replaced by separate chained post-processing commands.
+
+.. index:: CLI, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94309-DeprecatedGeneralUtilitystdAuthCode.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94309:
+
+=================================================
+Deprecation: #94309 - GeneralUtility::stdAuthCode
+=================================================
+
+See :issue:`94309`
+
+Description
+===========
+
+The method :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::stdAuthCode()`
+has not been used within the Core since at least v9. It internally fiddles
+with the `encryptionKey` while using :php:`md5()`. Furthermore, the default
+length of 8 chars could easily lead to hash collisions. The TYPO3 Core already
+provides :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::hmac()` for such
+purposes, which is using `sha1` with a length of 40. Therefore,
+:php:`stdAuthCode()` has been deprecated and will be removed in TYPO3 v12.
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Affected Installations
+======================
+
+All TYPO3 installations calling this method in custom code. The extension
+scanner will find all usages as strong match.
+
+Migration
+=========
+
+Replace all usages of the method in custom extension code by either using
+:php:`\TYPO3\CMS\Core\Utility\GeneralUtility::hmac()` or by a custom
+implementation.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94311-DeprecatedGeneralUtilityrmFromList.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94311:
+
+================================================
+Deprecation: #94311 - GeneralUtility::rmFromList
+================================================
+
+See :issue:`94311`
+
+Description
+===========
+
+The method :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::rmFromList()` has not
+been used in the Core since v10. The method has now been deprecated
+in :php:`\TYPO3\CMS\Core\Utility\GeneralUtility` and will be removed in
+TYPO3 v12.
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All TYPO3 installations calling this method in custom code. The extension
+scanner will find all such usages as strong match.
+
+
+Migration
+=========
+
+Replace all usages of the method in your extension code.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94313-ClassAbstractService.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94313:
+
+===========================================
+Deprecation: #94313 - AbstractService class
+===========================================
+
+See :issue:`94313`
+
+Description
+===========
+
+The :php:`TYPO3\CMS\Core\Service\AbstractService` class is part of the ancient
+:ref:`Service API <t3coreapi:services-developer-service-api>`.
+This API did not really prevail, except it's usage for the authentication process.
+
+Since the authentication service related functionality was already
+decoupled over the last years, the :php:`AbstractService` got finally
+unused in Core since :issue:`88646`. Therefore it has now been marked
+as deprecated.
+
+Impact
+======
+
+Extending this class does *not* raise a deprecation error level log entry.
+The class contains only a `@deprecated` class annotation. Extension classes
+can still extend this class in v11 without impact, it will raise a PHP fatal
+error in v12, when the class is dropped.
+
+
+Affected Installations
+======================
+
+As mentioned, the Service API never found many usages in casual extensions.
+It is therefore pretty unlikely that well maintained projects are affected.
+The extension scanner will find any class usages as a strong match.
+
+Migration
+=========
+
+Remove any usage of this class in your extension. In case you currently
+extend :php:`AbstractService` for use in an authentication service, which
+might be the most common scenario, you have to change your service class
+to extend from :php:`AbstractAuthenticationService` instead.
+
+In case you currently extend :php:`AbstractService` for another kind of
+service, which is rather unlikely, you have to implement the necessary
+methods in your service class yourself. Please see `Service Implementation
+<https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Services/Developer/ServiceApi.html#service-implementation>`__
+for more details about the required methods. However, even better would be to
+completely migrate away from the Service API (look for :php:`GeneralUtility::makeInstanceService()`),
+since the Core will deprecate these related methods as well.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94316-DeprecatedHTTPHeaderManipulatingMethodsFromHttpUtility.rst

@@ -0,0 +1,86 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94316:
+
+=======================================================================
+Deprecation: #94316 - HTTP header manipulating methods from HttpUtility
+=======================================================================
+
+See :issue:`94316`
+
+Description
+===========
+
+In order to properly handle PSR-7 response objects, explicit :php:`die()`
+or :php:`exit()` calls, as well as directly manipulating HTTP headers with
+:php:`header()` should be avoided. Therefore following methods from
+:php:`\TYPO3\CMS\Core\Utility\HttpUtility` have been marked as deprecated:
+
+*  :php:`redirect()`
+*  :php:`setResponseCode()`
+*  :php:`setResponseCodeAndExit()`
+
+The TYPO3 Core already provides a couple of possibilities to properly handle
+such events in a PSR-7 conform way. Most of the time, a proper PSR-7 response
+can be passed back to the call stack (request handler). Unfortunately there
+might still be some places, inside the call stack, where it's not possible to
+directly return a PSR-7 response. In such case, the
+:php:`\TYPO3\CMS\Core\Http\PropagateResponseException`
+could be thrown. It will automatically be caught by a PSR-15 middleware and the
+given PSR-7 response will then directly be returned, making any :php:`die()`
+or :php:`exit()` call obsolete.
+
+The usage is as following:
+
+.. code-block:: php
+
+   // Before
+   HttpUtility::redirect('https://example.com', HttpUtility::HTTP_STATUS_303);
+
+   // After
+
+   // Inject PSR-17 ResponseFactoryInterface
+   public function __construct(ResponseFactoryInterface $responseFactory)
+   {
+      $this->responseFactory = $responseFactory
+   }
+
+   // Create redirect response
+   $response = $this->responseFactory
+      ->createResponse(303)
+      ->withAddedHeader('location', 'https://example.com')
+
+   // Return Response directly
+   return $reponse;
+
+   // or throw PropagateResponseException
+   throw new PropagateResponseException($response);
+
+.. note::
+
+   Throwing exceptions for returning an immediate PSR-7 Response is considered
+   as an intermediate solution only, until it's possible to return PSR-7
+   responses in every relevant place. Therefore, the exception is marked
+   as :php:`@internal` and will most likely vanish again in the future.
+
+Impact
+======
+
+Calling one of those methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Affected Installations
+======================
+
+All TYPO3 installations calling those methods in custom code. The extension
+scanner will find all usages as strong match.
+
+Migration
+=========
+
+Replace all occurrences in custom extension code. Therefore, create a redirect
+response with the PSR-17 ResponseFactoryInterface, and pass it back to the call
+stack (request handler). In case, it's not possible to directly return a PSR-7
+Response, you can use the :php:`\TYPO3\CMS\Core\Http\PropagateResponseException`
+as an intermediate solution.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.3/Deprecation-94317-ExtformFinisherImplementations.rst

@@ -0,0 +1,68 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94317:
+
+=======================================================
+Deprecation: #94317 - ext:form Finisher implementations
+=======================================================
+
+See :issue:`94317`
+
+Description
+===========
+
+In preparation of the Extbase ObjectManager deprecation in favor of
+symfony dependency injection, some details of EXT:form finishers had
+to be adapted: In contrast to Extbase object management, symfony DI does
+not support prototype classes with a mixture of manual constructor arguments,
+plus dependency injection via other constructor arguments or inject methods.
+
+The EXT:form finishers based on :php:`TYPO3\CMS\Form\Domain\Finishers\FinisherInterface`
+relied on this and had to be adapted: The default constructor argument
+:php:`$finisherIdentifier` has been dropped, so finisher implementations can
+keep using dependency injection.
+
+
+Impact
+======
+
+A compatibility layer detects non-adapted finishers and falls back to
+initialization using Extbase ObjectManager. This will will trigger a
+PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+In general only instances with custom form based on EXT:form are affected, and
+only if they implement custom finishers.
+
+Most custom finishers probably extend :php:`TYPO3\CMS\Form\Domain\Finishers\AbstractFinisher`.
+Those are only affected if they override :php:`__construct()` or use or manipulate
+properties :php:`$finisherIdentifier` or :php:`$shortFinisherIdentifier` in
+:php:`inject*()` or :php:`injectObject()` methods. This is rather unlikely.
+
+Custom finishers that do not extend :php:`TYPO3\CMS\Form\Domain\Finishers\AbstractFinisher`
+are affected.
+
+
+Migration
+=========
+
+Custom finishers should extend :php:`TYPO3\CMS\Form\Domain\Finishers\AbstractFinisher`.
+
+If they must implement :php:`__construct()`, they should not expect :php:`$finisherIdentifier`
+to be hand over as first argument and must not call :php:`parent::construct()` anymore.
+
+Custom finishers must not rely on :php:`$finisherIdentifier` or :php:`$shortFinisherIdentifier`
+being set in early methods like :php:`__construct()`, :php:`inject*()` and :php:`injectObject()`,
+and must not set these properties.
+
+Custom finishers must implement method :php:`setFinisherIdentifier()`, this method will
+be added to :php:`TYPO3\CMS\Form\Domain\Finishers\FinisherInterface` in TYPO3 v12.
+
+Custom finishers must not use class property :php:`$objectManager` since this will vanish
+in v12. This will affect more API cases and will have a dedicated deprecation file
+with more details, though.
+
+.. index:: PHP-API, NotScanned, ext:form

Documentation/Changelog/11.3/Deprecation-94351-ExtextbaseStopActionException.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94351:
+
+=====================================================
+Deprecation: #94351 - ext:extbase StopActionException
+=====================================================
+
+See :issue:`94351`
+
+Description
+===========
+
+To further prepare towards clean PSR-7 request / response handling in
+Extbase, the Extbase internal exception
+:php:`TYPO3\CMS\Extbase\Mvc\Exception\StopActionException`
+has been deprecated.
+
+
+Impact
+======
+
+No deprecation is logged, but the :php:`StopActionException` will be
+removed in v12 as breaking change. Extension developers with Extbase
+based controllers can prepare in v11 towards this.
+
+
+Affected Installations
+======================
+
+Extensions with Extbase controllers that throw :php:`StopActionException` or
+use methods :php:`redirect` or :php:`redirectToUri` from Extbase
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController`
+are affected.
+
+
+Migration
+=========
+
+As a goal, Extbase actions will *always* return a
+:php:`\Psr\Http\Message\ResponseInterface`
+in v12. v11 prepares towards this, but still throws the :php:`StopActionException`
+in :php:`redirectToUri`. Developers should prepare towards this.
+
+Example before:
+
+.. code-block:: php
+
+   public function fooAction()
+   {
+      $this->redirect('otherAction');
+   }
+
+Example compatible with v10, v11 and v12 - IDE's and static code analyzers
+may complain in v10 and v11, though:
+
+.. code-block:: php
+
+   public function fooAction(): ResponseInterface
+   {
+      // A return is added!
+      return $this->redirect('otherAction');
+   }
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94367-ExtbaseReferringRequest.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94367:
+
+==============================================
+Deprecation: #94367 - Extbase ReferringRequest
+==============================================
+
+See :issue:`94367`
+
+Description
+===========
+
+To further prepare Extbase towards PSR-7 compatible requests, Extbase class
+:php:`TYPO3\CMS\Extbase\Mvc\Web\ReferringRequest` has been deprecated.
+
+
+Impact
+======
+
+Creating an instance of :php:`ReferringRequest` a PHP :php:`E_USER_DEPRECATED`
+error.
+
+
+Affected Installations
+======================
+
+:php:`ReferringRequest` has been mostly Extbase internal and rarely used in
+Extbase extensions, probably only in cases where
+:php:`ActionController->forwardToReferringRequest()` is overridden.
+The extension scanner will find usages with a strong match.
+
+Migration
+=========
+
+Extbase internally, :php:`ReferringRequest` has only been used to
+immediately create a :php:`ForwardResponse` from it. Consuming extensions
+should follow his approach and create a :php:`ForwardResponse` directly.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94377-ExtbaseObjectManager-getEmptyObject.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94377:
+
+===========================================================
+Deprecation: #94377 - Extbase ObjectManager->getEmptyObject
+===========================================================
+
+See :issue:`94377`
+
+Description
+===========
+
+Extbase has the odd behavior that
+:php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface` objects -
+typically classes in :file:`Classes/Domain/Model` of Extbase enabled
+extensions - don't call :php:`__construct` when the persistence layer
+"thaws" a model from database - typically when an Extbase
+:php:`Domain/Repository` uses a :php:`->findBy*` method.
+
+As a side-effect of switching away from Extbase :php:`ObjectManager` towards
+symfony based dependency injection, this behavior will change in TYPO3 v12:
+Method :php:`__construct()` will be called in v12 when the :php:`DataMapper`
+creates model instances from database rows.
+
+
+Impact
+======
+
+There is no impact in TYPO3 v11 and no deprecation log entry is raised.
+However, extension developers *should* prepare toward this change in v11
+to avoid any impact of a breaking change in v12.
+
+
+Affected Installations
+======================
+
+Extbase extensions having domain models that implement :php:`__construct()`
+are affected. It is rather unlikely this has any impact on the behavior
+of the extension, though.
+
+Additionally, calls to API method
+:php:`TYPO3\CMS\Extbase\Object\ObjectManager->getEmptyObject()` should be
+avoided since it will vanish in v12. The vast majority of extensions will
+not do this, though. The extension scanner will find candidates.
+
+
+Migration
+=========
+
+No migration possible. Simply expect that :php:`__construct()` of a domain
+model will be called in v12 when a domain repository :php:`findBy` method
+directly or indirectly reconstitutes a model object from a database row.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94394-ExtbaseRequestSetDispatchedAndIsDispatched.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94394:
+
+========================================================================
+Deprecation: #94394 - Extbase Request setDispatched() and isDispatched()
+========================================================================
+
+See :issue:`94394`
+
+Description
+===========
+
+To further prepare towards PSR-7 requests in Extbase, the two
+methods :php:`TYPO3\CMS\Extbase\Mvc\Request->setDispatched()` and
+:php:`TYPO3\CMS\Extbase\Mvc\Request->isDispatched()` have been
+marked as deprecated.
+
+
+Impact
+======
+
+Using the methods is discouraged. The Extbase dispatcher still
+recognizes them and acts accordingly, the methods do **not** raise
+a deprecation level log entry, though.
+
+
+Affected Installations
+======================
+
+Some Extbase based extensions may use :php:`setDispatched()`, but
+it's rather unlikely since that flag has been mostly used internally
+through existing helper methods in Extbase controllers.
+
+The extension scanner will find possible candidates.
+
+
+Migration
+=========
+
+Action dispatching in Extbase now depends on the returned response:
+
+*  A casual 2xx Response from a controller action that for instance contains HTML
+   or Json stops Extbase dispatching, the response is later returned to the client.
+
+*  An Extbase :php:`ForwardResponse` instructs the dispatcher to dispatch
+   internally to another controller action.
+
+*  A 3xx :php:`RedirectResponse` stops dispatching and is returned to the client
+   to initiate some client redirect.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.3/Deprecation-94414-DeprecateLanguageServiceContainerEntry.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-94414:
+
+=====================================================
+Deprecation: #94414 - LanguageService container entry
+=====================================================
+
+See :issue:`94414`
+
+Description
+===========
+
+Instances of :php:`TYPO3\CMS\Core\Localization\LanguageService` require
+custom initialization with a language key and additionally depend on Core services.
+:php:`TYPO3\CMS\Core\Localization\LanguageServiceFactory` has therefore
+previously been introduced in order to manage this initialization.
+This replaced prior used instantiation via
+:php:`TYPO3\CMS\Core\Localization\LanguageService::create()` or
+:php:`GeneralUtility::makeInstance(LanguageService::class)`.
+
+
+Impact
+======
+
+Injecting :php:`TYPO3\CMS\Core\Localization\LanguageService` or creating
+instances via :php:`GeneralUtility::makeInstance(LanguageService::class)`,
+:php:`LanguageService::create()`, :php:`LanguageService::createFromUserPreferences()`
+or :php:`LanguageService::createFromSiteLanguage()` will trigger a
+PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extensions injecting :php:`TYPO3\CMS\Core\Localization\LanguageService`
+or creating custom instances via :php:`GeneralUtility::makeInstance(LanguageService::class)`
+or :php:`TYPO3\CMS\Core\Localization\LanguageService::create()`.
+
+This is relatively unlikely since most usages are bootstrap related and
+extensions usually access the prepared LanguageService via :php:`GLOBALS['LANG']`
+in normal cases.
+
+Usages of :php:`LanguageService::create()`, :php:`LanguageService::createFromUserPreferences()`
+and :php:`LanguageService::createFromSiteLanguage()` are be found by the extension scanner
+as strong match.
+
+
+Migration
+=========
+
+The factory :php:`TYPO3\CMS\Core\Localization\LanguageServiceFactory`
+should be injected and used instead.
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/11.3/Feature-89507-AddDescriptionForTCAPalettes.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89507:
+
+==================================================
+Feature: #89507 - Add description for TCA palettes
+==================================================
+
+See :issue:`89507`
+
+Description
+===========
+
+A new TCA property :php:`description` on palettes entry level has been
+introduced. If provided, the FormEngine will render its value below the
+palette label, similar to the TCA field description. The value data
+type is the same as for the palette label: a localized string. This
+additional help text can therefore be used to clarify some field
+usages directly in the UI.
+
+.. note::
+
+   In contrast to the palette label, the description property can not
+   be overwritten on a record type basis.
+
+Example usage:
+
+.. code-block:: php
+
+   'types' => [
+       '0' => [
+           'showitem' => '
+               --div--;palette,
+                   --palette--;;palette_1,
+           '
+       ]
+   ],
+
+   'palettes' => [
+       'palette_1' => [
+           'label' => 'palette_1',
+           'description' => 'palette_1_description',
+           'showitem' => 'palette_field_1, palette_field_2, palette_field_3',
+       ],
+   ],
+
+
+Impact
+======
+
+Integrators now have the ability to add additional information
+to TCA palettes, supporting editors on their daily work.
+
+.. index:: Backend, TCA, ext:backend

Documentation/Changelog/11.3/Feature-89700-ShowLayoutsInTheWebInfoModule.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89700:
+
+=====================================================
+Feature: #89700 - Show layouts in the Web Info module
+=====================================================
+
+See :issue:`89700`
+
+Description
+===========
+
+It's now possible to get an overview of the configured backend and
+frontend layouts of a page in the :guilabel:`Web->Info` module. Therefore a
+new entry "Layouts" is available for the page tree overview.
+
+Besides the "Backend Layout (this page only)", the "Backend Layout (subpages of this page)"
+and the "Layout" fields, which do all just display the title of the current
+field value, an additional field "Actual backend layout" is displayed. This
+field contains the title of the backend layout, which is actually used for
+the page. If set, this is the same as "Backend Layout (this page only)".
+Otherwise, it contains the inherited layout from a parent page, which
+defined "Backend Layout (subpages of this page)".
+
+This is especially useful for editors to determine the actually used
+backend layout, which was previously often difficult. For example in
+installations with large page trees and highly developed inheritance.
+
+In case the current field value is invalid, e.g. referencing a non-existent
+backend layout, this is now also shown to the editor.
+
+Impact
+======
+
+The :guilabel:`Web->Info` module now contains a new page tree overview type, which
+contains the layout related fields as well as an additional field,
+displaying the actually used backend layout for the corresponding page.
+
+.. index:: Backend, TSConfig, ext:core

Documentation/Changelog/11.3/Feature-92358-AddGetModuleTemplateToPageLayoutController.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-92358:
+
+=================================================================
+Feature: #92358 - Add getModuleTemplate() to PageLayoutController
+=================================================================
+
+See :issue:`92358`
+
+Description
+===========
+
+The :php:`TYPO3\CMS\Backend\Controller\PageLayoutController` features
+two hooks for manipulating the "Page" module. :php:`drawHeaderHook` and
+:php:`drawFooterHook`. Those hooks already
+receive the parent object :php:`PageLayoutController`. Since the calling
+code expects the hooks to return additional content, it was previously
+not possible to change other parts of the module, for example the module header.
+
+To give developers more possibilities in manipulating the "Page" module,
+using the mentioned hooks, the parent object now contains a new getter
+method :php:`getModuleTemplate()`. It can for example be used to add an
+additional button to the modules' button bar.
+
+.. code-block:: php
+
+   public function drawHeaderHook(array $parameters, PageLayoutController $parentObject)
+   {
+      $moduleTemplate = $parentObject->getModuleTemplate();
+      $buttonBar = $moduleTemplate->getDocHeaderComponent()->getButtonBar();
+
+      $linkButton = $buttonBar
+         ->makeLinkButton()
+         ->setHref('/typo3/some/url')
+         ->setTitle('My custom button')
+         ->setClasses('custom-link-class')
+         ->setIcon($moduleTemplate->getIconFactory()->getIcon('actions-link', Icon::SIZE_SMALL));
+
+      $buttonBar->addButton($linkButton);
+   }
+
+Impact
+======
+
+When using either the :php:`drawHeaderHook` or the :php:`drawFooterHook` of the
+:php:`PageLayoutController`, the provided parent object now contains
+the :php:`getModuleTemplate()` method, which can be used to retrieve
+the corresponding :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate` instance.
+This provides more flexibility to third party code manipulating the "Page"
+module view.
+
+.. index:: Backend, PHP-API, ext:backend

Documentation/Changelog/11.3/Feature-92518-DownloadAndFilenameOptionsAddedToFileDumpController.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-92518:
+
+===========================================================================
+Feature: #92518 - Download and filename options added to FileDumpController
+===========================================================================
+
+See :issue:`92518`
+
+Description
+===========
+
+The :php:`\TYPO3\CMS\Core\Controller\FileDumpController` has been extended with
+the parameters :php:`dl` and :php:`fn`.
+
+*  :php:`dl`: Force download of the file
+*  :php:`fn`: Use an alternative filename
+
+See the following example on how to create a URI including the new parameters:
+
+.. code-block:: php
+
+   // use TYPO3\CMS\Core\Utility\GeneralUtility;
+   // use TYPO3\CMS\Core\Utility\PathUtility;
+   // use TYPO3\CMS\Core\Core\Environment;
+   $queryParameterArray = [
+      'eID' => 'dumpFile',
+      't' => 'f',
+      'f' => $resourceObject->getUid(),
+      'dl' => true,
+      'fn' => 'alternative-filename.jpg'
+   ];
+   $queryParameterArray['token'] =
+      GeneralUtility::hmac(
+         implode('|', $queryParameterArray),
+         'resourceStorageDumpFile'
+      );
+
+   $publicUrl =
+      GeneralUtility::locationHeaderUrl(
+         PathUtility::getAbsoluteWebPath(Environment::getPublicPath() . '/index.php')
+      );
+   $publicUrl .= '?' . http_build_query($queryParameterArray, '', '&', PHP_QUERY_RFC3986);
+
+This will create a URI from a :sql:`sys_file` record and trigger a download of the
+file with the alternative filename, using the :html:`Content-Disposition: attachment`
+header.
+
+To ease the use of the file dump functionality, also a new ViewHelper
+is added. See :doc:`FileViewHelper <../11.3/Feature-92518-IntroduceFileViewHelper>`
+for further information.
+
+Impact
+======
+
+The `dumpFile` eID script is now capable of the `dl` parameter, forcing
+the download of the corresponding file, as well as the `fn` parameter,
+which can be used to define an alternative file name.
+
+.. index:: FAL, ext:core

Documentation/Changelog/11.3/Feature-92518-IntroduceFileViewHelper.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-92518-1668719172:
+
+==========================================
+Feature: #92518 - Introduce FileViewHelper
+==========================================
+
+See :issue:`92518`
+
+Description
+===========
+
+With :doc:`#92518 <../11.3/Feature-92518-DownloadAndFilenameOptionsAddedToFileDumpController>`,
+the :php:`\TYPO3\CMS\Core\Controller\FileDumpController` has been extended with
+new options to force the download of a file, as well as the option to define a
+custom filename.
+
+To ease the use of the file dump functionality, especially the newly introduced
+options, a new ViewHelper :php:`TYPO3\CMS\Fluid\ViewHelpers\Link\FileViewHelper`
+is added, which allows extension authors to easily create links to both public
+and non-public files.
+
+The usage is as following:
+
+.. code-block:: html
+
+   <f:link.file file="{file}" download="true" filename="alternative-name.jpg">
+      Download file
+   </f:link.file>
+
+The above example will create a link to the given file, forcing a direct
+download, while using the alternative filename.
+
+In case the file is publicly accessible, a direct link will be used. Otherwise
+the file dump functionality comes into play.
+
+.. code-block:: html
+
+   <!-- Public file -->
+   <a href="https://example.com/fileadmin/path/to/file.jpg"
+      download="alternative-name.jpg"
+   >
+      Download file
+   </a>
+
+   <!-- Non-public file -->
+   <a href="https://example.com/index.php?eID=dumpFile&t=f&f=123&dl=1&fn=alternative-name.jpg&token=79bce812">
+      Download file
+   </a>
+
+.. note::
+
+   The :php:`file` argument accepts a
+   :php:`\TYPO3\CMS\Core\Resource\FileInterface`. So either a
+   :php:`\TYPO3\CMS\Core\Resource\File`,
+   a :php:`\TYPO3\CMS\Core\Resource\FileReference` or a
+   :php:`\TYPO3\CMS\Core\Resource\ProcessedFile` can be provided.
+
+.. note::
+
+   The :html:`filename` argument accepts an alternative filename. In case the
+   provided filename contains a file extension, this must be the same
+   as from the :html:`file` object. If file extensions is omitted, the original
+   file extension is automatically appended to the given filename.
+
+Impact
+======
+
+The new ViewHelper allows creating links to files - even non-public ones -
+in a straightforward way within Fluid templates.
+
+.. index:: FAL, Fluid, ext:fluid

Documentation/Changelog/11.3/Feature-93114-NativeSupportForLanguageShonaBantuAdded.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93114:
+
+=================================================================
+Feature: #93114 - Native support for language Shona (Bantu) added
+=================================================================
+
+See :issue:`93114`
+
+Description
+===========
+
+TYPO3 now supports Shona (Bantu language) - the language of the Shona
+people of Zimbabwe - out of the box.
+
+Shona is one of the most widely spoken Bantu languages
+(`Shona on Wikipedia <https://en.wikipedia.org/wiki/Shona_language>`__).
+
+The ISO 639-1 code for Shona is "sn", which is how TYPO3
+is accessing the language internally.
+
+
+Impact
+======
+
+It is now possible to
+
+*  Fetch translated labels from translations.typo3.org / CrowdIn
+   automatically within the TYPO3 Backend
+*  Switch the Backend Interface to Shona language
+*  Create a new language in a site configuration using Shona
+*  Create translation files with the "sn" prefix (such as `sn.locallang.xlf`)
+   to create your own labels
+
+and TYPO3 will pick Shona as a language just like any other
+supported language.
+
+.. index:: Backend, Frontend, ext:core

Documentation/Changelog/11.3/Feature-93210-PossibilityToRefreshDashboardWidgets.rst

@@ -0,0 +1,84 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93210:
+
+==========================================================
+Feature: #93210 - Possibility to refresh dashboard widgets
+==========================================================
+
+See :issue:`93210`
+
+Description
+===========
+
+For some widgets it makes sense for users to be able to refresh the widget
+without reloading the complete dashboard. Therefore, a new refresh action
+button will be available in the top right corner of widgets, which have the
+refresh option enabled.
+
+To enable the refresh action button, you have to define the
+:yaml:`refreshAvailable` option in the :yaml:`$options` part of the widget
+registration. Below is an example of a RSS widget with the refresh option enabled.
+
+.. code-block:: yaml
+
+   dashboard.widget.myOwnRSSWidget:
+     class: 'TYPO3\CMS\Dashboard\Widgets\RssWidget'
+     arguments:
+       $view: '@dashboard.views.widget'
+       $cache: '@cache.dashboard.rss'
+       $options:
+         rssFile: 'https://typo3.org/rss'
+         lifeTime: 43200
+         refreshAvailable: true
+     tags:
+       - name: dashboard.widget
+         identifier: 'myOwnRSSWidget'
+         groupNames: ‘general’
+         title: 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:widgets.myOwnRSSWidget.title'
+         description: 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:widgets.myOwnRSSWidget.description'
+         iconIdentifier: 'content-widget-rss'
+         height: 'medium'
+         width: 'medium'
+
+.. note::
+
+   In this example, the TYPO3 Core :php:`TYPO3\CMS\Dashboard\Widgets\RssWidget`
+   widget class is used. In case you have implemented own widget classes, you
+   have to add the :php:`getOptions()` method, returning :php:`$this->options`,
+   to the corresponding classes. Otherwise the refresh option won't have any
+   effect. The method will anyways be required by the :php:`WidgetInterface`
+   in TYPO3 v12.
+
+JavaScript API
+==============
+
+Besides having a refresh action button on widgets, which have the new option
+enabled, it is possible for all widgets to dispatch an event, which will cause
+the widget being refreshed. This is possible for all widgets on the dashboard
+even when the :yaml:`refreshAvailable` option is not defined, or set to `false`.
+This will give developers the option to refresh the widgets whenever they think
+it is appropriate.
+
+You therefore need to dispatch the :js:`widgetRefresh` event on the
+widget container (the :html:`div` element with the :html:`dashboard-item` class).
+You can identify the container by the data attribute :html:`widget-hash`, which
+is a unique hash for every widget, even if you have more widgets of the same
+type on your dashboard.
+
+A small example below:
+
+.. code-block:: javascript
+
+   document
+     .querySelector('[data-widget-hash="{your-unique-widget-hash}"]')
+     .dispatchEvent(new Event('widgetRefresh', {bubbles: true}));
+
+
+Impact
+======
+
+Widgets with the option :yaml:`refreshAvailable` set to `true`, will now
+feature a refresh action button in the top right corner of the widget.
+
+.. index:: Backend, ext:beuser

Documentation/Changelog/11.3/Feature-93631-SupportForPHP80.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93631:
+
+=====================================
+Feature: #93631 - Support for PHP 8.0
+=====================================
+
+See :issue:`93631`
+
+Description
+===========
+
+The TYPO3 Core is now compatible with PHP 8.0, which is officially supported
+with security updates until 26th November 2023.
+
+
+Impact
+======
+
+TYPO3 can now be installed on systems running with PHP 8.0.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.3/Feature-93668-PossibilityToConfigureSymfonyMailer.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93668:
+
+=========================================================
+Feature: #93668 - Possibility to configure Symfony mailer
+=========================================================
+
+See :issue:`93668`
+
+Description
+===========
+
+The install tool has now the possibility to configure the Symfony mailer with
+DSN. Symfony provides different mail transports like SMTP, sendmail or many 3rd
+party email providers like AWS SES, Gmail, MailChimp, Mailgun and more. You can
+find all supported providers in the
+`Symfony documentation <https://symfony.com/doc/current/mailer.html>`__.
+
+In the module :guilabel:`Admin tools > Settings` go to the card
+:guilabel:`Configure Installation-Wide Options` and open the dialog.
+Select :guilabel:`Mail` and set :php:`[MAIL][transport]` to :php:`dsn`.
+
+Additionally set :php:`[MAIL][dsn]` like described in the Symfony documentation.
+
+Examples:
+
+*  :php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['dsn'] = "smtp://user:pass@smtp.example.com:25"`
+*  :php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['dsn'] = "sendmail://default"`
+
+
+Impact
+======
+
+If :php:`[MAIL][transport]` is set to :php:`dsn` all mails are sent with your
+configured DSN.
+
+.. index:: LocalConfiguration, ext:core

Documentation/Changelog/11.3/Feature-93825-RateLimitingForFailedLogins.rst

@@ -0,0 +1,109 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93825:
+
+=================================================
+Feature: #93825 - Rate limiting for failed logins
+=================================================
+
+See :issue:`93825`
+
+Description
+===========
+
+The TYPO3 backend and frontend login now uses a rate limiter by default,
+which prevents further authentication attempts for an IP address,
+if a configurable amount of login attempts is exceeded in a given time.
+
+The hardcoded wait time of 5 seconds after a failed login has been removed,
+since it offers no real protection against brute force attacks and may
+result in unwanted side effects.
+
+.. important::
+
+   Rate limiters do not provide a useful protection against DoS attacks.
+   They should be used to limit the amount of requests to certain routes
+   (for example login or form submission) of an application.
+
+Impact
+======
+
+TYPO3 ships with a rate limiter for backend and frontend authentication.
+It implements the "Sliding Window Rate Limiter" allowing to define a
+maximum amount of login attempts for a given range of time before further login
+attempts will be denied for the remote IP address.
+
+A configurable list of IP addresses allows to exclude certain IP addresses or IP
+address blocks from being rate limited.
+
+The rate limiter utilizes the TYPO3 caching framework as storage for
+rate limiter states. The rate limiter takes care of garbage collection
+for affected cache tables on every login request.
+
+Note, that clearing the system cache will purge all limiter states.
+
+Backend login
+-------------
+
+The rate limiter :php:`Symfony\Component\RateLimiter\LoginRateLimiter`
+for the TYPO3 backend login is enabled by
+default and configured with the following default values:
+
+*  Maximum 5 login attempts for a timeframe of 15 minutes
+*  No IP address excluded
+
+When the maximum amount of login attempts has exceeded, a
+:php:`\TYPO3\CMS\Core\RateLimiter\RequestRateLimitedException`
+exception is thrown. The exception implements
+:php:`\TYPO3\CMS\Core\Error\Http\AbstractClientErrorException`
+resulting in a user readable error message together with a 403 HTTP status code.
+
+Configuration
+~~~~~~~~~~~~~
+
+The rate limiter for the TYPO3 backend can be configured using the
+Settings module or the Install tool. The following new configuration
+values are available:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['BE']['loginRateLimit'] = 5;
+   $GLOBALS['TYPO3_CONF_VARS']['BE']['loginRateLimitInterval'] = '15 minutes';
+   $GLOBALS['TYPO3_CONF_VARS']['BE']['loginRateLimitIpExcludeList'] = '';
+
+Setting `[BE][loginRateLimit] = 0` will disable rate limiting. The same
+applies, if `[BE][loginRateLimitIpExcludeList] = '*'` is configured.
+
+The provided defaults for `[BE][loginRateLimitInterval]` can be customized
+in `AdditionalConfiguration.php` by configuring a date/time string following
+PHP relative formats.
+
+Frontend login
+--------------
+
+The rate limiter for the TYPO3 frontend login is enabled by
+default and configured with the following default values:
+
+*  Maximum 10 login attempts for a timeframe of 15 minutes
+*  No IP address exclude list
+
+When the maximum amount of login attempts is exceeded, a
+:php:`\TYPO3\CMS\Core\RateLimiter\RequestRateLimitedException`
+exception is thrown. The exception implements
+:php:`\TYPO3\CMS\Core\Error\Http\AbstractClientErrorException`
+resulting in a user readable error message together with a 403 HTTP status code.
+
+Configuration
+~~~~~~~~~~~~~
+
+Configuration is similar to the rate limiter for the backend login.
+
+The following new configuration values are available:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['FE']['loginRateLimit'] = 10;
+   $GLOBALS['TYPO3_CONF_VARS']['FE']['loginRateLimitInterval'] = '15 minutes';
+   $GLOBALS['TYPO3_CONF_VARS']['FE']['loginRateLimitIpExcludeList'] = '';
+
+.. index:: Backend, Frontend, ext:core

Documentation/Changelog/11.3/Feature-93835-AddErrorForPropertyFunctionForAbstractValidator.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93835:
+
+====================================================================
+Feature: #93835 - AddErrorForProperty function for AbstractValidator
+====================================================================
+
+See :issue:`93835`
+
+Description
+===========
+
+When validating Extbase models, it could be helpful to assign the encountered
+error to a certain property. This is already possible by using
+:php:`$this->result->forProperty($propertyPath)->addError($error);`. This
+method however is cumbersome and requires knowledge about the result object.
+To ease the pain for developers, a convenience method :php:`addErrorForProperty`
+is now available.
+
+Use it like this in a validator class:
+
+.. code-block:: php
+
+   public function isValid(): void
+   {
+      // validation
+      $this->addErrorForProperty(
+         'object.property.name',
+         $this->translateErrorMessage(
+             'validator.errormessage',
+             'my-ext'
+         ),
+         // tstamp_of_now_as_errorcode
+         123456789
+      );
+   }
+
+
+Impact
+======
+
+The new method enables developers adding custom error messages to validation
+results of properties in a convenient way.
+
+.. index:: ext:extbase

Documentation/Changelog/11.3/Feature-93921-SharingBackendLinks.rst

@@ -0,0 +1,70 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-93921:
+
+=======================================
+Feature: #93921 - Sharing backend links
+=======================================
+
+See :issue:`93921`
+
+Description
+===========
+
+With the introduction of backend URL rewrites in :issue:`93048` and
+the backend module web component router in :issue:`93988`, it's finally
+possible to share backend URLs between each other.
+
+To ease the use of this, the
+:php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton` is
+extended for
+a new option :php:`$copyUrlToClipboard`, which defaults to :php:`true`.
+This option extends the shortcut button in the module header of a backend
+module. Therefore, the button's icon is also changed. On click, a dropdown
+opens, including the additional possibility to copy the current backend URL
+directly to the operating system's clipboard, next to the already existing
+bookmark option.
+
+For the dropdown button, a new icon :php:`share-alt` is registered, which can
+be used through the :php:`IconFactory`.
+
+In case you are using the shortcut API in your custom backend module and
+don't want to use this additional option, you can disabled it by setting
+:php:`$shortcutButton->setCopyUrlToClipboard(false)`. If disabled, the
+shortcut button is rendered with the same behaviour as before.
+
+.. note::
+
+   Since both ViewHelpers, :html:`<be:moduleLayout.button.shortcutButton>`
+   as well as :html:`<f:be.buttons.shortcut>` are deprecated, the new option
+   is not available for those. In case you are currently using one of those
+   ViewHelpers, but still want to profit from the new option in your custom
+   backend modules, you have to create the shortcut button in the corresponding
+   controller using the shortcut API. This will anyways be required in TYPO3 v12.
+
+Besides the new option for the :php:`ShortcutButton`, a new constant
+:php:`SHAREABLE_URL` is available in the :php:`UriBuilder`. It can be
+used as value for the :php:`$referenceType` parameter, which is available
+for most of the "buildUri" methods, for example :php:`UriBuilder->buildUriFromRoute()`.
+
+.. code-block:: php
+
+   $uri = $uriBuilder->buildUriFromRoute($routeName, $arguments, UriBuilder::SHAREABLE_URL);
+
+The above example will return an absolute URL without the automatically
+created token parameter.
+
+Impact
+======
+
+If the new option is enabled, instead of the shortcut button, a dropdown
+menu is displayed in the module header, including two options:
+
+*  Option to add a shortcut to the current page
+*  Option to copy the URL of the current page to the operating system's clipboard
+
+When setting :php:`UriBuilder::SHAREABLE_URL` as :php:`$referenceType` in
+one of the "buildUri" methods supporting this parameter, a shareable URL
+will be returned.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.3/Feature-94081-TCAReadOnlyForT3editor.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94081:
+
+===========================================
+Feature: #94081 - TCA readOnly for t3editor
+===========================================
+
+See :issue:`94081`
+
+Description
+===========
+
+The TCA :php:`'type' => 'text'` (textarea) based FormEngine
+render type :php:`'renderType' => 't3editor'` now supports the
+:php:`'readOnly' => true` option. If set, syntax highlighting
+is applied as usual, but the corresponding text can not be edited.
+
+Example:
+
+.. code-block:: php
+
+    't3editor_2' => [
+        'label' => 't3editor_2',
+        'description' => 'readOnly=true',
+        'config' => [
+            'type' => 'text',
+            'renderType' => 't3editor',
+            'format' => 'html',
+            'readOnly' => true,
+        ],
+    ],
+
+
+Impact
+======
+
+This minor feature allows rendering highlighted code without the edit option.
+
+.. index:: Backend, TCA, ext:backend

Documentation/Changelog/11.3/Feature-94143-DisplayCreationDateOfRedirects.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94143:
+
+====================================================
+Feature: #94143 - Display creation date of redirects
+====================================================
+
+See :issue:`94143`
+
+Description
+===========
+
+The EXT:redirects system extension provides a straightforward way of managing
+redirects within a TYPO3 installation. The corresponding backend module
+can be used to filter, create and analyse those redirects.
+
+Measuring the redirects performance is possible via the "Redirects hit count"
+feature, which - if enabled - displays the amount of hits for each redirect
+in the listing. More detailed information, for example the last hit, are
+available in the records' "Statistics" tab.
+
+This tab is now extended to also display the creation date of the redirect.
+This is especially useful to set the amount of hits in relation to the period
+of the redirect existence.
+
+.. note::
+
+   The creation date will only be shown if the "Redirects hit count"
+   feature is enabled, see:
+   :doc:`#83677 <../9.1/Feature-83677-GloballyDisableenableRedirectHitStatistics>`.
+
+Impact
+======
+
+The creation date of a redirect is now shown in the :guilabel:`Statistics` tab
+of the record's editing mask.
+
+.. index:: Backend, TCA, ext:redirects

Documentation/Changelog/11.3/Feature-94206-AddExcludePagesRecursiveOptionToSitemapGeneration.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94206:
+
+============================================================================
+Feature: #94206 - Add excludePagesRecursive option to XML sitemap generation
+============================================================================
+
+See :issue:`94206`
+
+Description
+===========
+
+With this option you can exclude pages recursively in the XML sitemap:
+
+.. code-block:: typoscript
+
+   plugin.tx_seo {
+       config {
+           xmlSitemap {
+               sitemaps {
+                   pages {
+                       config {
+                           # comma-separated list of page UIDs which should be excluded recursively
+                           excludePagesRecursive = 2,3
+                       }
+                   }
+               }
+           }
+       }
+   }
+
+Impact
+======
+
+The new option enables integrators to easily exclude pages recursively in the XML sitemap
+
+.. index:: ext:seo

Documentation/Changelog/11.3/Feature-94210-InformationAboutInheritedBackendLayout.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94210:
+
+============================================================
+Feature: #94210 - Information about inherited backend layout
+============================================================
+
+See :issue:`94210`
+
+Description
+===========
+
+When editing a page record, the field :php:`pages.backend_layout_next_level` can
+be used to apply a backend layout to all subpages.
+
+This can make it difficult for the editor to determine the currently applied
+backend layout. To help the editor in case of an inherited layout a message
+is now displayed below the :php:`pages.backend_layout` field label via a
+new FormEngine field information.
+
+
+.. index:: Backend, TCA, ext:backend

Documentation/Changelog/11.3/Feature-94218-SelectableColumnsPerTableInRecordList.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94218:
+
+=============================================================
+Feature: #94218 - Selectable columns per table in record list
+=============================================================
+
+See :issue:`94218`
+
+Description
+===========
+
+The Record List (commonly known from the list module) previously allowed to
+select specific columns for a table at the bottom of the module via the
+so-called "field selector".
+
+This approach had several drawbacks:
+
+*  UX-wise the selection was not directly visible for users, as the component was
+   separated at the module page at the bottom
+*  Only possible to select fields explicitly in the "single-table view"
+
+Instead, this feature - the column selector - is now available at all times in
+the title row of each table, regardless of the single-table-view, making it
+much more appealing and prominent to use for editors.
+
+This feature is active by default, and can be disabled via UserTSconfig per
+table or completely for a specific user or usergroup.
+
+Use cases / examples via UserTSconfig:
+
+.. code-block:: typoscript
+
+   # disable the column selector for tt_content
+   mod.web_list.table.tt_content.displayColumnSelector = 0
+
+   # disable the column selector completely
+   mod.web_list.displayColumnSelector = 0
+
+   # Disable the column selector everywhere except for a specific table
+   mod.web_list.displayColumnSelector = 0
+   mod.web_list.table.sys_category.displayColumnSelector = 1
+
+
+Impact
+======
+
+The field selector at the bottom is not available anymore,
+it has been replaced by a dropdown selector at the top of each table.
+
+.. index:: Backend, TSConfig, ext:recordlist

Documentation/Changelog/11.3/Feature-94345-AutoDetectEventTypes.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94345:
+
+=========================================
+Feature: #94345 - Auto-detect event types
+=========================================
+
+See :issue:`94345`
+
+Description
+===========
+
+If no "event" tag is specified on an event listener in Services.yaml, the
+event is automatically derived from the event method itself using reflection.
+
+
+Impact
+======
+
+In the vast majority of cases, the "event" tag on an event listener in Services.yaml
+is no longer necessary.
+
+Given this example event listener implementation:
+
+.. code-block:: php
+
+   final class CategoryPermissionsAspect
+   {
+       public function addUserPermissionsToCategoryTreeData(ModifyTreeDataEvent $event): void
+       {
+          // ...
+       }
+   }
+
+With this registration:
+
+.. code-block:: yaml
+
+   TYPO3\CMS\Backend\Security\CategoryPermissionsAspect:
+       tags:
+         - name: event.listener
+           identifier: 'backend-user-permissions'
+           method: 'addUserPermissionsToCategoryTreeData'
+           event: TYPO3\CMS\Core\Tree\Event\ModifyTreeDataEvent
+
+
+The :yaml:`event:` tag can be omitted, since it's automatically read from
+the method signature :php:`addUserPermissionsToCategoryTreeData(ModifyTreeDataEvent $event)`
+of the listener implementation:
+
+.. code-block:: yaml
+
+   TYPO3\CMS\Backend\Security\CategoryPermissionsAspect:
+       tags:
+         - name: event.listener
+           identifier: 'backend-user-permissions'
+           method: 'addUserPermissionsToCategoryTreeData'
+
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.3/Feature-94374-CreateNewFilemountViaFoldersContextMenu.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94374:
+
+=====================================================================
+Feature: #94374 - Create new file mount via the folder's context menu
+=====================================================================
+
+See :issue:`94374`
+
+Description
+===========
+
+The :php:`sys_filemounts` records are an important feature, which
+allows administrators to restrict their users to specific folders
+in a file storage.
+
+The workflow however was always to first create the folder in the
+"Filelist" module and afterwards switch to the list module to create
+a new :php:`sys_filemounts` record for this folder. This furthermore
+always required the administrator to select both, the storage and
+the previously created folder, in the new record.
+
+To ease the use for administrators, the context menu of folders is
+extended with a new option "New Filemount". Using this option opens
+the FormEngine with a new :php:`sys_filemounts` record, having the
+correct storage and folder prefilled.
+
+Impact
+======
+
+It is now possible to create new file mounts directly in the Filelist
+module, using the new "New Filemount" option in the folder's context
+menu. This option also prefills the new record with the correct storage
+and folder values.
+
+.. index:: Backend, ext:filelist

Documentation/Changelog/11.3/Feature-94390-DropdownForRecordListAndFileListInFavorOfExtendedView.rst

@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94390:
+
+==================================================================================
+Feature: #94390 - Dropdown for record list and file list in favor of Extended View
+==================================================================================
+
+See :issue:`94390`
+
+Description
+===========
+
+The option "Extended View", which was used in the TYPO3 Backend
+modules :guilabel:`Web => List` and :guilabel:`File => Filelist` to show
+additional icons, has been removed in favor of a dropdown with all items which is
+always available.
+
+
+Impact
+======
+
+This change is added as a user experience improvement over an additional
+configuration option to give editors a unified experience, as
+the additional menu with alternative items is common in other
+web applications.
+
+The TSconfig options `options.file_list.enableDisplayBigControlPanel`
+and `mod.web_list.enableDisplayBigControlPanel` have no effect anymore,
+because the checkboxes are removed.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.3/Feature-94411-RecordlistDownloadSettings.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94411:
+
+===============================================
+Feature: #94411 - Record list download settings
+===============================================
+
+See :issue:`94411`
+
+Description
+===========
+
+In :issue:`94366`, the record download functionality in the List
+module was improved. Since then, the download could be triggered via a
+button in each table's header and no longer just in the single table view.
+
+The download however did still not allow to adjust any settings, such as
+the definition of a custom filename. Furthermore, only CSV was available
+as possible download format.
+
+Therefore, and to further improve the already existing record download
+functionality, the download button in the table's header does not longer
+trigger the download directly, but opens a modal with various adjustable
+download settings such as:
+
+*  Selection of columns to download: All columns or selected columns
+*  Selection of the record values format: Either raw database values
+   or processed (resolved) values
+*  Definition of a custom filename
+*  Selection of the download format (for example CSV)
+
+Also download format specific options are available, for example selection of
+the delimiter for CSV downloads.
+
+In case your installation already defines related TSconfig options
+(for example :typoscript:`mod.web_list.csvDelimiter`), they will be added
+as default value to the configuration modal.
+
+Besides introducing those settings, also JSON is now available as
+an alternative download format, including a format specific option,
+which allows to define additional meta information to be included in
+the download.
+
+Impact
+======
+
+It's now possible to configure the download of records in the
+record list. Furthermore, the new format option :php:`json` is available.
+
+.. index:: Backend, ext:recordlist

Documentation/Changelog/11.3/Feature-94428-ExtbaseRequestImplementsServerRequestInterface.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94428:
+
+===================================================================
+Feature: #94428 - Extbase Request implements ServerRequestInterface
+===================================================================
+
+See :issue:`94428`
+
+Description
+===========
+
+The Extbase :php:`TYPO3\CMS\Extbase\Mvc\Request` now implements
+the PSR-7 :php:`ServerRequestInterface` and thus holds all request
+related information of the main Core request in addition to the
+plugin namespace specific Extbase arguments.
+
+
+Impact
+======
+
+This allows getting information of the main request especially within
+Extbase controllers from :php:`$this->request`.
+
+Developers of Fluid ViewHelpers can now retrieve the main PSR-7 request
+in many contexts from :php:`$renderingContext->getRequest()`, in addition
+to the Extbase specific information specified by
+:php:`TYPO3\CMS\Extbase\Mvc\Request\RequestInterface`.
+
+Note that with future patches, the request assigned to ViewHelper
+:php:`RenderingContext` may NOT implement Extbase
+:php:`TYPO3\CMS\Extbase\Mvc\Request\RequestInterface` anymore, and
+only PSR-7 :php:`ServerRequestInterface`. This will be the case when the
+ViewHelper is not called from within an Extbase plugin, but when Fluid
+is started as "standalone view" in non-extbase based plugins: Often in
+backend scenarios like toolbars, doc headers, non-extbase modules, etc.
+Extensions should thus test for instance of Extbase :php:`RequestInterface`
+if they don't know the context and rely on Extbase specific request data.
+
+
+.. index:: PHP-API, ext:extbase

Documentation/Changelog/11.3/Feature-94447-NativeSupportForLanguageWelshAdded.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94447:
+
+=========================================================
+Feature: #94447 - Native support for language Welsh added
+=========================================================
+
+See :issue:`94447`
+
+Description
+===========
+
+TYPO3 now supports Welsh (historically known as "Cymbric"). Welsh is part
+of the Celtic language family - is the official language in Wales, which is
+part of the United Kingdom.
+
+The ISO 639-1 code for Welsh is "cy", which is how TYPO3
+is accessing the language internally.
+
+
+Impact
+======
+
+It is now possible to
+
+*  Fetch translated labels from translations.typo3.org / CrowdIn automatically
+   within the TYPO3 Backend
+*  Switch the backend interface to Welsh language
+*  Create a new language in a site configuration using Welsh
+*  Create translation files with the "cy" prefix (such as `cy.locallang.xlf`)
+   to create your own labels
+
+and TYPO3 will pick Welsh as a language just like any other supported language.
+
+.. index:: Backend, Frontend, ext:core

Documentation/Changelog/11.3/Feature-94452-ImprovedMulti-SelectionInFileSelection.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94452:
+
+============================================================
+Feature: #94452 - Improved multi-selection in file selection
+============================================================
+
+See :issue:`94452`
+
+Description
+===========
+
+The file selector, which is used in TYPO3 Backend, to choose one
+or multiple files to be connected via :sql:`sys_file_reference` in the
+FormEngine, has been improved to have a better visual option
+when selecting multiple records.
+
+Previously, there was a checkbox button at the end of each file row. The
+checkbox is now re-ordered and moved to the beginning
+of each row and is now based on our TYPO3 Icon Set.
+
+In addition, the view is more compact and when selecting multiple
+items there is an option to select all items, no items or to toggle the
+selection. The :guilabel:`Import selection` button now has a visual text next to
+the icon, making it clearer what this button does.
+
+
+Impact
+======
+
+Selection of files is now quicker to grasp for editors working
+with files.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/11.3/Feature-94474-ImprovedShowColumnsSelectionInRecordList.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94474:
+
+================================================================
+Feature: #94474 - Improved show columns selection in record list
+================================================================
+
+See :issue:`94474`
+
+Description
+===========
+
+Since :issue:`94218`, the column selector in the record list,
+formerly known as "field selector", is available for each
+individual record type in its table header. When accessing
+the selector, a dropdown opened, displaying all available
+columns.
+
+This was already a huge improvement, as the selection was
+now directly bound to the corresponding table and was
+always available, not only in the "single-table view".
+
+However, there were still some drawbacks, especially the fact
+that the dropdown solution could lead to confusion in case a
+record contains a couple of columns with long labels. Therefore,
+the column selection has been improved and is now not longer
+opened in a dropdown, but lives in a clear and large enough modal.
+
+In the new modal, besides the columns to select, there are three
+new options available:
+
+*  Option to select all columns
+*  Option to unselect all columns
+*  Option to toggle (invert) the current selection
+
+Those options are also fixed at the top, so they are always
+visible, even for records with a lot of columns, for example `pages`.
+
+Management fields, such as `uid` or `cr_date` are now displayed
+with human-readable labels, making them more useful for editors.
+Especially because those labels are not only used in the selector,
+but are now also displayed in the record list table header.
+
+Furthermore, the columns are now sorted lexically, while always
+enabled columns, such as the record title, are always at the top
+and all columns, not having a label, are added at the end of the list.
+
+The checkboxes are improved in their size and appearance. Instead of
+the usual "check" icon, an "eye" icon is used, making the intention
+clear.
+
+Impact
+======
+
+The column selector of each table in the record list now opens
+a modal with improved selection functionality and an overall
+improved UX.
+
+.. index:: Backend, ext:recordlist

Documentation/Changelog/11.3/Feature-94524-EditMetadataForAFileViaTheContextMenu.rst

@@ -0,0 +1,25 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-94524:
+
+===============================================================
+Feature: #94524 - Edit metadata for a file via the context menu
+===============================================================
+
+See :issue:`94524`
+
+Description
+===========
+
+Editing metadata of files is an important task for editors.
+To ease the use, the context menu for files has been extended
+by a new option :guilabel:`Edit metadata of this file`, which can be
+used to direly jump into the corresponding editing mask.
+
+Impact
+======
+
+It is now possible to edit a file's metadata directly via the
+context menu.
+
+.. index:: Backend, ext:filelist

Documentation/Changelog/11.3/Important-91496-ChangesToPasswordResetFunctionality.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _important-91496:
+
+===========================================================
+Important: #91496 - Changes to password reset functionality
+===========================================================
+
+See :issue:`91496`
+
+Description
+===========
+
+For various reasons, administrators may disable the password reset functionality,
+introduced in :issue:`89513`, by setting
+:php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['passwordReset']= false`.
+If disabled, TYPO3 Backend users are not able to initiate the
+password reset process anymore.
+
+This however previously also disabled the password reset cli command as well as
+the reset password action in the backend user module. Since it is a valid
+use case for administrators to disallow a password reset initiated by users on
+the login screen, they might still need the possibility to do so, on their own.
+
+Therefore, some things changed in the password reset implementation:
+
+*  :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['passwordReset']` now only
+   affects the password reset functionality on the login screen
+*  :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['passwordResetForAdmins']` is
+   unchanged and affects all places
+*  Initiating the password reset on CLI is now always enabled, while still
+   taking the `passwordResetForAdmins` option into account
+*  Initiating the password reset in the backend can now be disabled separately
+   with a new user TSconfig option :typoscript:`options.passwordReset`
+
+For compatibility reasons, the new user TSconfig option defaults to :php:`true`.
+To completely disable the password reset in the backend for all users, you can
+set the user TSconfig globally in your :php:`ext_localconf.php`:
+
+.. code-block:: php
+
+   // use \TYPO3\CMS\Core\Utility\ExtensionManagementUtility;
+   ExtensionManagementUtility::addUserTSConfig(
+      'options.passwordReset = 0'
+   );
+
+If  required, this can of course still be overwritten on a per user basis
+in the corresponding :guilabel:`TSconfig` field.
+
+.. index:: Backend, CLI, TSConfig, ext:backend

Documentation/Changelog/11.3/Important-94312-RemovedBEloginSecurityLevelAndFEloginSecurityLevelOptions.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94312:
+
+===================================================================================
+Important: #94312 - Removed BE/loginSecurityLevel and FE/loginSecurityLevel options
+===================================================================================
+
+See :issue:`94312`
+
+Description
+===========
+
+The `FE/loginSecurityLevel` and `BE/loginSecurityLevel` options were used to
+define the security level of the backend and frontend login. Since dropping
+the two possibilities `challenged` and `superchallenged` in v7, `rsa` and
+`normal` were the only two valid values left.
+
+The `rsa` value however also became more or less obsolete, after dropping
+`EXT:rsaauth` from Core in :issue:`87470`. Setting `rsa` therefore only had
+effect in case the standalone `friendsoftypo3/rsaauth` extension was installed.
+
+Finally, with :issue:`94279` also the support for the standalone
+`friendsoftypo3/rsaauth` was abandoned, making the `loginSecurityLevel`
+option superfluous, as `normal` was left as the only valid option.
+
+Therefore, both options `FE/loginSecurityLevel` and `BE/loginSecurityLevel`
+have been removed. As a result and to follow our backwards-compatibility promise,
+all authentication services will still receive the `$passwordTransmissionStrategy`
+argument in their :php:`processLoginData()` method, which however will now
+always be `normal`.
+
+Impact
+======
+
+The options have been removed from the TYPO3's default configuration.
+When those options have been set in your :php:`LocalConfiguration.php`
+or :php:`AdditionalConfiguration.php` files, they are automatically
+removed when accessing the Install Tool or System Maintenance area.
+
+.. index:: LocalConfiguration, ext:core

Documentation/Changelog/11.3/Important-94315-UseProperPSR-3LoggingMessagesAndContext.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _important-94315:
+
+=================================================================
+Important: #94315 - Use proper PSR-3 logging messages and context
+=================================================================
+
+See :issue:`94315`
+
+Description
+===========
+
+The v11 Core is looking into proper PSR-3 Logging implementation again. When
+analyzing the current situation, we realized many Core logging calls were
+using messages that violated the PSR-3
+`placeholder specification <https://www.php-fig.org/psr/psr-3/>`__.
+
+The v11 Core fixed all places, but it's likely extensions have this issue,
+too. Extension developers should have a look at their logger calls and adapt
+them if necessary.
+
+Typical call before:
+
+.. code-block:: php
+
+   $this->logger->alert(
+      'Password reset requested for email "' .
+      $emailAddress . '" . but was requested too many times.'
+   );
+
+Correct call:
+
+.. code-block:: php
+
+   $this->logger->alert(
+      'Password reset requested for email {email} but was requested too many times.',
+      ['email' => $emailAddress]
+   );
+
+First argument is :php:`message`, second (optional) argument is :php:`context`.
+A message can use :php:`{placeholders}`.
+
+All Core provided log writers will substitute placeholders in the message
+with data from the context array, if a context array key with same name exists.
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/11.3/Index.rst

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