TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/10.4/Breaking-90660-RegistrationOfWidgetsChanged.rst

@@ -0,0 +1,157 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-90660:
+
+============================================================
+Breaking: #90660 - Registration of dashboard widgets changed
+============================================================
+
+See :issue:`90660`
+
+Description
+===========
+
+As the registration of dashboard widgets changed to allow creation of widgets
+through configuration, it is necessary to change your registration of widgets you
+registered yourself in version 10.3. The abstracts used to kick start your
+widgets were removed and the widgets shipped with EXT:dashboard were refactored.
+
+
+Impact
+======
+
+As the abstracts previously used to kick-start a widget are removed, you need
+to change to the new way of registering widgets. The dashboard
+module will break if you do not update your registration.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions that registered an own widget with TYPO3 v10.3, will be
+affected and need to update the widget registration. If you only used the widgets
+shipped with core, you don't have to do anything.
+
+
+Migration
+=========
+
+
+Migration of widgets based on default widget types
+--------------------------------------------------
+
+This section demonstrates how to migrate widgets that are based on one of
+the existing widget types shipped by core. If your widgets are extending
+one of the following classes, you can use this section to migrate your registration
+to the new syntax.
+
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractBarChartWidget`
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractChartWidget`
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractCtaButtonWidget`
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractDoughnutChartWidget`
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractListWidget`
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractNumberWithIconWidget`
+- :php:`\TYPO3\CMS\Dashboard\Widgets\AbstractRssWidget`
+
+First of all you need to update your registration in the :file:`Services.yaml` file.
+Here comes an example of a registration of RSS widget in the old version.
+
+**Before**
+
+.. code-block:: yaml
+
+   Vendor\Package\Widgets\MyOwnRSSWidget:
+     arguments: [‘myOwnRSSWidget’]
+     tags:
+       - name: dashboard.widget
+         identifier: myOwnRSSWidget
+         widgetGroups: ‘general’
+
+
+As you can now use the predefined widgets and only have to register your own
+implementation with your own configuration, you have to alter this registration
+a little bit.
+
+**Now**
+
+.. 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'
+         # 12 hours cache
+         lifeTime: 43200
+     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'
+
+
+It starts with the name of the service. Best practise is to use a dot-styled
+name as there will be no class with that name. You can have multiple services
+using the same class.
+
+On the second line, we define which widget to use. In this case we choose the
+RssWidget from the dashboard core extension. In the documentation, we explain
+all the arguments like :php:`$view` and :php:`$cache`. For the migration you need
+the :php:`$options` argument.
+
+As you can see we specify the RSS file and the cache lifetime for this feed.
+In the old situation you had to set these values in the class.
+Now you can just put those values in the registration.
+
+The second part that changed a little bit, is that you need to set the title,
+description, icon, height and width in the tags section of the registration.
+You can still use translatable strings like
+``LLL:EXT:extension/Resources/Private/Language/locallang.xlf:widgets.myOwnRSSWidget.title``.
+Important to remember is that the :yaml:`widgetGroups` property changed to :yaml:`groupNames`
+to stay consistent with other service registrations.
+
+Please note that valid values for height and width are now: :yaml:`small`, :yaml:`medium`,
+and :yaml:`large`.
+
+In the following table you can see which WidgetType to use now based on the
+abstract you used previously.
+
++--------------------------------------+----------------------------------------------------------------------+
+| Previously used abstract             | Widget class to use for your registration                            |
++======================================+======================================================================+
+| :php:`AbstractBarChartWidget`        | :php:`TYPO3\CMS\Dashboard\Widgets\BarChartWidget`                    |
++--------------------------------------+----------------------------------------------------------------------+
+| :php:`AbstractChartWidget`           | This was only used as an abstract of the other chart widgets and is  |
+|                                      | not used anymore. If you want another graph type, you have to create |
+|                                      | your own widget.                                                     |
++--------------------------------------+----------------------------------------------------------------------+
+| :php:`AbstractCtaButtonWidget`       | :php:`TYPO3\CMS\Dashboard\Widgets\CtaWidget`                         |
++--------------------------------------+----------------------------------------------------------------------+
+| :php:`AbstractDoughnutChartWidget`   | :php:`TYPO3\CMS\Dashboard\Widgets\DoughnutChartWidget`               |
++--------------------------------------+----------------------------------------------------------------------+
+| :php:`AbstractListWidget`            | :php:`TYPO3\CMS\Dashboard\Widgets\ListWidget`                        |
++--------------------------------------+----------------------------------------------------------------------+
+| :php:`AbstractNumberWithIconWidget`  | :php:`TYPO3\CMS\Dashboard\Widgets\NumberWithIconWidget`              |
++--------------------------------------+----------------------------------------------------------------------+
+| :php:`AbstractRssWidget`             | :php:`TYPO3\CMS\Dashboard\Widgets\RssWidget`                         |
++--------------------------------------+----------------------------------------------------------------------+
+
+
+You can check the documentation of EXT:dashboard to see the exact options for every type of widget.
+
+
+Migration of widgets based on own widget type
+---------------------------------------------
+
+When you created your complete own widget type, the main thing to check is you
+use the Dependency Injection options you have now. Please refer to the documentation
+of EXT:dashboard to see how to create your own widget type and what options you
+have.
+
+.. index:: Backend, ext:dashboard, NotScanned

Documentation/Changelog/10.4/Breaking-91066-MovedInterfacesOfDashboard.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91066:
+
+===============================================
+Breaking: #91066 - Move interfaces of Dashboard
+===============================================
+
+See :issue:`91066`
+
+Description
+===========
+
+The interfaces of the dashboard have been moved out of the
+interfaces folder to be consistent with the overall TYPO3 structure.
+
+
+Impact
+======
+
+New widget types that have implemented one or more of the interfaces of EXT:dashboard.
+If the namespace of those interfaces is not changed, you will get errors saying
+that the interfaces are not found anymore.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions that created own widget types and implement one of the
+interfaces of EXT:dashboard should update their paths. The accepted interfaces
+are:
+
+- :php:`AdditionalCssInterface`
+- :php:`AdditionalJavascriptInterface`
+- :php:`ButtonProviderInterface`
+- :php:`ChartDataProviderInterface`
+- :php:`EventDataProviderInterface`
+- :php:`ListDataProviderInterface`
+- :php:`NumberWithIconDataProviderInterface`
+- :php:`RequireJsModuleInterface`
+- :php:`WidgetConfigurationInterface`
+- :php:`WidgetInterface`
+
+
+Migration
+=========
+
+The interfaces listed above have been moved from :php:`TYPO3\CMS\Dashboard\Widgets\Interfaces`
+to :php:`TYPO3\CMS\Dashboard\Widgets`. You need to adapt the namespaces of those
+interfaces in your own widgets.
+
+.. index:: Backend, ext:dashboard, FullyScanned

Documentation/Changelog/10.4/Breaking-91066-RemovedButtonUtility.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91066-1668719172:
+
+========================================
+Breaking: #91066 - Removed ButtonUtility
+========================================
+
+See :issue:`91066`
+
+Description
+===========
+
+The :php:`ButtonUtility` was superfluous and therefor removed.
+
+
+Impact
+======
+
+You need to remove the usage of the :php:`ButtonUtility` class, otherwise you
+will get fatal errors of missing classes.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions that created own widget types with the option to add
+a button using the :php:`ButtonUtility::generateButtonConfig()` method are
+affected.
+
+
+Migration
+=========
+
+First of all you need to change one line in your Widget class. When assigning
+your button parameter to your Fluid Template, you most probably have the following
+line:
+
+.. code-block:: php
+
+   'button' => ButtonUtility::generateButtonConfig($this->buttonProvider),
+
+You have to change that into:
+
+.. code-block:: php
+
+   'button' => $this->buttonProvider,
+
+Because you change the variable passed to your template, you also need to do a
+small change in your template.
+
+In your template in the footer section, you will find a line like this:
+
+.. code-block:: html
+
+   <a href="{button.link}" target="{button.target}" class="widget-cta">{f:translate(id: button.text, default: button.text)}</a>
+
+You need to change the text property to the title property. So the line above will
+become:
+
+.. code-block:: html
+
+   <a href="{button.link}" target="{button.target}" class="widget-cta">{f:translate(id: button.title, default: button.title)}</a>
+
+.. index:: Backend, ext:dashboard, FullyScanned

Documentation/Changelog/10.4/Deprecation-88740-ExtFeloginPibasePlugin.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88740:
+
+=============================================================
+Deprecation: #88740 - ext:felogin pibase plugin related hooks
+=============================================================
+
+See :issue:`88740`
+
+Description
+===========
+
+All legacy hooks related to the pibase plugin of EXT:felogin have been disabled
+and will be removed in TYPO3v11.
+
+
+Impact
+======
+
+Extensions that use any of the following hooks will trigger a PHP :php:`E_USER_DEPRECATED` error:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['beforeRedirect']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['postProcContent']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['forgotPasswordMail']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_confirmed']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_error']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['loginFormOnSubmitFuncs']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['logout_confirmed']`
+
+
+Affected Installations
+======================
+
+All instances using extensions that use any of the previously named hooks.
+
+Migration
+=========
+
+All of the hooks have been replaced by equivalent PSR-14 events.
+
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+| Pibase hook                                                                       | PSR-14 event                                                         |
++===================================================================================+======================================================================+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['beforeRedirect']`         | :php:`\TYPO3\CMS\FrontendLogin\Event\BeforeRedirectEvent`            |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['postProcContent']`        | :php:`\TYPO3\CMS\FrontendLogin\Event\ModifyLoginFormViewEvent`       |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['forgotPasswordMail']`     | :php:`\TYPO3\CMS\FrontendLogin\Event\SendRecoveryEmailEvent`         |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed']`       | :php:`\TYPO3\CMS\FrontendLogin\Event\PasswordChangeEvent`            |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_confirmed']`        | :php:`\TYPO3\CMS\FrontendLogin\Event\LoginConfirmedEvent`            |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_error']`            | :php:`\TYPO3\CMS\FrontendLogin\Event\LoginErrorOccurredEvent`        |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['logout_confirmed']`       | :php:`\TYPO3\CMS\FrontendLogin\Event\LogoutConfirmedEvent`           |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+|:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['loginFormOnSubmitFuncs']` | :php:`\TYPO3\CMS\FrontendLogin\Event\ModifyLoginFormViewEvent`       |
++-----------------------------------------------------------------------------------+----------------------------------------------------------------------+
+
+.. index:: Frontend, FullyScanned, ext:felogin

Documentation/Changelog/10.4/Deprecation-90147-UnifiedFileNameValidator.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90147:
+
+=================================================
+Deprecation: #90147 - Unified File Name Validator
+=================================================
+
+See :issue:`90147`
+
+Description
+===========
+
+The logic for validating if a new (uploaded) or renamed file's name is allowed
+is now available in an encapsulated PHP class :php:`FileNameValidator`.
+
+The functionality is moved so all logic is encapsulated in one single place:
+
+- PHP constant `FILE_DENY_PATTERN_DEFAULT` is migrated into a class constant.
+- :file:`LocalConfiguration.php` setting is only used when it differs from the default.
+- The :php:`GeneralUtility` method has been marked as deprecated and calls :php:`FileNameValidator->isValid()` directly.
+
+This optimization helps to only utilize and use PHPs memory if
+needed, and avoids to define run-time constants or variables.
+Logic is only initialized when needed - e.g. when uploading files or using TYPO3's importer via EXT:impexp.
+
+In addition, the PHP constant :php:`PHP_EXTENSIONS_DEFAULT` which is not
+in use anymore, has been marked as deprecated, too.
+
+
+Impact
+======
+
+Using the method :php:`GeneralUtility::verifyFilenameAgainstDenyPattern()` directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Using the constants will continue to work but will stop doing so TYPO3 v11.0, when they will be removed.
+
+The system-wide setting to override the default file deny pattern,
+:php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern']` is only set when
+different from the systems default. If it is the same, the option is not set anymore by TYPO3 Core.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with PHP code calling the mentioned method directly or using one of the global constants directly.
+
+
+Migration
+=========
+
+Instead of calling
+
+:php:`GeneralUtility::verifyFilenameAgainstDenyPattern($filename)`
+
+use
+
+:php:`GeneralUtility::makeInstance(FileNameValidator::class)->isValid($filename);`
+
+Instead of using the constant :php:`FILE_DENY_PATTERN_DEFAULT`, use :php:`FileNameValidator::DEFAULT_FILE_DENY_PATTERN`.
+
+For the PHP constant :php:`PHP_EXTENSIONS_DEFAULT` there is no replacement, as it has no benefit for TYPO3 Core anymore.
+
+The extension scanner will detect the method calls or the usage of the constants.
+
+.. index:: LocalConfiguration, PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.4/Deprecation-90377-ParamTypesRefOfMethodCallUserFunction.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90377:
+
+=================================================================
+Deprecation: #90377 - Param types $ref of method callUserFunction
+=================================================================
+
+See :issue:`90377`
+
+Description
+===========
+
+:php:`GeneralUtility::callUserFunction()` accepts a reference variable which is
+used to pass on the caller to the called function. Said variable :php:`$ref`
+does not have a type hint, therefore it's possible to hand over any type of variable
+whilst it's purpose is to only accept objects.
+
+
+Impact
+======
+
+Passing :php:`$ref` into :php:`GeneralUtility::callUserFunction()` with a type other than :php:`object` or :php:`null` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that pass a non :php:`object` or non :php:`null` type :php:`$ref` variable into :php:`GeneralUtility::callUserFunction()`.
+
+
+Migration
+=========
+
+There is none. :php:`$ref` is meant to be the calling object. Using it to pass arbitrary data to the user function will eventually be forbidden.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/10.4/Deprecation-90625-ExtbaseSignalSlotDispatcher.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90625:
+
+===================================================
+Deprecation: #90625 - Extbase SignalSlot Dispatcher
+===================================================
+
+See :issue:`90625`
+
+Description
+===========
+
+TYPO3 has various methods to extend existing TYPO3 Core functionality via PHP.
+
+One of the famous APIs is the so-called "SignalSlot Dispatcher", originally provided by Extbase and
+TYPO3 Flow.
+
+The SignalSlot Dispatcher follows the Observer pattern, which was originally not designed to
+actually interact (= modify) the information handed in - it's a signal that is sent.
+
+Since March 2019, a new standard recommendation in PHP - PSR-14 - was put into place, and adopted
+in TYPO3 v10.0. TYPO3s PSR-14 implementation has several advantages over SignalSlot:
+
+* All Events ("Signals" in Extbase world) are actual PHP objects that clearly define what can
+  be read or modified.
+* All Events are registered at compile-time (inside the Service Container), so the Listeners
+  ("Slots" in Extbase world) are defined in one place and are always available. Previously the
+  registration of the slots was done in :file:`ext_localconf.php`.
+* Events can be used across other PHP projects as well, and the EventDispatcher can be the same
+  instance, as it is standard recommendation.
+
+In TYPO3 v10, all Extbase signals provided by TYPO3 Core have been migrated to PSR-14 events.
+
+For this reason, the Extbase SignalSlot Dispatcher has been marked as deprecated in TYPO3 Core.
+It is recommended to migrate to PSR-14 Events and Event Listeners.
+
+
+Impact
+======
+
+As :php:`SignalSlotDispatcher` is still in place within TYPO3 Core for backwards-compatibility reasons,
+and extensions still have lots of Signals defined, no PHP :php:`E_USER_DEPRECATED` error will be triggered
+if an extension is using the SignalSlot mechanism. However using it is highly discouraged, as it
+will be removed in future TYPO3 versions.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations with custom extensions that are using the SignalSlot Dispatcher.
+
+
+Migration
+=========
+
+Use PSR-14 Events and Event-Listeners instead.
+
+See the documentation for details:
+:ref:`EventDispatcher (PSR-14 Events) <t3coreapi:EventDispatcher>`
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.4/Deprecation-90686-ModelFileMount.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90686:
+
+=====================================
+Deprecation: #90686 - Model FileMount
+=====================================
+
+See :issue:`90686`
+
+Description
+===========
+
+The class :php:`\TYPO3\CMS\Extbase\Domain\Model\FileMount` has been marked as deprecated.
+
+The :php:`FileMount` is an internal class which never really had any functionality
+besides being an Extbase model for the database table :sql:`sys_filemounts`. Therefore
+and in order to streamline the codebase of Extbase, the class :php:`FileMount` will be removed with TYPO3 11.0.
+
+
+Impact
+======
+
+Using :php:`FileMount` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third-party extension using the model.
+
+
+Migration
+=========
+
+Copy the class and mapping to your own extension and adopt the usages.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.4/Deprecation-90692-FileCollectionModels.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90692:
+
+===========================================
+Deprecation: #90692 - FileCollection models
+===========================================
+
+See :issue:`90692`
+
+Description
+===========
+
+The following classes have been marked as deprecated:
+
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\StaticFileCollection`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\FolderBasedFileCollection`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\AbstractFileCollection`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverter\StaticFileCollectionConverter`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverter\FolderBasedFileCollectionConverter`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverter\AbstractFileCollectionConverter`
+
+The classes were marked as internal and never contained any logic. Therefore and in order to streamline the codebase of Extbase, the files will be removed with TYPO3 11.0.
+
+
+Impact
+======
+
+Using any of the mentioned classes will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third-party extension using the classes.
+
+
+Migration
+=========
+
+Copy the classes to your own extension and adopt the usages.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.4/Deprecation-90800-GeneralUtilityisRunningOnCgiServerApi.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90800:
+
+=============================================================
+Deprecation: #90800 - GeneralUtility::isRunningOnCgiServerApi
+=============================================================
+
+See :issue:`90800`
+
+Description
+===========
+
+The lowlevel API method :php:`GeneralUtility::isRunningOnCgiServerApi()` which detects if
+the current PHP is executed via a CGI wrapper script ("SAPI", see https://www.php.net/manual/en/function.php-sapi-name.php) has been
+moved to the Environment API and is now available via :php:`Environment::isRunningOnCgiServer()`.
+
+
+Impact
+======
+
+Calling the method from :php:`GeneralUtility` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with an extension using this PHP method, which will happen only in rare circumstances.
+
+
+Migration
+=========
+
+Use the new method :php:`Environment::isRunningOnCgiServer()` instead, which works exactly the same.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.4/Deprecation-90803-DeprecationOfObjectManagergetInExtbaseContext.rst

@@ -0,0 +1,172 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Deprecation-90803-ObjectManagerGet:
+
+===========================================================
+Deprecation: #90803 - ObjectManager::get in Extbase context
+===========================================================
+
+See :issue:`90803`
+
+Description
+===========
+
+To help understand the deprecation of :php:`$objectManager->get(Service::class)` let's first have a look at its domain: Dependency Injection
+and its history as well as the culprits to deal with.
+
+With the introduction of Extbase over one decade ago, a lot of modern software development paradigms have been introduced into TYPO3.
+One of that paradigms is Dependency Injection (DI) which is an approach of handling dependencies different than the one the TYPO3 core followed ever since.
+
+Given there is an EmailService class, which is responsible for sending emails, the usual approach of creating such a service was to create it
+the moment it was needed. TYPO3 never used the :php:`new` keyword to create new objects, but :php:`GeneralUtility::makeInstance()`, which pretty much does the same thing.
+So, one approach of creating dependencies is creating them in the current scope where the dependency is needed.
+
+.. tip::
+
+   As a rule of thumb, you can remember the following:
+   Whenever you are creating dependencies yourself with :php:`new` or :php:`GeneralUtility::makeInstance()`, you are not using Dependency Injection.
+
+Extbase introduced the concept of Dependency Injection (DI) which means, that all dependencies are declared in a way, that the dependency chain is known before runtime.
+The most common way of implementing DI is to declare dependencies as constructor arguments. This means, in the scope of the current class, all dependencies are made visible as constructor arguments.
+As those dependencies need to be created outside the current scope, a service container implementation is responsible for the creation and management of service instances.
+Then, instead of calling :php:`new Service(...)`, the container needs to be queried for the needed service, e.g. by calling :php:`$container->get(Service::class)`.
+This also assures that the container provide the requested services with their dependencies, as they are created the same way.
+
+There is an service container in Extbase but it's not exposed to the public. Instead, there is the :php:`ObjectManager` class, which acts as a proxy for the container and also has a :php:`get` method, to query instances of services.
+
+Exactly that :php:`get()` method is now deprecated in the extbase context because it should never be called directly.
+
+The usual extbase context is a controller. All controllers are created by the object manager and therefore support DI. Whenever a dependency is needed in an extbase context,
+instead of calling :php:`$objectManager->get(Service::class)`, the usual DI approaches have to be used. Those approaches are constructor, method and property injection.
+
+Migration
+---------
+
+If you are using code similar to the following example, you should migrate to dependency injection:
+
+.. code-block:: php
+
+   class MainController
+   {
+       public function listAction()
+       {
+           $service = $this->objectManager->get(Service::class);
+           $service->doSomething();
+       }
+   }
+
+
+Examples how to use dependency injection:
+
+Constructor Injection
+^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: php
+
+   class MainController
+   {
+       private $service;
+
+       public function __construct(Service $service)
+       {
+           $this->service = $service;
+       }
+
+       public function listAction()
+       {
+           $this->service->doSomething();
+       }
+   }
+
+
+.. tip::
+
+   Constructor injection is the preferred type of injection for dependencies.
+
+
+Method Injection
+^^^^^^^^^^^^^^^^
+
+.. code-block:: php
+
+   class MainController
+   {
+       private $service;
+
+       public function injectService(Service $service)
+       {
+           $this->service = $service;
+       }
+
+       public function listAction()
+       {
+           $this->service->doSomething();
+       }
+   }
+
+
+Property Injection
+^^^^^^^^^^^^^^^^^^
+
+.. code-block:: php
+
+   class MainController
+   {
+       /**
+        * @var Service
+        * @TYPO3\CMS\Extbase\Annotation\Inject
+        */
+       public $service;
+
+       public function listAction()
+       {
+           $this->service->doSomething();
+       }
+   }
+
+
+Unfortunately, there is even more to consider here. Dependencies usually are services and services are objects which are shareable. TYPO3 users might be more used to the term `Singleton`, which means,
+that there is just one instance of a service during runtime which is shared across all scopes. Singletons are a great way to save resources but there is more to Singletons than just that.
+To be able to share the same instance of a class across all scopes, the instance cannot store information about its state in its properties.
+The idea of Singletons is to have an object that always behaves the same, no matter where it is used.
+
+Let's have a look at classes that are no services. We can borrow the term prototype from the Java world. A commonly used prototype object is a model. Each instance of a model clearly has a different state and therefore a different functionality.
+Those objects can theoretically be injected but it's very uncommon to do so. Still, in Extbase, instances of prototypes (e.g. instances of models, or other instances that hold state) are very often created with the object manager,
+which is bad practice. :php:`new` or :php:`GeneralUtility::makeInstance()` should be used for instantiating prototypes.
+
+However, when it comes to prototypes, there is a mechanic which cannot be implemented differently yet: the override of an implementation.
+
+It means, that it's possible to tell the :php:`ObjectManager` to create an instance of a different class than the one which is requested.
+One example of that is class :php:`TYPO3\CMS\Extbase\Persistence\Generic\Storage\Typo3DbBackend`, which can be fetched from the :php:`ObjectManager` by requesting an instance of the :php:`TYPO3\CMS\Extbase\Persistence\Generic\Storage\BackendInterface` interface.
+This feature should only be used for services as well but it is often used to override models of other extensions. For models you can either decide to simply instantiate via :php:`new`, or if you want to provide support for overwriting models
+via XCLASSes configured in :file:`ext_localconf.php` (configuration variable: :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects']`) you may also use :php:`GeneralUtility::makeInstance()`.
+
+.. tip::
+
+   Conclusion:
+
+   Singletons (services without state) should be provided by Dependency Injection wherever possible.
+
+   To create prototypes (instances with state), use :php:`new` or :php:`GeneralUtility::makeInstance()`.
+
+   :php:`ObjectManager->get()` must no longer be used.
+
+
+Impact
+======
+
+There is no impact yet. No PHP :php:`E_USER_DEPRECATED` error is triggered in TYPO3 10. This will probably change in TYPO3 11.x.
+
+
+Affected Installations
+======================
+
+All installations that use :php:`ObjectManager->get()` directly to create instances of dependencies in a scope that supports native Dependency Injection.
+
+
+Migration
+=========
+
+As mentioned above, constructor, method or property injection must be used instead.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/10.4/Deprecation-90856-WidgetAutocompleteViewHelper.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90856:
+
+====================================================
+Deprecation: #90856 - Widget AutoComplete ViewHelper
+====================================================
+
+See :issue:`90856`
+
+Description
+===========
+
+The Fluid ViewHelper :html:`<f:widget.autocomplete>` and the related controller
+:php:`TYPO3\CMS\Fluid\ViewHelpers\Widget\Controller\AutocompleteController`
+have been marked as deprecated and will be removed in TYPO3 v11.
+
+The widget depends on third-party libraries that cannot be
+maintained for a full LTS release lifecycle.
+
+
+Impact
+======
+
+Any usage of this ViewHelper or extending one of the following classes will trigger a PHP :php:`E_USER_DEPRECATED` error:
+
+* :php:`TYPO3\CMS\Fluid\ViewHelpers\Widget\AutocompleteViewHelper`
+* :php:`TYPO3\CMS\Fluid\ViewHelpers\Widget\Controller\AutocompleteController`
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with custom templates that contain this ViewHelper.
+
+
+Migration
+=========
+
+Remove any usages within the Fluid templates. There is no replacement provided by the core.
+If you need this widget, you have to provide your own implementation with your
+own frontend libraries for the handling.
+
+If you still need it, copy the ViewHelper and Controller into an own extension.
+
+
+.. index:: Fluid, PHP-API, NotScanned, ext:fluid

Documentation/Changelog/10.4/Deprecation-90861-Image-relatedMethodsWithinContentObjectRenderer.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90861:
+
+========================================================================
+Deprecation: #90861 - Image-related methods within ContentObjectRenderer
+========================================================================
+
+See :issue:`90861`
+
+Description
+===========
+
+The following methods within :php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer`,
+all which are related to generating :html:`<img>` tags for TYPO3 Frontend output via TypoScript, have been marked as deprecated:
+
+* :php:`cImage()`
+* :php:`getBorderAttr()`
+* :php:`getImageTagTemplate()`
+* :php:`getImageSourceCollection()`
+* :php:`linkWrap()`
+* :php:`getAltParam()`
+
+An additional method, :php:`imageLinkWrap()` has been marked as "internal" now in order to allow refactoring in future TYPO3 versions.
+
+All methods have been moved to the :php:`ImageContentObject` class, als known as "IMAGE" cObject.
+
+The methods purpose is only relevant for generating IMAGE, thus making the actual ContentObjectRenderer class smaller.
+
+
+Impact
+======
+
+Any TypoScript configuration using code of this is not affected.
+
+Only third-party extensions that use this code for frontend-related
+image rendering might directly call these PHP methods. Calling these
+methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom third-party extensions calling these
+methods. TYPO3's Extension Scanner code can directly detect these calls.
+
+
+Migration
+=========
+
+As all moved methods are protected, it is recommended to either
+extend the ImageContentObject class, or copy the respective code
+into the third-party extension requiring this code.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/10.4/Deprecation-90937-VariousHooksInContentObjectRenderer.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90937:
+
+============================================================
+Deprecation: #90937 - Various hooks in ContentObjectRenderer
+============================================================
+
+See :issue:`90937`
+
+Description
+===========
+
+The following hooks within class :php:`ContentObjectRenderer` have been marked as deprecated:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['cObjTypeAndClass']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['cObjTypeAndClassDefault']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['extLinkATagParamsHandler']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['typolinkLinkHandler']`
+
+All hooks have been available for a long time, and several new concepts and APIs that have been added in previous LTS versions already, that superseded these hooks.
+
+
+Impact
+======
+
+Extensions registering the any one of the hooks listed above will trigger a PHP :php:`E_USER_DEPRECATED` error when the code is executed.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with older extensions implementing one of the hooks above, which is very rare and only serve specific use-cases
+for rendering ContentObjects or custom link style tags that are not related to TYPO3 v8 linking syntax (`t3://...`).
+
+
+Migration
+=========
+
+The hooks :php:`cObjTypeAndClass` and :php:`cObjTypeAndClassDefault` can be simplified by using the new way of registering custom ContentObjects via:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['ContentObjects']` - see :file:`EXT:frontend/ext_localconf.php` for examples - TYPO3 Core adds its shipped ContentObjects exactly the same way.
+
+The :php:`typolinkLinkHandler` hook is used for registering custom link syntax that start with a certain keyword such as "news:13".
+
+Since TYPO3 v8, LinkHandler support has been added to TYPO3 Core natively, using the new `t3://` syntax.
+The "LinkHandler" registry can be extended via :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['linkHandler']`
+and :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['typolinkBuilder']` that serves the same purpose with a better API.
+
+.. index:: Frontend, FullyScanned, ext:frontend

Documentation/Changelog/10.4/Deprecation-90956-AlternativeFetchMethodsAndReportsForGeneralUtilitygetUrl.rst

@@ -0,0 +1,77 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90956:
+
+========================================================================================
+Deprecation: #90956 - Alternative fetch methods and reports for GeneralUtility::getUrl()
+========================================================================================
+
+See :issue:`90956`
+
+Description
+===========
+
+The short-hand method :php:`GeneralUtility::getUrl()` provides a
+fast way to fetch the contents of a local file or remote URL.
+
+For Remote URLs, TYPO3 v8 provides an object-oriented (PSR-7 compatible) way by using
+the :php:`RequestFactory->request($url, $method, $options)` API. Under the hood, the PHP library GuzzleHTTP is used,
+which evaluates what best option (e.g. curl library) should handle
+the download to TYPO3.
+
+In general, it is recommended for any third-party extension developer to use either
+PHP's native :php:`file_get_contents($file)` method or the :php:`RequestFactory->request()` method to fetch a PSR-7 ResponseInterface object.
+
+The additional arguments in :php:`GeneralUtility::getUrl()` which allowed
+to send headers to the content or just do a HEAD request, or find reports on why
+the request did not succeed have been marked as deprecated.
+
+PHP's native Exception Handling and the response object give enough insights already to load the HTTP headers as well, or even do HTTP `POST` requests.
+
+
+Impact
+======
+
+Calling the method :php:`GeneralUtility::getUrl()` with more than one
+method argument will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using a third-party extension with :php:`GeneralUtility::getUrl()`
+and more than one parameter in the call.
+
+
+Migration
+=========
+
+Depending on the use-case of using the additional method parameters,
+certain alternatives exist since TYPO3 v8 already:
+
+Fetching the headers (as array) from a HTTP response:
+
+.. code-block:: php
+
+   $response = GeneralUtility::makeInstance(RequestFactory::class)->request($url);
+   $allHeaders = $response->getHeaders();
+   // Also see $response->getHeader($headerName) and $response->getHeaderLine($headerName)
+
+Sending additional headers with the HTTP request:
+
+.. code-block:: php
+
+   $response = GeneralUtility::makeInstance(RequestFactory::class)->request($url, 'GET', ['headers' => ['accept' => 'application/json']]);
+
+Finding additional information about the response:
+
+.. code-block:: php
+
+   $response = GeneralUtility::makeInstance(RequestFactory::class)->request($url, 'GET', ['headers' => ['accept' => 'application/json']]);
+   if ($response->getStatusCode() >= 300) {
+      $content = $response->getReasonPhrase();
+   } else {
+      $content = $response->getBody()->getContents();
+   }
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.4/Deprecation-90964-LanguageServiceFunctionalityAndInternalProperties.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-90964:
+
+===========================================================================
+Deprecation: #90964 - LanguageService functionality and internal properties
+===========================================================================
+
+See :issue:`90964`
+
+Description
+===========
+
+LanguageService - also known as :php:`$GLOBALS[LANG]` within TYPO3 Core
+is used to fetch a label string from a XLF file and deliver the
+translated value from that string.
+
+Some functionality related to legacy functionality or internal logic has been marked as deprecated and changed visibility:
+
+* :php:`LanguageService->LL_files_cache` - is now protected instead of public
+* :php:`LanguageService->LL_labels_cache` - is now protected instead of public
+* :php:`LanguageService->getLabelsWithPrefix()` - is deprecated as it is not needed
+* :php:`LanguageService->getLLL()` - is now protected instead of public
+* :php:`LanguageService->debugLL()` - is now protected instead of public
+
+The method :php:`LanguageService->loadSingleTableDescription()` is marked as internal now.
+
+
+Impact
+======
+
+Calling any of the methods or properties listed above will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions of custom logic using the internals of specifics of the :php:`LanguageService` class.
+
+
+Migration
+=========
+
+Use the Public API of the :php:`LanguageService` - namely :php:`sL()` and :php:`getLL()` directly.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.4/Deprecation-91001-VariousMethodsWithinGeneralUtility.rst

@@ -0,0 +1,59 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-91001:
+
+===========================================================
+Deprecation: #91001 - Various methods within GeneralUtility
+===========================================================
+
+See :issue:`91001`
+
+Description
+===========
+
+The following methods within GeneralUtility have been marked as deprecated,
+as the native PHP methods can be used directly:
+
+* :php:`GeneralUtility::IPv6Hex2Bin()`
+* :php:`GeneralUtility::IPv6Bin2Hex()`
+* :php:`GeneralUtility::compressIPv6()`
+* :php:`GeneralUtility::milliseconds()`
+
+In addition, these methods are unused by Core and marked as deprecated as well:
+
+* :php:`GeneralUtility::linkThisUrl()`
+* :php:`GeneralUtility::flushDirectory()`
+
+
+Impact
+======
+
+Calling any methods directly from PHP will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions using any of these methods.
+
+
+Migration
+=========
+
+As the following methods are just wrappers around native PHP methods, it is
+recommended to switch to native PHP to speed up performance:
+
+* :php:`GeneralUtility::IPv6Hex2Bin($hex)`: :php:`inet_pton($hex)`
+* :php:`GeneralUtility::IPv6Bin2Hex($bin)`: :php:`inet_ntop($bin)`
+* :php:`GeneralUtility::compressIPv6($address)`: :php:`inet_ntop(inet_pton($address))`
+* :php:`GeneralUtility::milliseconds()`: :php:`round(microtime(true) * 1000)`
+
+As for :php:`GeneralUtility::linkThisUrl()` it is recommended to migrate to
+PSR-7 (UriInterface).
+
+The method :php:`GeneralUtility::flushDirectory()` uses a clearing
+folder structure which is only used for caching to avoid race-conditioning. It
+is recommended to use :php:`GeneralUtility::rmdir()` or implement the code
+directly in the third-party extension.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.4/Deprecation-91012-VariousHooksRelatedToTypoScriptFrontendController.rst

@@ -0,0 +1,71 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-91012:
+
+===========================================================================
+Deprecation: #91012 - Various hooks related to TypoScriptFrontendController
+===========================================================================
+
+See :issue:`91012`
+
+Description
+===========
+
+The following hooks related to class :php:`TypoScriptFrontendController`
+and frontend-rendering have been marked as deprecated:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageIndexing']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['isOutputting']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['tslib_fe-contentStrReplace']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-output']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_eofe']`
+
+The following methods have been marked as deprecated as well, as they only
+contain code relevant for executing the hooks:
+
+* :php:`TypoScriptFrontendController->isOutputting()`
+* :php:`TypoScriptFrontendController->processContentForOutput()`
+
+
+Impact
+======
+
+If third-party extensions are using the hooks, a PHP :php:`E_USER_DEPRECATED` error will be triggered when the hook is executed.
+
+Calling the two methods above will also trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using the hooks or mentioned above, which is common if they haven't been using
+PSR-15 middlewares or other hooks instead.
+
+
+Migration
+=========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageIndexing']`
+should be replaced by the :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-cached']` hook
+to index pages. However, please note that :php:`$TSFE->content` might contain UTF-8 content now,
+instead of content already converted to the defined character set related to :typoscript:`metaCharset` TypoScript property.
+
+Since TYPO3 v9, the emitter of HTTP responses is based on PSR-7, the hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['isOutputting']` can be removed, as
+TYPO3 can be configured via PSR-15 middlewares to define whether
+page content should be emitted / rendered or not.
+
+The hook to dynamically replace content via :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['tslib_fe-contentStrReplace']`
+is removed as it serves no purpose for TYPO3 Core anymore. If content should be dynamically modified, use a PSR-15 middleware instead.
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-output']` is not needed as this can be built via a PSR-15 middleware instead, and
+all content is returned via the RequestHandler of TYPO3 Frontend.
+
+Extensions using hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_eofe']` should
+be converted to PSR-15 middlewares, as this allows to modify content and headers of a PSR-7 Response object.
+
+The method :php:`TypoScriptFrontendController->isOutputting()` is obsolete and can be removed in third-party code.
+
+The same applies to :php:`TypoScriptFrontendController->processContentForOutput()` which should only be used to trigger
+legacy hooks still applied in the system.
+
+.. index:: PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/10.4/Deprecation-91030-Runtime-ActivatedPackages.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-91030:
+
+================================================
+Deprecation: #91030 - Runtime-Activated Packages
+================================================
+
+See :issue:`91030`
+
+Description
+===========
+
+TYPO3's global configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['EXT']['runtimeActivatedPackages']` has been marked as deprecated.
+
+The option to register packages during runtime was introduced as
+a work-around to dynamically modify the "extension list" when migrating from TYPO3 v4.5 to TYPO3 v6.x.
+
+However, using this feature has certain limitations:
+
+* Runtime-activated Extensions cannot add their DI configuration
+* Runtime-activated Extensions make every (!) single TYPO3 request much slower just like back in 6.2.0 times
+
+The main use case we know from people was to this functionality to enable e.g. extensions such as "devlog", "mask"/"mask_export" or "extensionbuilder" only on development systems.
+
+
+Impact
+======
+
+Having a TYPO3 system using Runtime Activated Packages functionality
+will trigger a PHP :php:`E_USER_DEPRECATED` error on every TYPO3 request.
+
+
+Affected Installations
+======================
+
+TYPO3 installations having the affected option set in either :file:`typo3conf/LocalConfiguration.php` or :file:`typo3conf/AdditionalConfiguration.php`.
+
+
+Migration
+=========
+
+It is recommended - if this functionality is needed - to use TYPO3
+Console and Composer Mode (with require-dev) to achieve a similar behavior.
+
+If it is critical to have such features, consider modifying the extension in question to deal with TYPO3's Context
+feature to enable / disable functionality for Production environment.
+
+.. index:: LocalConfiguration, FullyScanned, ext:core

Documentation/Changelog/10.4/Feature-83128-ContentElementFilter.rst

@@ -0,0 +1,25 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-83128:
+
+========================================
+Feature: #83128 - Content Element Filter
+========================================
+
+See :issue:`83128`
+
+Description
+===========
+
+A backend user is now able to search for a set of content types in the "New
+Content Element" wizard.
+
+Impact
+======
+
+If a user enters a search query, any content type whose title or description
+doesn't match the query are hidden to the user. Since content types are grouped in
+tabs, tabs without content get disabled to the user. If the current active tab
+becomes empty, the next available tab is activated.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/10.4/Feature-87776-LimitRestrictionToTablesInQueryBuilder.rst

@@ -0,0 +1,75 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87776:
+
+==============================================================
+Feature: #87776 - Limit Restriction to table/s in QueryBuilder
+==============================================================
+
+See :issue:`87776`
+
+Description
+===========
+
+In some cases it is needed to apply restrictions only to a certain table.
+With the new :php:`\TYPO3\CMS\Core\Database\Query\Restriction\LimitToTablesRestrictionContainer`
+it is possible to apply restrictions to a query only for a given set of tables, or to be precise, table aliases.
+Since it is a restriction container, it can be added to the restrictions of the query builder and
+it can hold restrictions itself. The restrictions it holds can be limited to tables like this:
+
+
+Example implementation:
+-----------------------
+
+.. code-block:: php
+
+   $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable('tt_content');
+   $queryBuilder->getRestrictions()
+       ->removeByType(HiddenRestriction::class)
+       ->add(
+           GeneralUtility::makeInstance(LimitToTablesRestrictionContainer::class)
+               ->addForTables(GeneralUtility::makeInstance(HiddenRestriction::class), ['tt'])
+       );
+   $queryBuilder->select('tt.uid', 'tt.header', 'sc.title')
+       ->from('tt_content', 'tt')
+       ->from('sys_category', 'sc')
+       ->from('sys_category_record_mm', 'scmm')
+       ->where(
+           $queryBuilder->expr()->eq('scmm.uid_foreign', $queryBuilder->quoteIdentifier('tt.uid')),
+           $queryBuilder->expr()->eq('scmm.uid_local', $queryBuilder->quoteIdentifier('sc.uid')),
+           $queryBuilder->expr()->eq('tt.uid', $queryBuilder->createNamedParameter($id, \PDO::PARAM_INT))
+       );
+
+
+In this example the HiddenRestriction is only applied to :sql:`tt` table alias of :sql:`tt_content`.
+
+Furthermore it is possible to restrict the complete set of restrictions of a query builder to a
+given set of table aliases.
+
+.. code-block:: php
+
+   $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable('tt_content');
+   $queryBuilder->getRestrictions()->removeAll()->add(GeneralUtility::makeInstance(HiddenRestriction::class));
+   $queryBuilder->getRestrictions()->limitRestrictionsToTables(['c2']);
+   $queryBuilder
+      ->select('c1.*')
+      ->from('tt_content', 'c1')
+      ->leftJoin('c1', 'tt_content', 'c2', 'c1.parent_field = c2.uid')
+      ->orWhere($queryBuilder->expr()->isNull('c2.uid'), $queryBuilder->expr()->eq('c2.pid', $queryBuilder->createNamedParameter(1, \PDO::PARAM_INT)));
+
+Which will result in:
+
+.. code-block:: sql
+
+   SELECT "c1".*
+   FROM "tt_content" "c1"
+   LEFT JOIN "tt_content" "c2" ON c1.parent_field = c2.uid
+   WHERE (("c2"."uid" IS NULL) OR ("c2"."pid" = 1)) AND ("c2"."hidden" = 0))
+
+Impact
+======
+
+It is now easily possible to add restrictions that are only applied to certain tables/ table aliases,
+by using :php:`\TYPO3\CMS\Core\Database\Query\Restriction\LimitToTablesRestrictionContainer`.
+
+.. index:: Database, ext:core, PHP-API

Documentation/Changelog/10.4/Feature-89513-PasswordResetForBackendUsers.rst

@@ -0,0 +1,96 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89513:
+
+================================================================
+Feature: #89513 - Password Reset Functionality For Backend Users
+================================================================
+
+See :issue:`89513`
+
+Description
+===========
+
+It is now possible for TYPO3 Backend users who use the default username / password
+mechanism to log in, to reset their password by triggering an email through the
+Login form.
+
+The reset link is only shown if there is at least one user that matches the
+following criteria:
+
+* The user has a password entered previously (used to indicate that no third-party login was used)
+* The user has a valid email added to their user record
+* The user is neither deleted nor disabled
+* The email address is only used once among all Backend users of the instance
+
+Once the user has entered their email address, an email is sent out with a
+link to set a new password which needs to have a least 8 characters.
+
+The link is valid for 2 hours, and a token is added to the link.
+
+If the password was provided correctly, it is updated for the user and can log-in.
+
+Some notes on security:
+
+* When having multiple users with the same email address, no reset functionality is provided
+* No information disclosure is built-in, so if the email address is not in the system, it is not known to the outside
+* Rate limiting is activated for allowing three emails to be sent within 30 minutes per email address
+* Tokens are stored for the backend users in the database but hashed again just like the password
+* When a user has logged in successfully (e.g. because he/she remembered the password) the token is removed from the database, effectively invalidating all existing email links
+
+The feature is active by default and can be deactivated completely via the system-wide
+configuration option:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['passwordReset']`
+
+Optionally it is possible to restrict this feature to non-admins only, by setting
+the following system-wide option to "false".
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['passwordResetForAdmins']`
+
+Both options are available to be configured within the Maintenance Area
+=> Settings module, or in the Install Tool, but can be set manually via
+:file:`typo3conf/LocalConfiguration.php` or :file:`typo3conf/AdditionalConfiguration.php`.
+
+In addition, it is possible for administrators to reset a users password.
+This is especially useful for security purposes so an administrator does not
+need to send a password over the wire in plaintext (e.g. email) to a user.
+
+The administrator can use the CLI command:
+
+.. code-block:: bash
+
+   ./typo3/sysext/core/bin/typo3 backend:resetpassword https://www.example.com/typo3/ editor@example.com
+
+where usage is described as this:
+
+.. code-block:: bash
+
+   backend:resetpassword <backendurl> <email>
+
+Alternatively it is possible for administrators to use the "Backend users" module
+and select the password reset button to initiate the password reset process for
+a specific user.
+
+Both options are only available for users that have an email address and a password
+set.
+
+Impact
+======
+
+Administrators do not have additional overhead to re-set passwords for editors,
+and they do not need to add the passwords for editors themselves.
+
+In addition, the email can be styled completely for HTML and plain-text only
+versions through the Fluid-based templated email feature.
+
+Further improvements on the horizon:
+
+* Trigger a password-reset via CLI or the Backend users module
+* Trigger a password-set email on creation of a new user, so the admin has no
+  involvement in needing to know or share the password
+* Require an email address when adding backend users to enable this feature for everybody
+* Implement ways to allow the password reset functionality via different ways than email
+* Find solutions for handling third-party authentication system
+
+.. index:: LocalConfiguration, ext:backend

Documentation/Changelog/10.4/Feature-89573-AllowFlexibleBaseUrlForSlugFieldsInFormEngine.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89573:
+
+=======================================================================
+Feature: #89573 - Allow flexible base url for slug fields in FormEngine
+=======================================================================
+
+See :issue:`89573`
+
+Description
+===========
+
+It is now possible to add a custom base url for TCA columns of type :php:`slug`. The
+base url is displayed in front of the input field in FormEngine.
+
+To add a custom base url a :php:`userFunc` can be assigned to the new setting
+:php:`prefix` which is available under :php:`['columns'][*]['config']['appearance']` at the fields TCA definition.
+
+.. code-block:: php
+
+   'config' => [
+       'type' => 'slug',
+       'appearance' => [
+           'prefix' => \Vendor\Extension\UserFunctions\FormEngine\SlugPrefix::class . '->getPrefix'
+       ]
+   ]
+
+The :php:`userFunc` receives two parameters. The first parameter is the parameters
+array containing the site object, the language id, the current table and the
+current row. The second parameter is the reference object :php:`TcaSlug`. The
+:php:`userFunc` should return the string which is then used as the base url in
+FormEngine.
+
+.. code-block:: php
+
+   <?php
+   declare(strict_types = 1);
+
+   namespace Vendor\Extension\UserFunctions\FormEngine
+
+   use TYPO3\CMS\Backend\Form\FormDataProvider\TcaSlug;
+
+   class SlugPrefix
+   {
+       public function getPrefix(array $parameters, TcaSlug $reference): string
+       {
+           return 'custom base url';
+       }
+   }
+
+
+Impact
+======
+
+Developers are enabled to provide custom base urls for their slug fields. If you
+are already using slug fields in your TCA, nothing changes as the current
+behaviour is still used as the default.
+
+.. index:: Backend, PHP-API, TCA, ext:backend

Documentation/Changelog/10.4/Feature-90613-AddLanguageArgumentToPage-relatedLinkViewHelpersAndUriViewHelpersInFluid.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90613:
+
+===================================================================================================
+Feature: #90613 - Add language argument to page-related LinkViewHelpers and UriViewHelpers in Fluid
+===================================================================================================
+
+See :issue:`90613`
+
+Description
+===========
+
+A new argument :html:`language` is added to the following Fluid ViewHelpers:
+
+* :html:`<f:link.typolink>`
+* :html:`<f:link.page>`
+* :html:`<f:uri.typolink>`
+* :html:`<f:uri.page>`
+
+They are responsible for linking to a page, and are using TypoLink functionality
+under-the-hood.
+
+
+Examples
+--------
+
+A Link to page with ID 13 but with language 3 - no matter what language the
+current page is:
+
+
+.. code-block:: html
+
+   <f:link.page pageUid="13" language="3">Go to french version of about us page</f:link.page>
+
+
+Creating a language menu:
+
+.. code-block:: html
+
+   <ul>
+     <li>
+       <f:link.typolink parameter="current" language="3">Current page in french</f:link.typolink>
+     </li>
+     <li>
+       <f:link.typolink parameter="current" language="4">Current page in german</f:link.typolink>
+     </li>
+     <li>
+       <f:link.typolink parameter="current" language="5">Current page in spanish</f:link.typolink>
+     </li>
+   </ul>
+
+
+Impact
+======
+
+The new argument allows to force a language when linking to a specific page,
+making it consistent with the TypoLink option added in site handling for TYPO3 v9:
+
+https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/Functions/Typolink.html#language
+
+This Fluid option should be used instead of adding a `L` parameter to
+`additionalParameters` argument to make linking to a specific language possible.
+In general, using of the magic GET variable `L` is discouraged.
+
+.. index:: Fluid, ext:fluid

Documentation/Changelog/10.4/Feature-90826-CompareBackendUsergroups.rst

@@ -0,0 +1,20 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90826:
+
+============================================
+Feature: #90826 - Compare backend usergroups
+============================================
+
+See :issue:`90826`
+
+Description
+===========
+
+Integrators are now able to compare individual backend usergroups.
+
+Backend usergroups are used to split permissions into smaller parts which can be later assigned to a backend user.
+This feature makes it possible to compare the defined permissions including the ones inherited from sub groups.
+
+
+.. index:: Backend, ext:beuser

Documentation/Changelog/10.4/Feature-90899-IntroduceAssetPreRenderingEvents.rst

@@ -0,0 +1,129 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Feature-90899-IntroduceAssetPreRenderingEvents:
+
+==============================================================
+Feature: #90899 - Introduce AssetRenderer pre-rendering events
+==============================================================
+
+See :issue:`90899`
+
+Description
+===========
+
+AssetRenderer is amended by two events which allow post-processing of
+AssetCollector assets.
+
+These new PSR-14 events are introduced:
+
+* :php:`\TYPO3\CMS\Core\Page\Event\BeforeJavaScriptsRenderingEvent`
+* :php:`\TYPO3\CMS\Core\Page\Event\BeforeStylesheetsRenderingEvent`
+
+Both stem fom the abstract base class
+:php:`\TYPO3\CMS\Core\Page\Event\AbstractBeforeAssetRenderingEvent` and provide
+these public methods:
+
+* :php:`getAssetCollector(): AssetCollector`
+* :php:`isInline(): bool`
+* :php:`isPriority(): bool`
+
+:php:`inline` and :php:`priority` refer to how the asset was registered with
+:ref:`AssetCollector <changelog-Feature-90522-IntroduceAssetCollector>`.
+
+The events are fired exactly once for every combination of
+:php:`inline`/:php:`priority` before the corresponding section of JS/CSS assets
+is rendered by the AssetRenderer.
+
+To make the events easier to use, the :php:`AssetCollector::get*()` methods
+have gotten an optional parameter :html:`?bool $priority = null` which when given a
+boolean only returns assets of the given priority.
+
+
+.. note::
+
+   post-processing functionality for assets registered via
+   TypoScript :typoscript:`page.include...` or the :php:`PageRenderer::add*()`
+   functions are still provided by these hooks:
+
+   * :php:`$GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['cssCompressHandler']`
+   * :php:`$GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['jsCompressHandler']`
+   * :php:`$GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['cssConcatenateHandler']`
+   * :php:`$GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['jsConcatenateHandler']`
+   * :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_pagerenderer.php']['render-preProcess']`
+
+   Assets registered with the AssetCollector (and output through the
+   AssetRenderer) are not included in those.
+
+
+Example
+=======
+
+As an example let's make sure jQuery is included in a specific version and
+from a CDN.
+
+.. rst-class:: bignums
+
+   1. Register our listeners
+
+      :file:`Configuration/Services.yaml`
+
+      .. code-block:: yaml
+
+         services:
+            MyVendor\MyExt\EventListener\AssetRenderer\LibraryVersion:
+             tags:
+               - name: event.listener
+                 identifier: 'myExt/LibraryVersion'
+                 event: TYPO3\CMS\Core\Page\Event\BeforeJavaScriptsRenderingEvent
+
+
+   2. Implement Listener to enforce a library version or CDN URI
+
+      .. code-block:: php
+
+         namespace MyVendor\MyExt\EventListener\AssetRenderer;
+
+         use TYPO3\CMS\Core\Page\Event\BeforeJavaScriptsRenderingEvent;
+
+         /**
+          * If a library has been registered, it is made sure that it is loaded
+          * from the given URI
+          */
+         class LibraryVersion
+         {
+             protected $libraries = [
+                 'jquery' => 'https://code.jquery.com/jquery-3.4.1.min.js',
+             ];
+
+             public function __invoke(BeforeJavaScriptsRenderingEvent $event): void
+             {
+                 if ($event->isInline()) {
+                     return;
+                 }
+
+                 foreach ($this->libraries as $library => $source) {
+                     $asset = $event->getAssetCollector()->getJavaScripts($event->isPriority())
+                     // if it was already registered
+                     if ($asset[$library] ?? false) {
+                         // we set our authoritative version
+                         $event->getAssetCollector()->addJavaScript($library, $source);
+                     }
+                 }
+             }
+         }
+
+
+Impact
+======
+
+Existing installations are not affected.
+
+If using the AssetCollector API, these new events should be used for asset
+postprocessing.
+
+Related
+=======
+
+- :ref:`changelog-Feature-90522-IntroduceAssetCollector`
+
+.. index:: PHP-API, ext:core

Documentation/Changelog/10.4/Feature-90945-PSR-14EventForLocalizationControllerWhenReadingRecordscolumnsToBeTranslated.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-90945:
+
+=======================================================================================================
+Feature: #90945 - PSR-14 event for LocalizationController when reading records/columns to be translated
+=======================================================================================================
+
+See :issue:`90945`
+
+Description
+===========
+
+A new PSR-14 event :php:`\TYPO3\CMS\Backend\Controller\Event\AfterPageColumnsSelectedForLocalizationEvent`
+has been added and will be dispatched after records and columns are collected in the :php`LocalizationController`.
+
+The event receives:
+
+* The default columns and columnsList built by :php:`LocalizationController`
+* The list of records that were analyzed to create the columns manifest
+* The parameters received by the :php`LocalizationController`
+
+The event allows changes to:
+
+* the columns
+* the columnsList
+
+
+Impact
+======
+
+This allows third party code to read or manipulate the "columns manifest" that gets displayed in the
+translation modal when a user has clicked the ``Translate`` button in the page module, by implementing
+a listener for the :php:`\TYPO3\CMS\Backend\Controller\Event\AfterPageColumnsSelectedForLocalizationEvent` event.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/10.4/Feature-91008-ItemGroupingForTCASelectItems.rst

@@ -0,0 +1,154 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Feature-91008-ItemGroupingForTCASelectItems:
+
+====================================================
+Feature: #91008 - Item grouping for TCA select items
+====================================================
+
+See :issue:`91008`
+
+Description
+===========
+
+The TCA column type ``select`` now has a clean API to group items for dropdowns
+in FormEngine. This was previously handled via placeholder ``--div--`` items,
+which then rendered as :html:`<optgroup>` HTML elements in a dropdown.
+
+In larger installations or TYPO3 instances with lots of extensions, Plugins
+(:php:`tt_content.list_type`), Content Types (:php:`tt_content.CType`) or custom
+Page Types (:php:`pages.doktype`) drop down lists could grow large and adding item groups
+caused tedious work for developers or integrators.
+Grouping can now be configured on a per-item
+basis. Custom groups can be added via an API or when defining TCA for a new table.
+
+Adding Custom Select Item Groups
+--------------------------------
+
+Registration of a select item group takes place in :file:`Configuration/TCA/tx_mytable.php`
+for new TCA tables, and in :file:`Configuration/TCA/Overrides/a_random_core_table.php`
+for modifying an existing TCA definition.
+
+The following two examples illustrate adding a new group to a field of
+type "select":
+
+.. code-block:: php
+
+   ExtensionManagementUtility::addTcaSelectItemGroup(
+       'tt_content',
+       'CType',
+       'sliders',
+       'LLL:EXT:my_slider_mixtape/Resources/Private/Language/locallang_tca.xlf:tt_content.group.sliders',
+       'after:lists'
+   );
+
+The TCA for :php:`tt_content.CType` column configuration looks like this now:
+
+.. code-block:: php
+
+   'items' => ...
+   'itemGroups' => [
+       'default' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.div.standard',
+       'lists' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.div.lists',
+       'sliders' => 'LLL:EXT:my_slider_mixtape/Resources/Private/Language/locallang_tca.xlf:tt_content.group.sliders',
+       'menu' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.div.menu',
+       'forms' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.div.forms',
+       'special' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.div.special',
+    ],
+
+When adding a new select field, itemGroups should be added directly in the
+original TCA definition without using the API method. Use the API within
+:file:`TCA/Configuration/Overrides/` files to extend an existing TCA select field with
+grouping.
+
+Attaching Select Items to Item Groups
+-------------------------------------
+
+A select item now has a fourth array key to define a "Group ID" which group it
+belongs to. In the example above, the group ID is named "sliders" and used
+in the examples below to attach items to this group.
+
+Grouping for select items can be used via API or in TCA configuration directly.
+
+This is the example for a custom Content Type "slickslider" belonging to the
+group from above:
+
+.. code-block:: php
+
+   'items' => [
+       ...,
+       [
+           // Label
+           'LLL:EXT:my_slider_mixtape/Resources/Private/Locallang/locallang_tca.xlf:tt_content.CType.slickslider',
+           // Value written to the database
+           'slickslider',
+           // Icon for the dropdown
+           'EXT:my_slider_mixtape/Resources/Public/Icons/slickslider.png',
+           // The group ID, if not given, falls back to "none" or the last used --div-- in the item array
+           'sliders'
+       ],
+   ]
+
+
+The item can be added via API like this:
+
+.. code-block:: php
+
+   ExtensionManagementUtility::addTcaSelectItem(
+       'tt_content',
+       'CType',
+       [
+           'LLL:EXT:my_slider_mixtape/Resources/Private/Locallang/locallang_tca.xlf:tt_content.CType.slickslider',
+           'slickslider',
+           'EXT:my_slider_mixtape/Resources/Public/Icons/slickslider.png',
+           'sliders'
+       ]
+   );
+
+The same approach applies to :php:`ExtensionManagementUtility::addPlugin()` when
+adding pi-based plugins.
+
+When adding Extbase plugins, the API method now allows to specify a group ID
+directly as additional parameter. This falls back to the "default" group ID,
+which is available in :php:`tt_content.CType` and :php:`tt_content.list_type`.
+
+.. code-block:: php
+
+   ExtensionUtility::registerPlugin(
+       // Extension key
+       'my_slider_mixtape',
+       // Plugin value
+       'slider_from_records',
+       // Plugin label
+       'LLL:EXT:my_slider_mixtape/Resources/Private/Locallang/locallang_tca.xlf:tt_content.plugin.slider_from_records',
+       // Icon for plugin
+       'EXT:my_slider_mixtape/Resources/Public/Icons/slickslider.png',
+       // Group ID
+       'sliders'
+   );
+
+
+Impact
+======
+
+By default, Page Types (:php:`pages.doktype`), Content Types (:php:`tt_content.CType`) and
+Plugins (:php:`tt_content.list_type`) now have native grouping enabled.
+
+The order of the :php:`itemGroups` value is important when using groups, as this
+is the order of the groups rendered in the dropdown of FormEngine.
+
+The API methods can be used to build more groups without juggling with
+TCA arrays.
+
+It is possible now, and encouraged to remove the :php:`--div--` items in custom
+selects and use itemGroups instead. TYPO3 Core keeps the :php:`--div--` for
+backwards-compatible reasons in TYPO3 v10, but all items of the fields mentioned
+above the grouping parameter has been added already.
+
+Please note that this :php:`--div--` is related to select items, and not the
+"showItem" definition which fields should be shown.
+
+Currently Item Groups are used in FormEngine DropDowns / single-select items
+from TYPO3 Core, but can be used in multi-select fields as well.
+
+.. index:: TCA, ext:core

Documentation/Changelog/10.4/Feature-91008-ItemSortingForTCASelectItems.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91008:
+
+===================================================
+Feature: #91008 - Item sorting for TCA select items
+===================================================
+
+See :issue:`91008`
+
+Description
+===========
+
+A new option :php:`sortOrders` for TCA-based select fields has been added to allow
+sorting of static TCA select items by their values or labels.
+
+This is now used in TYPO3 Core's :php:`tt_content.list_type` whereas
+a previous :php:`itemsProcFunc` was used to sort all plugins by label
+in the FormEngine dropdown.
+
+Built-in orderings are to sort items by their labels or values. It is also possible
+to define custom :php:`sortOrders` via custom PHP code.
+
+Examples from tt_contents' :php:`list_type` TCA:
+
+.. code-block:: php
+
+   // Sort all items by label ("asc" or "desc" is possible)
+   $GLOBALS['TCA']['tt_content']['columns']['list_type']['config']['sortItems'] = [
+       'label' => 'asc'
+   ];
+
+   // Sort all items by value ("asc" or "desc" is possible)
+   $GLOBALS['TCA']['tt_content']['columns']['list_type']['config']['sortItems'] = [
+       'value' => 'desc'
+   ];
+
+   // Sort all items by a custom function
+   $GLOBALS['TCA']['tt_content']['columns']['list_type']['config']['sortItems'] = [
+       'My_Extension' => 'ksort'
+   ];
+
+   $GLOBALS['TCA']['tt_content']['columns']['list_type']['config']['sortItems'] = [
+       'My_Extension' => \VendorName\PackageName\TcaSorter::class . '->sortByMagic'
+   ];
+
+When using grouped select fields with "itemGroups", sorting happens on a
+per-group basis - all items within one group are sorted - as the group ordering
+is preserved.
+
+
+Impact
+======
+
+Plugins in FormEngine are now using this option in TYPO3 Core, and other TCA
+select fields can benefit from this as well.
+
+This option is solely built for display purposes in FormEngine.
+
+.. index:: TCA, ext:core

Documentation/Changelog/10.4/Feature-91080-SiteSettingsAsTsConstantsAndInTsConfig.rst

@@ -0,0 +1,77 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91080-1657827157:
+
+=======================================================================
+Feature: #91080 - Site settings as TypoScript constants and in TSconfig
+=======================================================================
+
+See :issue:`91080`
+See :issue:`91081`
+
+Description
+===========
+
+Prior to TYPO3 v10.0 it was possible to inject information from
+page TSconfig into TypoScript constants with :typoscript:`TSFE.constants.const1 = a`.
+
+This could be used to centralize configuration of e.g. record storagePids,
+which could then be used in Backend for modules or for IRRE and for Frontend plugins.
+
+This old feature has been removed, because it was recommended to add site settings.
+The according new feature added with TYPO3 v10 was reverted in v10.1 though.
+
+This re-implementation now allows to define site settings via :file:`config/sites/<site-name>/config.yml`
+
+The newly introduced settings inside :file:`config.yml` are made available
+as TypoScript constants and page TSconfig constants.
+
+An example configuration in the :file:`config/sites/<site-name>/config.yml`:
+
+.. code-block:: yaml
+
+   settings:
+     categoryPid: 658
+     styles:
+       content:
+         loginform:
+           pid: 23
+
+This will make these constants available in the template and in page TSconfig:
+
+*  :typoscript:`{$categoryPid}`
+*  :typoscript:`{$styles.content.loginform.pid}`
+
+The newly introduced constants for page TSconfig can be used just like constants
+in TypoScript.
+
+In page TSconfig this can be used like this:
+
+.. code-block:: typoscript
+
+   # store tx_ext_data records on the given storage page by default (e.g. through IRRE)
+   TCAdefaults.tx_ext_data.pid = {$categoryPid}
+   # load category selection for plugin from out dedicated storage page
+   TCEFORM.tt_content.pi_flexform.ext_pi1.sDEF.categories.PAGE_TSCONFIG_ID = {$categoryPid}
+
+
+.. note::
+
+   The TypoScript constants are now evaluated in this order:
+
+   #. Global :php:`'defaultTypoScript_constants'`
+   #. Site specific settings from the site configuration
+   #. Constants from sys_template database records
+
+
+Impact
+======
+
+It is now possible again to have a central place for configuration relevant
+for Backend and Frontend.
+
+For instance: It is now possible to define all page-uid related configuration centrally
+with the site configuration and get templates and page TSconfig independent
+of actual UIDs.
+
+.. index:: TypoScript, ext:core, ext:frontend, ext:backend

Documentation/Changelog/10.4/Feature-91122-IntroduceDocumentServiceAsJQueryreadySubstitute.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91122:
+
+======================================================================
+Feature: #91122 - Introduce DocumentService as JQuery.ready substitute
+======================================================================
+
+See :issue:`91122`
+
+Description
+===========
+
+The module :js:`TYPO3/CMS/Core/DocumentService` provides native JavaScript
+functions to detect DOM ready-state returning a :js:`Promise<Document>`.
+
+Internally the Promise is resolved when native :js:`DOMContentLoaded` event has
+been emitted or when :js:`document.readyState` is defined already. It means
+that initial HTML document has been completely loaded and parsed, without
+waiting for stylesheets, images, and subframes to finish loading.
+
+
+Impact
+======
+
+.. code-block:: javascript
+
+   $(document).ready(() => {
+     // your application code
+   });
+
+Above JQuery code can be transformed into the following using :js:`DocumentService`:
+
+.. code-block:: javascript
+
+   require(['TYPO3/CMS/Core/DocumentService'], function (DocumentService) {
+     DocumentService.ready().then(() => {
+       // your application code
+     });
+   });
+
+.. index:: Backend, JavaScript, ext:core

Documentation/Changelog/10.4/Important-18079-PagesdoktypeRestrictionForFrontendQueriesRefined.rst

@@ -0,0 +1,26 @@
+.. include:: /Includes.rst.txt
+
+.. _important-18079:
+
+==========================================================================
+Important: #18079 - pages.doktype restriction for frontend queries refined
+==========================================================================
+
+See :issue:`18079`
+
+Description
+===========
+
+Since over 15 years, TYPO3's Frontend rendering had a restriction to only allow
+pages with a "page type" (pages.doktype such as "Shortcut", "Link to external URL") to be limited to a fixed number less than 200.
+
+This meant that pages of certain types such as a Sys Folder and Recycler never were
+respected when fetching content from a specific page (via Typoscript) or querying records from there.
+
+This limitation has now been lifted in order to fix certain bugs,
+such as "content sliding" via TypoScript. But this also allows custom page doktypes to be used that have a number higher than 200.
+
+This could potentially result in unexpected behavior in TypoScript or content fetching, if the previous limited behavior was mis-used
+for certain purposes.
+
+.. index:: Frontend, TypoScript, ext:frontend

Documentation/Changelog/10.4/Important-77715-NoMorePasswordTrimmingForThird-partyAuthenticationServices.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _important-77715:
+
+=====================================================================================
+Important: #77715 - No more password trimming for third-party authentication services
+=====================================================================================
+
+See :issue:`77715`
+
+Description
+===========
+
+TYPO3's Authentication Service API allows third-party extensions
+to handle custom login / password data to authenticate against identity brokers
+via "OAuth", "LDAP" or "SAML2" now receive a given password (called `uident`)
+directly as given from the input value.
+
+Before TYPO3 v10 LTS, TYPO3's "AbstractUserAuthentication" object trimmed all incoming
+usernames and passwords, and afterwards handed the sanitized input values over
+to the Authentication Providers.
+
+This made it impossible to ever have passwords that included spaces at
+the beginning or the end of a given password.
+
+This behaviour is now changed, and only affects Third-Party Authentication
+providers - which can now decide to also trim passwords or keep them as is.
+
+This logic is mostly handled within :php:`processLoginData()`. If the Third-Party
+Authentication Provider is extending from Core's :php:`AuthenticationService` class and does
+not override the method, then the behaviour will still be the same as before.
+
+TYPO3's native Authentication Service still requires a password without spaces
+at the beginning or end, however it is now up to the Authentication Service to
+define what is possible or allowed.
+
+.. index:: PHP-API, ext:frontend

Documentation/Changelog/10.4/Important-86343-ReplaceJQueryDataTablesWithTablesort.rst

@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _important-86343:
+
+============================================================
+Important: #86343 - Replace jQuery.datatables with tablesort
+============================================================
+
+See :issue:`86343`
+
+Description
+===========
+
+In our effort to reduce the dependency to jQuery, the internally used JavaScript
+library ``jQuery.datatables`` has been replaced with ``tablesort``.
+
+Extensions relying on that internal library may be dysfunctional now.
+
+.. important::
+
+   Extension authors are encouraged to not use libraries that are not explicitly
+   marked as public API.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/10.4/Important-89555-Workspace-relatedDatabaseRecordsContainTheProperPageID.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _important-89555:
+
+==================================================================================
+Important: #89555 - Workspace-related database records contain the proper Page ID.
+==================================================================================
+
+See :issue:`89555`
+
+Description
+===========
+
+Back in 2006, when the workspaces functionality was added to TYPO3 v4.0, Kasper - the original author of TYPO3 - provided
+an easy way to put workspaces on top while not worrying about existing logic. Every record that wasn't published had
+the "pid" field set to "-1" - and thus was filtered out from any database query without having to worry about specific implementations.
+
+14 years later, we have Doctrine DBAL and the solution for "enableFields" has widely been replaced by Database Restrictions,
+allowing to modify database queries by TYPO3 Core without having to worry about custom queries.
+
+For workspaces however, it is and was very tedious to find the "real pid" for versioned records,
+and the "pid = -1" scenario is also one of the reasons why workspace overlays are more complex than they need to be.
+
+For this reason, TYPO3 Core now handles versioned records by validating their "t3ver_wsid" (the workspace ID the record is versioned in),
+"t3ver_state" (the type of the versioned record) and "t3ver_oid" (the live version of a record), and does not need to check for "pid=-1" anymore.
+
+This opens up a more straightforward approach to select and overlay
+records and reduce the need for some magic methods in TYPO3 Core,
+which still exist.
+
+An Upgrade Wizard transfers all "pid" fields of versioned records,
+into the real "pid" fields. TYPO3 Core now only checks for versionized records based on the other fields above.
+
+Please note: This only affects TYPO3 installations with workspaces enabled, and nothing should change for any extension if they use
+proper WorkspaceRestriction or Workspace Overlay mechanisms in TYPO3 v10.
+
+.. index:: Database, ext:workspaces

Documentation/Changelog/10.4/Important-90285-FreshInstallsWithoutConstraintForTypo3fluidfluidWillGetVersion30.rst

@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+.. _important-90285:
+
+================================================================================================
+Important: #90285 - Fresh installs without constraint for typo3fluid/fluid will get version 3.0+
+================================================================================================
+
+See :issue:`90285`
+
+Description
+===========
+
+Projects which have no dependencies that add a constraint on the maximum allowed version of Fluid
+will in the future download and install ``typo3fluid/fluid:^3``.
+
+The TYPO3 core is fully compatible with both major versions of Fluid and lets you choose between
+version ``2.6+`` or ``3.0+`` by constraining your project dependencies. However, some projects based
+on TYPO3 may contain Fluid templates or dependencies which are not compatible with Fluid 3.0, yet
+neglect to declare a maximum version constraint for Fluid - since until the release of version 3.0,
+the only/highest major version was 2.6 and ``composer install`` would therefore always select version
+``^2.6`` as it was the only option.
+
+If your project has no maximum version constraint and contains Fluid templates which are incompatible
+with version ``3.0+`` you will therefore need to take one of the following actions:
+
+* Either declare a maximum version constraint for ``typo3fluid/fluid:^2`` in the root project
+  ``composer.json`` or any dependency of the project that you control, and perform ``composer update``.
+* Or execute ``composer req typo3fluid/fluid:^2`` in the project directory to make the project itself
+  declare the maximum version constraint.
+
+.. index:: Fluid, ext:fluid

Documentation/Changelog/10.4/Important-90897-RemoveBootstrap-slider.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _important-90897:
+
+===========================================
+Important: #90897 - Remove bootstrap-slider
+===========================================
+
+See :issue:`90897`
+
+Description
+===========
+
+The internally used library `bootstrap-slider` has been removed. HTML input
+fields using `type="range"` are used as substitution.
+
+Extension relying on that internal library may be dysfunctional now.
+
+Example:
+
+.. code-block:: html
+
+   <div class="slider-wrapper">
+       <input type="range" class="slider" min="10" max="50" step="5">
+   </div>
+
+
+If the value of the `range` field is changed, the `input` event is emitted which
+can be listened to by registering an event listener.
+
+.. important::
+
+   Extension authors are encouraged to not use libraries that are not explicitly
+   marked as public API.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/10.4/Important-91079-VariousTypoScriptFrontendRendererFunctionalityIsNowInternal.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _important-91079:
+
+====================================================================================
+Important: #91079 - Various TypoScriptFrontendRenderer functionality is now internal
+====================================================================================
+
+See :issue:`91079`
+
+Description
+===========
+
+TypoScriptFrontendController has methods and properties which
+are marked as "@internal" in TYPO3 v10.
+
+They are still used in TYPO3 v10 from within TYPO3 Core, but
+extension authors should use the actual APIs directly.
+
+The properties
+
+* :php:`TypoScriptFrontendController->sPre`
+* :php:`TypoScriptFrontendController->pSetup`
+* :php:`TypoScriptFrontendController->all`
+
+are related to unpacking TypoScript details related
+to a page object in TypoScript and to its caching part,
+this is now officially marked as internal - if needed,
+TemplateService should be queried directly. These properties
+will likely be removed in future TYPO3 versions, in order to
+decouple TypoScript Parsing from the global `TSFE` object.
+
+The properties
+
+* :php:`TypoScriptFrontendController->additionalJavaScript`
+* :php:`TypoScriptFrontendController->additionalCSS`
+* :php:`TypoScriptFrontendController->JSCode`
+* :php:`TypoScriptFrontendController->inlineJS`
+
+and the method :php:`TypoScriptFrontendController->setJS()` are
+marked as internal. The AssetCollector API and the PageRenderer
+can be used instead, and TYPO3 Core will move towards these
+APIs completely internally.
+
+The property :php:`TypoScriptFrontendController->indexedDocTitle`
+is now marked as internal as the PageTitle API is in place since
+TYPO3 v9 LTS.
+
+.. index:: Frontend, ext:frontend

Documentation/Changelog/10.4/Important-91095-VariousMethodsAndPropertiesOfBackend-relatedCoreAPIsNowInternal.rst

@@ -0,0 +1,236 @@
+.. include:: /Includes.rst.txt
+
+.. _important-91095:
+
+============================================================================================
+Important: #91095 - Various methods and properties of Backend-related Core APIs now internal
+============================================================================================
+
+See :issue:`91095`
+
+Description
+===========
+
+Some cornerstones of TYPO3 Core have been kept and migrated since before TYPO3 v4.0. This was when PHP 5 and class visibility was not
+even available.
+
+Most classes contain various methods which have been marked as
+"public", making it public API for TYPO3, even though their usages
+should only be available for TYPO3 Core.
+
+All methods are now marked as "@internal", as official Core API
+should be used instead.
+
+:php:`DataHandler` class properties and methods: Except for the public methods
+that are still available, it is highly recommended to use DataHandler as defined in the official documentation.
+
+The following properties and methods are now marked as internal:
+
+* :php:`DataHandler->checkSimilar`
+* :php:`DataHandler->bypassWorkspaceRestrictions`
+* :php:`DataHandler->copyWhichTables`
+* :php:`DataHandler->defaultValues`
+* :php:`DataHandler->overrideValues`
+* :php:`DataHandler->data_disableFields`
+* :php:`DataHandler->callBackObj`
+* :php:`DataHandler->autoVersionIdMap`
+* :php:`DataHandler->substNEWwithIDs_table`
+* :php:`DataHandler->newRelatedIDs`
+* :php:`DataHandler->copyMappingArray_merged`
+* :php:`DataHandler->errorLog`
+* :php:`DataHandler->pagetreeRefreshFieldsFromPages`
+* :php:`DataHandler->pagetreeNeedsRefresh`
+* :php:`DataHandler->userid`
+* :php:`DataHandler->username`
+* :php:`DataHandler->admin`
+* :php:`DataHandler->sortIntervals`
+* :php:`DataHandler->dbAnalysisStore`
+* :php:`DataHandler->registerDBList`
+* :php:`DataHandler->registerDBPids`
+* :php:`DataHandler->copyMappingArray`
+* :php:`DataHandler->remapStack`
+* :php:`DataHandler->remapStackRecords`
+* :php:`DataHandler->updateRefIndexStack`
+* :php:`DataHandler->callFromImpExp`
+* :php:`DataHandler->checkValue_currentRecord`
+* :php:`DataHandler->setControl()`
+* :php:`DataHandler->setMirror()`
+* :php:`DataHandler->setDefaultsFromUserTS()`
+* :php:`DataHandler->hook_processDatamap_afterDatabaseOperations()`
+* :php:`DataHandler->placeholderShadowing()`
+* :php:`DataHandler->getPlaceholderTitleForTableLabel()`
+* :php:`DataHandler->fillInFieldArray()`
+* :php:`DataHandler->checkValue()`
+* :php:`DataHandler->checkValue_SW()`
+* :php:`DataHandler->checkValue_flexArray2Xml()`
+* :php:`DataHandler->checkValue_inline()`
+* :php:`DataHandler->checkValueForInline()`
+* :php:`DataHandler->checkValue_checkMax()`
+* :php:`DataHandler->getUnique()`
+* :php:`DataHandler->getRecordsWithSameValue()`
+* :php:`DataHandler->checkValue_text_Eval()`
+* :php:`DataHandler->checkValue_input_Eval()`
+* :php:`DataHandler->checkValue_group_select_processDBdata()`
+* :php:`DataHandler->checkValue_group_select_explodeSelectGroupValue()`
+* :php:`DataHandler->checkValue_flex_procInData()`
+* :php:`DataHandler->checkValue_flex_procInData_travDS()`
+* :php:`DataHandler->copyRecord()`
+* :php:`DataHandler->copyPages()`
+* :php:`DataHandler->copySpecificPage()`
+* :php:`DataHandler->copyRecord_raw()`
+* :php:`DataHandler->insertNewCopyVersion()`
+* :php:`DataHandler->copyRecord_flexFormCallBack()`
+* :php:`DataHandler->copyL10nOverlayRecords()`
+* :php:`DataHandler->moveRecord()`
+* :php:`DataHandler->moveRecord_raw()`
+* :php:`DataHandler->moveRecord_procFields()`
+* :php:`DataHandler->moveRecord_procBasedOnFieldType()`
+* :php:`DataHandler->moveL10nOverlayRecords()`
+* :php:`DataHandler->localize()`
+* :php:`DataHandler->deleteAction()`
+* :php:`DataHandler->deleteEl()`
+* :php:`DataHandler->deleteVersionsForRecord()`
+* :php:`DataHandler->undeleteRecord()`
+* :php:`DataHandler->deleteRecord()`
+* :php:`DataHandler->deletePages()`
+* :php:`DataHandler->canDeletePage()`
+* :php:`DataHandler->cannotDeleteRecord()`
+* :php:`DataHandler->isRecordUndeletable()`
+* :php:`DataHandler->deleteRecord_procFields()`
+* :php:`DataHandler->deleteRecord_procBasedOnFieldType()`
+* :php:`DataHandler->deleteL10nOverlayRecords()`
+* :php:`DataHandler->versionizeRecord()`
+* :php:`DataHandler->version_remapMMForVersionSwap()`
+* :php:`DataHandler->version_remapMMForVersionSwap_flexFormCallBack()`
+* :php:`DataHandler->version_remapMMForVersionSwap_execSwap()`
+* :php:`DataHandler->remapListedDBRecords()`
+* :php:`DataHandler->remapListedDBRecords_flexFormCallBack()`
+* :php:`DataHandler->remapListedDBRecords_procDBRefs()`
+* :php:`DataHandler->remapListedDBRecords_procInline()`
+* :php:`DataHandler->processRemapStack()`
+* :php:`DataHandler->addRemapAction()`
+* :php:`DataHandler->addRemapStackRefIndex()`
+* :php:`DataHandler->getVersionizedIncomingFieldArray()`
+* :php:`DataHandler->checkModifyAccessList()`
+* :php:`DataHandler->isRecordInWebMount()`
+* :php:`DataHandler->isInWebMount()`
+* :php:`DataHandler->checkRecordUpdateAccess()`
+* :php:`DataHandler->checkRecordInsertAccess()`
+* :php:`DataHandler->isTableAllowedForThisPage()`
+* :php:`DataHandler->doesRecordExist()`
+* :php:`DataHandler->doesBranchExist()`
+* :php:`DataHandler->tableReadOnly()`
+* :php:`DataHandler->tableAdminOnly()`
+* :php:`DataHandler->destNotInsideSelf()`
+* :php:`DataHandler->getExcludeListArray()`
+* :php:`DataHandler->doesPageHaveUnallowedTables()`
+* :php:`DataHandler->pageInfo()`
+* :php:`DataHandler->recordInfo()`
+* :php:`DataHandler->getRecordProperties()`
+* :php:`DataHandler->getRecordPropertiesFromRow()`
+* :php:`DataHandler->eventPid()`
+* :php:`DataHandler->updateDB()`
+* :php:`DataHandler->insertDB()`
+* :php:`DataHandler->checkStoredRecord()`
+* :php:`DataHandler->setHistory()`
+* :php:`DataHandler->updateRefIndex()`
+* :php:`DataHandler->getSortNumber()`
+* :php:`DataHandler->newFieldArray()`
+* :php:`DataHandler->addDefaultPermittedLanguageIfNotSet()`
+* :php:`DataHandler->overrideFieldArray()`
+* :php:`DataHandler->compareFieldArrayWithCurrentAndUnset()`
+* :php:`DataHandler->convNumEntityToByteValue()`
+* :php:`DataHandler->deleteClause()`
+* :php:`DataHandler->getTableEntries()`
+* :php:`DataHandler->getPID()`
+* :php:`DataHandler->dbAnalysisStoreExec()`
+* :php:`DataHandler->int_pageTreeInfo()`
+* :php:`DataHandler->compileAdminTables()`
+* :php:`DataHandler->fixUniqueInPid()`
+* :php:`DataHandler->fixCopyAfterDuplFields()`
+* :php:`DataHandler->isReferenceField()`
+* :php:`DataHandler->getInlineFieldType()`
+* :php:`DataHandler->getCopyHeader()`
+* :php:`DataHandler->prependLabel()`
+* :php:`DataHandler->resolvePid()`
+* :php:`DataHandler->clearPrefixFromValue()`
+* :php:`DataHandler->isRecordCopied()`
+* :php:`DataHandler->log()`
+* :php:`DataHandler->newlog()`
+* :php:`DataHandler->printLogErrorMessages()`
+* :php:`DataHandler->insertUpdateDB_preprocessBasedOnFieldType()`
+* :php:`DataHandler->hasDeletedRecord()`
+* :php:`DataHandler->getAutoVersionId()`
+* :php:`DataHandler->getHistoryRecords()`
+
+The reason for this long list is this: If the DataHandler API is
+not called via :php:`start()` and the :php:`process_*`  methods, but rather
+the methods would be called directly, certain hooks would be disabled completely, resulting in a huge data inconsistency.
+
+At this point, it is highly recommended to use the official API
+of :php:`DataHandler` as written in the main documentation.
+
+Various :php:`BackendUtility` class methods are called statically, but cannot
+guarantee any Context. Short-hand functions for TCA or Database
+Queries are now better suited by using the appropriate Database
+Restrictions.
+
+* :php:`BackendUtility::purgeComputedPropertiesFromRecord()`
+* :php:`BackendUtility::purgeComputedPropertyNames()`
+* :php:`BackendUtility::splitTable_Uid()`
+* :php:`BackendUtility::BEenableFields()`
+* :php:`BackendUtility::openPageTree()`
+* :php:`BackendUtility::getUserNames()`
+* :php:`BackendUtility::getGroupNames()`
+* :php:`BackendUtility::blindUserNames()`
+* :php:`BackendUtility::blindGroupNames()`
+* :php:`BackendUtility::getCommonSelectFields()`
+* :php:`BackendUtility::helpTextArray()`
+* :php:`BackendUtility::helpText()`
+* :php:`BackendUtility::wrapInHelp()`
+* :php:`BackendUtility::softRefParserObj()`
+* :php:`BackendUtility::explodeSoftRefParserList()`
+* :php:`BackendUtility::selectVersionsOfRecord()`
+* :php:`BackendUtility::fixVersioningPid()`
+* :php:`BackendUtility::movePlhOL()`
+* :php:`BackendUtility::getLiveVersionIdOfRecord()`
+* :php:`BackendUtility::versioningPlaceholderClause()`
+* :php:`BackendUtility::getWorkspaceWhereClause()`
+* :php:`BackendUtility::wsMapId()`
+* :php:`BackendUtility::getMovePlaceholder()`
+* :php:`BackendUtility::getBackendScript()`
+* :php:`BackendUtility::getWorkspaceWhereClause()`
+
+
+:php:`BackendUserAuthentication` a.k.a. :php:`$GLOBALS['BE_USER']` contains a lot of internal calls and properties which are only
+used for within TYPO3 Core or to keep state. This should not
+be exposed in the future anymore, especially when a more flexible
+permission system might get introduced. The affected properties
+and methods are:
+
+* :php:`BackendUserAuthentication->includeGroupArray`
+* :php:`BackendUserAuthentication->errorMsg`
+* :php:`BackendUserAuthentication->sessionTimeout`
+* :php:`BackendUserAuthentication->firstMainGroup`
+* :php:`BackendUserAuthentication->uc_default`
+* :php:`BackendUserAuthentication->isMemberOfGroup()`
+* :php:`BackendUserAuthentication->getPagePermsClause()`
+* :php:`BackendUserAuthentication->isRTE()`
+* :php:`BackendUserAuthentication->recordEditAccessInternals()`
+* :php:`BackendUserAuthentication->workspaceCannotEditRecord()`
+* :php:`BackendUserAuthentication->workspaceAllowLiveRecordsInPID()`
+* :php:`BackendUserAuthentication->workspaceAllowsLiveEditingInTable()`
+* :php:`BackendUserAuthentication->workspaceCreateNewRecord()`
+* :php:`BackendUserAuthentication->workspaceCanCreateNewRecord()`
+* :php:`BackendUserAuthentication->workspaceAllowAutoCreation()`
+* :php:`BackendUserAuthentication->workspaceCheckStageForCurrent()`
+* :php:`BackendUserAuthentication->workspaceInit()`
+* :php:`BackendUserAuthentication->checkWorkspace()`
+* :php:`BackendUserAuthentication->checkWorkspaceCurrent()`
+* :php:`BackendUserAuthentication->setWorkspace()`
+* :php:`BackendUserAuthentication->setTemporaryWorkspace()`
+* :php:`BackendUserAuthentication->setDefaultWorkspace()`
+* :php:`BackendUserAuthentication->getDefaultWorkspace()`
+* :php:`BackendUserAuthentication->checkLockToIP()`
+
+.. index:: Backend, PHP-API, ext:backend

Documentation/Changelog/10.4/Important-91099-ChangedFlagIdentifierForEngland.rst

@@ -0,0 +1,21 @@
+.. include:: /Includes.rst.txt
+
+.. _important-91099:
+
+====================================================================
+Important: #91099 - Flag identifier changed for SiteLanguage England
+====================================================================
+
+See :issue:`91099`
+
+Description
+===========
+
+The flag identifier for England ("england") in the SiteLanguage was broken and resulted
+in a broken icon in the backend.
+To fix that issue the identifier has been changed ("gb-eng") and results in a proper icon.
+
+If you used this flag identifier in your Frontend setup, double check whether things are
+still working as desired.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/10.4/Index.rst

@@ -0,0 +1,53 @@
+:template: changelogOverview.html
+.. include:: /Includes.rst.txt
+..  _changelog-10-4:
+
+10.4 Changes
+=============
+
+**Table of contents**
+
+.. contents::
+   :local:
+   :depth: 1
+
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Breaking-*
+
+Features
+^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Feature-*
+
+Deprecation
+^^^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Deprecation-*
+
+Important
+^^^^^^^^^
+
+.. toctree::
+   :maxdepth: 1
+   :titlesonly:
+   :glob:
+
+   Important-*