TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/12.0/Breaking-87616-RemovedHookForAlteringPageLinks.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87616:
+
+=======================================================
+Breaking: #87616 - Removed hook for altering page links
+=======================================================
+
+See :issue:`87616`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typolinkProcessing']['typolinkModifyParameterForPageLinks']`
+has been removed in favor of a new PSR-14 event :php:`TYPO3\CMS\Frontend\Event\ModifyPageLinkConfigurationEvent`.
+
+The event is called after TYPO3 has already prepared some functionality
+within the :php:`PageLinkBuilder`. This therefore allows to modify more
+properties, if needed.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore
+in TYPO3 v12.0+.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-87616-PSR-14EventForModifyingPageLinkGeneration>`
+to allow greater influence in the functionality.
+
+.. index:: Frontend, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-90044-ConfigspamProtectEmailAddressesWithOptionAsciiRemoved.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-90044:
+
+===============================================================================
+Breaking: #90044 - config.spamProtectEmailAddresses with option "ascii" removed
+===============================================================================
+
+See :issue:`90044`
+
+Description
+===========
+
+The TypoScript setting :typoscript:`config.spamProtectEmailAddresses` set to `ascii` has no
+effect anymore as the ASCII-encryption feature has been removed.
+
+The option changed any links to emails like `href="mailto:benni@example.com"`
+to point to the ASCII-encoded equivalent. Since all browsers (and most bots/crawlers)
+do this automatically and instantly this feature has no spam-protection
+relevance anymore.
+
+Impact
+======
+
+Setting the option to `ascii` has no effect anymore, which is the same as not
+setting the option at all. However, in case the option is set to `ascii` a
+PHP :php:`E_USER_DEPRECATED` error is raised.
+
+Affected Installations
+======================
+
+TYPO3 installations having this option set in their TypoScript setup.
+
+Migration
+=========
+
+In case you still want to keep an email SPAM protection around, it is recommended
+to set the option :typoscript:`config.spamProtectEmailAddresses` to a numeric value between
+`-10` and `10`.
+
+Alternatively, there is an extension called `emailobfuscator` available in the
+TYPO3 Extension Repository, which also aims to achieve a similar behaviour.
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-92508-RemovedHookForFilteringHMENUItems.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92508:
+
+=========================================================
+Breaking: #92508 - Removed hook for filtering HMENU items
+=========================================================
+
+See :issue:`92508`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms/tslib/class.tslib_menu.php']['filterMenuPages']`
+has been removed in favor of a new PSR-14 event :php:`TYPO3\CMS\Frontend\Event\FilterMenuItemsEvent`.
+
+The event is called with all menu items instead of operating on
+one single item.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore
+in TYPO3 v12.0+.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom menus using this hook.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-92508-PSR-14EventForModifyingMenuItems>`
+to allow greater influence in the functionality.
+
+.. index:: Frontend, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-93182-ChangedFileExtensionForGzipCompressedFiles.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93182-1651654104:
+
+===================================================================
+Breaking: #93182 - Changed file extension for gzip compressed files
+===================================================================
+
+See :issue:`93182`
+
+Description
+===========
+
+When using file compression for resources such as JavaScript or
+StyleSheets via :php:`$GLOBALS[TYPO3_CONF_VARS][FE][compressionLevel]` or
+:php:`$GLOBALS[TYPO3_CONF_VARS][BE][compressionLevel]` the generated files are
+now written via the file extension ".gz" instead of ".gzip" in previous versions.
+
+TYPO3 follows the de-facto standard for compressed assets,
+as ".gz" is much more widespread than ".gzip" file extensions
+(see https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types).
+
+Impact
+======
+
+Compressed resources are now generated and served via ".gz".
+
+Affected installations
+======================
+
+TYPO3 installations setting the global configuration option.
+
+Migration
+=========
+
+Adapt possible :file:`.htaccess` or other webserver configuration files
+by replacing ".gzip" with ".gz" if this feature is activated.
+
+.. index:: Backend, Frontend, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-94117-RegisterExtbaseTypeConvertersAsServices.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-94117:
+
+===============================================================
+Breaking: #94117 - Register Extbase type converters as services
+===============================================================
+
+See :issue:`94117`
+
+Description
+===========
+
+Extbase type converters are used to convert from a simple type to an
+object or another simple type. The registration of those type converters
+is no longer done via :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerTypeConverter()`,
+but via container services in the extension's :file:`Services.yaml` file.
+
+As a side effect, the type converter configuration such as `sourceType` or
+`targetType` has been moved from the :php:`TypeConverterInterface` to the
+service container configuration.
+
+Impact
+======
+
+Type converters registered via :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerTypeConverter()`
+are no longer evaluated.
+
+The :php:`TypeConverterInterface` does no longer define the configuration
+related methods:
+
+- :php:`getSupportedSourceTypes()`
+- :php:`getSupportedTargetType()`
+- :php:`getPriority()`
+- :php:`canConvertFrom()`
+
+Affected Installations
+======================
+
+All installations that do not register type converters via :php:`Services.yaml`.
+
+All installations, which rely on the configuration related methods, being
+defined in the :php:`TypeConverterInterface`.
+
+Migration
+=========
+
+Remove registration via :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerTypeConverter()`
+from your :file:`ext_localconf.php` file and register the type converters
+in your :php:`Services.yaml` instead. See :doc:`changelog <../12.0/Feature-94117-ImproveExtbaseTypeConverterRegistration>`
+for an example.
+
+Remove any call to the configuration related methods, see the
+:doc:`deprecation changelog <../12.0/Deprecation-94117-RegisterExtbaseTypeConvertersAsServices>`
+for more information.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/12.0/Breaking-94243-SendUserSessionCookiesAsHash-signedJWT.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-94243-1664786038:
+
+===============================================================
+Breaking: #94243 - Send user session cookies as hash-signed JWT
+===============================================================
+
+See :issue:`94243`
+
+Description
+===========
+
+`JSON Web Tokens (JWT) <https://jwt.io/>`__ are used to transport user session
+identifiers in `be_typo_user` and `fe_typo_user` cookies. Using JWT's `HS256`
+(HMAC signed based on SHA256) allows to determine whether a session cookie is
+valid before comparing with server-side stored session data. This enhances the
+overall performance a bit, since sessions cookies would be checked for every
+request to TYPO3's backend and frontend.
+
+JWT handling in PHP is provided by 3rd party package
+`firebase/php-jwt <https://packagist.org/packages/firebase/php-jwt>`__.
+
+
+Impact
+======
+
+Session cookies `be_typo_user` and `fe_typo_user` can be pre-validated without
+querying the database, which can filter invalid requests and might reduce the
+enhances the overall performance a bit.
+
+As a consequence session tokens are not sent "as is" anymore, but are
+wrapped in a corresponding JWT message, which contains the following payload:
+
+* `identifier` reflects the actual session identifier
+* `time` reflects the time of creating the cookie (RFC 3339 format)
+
+
+Affected installations
+======================
+
+All instances using TYPO3 v12 and having custom implementations handling `be_typo_user`
+and `fe_typo_user` cookie values.
+
+
+Migration
+=========
+
+Custom implementations handling `be_typo_user` or `fe_typo_user` cookies,
+have to use the introduced method :php:`\TYPO3\CMS\Core\Session\UserSession::getJwt()`
+instead of existing :php:`\TYPO3\CMS\Core\Session\UserSession::getIdentifier()`.
+
+
+.. index:: Backend, Frontend, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-95132-SetPasswordForgotHashBasedOnUserUidInExtfelogin.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-95132-1659375274:
+
+============================================================================
+Breaking: #95132 - Set password forgot hash based on user uid in ext:felogin
+============================================================================
+
+See :issue:`95132`
+
+Description
+===========
+
+The signature of the :php:`sendRecoveryEmail()` function in the
+:php:`TYPO3\CMS\FrontendLogin\Service\RecoveryService` has changed. The function
+now requires 2 arguments in order to support scenarios for multi-site TYPO3
+setups with multiple storage folders for users with the same email address.
+
+Additionally, the :php:`RecoveryService` class now does not implement
+:php:`TYPO3\CMS\FrontendLogin\Service\RecoveryServiceInterface` any more, since
+the interface has been removed.
+
+Impact
+======
+
+3rd party extensions implementing :php:`RecoveryService` have to be adapted
+manually to support the new function signature.
+
+3rd party extensions implementing :php:`RecoveryServiceInterface` have to be
+adapted manually to extend :php:`RecoveryService` instead.
+
+Affected installations
+======================
+
+3rd party extensions implementing :php:`RecoveryService` and
+:php:`RecoveryServiceInterface`.
+
+Migration
+=========
+
+Custom implementations of :php:`RecoveryService` must be adopted to support the new
+function signature :php:`sendRecoveryEmail(array $userData, string $hash)`.
+
+Custom implementations of :php:`RecoveryServiceInterface` must be adopted to
+extend :php:`RecoveryService` instead.
+
+.. index:: Frontend, PHP-API, NotScanned, ext:felogin

Documentation/Changelog/12.0/Breaking-96041-ToolbarItemsRegisterByTag.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96041:
+
+=================================================
+Breaking: #96041 - Toolbar items: Register by tag
+=================================================
+
+See :issue:`96041`
+
+Description
+===========
+
+Toolbar items implementing :php:`\TYPO3\CMS\Backend\Toolbar\ToolbarItemInterface` are now automatically
+registered by adding the tag :yaml:`backend.toolbar.item`, if :yaml:`autoconfigure`
+is enabled in :file:`Services.yaml`.
+
+Impact
+======
+
+The registration via :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['toolbarItems']` isn't evaluated anymore.
+
+Affected Installations
+======================
+
+Every extension, that adds toolbar items via :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['toolbarItems']`
+in its :file:`ext_localconf.php` file.
+
+Migration
+=========
+
+Remove :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['toolbarItems']` from your :file:`ext_localconf.php` file.
+If :yaml:`autoconfigure` is not enabled in your :file:`Configuration/Services.(yaml|php)`, add the tag :yaml:`backend.toolbar.item` to your toolbar item class.
+
+Example:
+
+..  code-block:: yaml
+
+    VENDOR\Extension\ToolbarItem\YourAdditionalToolbarItem:
+      tags:
+        - name: backend.toolbar.item
+
+.. index:: Backend, LocalConfiguration, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96044-HardenMethodSignatureOfLogicalAndAndLogicalOr.rst

@@ -0,0 +1,85 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96044:
+
+==========================================================================
+Breaking: #96044 - Harden method signature of logicalAnd() and logicalOr()
+==========================================================================
+
+See :issue:`96044`
+
+Description
+===========
+
+The method signature of :php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface::logicalAnd()`
+and :php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface::logicalOr()` has changed.
+As a consequence the method signature of :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Query::logicalAnd()`
+and :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Query::logicalOr()` has changed as well.
+
+Both methods do no longer accept an array as first parameter.
+
+Both methods do indeed accept an infinite number of further constraints.
+
+The :php:`logicalAnd()` method does now reliably return an instance of
+:php:`\TYPO3\CMS\Extbase\Persistence\Generic\Qom\AndInterface` instance
+while the :php:`logicalOr()` method returns a :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Qom\OrInterface`
+instance.
+
+Impact
+======
+
+This change impacts all usages of said methods with just one array parameter containing all constraints.
+
+Affected Installations
+======================
+
+All installations that passed all constraints as array.
+
+Migration
+=========
+
+The migration is the same for :php:`logicalAnd()` and :php:`logicalOr()`
+since their method signature is the same. The upcoming example will show a
+migration for a :php:`logicalAnd()` call.
+
+**Example**:
+
+..  code-block:: php
+
+    $query = $this->createQuery();
+    $query->matching($query->logicalAnd([
+        $query->equals('propertyName1', 'value1'),
+        $query->equals('propertyName2', 'value2'),
+        $query->equals('propertyName3', 'value3'),
+    ]));
+
+In this case an array is used as one and only method argument. The migration is
+easy and quickly done. Simply don't use an array:
+
+..  code-block:: php
+
+    $query = $this->createQuery();
+    $query->matching($query->logicalAnd(
+        $query->equals('propertyName1', 'value1'),
+        $query->equals('propertyName2', 'value2'),
+        $query->equals('propertyName3', 'value3'),
+    ));
+
+Alternatively you can use the spread operator :php:`...` to expand your array to arguments:
+
+..  code-block:: php
+
+    $query = $this->createQuery();
+    $arrayOfConditions = [];
+    $arrayOfConditions[] = $query->equals('propertyName1', 'value1');
+    $arrayOfConditions[] = $query->equals('propertyName2', 'value2');
+    $arrayOfConditions[] = $query->equals('propertyName3', 'value3');
+    $query->matching($query->logicalAnd(...$arrayOfConditions));
+
+..  tip::
+
+    Wrapping the array to spread into :php:`logicalAnd()` using :php:`array_values()` avoids
+    spreading associative array element keys as as named arguments, for example:
+    :php:`$query->matching($query->logicalAnd(...array_values($arrayOfConditions)));`
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/12.0/Breaking-96094-ModuleIconsRemoved.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96094:
+
+=======================================
+Breaking: #96094 - Module icons removed
+=======================================
+
+See :issue:`96094`
+
+Description
+===========
+
+The following module icons are removed as they are not needed anymore
+by TYPO3 itself. You can find the according icon identifier in parenthesis.
+
+*  :file:`EXT:backend/Resources/Public/Icons/module-about.svg` (`module-about`)
+*  :file:`EXT:backend/Resources/Public/Icons/module-contentelements.svg` (`module-contentelements`)
+*  :file:`EXT:backend/Resources/Public/Icons/module-cshmanual.svg` (`module-cshmanual`)
+*  :file:`EXT:backend/Resources/Public/Icons/module-page.svg` (`module-page`)
+*  :file:`EXT:backend/Resources/Public/Icons/module-sites.svg` (`module-sites`)
+*  :file:`EXT:backend/Resources/Public/Icons/module-templates.svg` (`module-templates`)
+*  :file:`EXT:backend/Resources/Public/Icons/module-urls.svg` (`module-urls`)
+*  :file:`EXT:belog/Resources/Public/Icons/module-belog.svg` (`module-belog`)
+*  :file:`EXT:beuser/Resources/Public/Icons/module-beuser.svg` (`module-beuser`)
+*  :file:`EXT:beuser/Resources/Public/Icons/module-permission.svg` (`module-permission`)
+*  :file:`EXT:extensionmanager/Resources/Public/Icons/module-extensionmanager.svg` (`module-extensionmanager`)
+*  :file:`EXT:filelist/Resources/Public/Icons/module-filelist.svg` (`module-filelist`)
+*  :file:`EXT:form/Resources/Public/Icons/module-form.svg` (`module-form`)
+*  :file:`EXT:indexed_search/Resources/Public/Icons/module-indexed_search.svg` (`module-indexed_search`)
+*  :file:`EXT:info/Resources/Public/Icons/module-info.svg` (`module-info`)
+*  :file:`EXT:lowlevel/Resources/Public/Icons/module-config.svg` (`module-config`)
+*  :file:`EXT:lowlevel/Resources/Public/Icons/module-dbint.svg` (`module-dbint`)
+*  :file:`EXT:recordlist/Resources/Public/Icons/module-list.svg` (`module-list`)
+*  :file:`EXT:recycler/Resources/Public/Icons/module-recycler.svg` (`module-recycler`)
+*  :file:`EXT:reports/Resources/Public/Icons/module-reports.svg` (`module-reports`)
+*  :file:`EXT:scheduler/Resources/Public/Icons/module-scheduler.svg` (`module-scheduler`)
+*  :file:`EXT:setup/Resources/Public/Icons/module-setup.svg` (`module-setup`)
+*  :file:`EXT:tstemplate/Resources/Public/Icons/module-tstemplate.svg` (`module-tstemplate`)
+*  :file:`EXT:viewpage/Resources/Public/Icons/module-viewpage.svg` (`module-viewpage`)
+*  :file:`EXT:workspaces/Resources/Public/Icons/module-workspaces.svg` (`module-workspaces`)
+
+Impact
+======
+
+The mentioned icons are removed, any usage by path will result in a broken
+image.
+
+Affected Installations
+======================
+
+Third-party TYPO3 extensions using these icons.
+
+Migration
+=========
+
+Use the already available icon identifiers from `TYPO3.Icons <https://typo3.github.io/TYPO3.Icons/>`_.
+The module icons are all registered automatically by the IconRegistry.
+In Fluid you can render them by calling :html:`<core:icon identifier="module-icon">`.
+In case you need the SVG file directly, download it from the above-mentioned
+icon repository page.
+
+.. index:: Backend, NotScanned

Documentation/Changelog/12.0/Breaking-96107-DeprecatedFunctionalityRemoved.rst

@@ -0,0 +1,446 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96107:
+
+===================================================
+Breaking: #96107 - Deprecated functionality removed
+===================================================
+
+See :issue:`96107`
+
+Description
+===========
+
+The following PHP classes that have previously been marked as deprecated for v11 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\View\BackendTemplateView`
+- :php:`\TYPO3\CMS\Core\Cache\Backend\PdoBackend`
+- :php:`\TYPO3\CMS\Core\Cache\Backend\WincacheBackend`
+- :php:`\TYPO3\CMS\Core\Category\CategoryRegistry`
+- :php:`\TYPO3\CMS\Core\Database\QueryGenerator`
+- :php:`\TYPO3\CMS\Core\Database\QueryView`
+- :php:`\TYPO3\CMS\Core\Database\SoftReferenceIndex`
+- :php:`\TYPO3\CMS\Core\Service\AbstractService`
+- :php:`\TYPO3\CMS\Extbase\Annotation\Inject`
+- :php:`\TYPO3\CMS\Extbase\Configuration\Exception\ParseErrorException`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\BackendUser`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\BackendUserGroup`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\FrontendUser`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\FrontendUserGroup`
+- :php:`\TYPO3\CMS\Extbase\Domain\Repository\BackendUserGroupRepository`
+- :php:`\TYPO3\CMS\Extbase\Domain\Repository\BackendUserRepository`
+- :php:`\TYPO3\CMS\Extbase\Domain\Repository\CategoryRepository`
+- :php:`\TYPO3\CMS\Extbase\Domain\Repository\FrontendUserGroupRepository`
+- :php:`\TYPO3\CMS\Extbase\Domain\Repository\FrontendUserRepository`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ControllerContext`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Exception\InvalidRequestMethodException`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Exception\StopActionException`
+- :php:`\TYPO3\CMS\Extbase\Mvc\View\AbstractView`
+- :php:`\TYPO3\CMS\Extbase\Mvc\View\EmptyView`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\ReferringRequest`
+- :php:`\TYPO3\CMS\Extbase\Object\Container\Container`
+- :php:`\TYPO3\CMS\Extbase\Object\Container\Exception\UnknownObjectException`
+- :php:`\TYPO3\CMS\Extbase\Object\Exception`
+- :php:`\TYPO3\CMS\Extbase\Object\Exception\CannotBuildObjectException`
+- :php:`\TYPO3\CMS\Extbase\Object\Exception\CannotReconstituteObjectException`
+- :php:`\TYPO3\CMS\Extbase\Object\ObjectManager`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Exception\InvalidNumberOfConstraintsException`
+- :php:`\TYPO3\CMS\Extbase\Service\EnvironmentService`
+- :php:`\TYPO3\CMS\Extbase\SignalSlot\Dispatcher`
+- :php:`\TYPO3\CMS\Extbase\SignalSlot\Exception\InvalidSlotException`
+- :php:`\TYPO3\CMS\Extbase\SignalSlot\Exception\InvalidSlotReturnException`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\EditPanelContentObject`
+
+The following PHP classes have been declared final:
+
+- All Fluid ViewHelpers
+
+The following PHP interfaces that have previously been marked as deprecated for v11 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\Toolbar\ClearCacheActionsHookInterface`
+- :php:`\TYPO3\CMS\Core\Database\TableConfigurationPostProcessingHookInterface`
+- :php:`\TYPO3\CMS\Core\Resource\Hook\FileDumpEIDHookInterface`
+- :php:`\TYPO3\CMS\Core\Utility\File\ExtendedFileUtilityProcessDataHookInterface`
+- :php:`\TYPO3\CMS\Extbase\Mvc\View\ViewInterface`
+- :php:`\TYPO3\CMS\Extbase\Object\ObjectManagerInterface`
+- :php:`\TYPO3\CMS\Extbase\Persistence\ForwardCompatibleQueryInterface`
+- :php:`\TYPO3\CMS\Extbase\Persistence\ForwardCompatibleQueryResultInterface`
+- :php:`\TYPO3\CMS\Filelist\FileListEditIconHookInterface'`
+- :php:`\TYPO3\CMS\Recordlist\RecordList\RecordListHookInterface`
+
+The following PHP interfaces changed:
+
+- :php:`\TYPO3\CMS\Core\Collection\CollectionInterface` (no longer extends \Serializable)
+- :php:`\TYPO3\CMS\Core\Resource\FolderInterface` (method :php:`getFile()` added)
+- :php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface` (method :php:`setType()` added)
+- :php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface->logicalAnd` (all arguments are now type hinted as `ConstraintInterface`)
+- :php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface->logicalOr` (all arguments are now type hinted as `ConstraintInterface`)
+- :php:`\TYPO3\CMS\Extbase\Persistence\QueryResultInterface` (method :php:`setQuery()` added)
+- :php:`\TYPO3\CMS\Form\Domain\Finishers\FinisherInterface` (method :php:`setFinisherIdentifier()` added)
+- :php:`\TYPO3\CMS\Frontend\ContentObject\Exception\ExceptionHandlerInterface` (method :php:`setConfiguration()` added)
+
+The following PHP class methods that have previously been marked as deprecated for v11 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\Form\FormDataProvider\AbstractItemProvider->addItemsFromSpecial()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\AbstractControl->getOnClick'()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\AbstractControl->setOnClick'()`
+- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->getIconFactory()`
+- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->getPageRenderer()`
+- :php:`\TYPO3\CMS\Backend\Domain\Module\BackendModule->setNavigationFrameScript()`
+- :php:`\TYPO3\CMS\Backend\Domain\Module\BackendModule->getNavigationFrameScript()`
+- :php:`\TYPO3\CMS\Backend\Domain\Module\BackendModule->setNavigationFrameScriptParameters()`
+- :php:`\TYPO3\CMS\Backend\Domain\Module\BackendModule->getNavigationFrameScriptParameters()`
+- :php:`\TYPO3\CMS\Backend\Domain\Module\BackendModule->setOnClick()`
+- :php:`\TYPO3\CMS\Backend\Domain\Module\BackendModule->getOnClick()`
+- :php:`\TYPO3\CMS\Backend\View\Event\AbstractSectionMarkupGeneratedEvent->getPageLayoutView()`
+- :php:`\TYPO3\CMS\Backend\View\Event\AbstractSectionMarkupGeneratedEvent->getLanguageId()`
+- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->createSessionId()`
+- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->fetchUserSession()`
+- :php:`\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools->getArrayValueByPath()`
+- :php:`\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools->setArrayValueByPath()`
+- :php:`\TYPO3\CMS\Core\Database\ReferenceIndex->disableRuntimeCache()`
+- :php:`\TYPO3\CMS\Core\Database\ReferenceIndex->enableRuntimeCache()`
+- :php:`\TYPO3\CMS\Core\Database\RelationHandler->setUpdateReferenceIndex()`
+- :php:`\TYPO3\CMS\Core\Database\RelationHandler->remapMM()`
+- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository->fixVersioningPid()`
+- :php:`\TYPO3\CMS\Core\Resource\Event\GeneratePublicUrlForResourceEvent->isRelativeToCurrentScript()`
+- :php:`\TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider->getRootUid()`
+- :php:`\TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider->setRootUid()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController->buildControllerContext()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController->getControllerContext()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController->forward()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Request->getBaseUri()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Request->getRequestUri()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Request->isDispatched()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Request->setDispatched()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\View\JsonView->setControllerContext()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->setAddQueryStringMethod()`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->getLanguageMode()`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->setLanguageMode()`
+- :php:`\TYPO3\CMS\Fluid\Core\Rendering\RenderingContext->getControllerContext()`
+- :php:`\TYPO3\CMS\Fluid\Core\Rendering\RenderingContext->setControllerContext()`
+- :php:`\TYPO3\CMS\Fluid\View\AbstractTemplateView->setControllerContext()`
+- :php:`\TYPO3\CMS\Form\Domain\Renderer\AbstractElementRenderer->setControllerContext()`
+- :php:`\TYPO3\CMS\Form\Domain\Renderer\RendererInterface->setControllerContext()`
+- :php:`\TYPO3\CMS\Form\Domain\Runtime\FormRuntime->getControllerContext()`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->editIcons()`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->editPanel()`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->isDisabled()`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->stdWrap_editIcons()`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->stdWrap_editPanel()`
+- :php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin->pi_getEditPanel()`
+- :php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin->pi_getEditIcon()`
+
+The following PHP static class methods that have previously been marked as deprecated for v11 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::explodeSoftRefParserList()`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::fixVersioningPid()`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::softRefParserObj()`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::viewOnClick`
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService::create()`
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService::createFromSiteLanguage()`
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService::createFromUserPreferences()`
+- :php:`\TYPO3\CMS\Core\Resource\Index\ExtractorRegistry::getInstance()`
+- :php:`\TYPO3\CMS\Core\Resource\Index\FileIndexRepository::getInstance()`
+- :php:`\TYPO3\CMS\Core\Resource\Index\MetaDataRepository::getInstance()`
+- :php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelperRegistry::getInstance()`
+- :php:`\TYPO3\CMS\Core\Resource\Rendering\RendererRegistry::getInstance()`
+- :php:`\TYPO3\CMS\Core\Resource\TextExtraction\TextExtractorRegistry::getInstance()`
+- :php:`\TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->doSyntaxHighlight()`
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::compileSelectedGetVarsFromArray()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::hideIfNotTranslated()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::hideIfDefaultLanguage()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::isAbsPath()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedHostHeaderValue()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::isFirstPartOfStr()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::minifyJavaScript()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::rmFromList()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::shortMD5()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::stdAuthCode()`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::uniqueList()`
+- :php:`\TYPO3\CMS\Core\Utility\HttpUtility::redirect()`
+- :php:`\TYPO3\CMS\Core\Utility\HttpUtility::setResponseCode()`
+- :php:`\TYPO3\CMS\Core\Utility\HttpUtility::setResponseCodeAndExit()`
+- :php:`\TYPO3\CMS\Core\Utility\StringUtility::beginsWith()`
+- :php:`\TYPO3\CMS\Core\Utility\StringUtility::endsWith()`
+- :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::getControllerClassName()`
+- :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::resolveVendorFromExtensionAndControllerClassName()`
+- :php:`\TYPO3\CMS\Form\Service\TranslationService::getInstance()`
+- :php:`\TYPO3\CMS\T3editor\Registry\AddonRegistry::getInstance()`
+- :php:`\TYPO3\CMS\T3editor\Registry\ModeRegistry::getInstance()`
+
+The following PHP class methods changed signature according to previous deprecations in v11 at the end of the argument list:
+
+- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->unpack_uc()` (argument 1 removed)
+- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->writeUC()` (argument 1 removed)
+- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->start()` (argument 1 always required)
+- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->checkAuthentication()` (argument 1 always required)
+- :php:`\TYPO3\CMS\Core\Authentication\CommandLineUserAuthentication->checkAuthentication()` (argument 1 always required)
+- :php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->isInWebMount()` (argument 3 removed)
+- :php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->backendCheckLogin()` (argument 1 removed)
+- :php:`\TYPO3\CMS\Core\Core\ApplicationInterface->run()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Database\RelationHandler->writeForeignField()` (argument 4 removed)
+- :php:`\TYPO3\CMS\Core\Resource\AbstractFile->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\File->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\FileInterface->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\FileReference->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\Folder->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\InaccessibleFolder->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile->getPublicUrl()` (argument 1 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorage->getPublicUrl()` (argument 2 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelperInterface->getPublicUrl()` (argument 2 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\VimeoHelper->getPublicUrl()` (argument 2 is removed)
+- :php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\YouTubeHelper->getPublicUrl()` (argument 2 is removed)
+- :php:`\TYPO3\CMS\Extbase\Core\Bootstrap->run()` (optional third argument is now required)
+- :php:`\TYPO3\CMS\Fluid\View\StandaloneView->__construct()` (optional constructor argument is removed)
+- :php:`\TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->fetchGroupData()` (argument 1 always required)
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->ATagParams()` (argument 2 is removed)
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->getConfigArray()` (argument 1 is always required)
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->determineId()` (argument 1 is always required)
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->INTincScript()` (argument 1 is always required)
+- :php:`\TYPO3\CMS\Frontend\Typolink\AbstractTypolinkBuilder->build()` (return type is now of LinkResultInterface)
+
+The following PHP static class methods changed signature according to previous deprecations in v11 at the end of the argument list:
+
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::wrapClickMenuOnIcon()` (arguments 5, 6 and 7 are removed)
+- :php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()` (argument 3 is removed)
+
+The following PHP class methods changed signature according to previous deprecations in v11 and are now type hinted:
+
+- :php:`\TYPO3\CMS\Core\Database\Query\Expression\ExpressionBuilder->literal()` (second argument requires an integer)
+- :php:`\TYPO3\CMS\Core\Database\Query\QueryBuilder->quote()` (second argument requires an integer)
+- :php:`\TYPO3\CMS\Core\TimeTracker\TimeTracker->setTSlogMessage()` (second argument requires a string)
+- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->getIcon()` (first argument is now type hinted `array`)
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Query->logicalAnd()` (all arguments are now type hinted as `ConstraintInterface`)
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Query->logicalOr()` (all arguments are now type hinted as `ConstraintInterface`)
+- :php:`\TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList->linkUrlMail()` (all arguments are now type hinted as `string`)
+
+The following PHP class methods changed signature according to previous deprecations:
+
+- :php:`\TYPO3\CMS\Core\Controller\ErrorPageController->errorAction()` (the third argument :php:`$severity` is removed)
+
+The following class properties have been removed:
+
+- :php:`\TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->breakPointLN`
+- :php:`\TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->parentObject`
+- :php:`\TYPO3\CMS\Core\TypoScript\TemplateService->ext_constants_BRP`
+- :php:`\TYPO3\CMS\Core\TypoScript\TemplateService->ext_config_BRP`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController->controllerContext`
+- :php:`\TYPO3\CMS\Extbase\Mvc\View\JsonView->controllerContext`
+- :php:`\TYPO3\CMS\Fluid\Core\Rendering\RenderingContext->controllerContext`
+- :php:`\TYPO3\CMS\Fluid\View\AbstractTemplateView->controllerContext`
+- :php:`\TYPO3\CMS\Form\Domain\Renderer\AbstractElementRenderer->controllerContext`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->align`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->oldData`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->alternativeData`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->currentRecordTotal`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->recordRegister`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->ATagParams`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->cObjectDepthCounter`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->displayEditIcons`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->displayFieldEditIcons`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->sWordRegex` (internal, but public)
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->sWordList` (internal, but public)
+- :php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin->pi_EPtemp_cObj`
+
+The following class properties have been changed:
+
+- :php:`\TYPO3\CMS\Core\TimeTracker\TimeTracker->wrapError` (does not contain numeric keys anymore)
+- :php:`\TYPO3\CMS\Core\TimeTracker\TimeTracker->wrapIcon` (does not contain numeric keys anymore)
+
+The following class methods visibility have been changed to protected:
+
+- :php:`\TYPO3\CMS\Core\DataHandling\SoftReference\TypolinkSoftReferenceParser->getTypoLinkParts()`
+- :php:`\TYPO3\CMS\Core\DataHandling\SoftReference\TypolinkSoftReferenceParser->setTypoLinkPartsElement()`
+- :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::resolveControllerAliasFromControllerClassName()`
+
+The following class properties visibility have been changed to protected:
+
+- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->cObj`
+- :php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin->cObj`
+
+The following ViewHelpers have been changed or removed:
+
+- :html:`<be:moduleLayout>` removed
+- :html:`<be:moduleLayout.menu>` removed
+- :html:`<be:moduleLayout.menuItem>` removed
+- :html:`<be:moduleLayout.button.linkButton>` removed
+- :html:`<be:moduleLayout.button.shortcutButton>` removed
+- :html:`<f:base>` removed
+- :html:`<f:be.container>` removed
+- :html:`<f:uri.email>` removed
+- :html:`<f:form>` (:php:`addQueryStringMethod` argument removed)
+- :html:`<f:link.action>` (:php:`addQueryStringMethod` argument removed)
+- :html:`<f:link.page>` (:php:`addQueryStringMethod` argument removed)
+- :html:`<f:link.typolink>` (:php:`addQueryStringMethod` argument removed)
+- :html:`<f:uri.action>` (:php:`addQueryStringMethod` argument removed)
+- :html:`<f:uri.page>` (:php:`addQueryStringMethod` argument removed)
+- :html:`<f:uri.typolink>` (:php:`addQueryStringMethod` argument removed)
+
+The following TypoScript options have been removed or adapted:
+
+- `config.sword_standAlone`
+- `config.sword_noMixedCase`
+- `_parseFunc.sword`
+- `EDITPANEL` content object
+- `mod.linkvalidator.linkhandler.reportHiddenRecords`
+- `page.includeCSS.myfile*.import`
+- `page.includeCSSLibs.myfile*.import`
+- `plugin.tx_indexedsearch.settings.forwardSearchWordsInResultLink`
+- `plugin.tx_indexedsearch.settings.forwardSearchWordsInResultLink.no_cache`
+- `stdWrap.editPanel`
+- `stdWrap.editPanel.`
+- `stdWrap.editIcons`
+- `stdWrap.editIcons.`
+- `TMENU.JSWindow`
+- `TMENU.JSWindow.params`
+
+The following constants have been dropped:
+
+- :php:`TYPO3_branch`
+- :php:`TYPO3_MODE`
+- :php:`TYPO3_REQUESTTYPE`
+- :php:`TYPO3_REQUESTTYPE_AJAX`
+- :php:`TYPO3_REQUESTTYPE_BE`
+- :php:`TYPO3_REQUESTTYPE_CLI`
+- :php:`TYPO3_REQUESTTYPE_FE`
+- :php:`TYPO3_REQUESTTYPE_INSTALL`
+- :php:`TYPO3_version`
+
+The following class constants have been dropped:
+
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_ALLOW_ALL`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_SERVER_NAME`
+- :php:`\TYPO3\CMS\Core\Versioning\VersionState::NEW_PLACEHOLDER_VERSION`
+- :php:`\TYPO3\CMS\Core\Versioning\VersionState::MOVE_PLACEHOLDER`
+
+The following global option handling have been dropped and are ignored:
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultCategorizedTables']`
+
+The following hooks have been removed:
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['additionalBackendItems']['cacheActions']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['FileDumpEID.php']['checkFileAccess']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['fileList']['editIconsHook']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['extTablesInclusion-PostProcessing']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['recordlist/Modules/Recordlist/index.php']['drawHeaderHook']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['recordlist/Modules/Recordlist/index.php']['drawFooterHook']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_extfilefunc.php']['processData']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_parsehtml_proc.php']['transformation']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/browse_links.php']['browserRendering']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/class.db_list_extra.inc']['actions']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/classes/class.frontendedit.php']`
+- :php:`$GLOBALS['TBE_MODULES_EXT']['xMOD_db_new_content_el']['addElClasses']`
+
+The following single field configurations have been removed from TCA:
+
+- :php:`special` (for TCA type :php:`select`)
+- :php:`treeConfig.rootUid` (for TCA renderType :php:`selectTree` and :php:`category`)
+
+The following single field configurations have been removed from :php:`$GLOBALS['TYPO3_USER_SETTINGS']`:
+
+- :php:`confirmData.jsCodeAfterOk`
+- :php:`onClick`
+- :php:`onClickLabels`
+
+The following features are now always enabled:
+
+- `runtimeDbQuotingOfTcaConfiguration`
+- `subrequestPageErrors`
+- `yamlImportsFollowDeclarationOrder`
+
+The following features have been removed:
+
+- Extbase switchable controller actions
+- Upgrade wizard "Migrate felogin plugins to use prefixed FlexForm keys"
+- Upgrade wizard "Migrate felogin plugins to use Extbase CType"
+- Upgrade wizard "Install extension 'feedit' from TER"
+- Upgrade wizard "Install extension 'sys_action' from TER"
+- Upgrade wizard "Install extension "taskcenter" from TER"
+- Row upgrader "Workspace 'pid -1' migration"
+
+The following fallbacks have been removed:
+
+- Usage of the :html:`t3js-toggle-new-content-element-wizard` class to trigger the new content element wizard
+- Usage of the :php:`DataHandler->inlineLocalizeSynchronize()` functionality without an array as input argument
+- The :php:`route` parameter is no longer added to backend URLs
+- Extensions, which are located in `typo3conf/ext`, but not installed by Composer, are no longer evaluated for installations in "Composer mode"
+- Extbase no longer accepts :php:`MyVendor.` prefixed :php:`MyExtensionName` as first argument in
+  :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin()`, :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin()`
+  and :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule()` and controller class names must be registered
+  with their fully qualified name.
+- Extbase no longer determines types from doc block annotations for dependency injection methods and actions with validators,
+  defined types in method signatures must be used.
+- Accessing Core related caches with :php:`cache_` prefix has been removed.
+- Accessing :php:`\TYPO3\CMS\Frontend\Typolink\LinkResult` properties as arrays - ArrayAccess functionality removed
+
+The following database tables have been removed:
+
+- :sql:`sys_language`
+
+The following global JavaScript variables have been removed:
+
+- :js:`top.currentSubScript`
+- :js:`top.fsMod`
+- :js:`top.nextLoadModuleUrl`
+
+The following global JavaScript functions have been removed:
+
+- :js:`top.goToModule()`
+- :js:`top.jump()`
+
+The following JavaScript functions have been removed:
+
+- :js:`FormEngine.requestConfirmationOnFieldChange()`
+- :js:`TBE_EDITOR.fieldChanged()`
+
+The following JavaScript methods behaviour has changed:
+
+- :js:`show()` and :js:`hide()` of :js:`TYPO3/CMS/Backend/Tooltip` do no longer allow JQuery objects passed as first argument
+- :js:`FormEngine.setSelectOptionFromExternalSource()` does no longer allow JQuery objects passed as sixth argument
+- :js:`DateTimePicker.initialize()` always requires an :js:`HTMLInputElement` to be passed as first argument
+
+The following JavaScript modules have been removed:
+
+- :js:`TYPO3/CMS/Backend/SplitButtons`
+- :js:`TYPO3/CMS/Core/Ajax/ResponseError`
+- :js:`TYPO3/CMS/T3editor/T3editor`
+
+The following RequireJS module names have been removed:
+
+- :js:`Sortable`
+
+The following module configuration have been removed:
+
+- :php:`navFrameScript`
+- :php:`navFrameScriptParam`
+- :php:`navigationFrameModule` (Extbase)
+
+The following command line options have been removed:
+
+- :bash:`impexp:export --includeRelated`
+- :bash:`impexp:export --includeStatic`
+- :bash:`impexp:export --excludeDisabledRecords`
+- :bash:`impexp:export --excludeHtmlCss`
+- :bash:`impexp:export --saveFilesOutsideExportFile`
+- :bash:`impexp:import --updateRecords`
+- :bash:`impexp:import --ignorePid`
+- :bash:`impexp:import --forceUid`
+- :bash:`impexp:import --importMode`
+- :bash:`impexp:import --enableLog`
+
+The following dependency injection container entries have been removed:
+
+- `\TYPO3\CMS\Core\Localization\LanguageService`
+- `\TYPO3\CMS\Fluid\Core\Rendering\RenderingContext`
+- `\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController`
+
+Impact
+======
+
+Using above removed functionality will most likely raise PHP fatal level errors,
+may change website output or crashes browser JavaScript.
+
+.. index:: Backend, CLI, FlexForm, Fluid, Frontend, JavaScript, LocalConfiguration, PHP-API, TCA, TSConfig, TypoScript, PartiallyScanned

Documentation/Changelog/12.0/Breaking-96149-EXTformEmailFinisherAlwaysUsesFluidEmail.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96149:
+
+================================================================
+Breaking: #96149 - EXT:form EmailFinisher always uses FluidEmail
+================================================================
+
+See :issue:`96149`
+
+Description
+===========
+
+In recent versions, the :php:`EmailFinisher` of EXT:form allowed sending
+emails with either :php:`StandaloneView` or via :php:`FluidEmail`, which
+has been introduced in TYPO3 v10. The :php:`StandaloneView` option has
+therefore now been removed together with the :file:`Html.html` and
+:file:`Plaintext.html` templates.
+
+Impact
+======
+
+Since the EXT:form :php:`EmailFinisher` is now always using :php:`FluidEmail`
+for sending emails, the :yaml:`templatePathAndFilename` is not evaluated
+anymore. For forms, which still define custom templates with this option,
+a fallback kicks in, sending the emails with the default EXT:form
+:php:`FluidEmail` templates.
+
+Also the :yaml:`useFluidEmail` configuration option, previously used to
+allow a smooth migration path is now obsolete and can safely be removed
+from any form finisher configuration.
+
+Affected Installations
+======================
+
+Installations, which have not yet switched to :php:`FluidEmail`, while using
+custom email templates, configured with :yaml:`templatePathAndFilename`.
+
+Migration
+=========
+
+In case you use custom email templates, replace :yaml:`templatePathAndFilename`
+with the :yaml:`templateName` and :yaml:`templateRootPaths` options. Also
+make sure, you have separate template files for the used formats, e.g.
+:file:`ContactForm.html` and :file:`ContactForm.txt`.
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/12.0/Breaking-96154-DeprecatedShortcutAPIFunctionalityRemoved.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96154:
+
+================================================================
+Breaking: #96154 - Deprecated Shortcut API functionality removed
+================================================================
+
+See :issue:`96154`
+
+Description
+===========
+
+In TYPO3 v11 the Shortcut API was reworked to clean up the codebase and
+to align with the new Backend routing. Therefore, previously deprecated
+functionality has now been removed.
+
+The following methods have been removed:
+
+- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->makeShortcutIcon()`
+- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->makeShortcutUrl()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->getGetVariables()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->getModuleName()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->getSetVariables()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setGetVariables()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setModuleName()`
+- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setSetVariables()`
+
+The following ViewHelper has been removed:
+
+- :html:`<f:be.buttons.shortcut>`
+
+The following functionality has been removed:
+
+- The automatic fallback, calculating a title for a new shortcut, based on the module
+- The automatic fallback, calculating a description for existing shortcuts, based on the module
+- The automatic fallback, determining the route identifier, based on the route path
+- The automatic fallback, determining the route identifier, based on the module name
+- The automatic fallback, determining the route identifier, based on the route parameter
+
+Impact
+======
+
+Calling one of the removed methods or using the ViewHelper will most likely
+raise a PHP fatal level error.
+
+When using an existing shortcut without a title, the fallback "Shortcut"
+will be displayed.
+
+When adding a :php:`ShortcutButton`, without providing a valid route
+identifier or a display name, an exception will be triggered.
+
+Affected Installations
+======================
+
+All installations using one of the mentioned methods or the ViewHelper.
+
+All installations relying on one or multiple of the mentioned fallbacks.
+
+Migration
+=========
+
+Remove any usage to the mentioned methods or the ViewHelper.
+
+Properly add the :php:`ShortcutButton` with the required information.
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96158-RemoveSupportForInlineJavaScriptInFieldChangeFunc.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96158:
+
+==========================================================================
+Breaking: #96158 - Remove support for inline JavaScript in fieldChangeFunc
+==========================================================================
+
+See :issue:`96158`
+
+Description
+===========
+
+Custom :php:`FormEngine` nodes allow to use internal property `fieldChangeFunc`
+to add or modify client-side JavaScript behavior when field values are changed.
+Through TYPO3 v11 it was possible to directly use inline JavaScript that was
+assigned as plain :php:`string` type. With TYPO3 v12.0 inline JavaScript is
+not supported anymore - values assigned to `fieldChangeFunc` items have to
+implement :php:`\TYPO3\CMS\Backend\Form\Behavior\OnFieldChangeInterface`
+which allows to declare the behavior in a structured way.
+
+Impact
+======
+
+Assigning scalar values to `fieldChangeFunc` items - without using
+:php:`\TYPO3\CMS\Backend\Form\Behavior\OnFieldChangeInterface` - is not
+supported anymore and will lead to PHP type errors.
+
+Affected Installations
+======================
+
+Installations implementing custom :php:`FormEngine` components (wizards, nodes,
+render-types, ...) that provide inline JavaScript using `fieldChangeFunc`.
+
+..  code-block:: php
+
+    // examples
+    $this->data['parameterArray']['fieldChangeFunc']['example'] = "alert('demo');";
+    $parameterArray['fieldChangeFunc']['example'] = "alert('demo');";
+
+Migration
+=========
+
+:doc:`Previous deprecation ChangeLog documentation <../11.5/Deprecation-91787-DeprecateInlineJavaScriptInFieldChangeFunc>`
+provided migration details already. A complete and installable example is available with
+`ext:demo_91787 <https://github.com/ohader/demo_91787>`__ as well.
+
+The provided code examples are supposed to work with TYPO3 v11 and v12, easing
+the migration path for extension maintainers. The crucial point is to use
+:php:`\TYPO3\CMS\Backend\Form\Behavior\OnFieldChangeInterface` which still
+would inline JavaScript as a fallback in TYPO3 v11.
+
+Thus, basically scalar assignments like...
+
+..  code-block:: php
+
+    // examples
+    $this->data['parameterArray']['fieldChangeFunc']['example'] = "alert('demo');";
+    $parameterArray['fieldChangeFunc']['example'] = "alert('demo');";
+
+... have to be replaced by custom :php:`OnFieldChangeInterface` instances...
+
+..  code-block:: php
+
+    // examples
+    $this->data['parameterArray']['fieldChangeFunc']['example'] = new AlertOnFieldChange('demo');
+    $parameterArray['fieldChangeFunc']['example'] = new AlertOnFieldChange('demo');
+
+.. index:: Backend, JavaScript, TCA, NotScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96205-RemovalOfLastRelativeToCurrentScriptRemains.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96205:
+
+==================================================================
+Breaking: #96205 - Removal of last relativeToCurrentScript remains
+==================================================================
+
+See :issue:`96205`
+
+Description
+===========
+
+Due to the removal of relative paths in the FAL API (:issue:`95027` and
+:issue:`96201`) the :php:`$usedPathsRelativeToCurrentScript` argument in
+media renderers :php:`render()` method got obsolete. The same applies to
+the :php:`$relativeToCurrentScript` argument of :php:`Avatar->getUrl()`.
+
+Therefore, :php:`$usedPathsRelativeToCurrentScript` is removed as last
+argument from following PHP class methods:
+
+- :php:`\TYPO3\CMS\Core\Resource\Rendering\AudioTagRenderer->render()`
+- :php:`\TYPO3\CMS\Core\Resource\Rendering\FileRendererInterface->render()`
+- :php:`\TYPO3\CMS\Core\Resource\Rendering\VideoTagRenderer->render()`
+- :php:`\TYPO3\CMS\Core\Resource\Rendering\VimeoRenderer->render()`
+- :php:`\TYPO3\CMS\Core\Resource\Rendering\YoutubeRenderer->render()`
+
+Further is :php:`$relativeToCurrentScript` removed as last argument
+from :php:`\TYPO3\CMS\Backend\Backend\Avatar->getUrl()`.
+
+Impact
+======
+
+Passing the removed argument to one of the mentioned methods does
+no longer have any effect.
+
+Affected Installations
+======================
+
+Installations, passing the removed argument to one of the mentioned
+methods, which is rather unlikely as those methods are usually not
+called by extension code directly.
+
+Migration
+=========
+
+Remove the corresponding argument from the methods.
+
+.. index:: FAL, PHP-API, FullyScanned, ext:core

Documentation/Changelog/12.0/Breaking-96212-AltTextIsEnforcedForCustomLoginLogos.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96212:
+
+==============================================================
+Breaking: #96212 - Alt text is enforced for custom login logos
+==============================================================
+
+See :issue:`96212`
+
+Description
+===========
+
+To improve the accessibility of the login screen, the :html:`alt` attribute
+has been added to the login logo in :issue:`92628`. In case installations use
+a custom login logo, configured in :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['backend']['loginLogo']`,
+it had also been possible to add a corresponding "alt" text for it with
+:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['backend']['loginLogoAlt']`.
+
+In case a custom logo was used, but no custom "alt" text configured, the
+:html:`alt` attribute was omitted. This has changed. The :html:`alt`
+attribute is now always added to the login logo. In case a custom logo is
+used, but no custom "alt" text defined, TYPO3 now automatically falls back
+to a default "alt" text.
+
+Impact
+======
+
+The :html:`alt` attribute is now enforced for the login logo.
+
+Affected Installations
+======================
+
+All installations using a custom login logo, while not defining a
+corresponding "alt" text.
+
+Migration
+=========
+
+Add a corresponding "alt" text with
+:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['backend']['loginLogoAlt']`.
+
+.. note::
+
+    Those settings are also available in the backend extension configuration
+    :guilabel:`Admin Tools -> Settings -> Configure extensions -> backend`
+
+.. index:: Backend, LocalConfiguration, NotScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96221-DenyInlineJavaScriptInFormEnginesRequireJsModules.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96221:
+
+==========================================================================
+Breaking: #96221 - Deny inline JavaScript in FormEngine's requireJsModules
+==========================================================================
+
+See :issue:`96221`
+
+Description
+===========
+
+Custom :php:`FormEngine` components allowed to load RequireJS modules
+with arbitrary inline JavaScript to initialize those modules. In favor
+of introducing content security policy headers, the amount of inline
+JavaScript shall be reduced and replaced by corresponding declarations.
+
+Using callback functions as inline JavaScript is not possible anymore,
+initializations have to be declared using an instance of
+:php:`TYPO3\CMS\Core\Page\JavaScriptModuleInstruction`.
+
+Impact
+======
+
+Using inline JavaScript to initialize RequireJS modules in `FormEngine`,
+like shown in the example below, will throw a corresponding
+:php:`\LogicException`.
+
+..  code-block:: php
+
+    $resultArray['requireJsModules'][] = ['TYPO3/CMS/Backend/FormEngine/Element/InputDateTimeElement' => '
+        // inline JavaScript code to initialize `InputDateTimeElement`
+        function(InputDateTimeElement) {
+            new InputDateTimeElement(' . GeneralUtility::quoteJSvalue($fieldId) . ');
+        }'
+    ];
+
+Affected Installations
+======================
+
+All instances that are using RequireJS modules with custom initializations
+as inline JavaScript in `FormEngine`.
+
+Migration
+=========
+
+:doc:`Previous deprecation ChangeLog documentation <../11.5/Deprecation-95200-DeprecateRequireJSCallbacksAsInlineJavaScript>`
+provided migration details already.
+
+The following snippet shows the migrated source code of shown above - using
+:php:`TYPO3\CMS\Core\Page\JavaScriptModuleInstruction` instead of inline JavaScript.
+
+..  code-block:: php
+
+    // use use TYPO3\CMS\Core\Page\JavaScriptModuleInstruction;
+    $resultArray['requireJsModules'][] = JavaScriptModuleInstruction::forRequireJS(
+        'TYPO3/CMS/Backend/FormEngine/Element/InputDateTimeElement'
+    )->instance($fieldId);
+
+:php:`JavaScriptModuleInstruction` forwards arguments as `JSON` data - and thus
+handles proper context-aware encoding implicitly (:php:`GeneralUtility::quoteJSvalue`
+and similar custom encoding can be omitted in this case).
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96222-AddGetOptionsToWidgetInterface.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96222:
+
+======================================================
+Breaking: #96222 - Add getOptions() to WidgetInterface
+======================================================
+
+See :issue:`96222`
+
+Description
+===========
+
+With :issue:`93210` the dashboard was extended for the functionality to
+refresh single widgets. This also required to extend the :php:`WidgetInterface`.
+To stick to TYPO3's backwards compatibility promise, the new method was
+commented out and instead a :php:`methodExists()` check performed.
+
+This now has changed. The check is removed and the :php:`WidgetInterface`
+now forces the presence of the :php:`getOptions()` method in all widgets.
+
+Impact
+======
+
+All dashboard widgets are now forced to implement the :php:`getOptions()`
+method, returning the widget options. Otherwise this will cause a PHP
+fatal error.
+
+Affected Installations
+======================
+
+All installations using custom dashboard widgets.
+
+Migration
+=========
+
+Add the :php:`getOptions()` method to all of your custom widget classes.
+
+..  code-block:: php
+
+    public function getOptions(): array
+    {
+        return $this->options;
+    }
+
+.. index:: Backend, PHP-API, NotScanned, ext:dashboard

Documentation/Changelog/12.0/Breaking-96263-RemoveJQueryPromiseSupportForAJAXRequests.rst

@@ -0,0 +1,64 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96263:
+
+==================================================================
+Breaking: #96263 - Remove jQuery promise support for AJAX requests
+==================================================================
+
+See :issue:`96263`
+
+Description
+===========
+
+With :issue:`89738`, a polyfill for jQuery promises was introduced to ease the
+migration of :js:`$.ajax()` to our AJAX request API.
+
+The polyfilled methods :js:`done()` and :js:`fail()` are now removed.
+
+Impact
+======
+
+Relying on the existence of the polyfill will trigger JavaScript errors.
+
+Affected Installations
+======================
+
+All extensions using the polyfilled methods are affected.
+
+Migration
+=========
+
+For success handling, replace :js:`done()` with :js:`then()`.
+
+Example:
+
+..  code-block:: js
+
+    // Polyfill
+    new AjaxRequest('/foobar/baz').get().done(function(response) {
+      // do stuff
+    });
+
+    // Native
+    new AjaxRequest('/foobar/baz').get().then(async function(response) {
+      // do stuff
+    });
+
+For error handling, replace :js:`fail()` with :js:`catch()`.
+
+Example:
+
+..  code-block:: js
+
+    // Polyfill
+    new AjaxRequest('/foobar/baz').get().fail(function() {
+      // oh noes
+    });
+
+    // Native
+    new AjaxRequest('/foobar/baz').get().catch(function() {
+      // oh noes
+    });
+
+.. index:: JavaScript, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96287-DoctrineDBALv3.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96287:
+
+===================================
+Breaking: #96287 - Doctrine DBAL v3
+===================================
+
+See :issue:`96287`
+
+Description
+===========
+
+TYPO3 v12.0 has updated its Database Abstraction package based on Doctrine
+DBAL to the next major version Doctrine DBAL v3.
+
+Impact
+======
+
+Doctrine DBAL 3 has undergone major refactorings internally by separating
+Doctrine's internal driver logic from PHP's native PDO functionality.
+
+See https://www.doctrine-project.org/2021/03/29/dbal-2.13.html and
+https://www.doctrine-project.org/2020/11/17/dbal-3.0.0.html
+for more details.
+
+In addition, most database APIs which TYPO3 provides as wrappers around
+the existing functionality is already available in TYPO3 v11 and
+continue to work in TYPO3 v12.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom third-party extensions using TYPO3's
+Database Abstraction functionality, or extensions using
+the Doctrine DBAL API directly.
+
+Migration
+=========
+
+Read Doctrine's migration paths (see links above) to migrate any existing
+code.
+
+The main change for 95% of the developers are, that queries and database result-sets
+now have more explicit APIs when querying the database.
+
+Examples:
+
+..  code-block:: php
+
+    $result = $queryBuilder
+      ->select(...)
+      ->from(...)
+      // use executeQuery() instead of execute()
+      ->executeQuery();
+
+:php:`$result` is now of type :php:`\Doctrine\DBAL\Result`, and not of type
+:php:`\Doctrine\DBAL\Statement` anymore, which allows to fetch rows / columns via
+new and more speaking methods:
+
+* :php:`->fetchAllAssociative()` instead of :php:`->fetchAll()`
+* :php:`->fetchAssociative()` - instead of :php:`->fetch()`
+* :php:`->fetchOne()` - instead of :php:`->fetchColumn(0)`
+
+The method :php:`executeQuery` - available in the QueryBuilder and
+the Connection class is now in for select/count queries and returns a Result
+object directly, whereas :php:`executeStatement()` is used for insert / update / delete
+statements, returning an integer - the number of affected rows.
+
+Use both methods instead of the previous :php:`execute()` method,
+which is still available for backwards-compatibility.
+
+.. index:: Database, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96291-DisallowDBConnectionBeforeTCAIsLoaded.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96291:
+
+==============================================================
+Breaking: #96291 - Disallow DB connection before TCA is loaded
+==============================================================
+
+See :issue:`96291`
+
+Description
+===========
+
+Accessing the database API before TCA is loaded
+is considered to be a logic mistake, as TCA is required
+to generate the expected database schema.
+
+Impact
+======
+
+Extensions that access the TYPO3 database API in
+:file:`ext_localconf.php` files or TCA files will not work
+any more, because TYPO3 will throw an exception in this case.
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions,
+that access database API before TCA is loaded.
+
+Migration
+=========
+
+Database API can be accessed earliest in the
+:php:`\TYPO3\CMS\Core\Core\Event\BootCompletedEvent`.
+
+.. index:: Database, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96333-AutoConfigurationOfContextMenuItemProviders.rst

@@ -0,0 +1,123 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96333:
+
+===================================================================
+Breaking: #96333 - Auto configuration of ContextMenu item providers
+===================================================================
+
+See :issue:`96333`
+
+Description
+===========
+
+ContextMenu item providers, implementing :php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\ProviderInterface`
+are now automatically registered by adding the :yaml:`backend.contextmenu.itemprovider`
+tag, if :yaml:`autoconfigure` is enabled in :file:`Services.yaml`. The new
+:php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\ItemProvidersRegistry` then
+automatically receives those services and registers them.
+
+All Core item providers extend the :php:`AbstractProvider` class, which is
+usually also used by extensions. Due to the auto configuration, the context
+information (table, record identifier and context) is no longer passed to the
+:php:`__construct()`, but instead to the new :php:`setContext()` method.
+
+The :php:`setContext()` method is therefore required for all item providers.
+
+Impact
+======
+
+The registration via :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['ContextMenu']['ItemProviders']`
+isn't evaluated anymore.
+
+The item providers are retrieved from the container and are no longer
+instantiated while passing context information as constructor arguments.
+The context information is now passed to :php:`setContext()`.
+
+Affected Installations
+======================
+
+All extensions, registering custom ContextMenu item providers.
+
+All extensions, extending :php:`AbstractProvider` and overwriting the
+:php:`__construct()` method.
+
+All extensions, not extending :php:`AbstractProvider`, but implementing
+:php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\ProviderInterface` directly.
+
+Migration
+=========
+
+Remove :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['ContextMenu']['ItemProviders']`
+from your :file:`ext_localconf.php` file. If :yaml:`autoconfigure` is
+not enabled in your :file:`Configuration/Services.(yaml|php)` file,
+manually configure your item providers with the
+:yaml:`backend.contextmenu.itemprovider` tag.
+
+If your item providers extend :php:`AbstractProvider` and overwrite the
+:php:`__construct()` method, adjust the signature like shown below:
+
+..  code-block:: php
+
+    // Before
+
+    class MyItemProvider extends AbstractProvider {
+
+        public function __construct(string $table, string $identifier, string $context = '')
+        {
+            parent::__construct($table, $identifier, $context);
+
+            // My custom code
+        }
+    }
+
+    // After
+
+    class MyItemProvider extends AbstractProvider {
+
+        public function __construct()
+        {
+            parent::__construct();
+
+            // My custom code
+        }
+    }
+
+In case you rely on the arguments, previously passed to :php:`__construct()`,
+you can override the new :php:`setContext()` method, which is executed
+prior to any other action like :php:`canHandle()`.
+
+..  code-block:: php
+
+    // Before
+
+    class MyItemProvider extends AbstractProvider {
+
+        public function __construct(string $table, string $identifier, string $context = '')
+        {
+            parent::__construct($table, $identifier, $context);
+
+            if ($table === 'my_table') {
+                // Do something
+            }
+    }
+
+    // After
+
+    class MyItemProvider extends AbstractProvider {
+
+        public function setContext(string $table, string $identifier, string $context = ''): void
+        {
+            parent::setContext($table, $identifier, $context);
+
+            if ($table === 'my_table') {
+                // Do something
+            }
+        }
+    }
+
+In case your item provider does not extend :php:`AbstractProvider`, but instead
+implements the :php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\ProviderInterface`
+directly, add the new :php:`setContext()` to the item provider.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96351-UnusedTemplateService-updateRootlineDataMethodRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96351:
+
+============================================================================
+Breaking: #96351 - Unused TemplateService->updateRootlineData method removed
+============================================================================
+
+See :issue:`96351`
+
+Description
+===========
+
+The PHP method :php:`TemplateService->updateRootlineData()` has been removed.
+
+It was used as a workaround to update the fetched rootline with
+translated pages until TYPO3 v10. This was necessary because the
+TypoScript information contained the language information, and
+then the page translations were loaded accordingly.
+
+Since TYPO3 v11 the language is resolved earlier, at the same
+time as the page ID, and the mechanism became obsolete.
+
+Impact
+======
+
+Calling the method in PHP will throw a fatal PHP error, as the method does not exist anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations, mainly legacy installations with legacy
+extensions using this method to boot up their own TypoScript
+parsing.
+
+Migration
+=========
+
+Calling this method is not needed anymore and can be removed
+from the affected code.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:core

Documentation/Changelog/12.0/Breaking-96501-PrefixLocalAnchorsOptionInHTMLParserRemoved.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96501:
+
+==================================================================
+Breaking: #96501 - prefixLocalAnchors option in HTMLParser removed
+==================================================================
+
+See :issue:`96501`
+
+Description
+===========
+
+The property :php:`prefixLocalAnchors` in TypoScript's HTMLParser
+is removed without substitution.
+
+This is a leftover from times before there was Site Handling
+and absolute URLs, related to :typoscript:`config.prefixLocalAnchors` which was
+removed in TYPO3 v8.
+
+The option has many side-effects such as relying on the request
+when parsing HTML (which behaves differently in TYPO3 Backend
+and in Frontend).
+
+Impact
+======
+
+Setting this TypoScript option has no effect anymore.
+
+Affected Installations
+======================
+
+TYPO3 installation having TypoScript configured with this
+option activated.
+
+Migration
+=========
+
+None.
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96517-TMENUcollapseTyposcriptRemoved.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96517:
+
+====================================================
+Breaking: #96517 - TMENU.collapse TypoScript removed
+====================================================
+
+See :issue:`96517`
+
+Description
+===========
+
+The :typoscript:`collapse` TypoScript property of :typoscript:`TMENU` is removed
+without substitution.
+
+When set, active :typoscript:`TMENU` items previously linked to their parent page,
+which was primarily a use case for :typoscript:`GMENU_LAYERS`, which was
+removed in TYPO3 v6.0.
+
+Impact
+======
+
+Setting this TypoScript option has no effect anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations with :typoscript:`TMENU` definitions having this option
+set which is highly unlikely.
+
+Migration
+=========
+
+Use a custom user function or the PSR-14 :php:`FilterMenuItemsEvent` event to modify
+the menu items.
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96518-Ext_typoscript_txtFilesNotIncludedAnymore.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96518:
+
+==================================================================
+Breaking: #96518 - ext_typoscript_*.txt files not included anymore
+==================================================================
+
+See :issue:`96518`
+
+Description
+===========
+
+In previous TYPO3 versions, files named :file:`ext_typoscript_setup.txt` and
+:file:`ext_typoscript_constants.txt` which could be placed into an extension's
+root folder, were automatically included for all TypoScript evaluations.
+
+This functionality stopped working, as the file ending `.typoscript`
+has been unified since TYPO3 v8.
+
+Impact
+======
+
+Contents of these files are not evaluated for TypoScript anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions including such files.
+
+Migration
+=========
+
+Rename the files to :file:`ext_typoscript_setup.typoscript` and
+:file:`ext_typoscript_constants.typoscript` which ensures compatibility
+with all supported TYPO3 versions.
+
+The file extension `.typoscript` was used since TYPO3 v8 and both versions (.txt
+and .typoscript) have been working side-by-side since TYPO3 v8.
+
+.. index:: TypoScript, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96520-EnforceNon-emptyConfigurationInCObjparseFunc.rst

@@ -0,0 +1,90 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96520:
+
+=====================================================================
+Breaking: #96520 - Enforce non-empty configuration in cObj::parseFunc
+=====================================================================
+
+See :issue:`96520`
+
+Description
+===========
+
+Invoking :php:`ContentObjectRenderer::parseFunc` without configuration
+or TypoScript reference is not possible anymore and in general did not
+make much sense.
+
+Calling this method without any instructions led to various
+side-effects, e.g. unintentionally enforcing `typo3/html-sanitizer`.
+This problem was amplified when using :html:`<f:format.html parseFuncTSPath="">`
+with an explicitly empty reference which actually did not do anything
+and behaved the same as :html:`<f:format.raw>`.
+
+This change enforces that parseFunc is only invoked with actual
+instructions. An empty configuration will throw a :php:`\LogicException` and
+requires corresponding source code or Fluid templates to be adjusted.
+
+Impact
+======
+
+Still invoking :php:`ContentObjectRenderer::parseFunc` without configuration
+will throw a :php:`\LogicException` in the frontend rendering process.
+
+Affected Installations
+======================
+
+All installations using one of the following examples
+
+PHP
+---
+
+..  code-block:: php
+
+    /** @var \TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer $cObj */
+    $cObj->parseFunc($content, []);
+    $cObj->parseFunc($content, [], '');
+    $cObj->parseFunc($content, [], '< null.this.does.not.exist');
+
+TypoScript
+----------
+
+..  code-block:: typoscript
+
+    # `1` is considered a TypoScript reference which
+    # most probably does not exist
+    stdWrap.parseFunc = 1
+
+    # non-existing TypoScript reference leading to empty configuration
+    stdWrap.parseFunc =< null.this.does.not.exist
+
+Fluid Templates
+---------------
+
+..  code-block:: html
+
+    <!-- empty TypoScript reference leading to empty configuration -->
+    <f:format.html parseFuncTSPath="">{content}</f:format.html>
+
+    <!-- non-existing TypoScript reference leading to empty configuration -->
+    <f:format.html parseFuncTSPath="null.this.does.not.exist">{content}</f:format.html>
+
+Migration
+=========
+
+Invocations of `parseFunc` in PHP and TypoScript without using
+any configuration or TypoScript reference have to be removed.
+
+In Fluid templates :html:`<f:format.html parseFuncTSPath="">`
+has the same effect as :html:`<f:format.raw>` which can be used
+as replacement. However content is used "as-is" without further
+sanitizing against cross-site scripting.
+
+In case of the need for just replacing links with typolink,
+it is recommended to use :html:`<f:transform.html>` ViewHelper.
+
+Thus, any occurrence of the new :php:`\LogicException` mentioned above,
+is also an indicator of some missing processing that has been unseen in
+custom source code or template instructions.
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96522-ConfigdisablePageExternalUrlRemoved.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96522:
+
+========================================================
+Breaking: #96522 - config.disablePageExternalUrl removed
+========================================================
+
+See :issue:`96522`
+
+Description
+===========
+
+The TypoScript setting :typoscript:`config.disablePageExternalUrl` has been removed.
+
+In previous versions, it allowed to have third-party extensions such as
+"jumpurl" handle the redirect, and/or do tracking like extensions "sys_stat"
+did back in 2006. TYPO3 Core did not do a redirect itself then when this
+option was activated.
+
+Impact
+======
+
+This option is removed, meaning that TYPO3 Core will always handle a deep link
+to a page with an external URL as a redirect, which has been the default
+behaviour for TYPO3 installations anyways.
+
+Affected Installations
+======================
+
+TYPO3 installations explicitly setting this option, which is highly unlikely,
+as modern solutions - even jumpurl - use middlewares already since TYPO3 v9.
+
+Migration
+=========
+
+Migrate to a PSR-15 middleware in your own extension to mimic the same behavior,
+if this option was actually useful for anybody in recent years.
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96526-RemovedHooksForModifyingPageModuleContent.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96526:
+
+==================================================================
+Breaking: #96526 - Removed hooks for modifying page module content
+==================================================================
+
+See :issue:`96526`
+
+Description
+===========
+
+The previously available hooks to modify the header
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms/layout/db_layout.php']['drawHeaderHook']`
+and footer :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms/layout/db_layout.php']['drawFooterHook']`
+content of the page module have been removed in favor of a new PSR-14
+event :php:`TYPO3\CMS\Backend\Controller\Event\ModifyPageLayoutContentEvent`.
+
+The public method :php:`PageLayoutController->getModuleTemplate()` has been
+removed as well, since it was only used for the removed hooks.
+
+Impact
+======
+
+Registering any of the mentioned hooks does no longer have any
+effect in TYPO3 v12.0+. The extension scanner will detect usages
+as strong match.
+
+The method :php:`PageLayoutController->getModuleTemplate()` is no longer
+available and will therefore lead to PHP errors when called from extension
+code. The extension scanner will detect usages as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations using one of the mentioned hooks or calling
+:php:`PageLayoutController->getModuleTemplate()` in custom extension
+code.
+
+Migration
+=========
+
+Replace the hooks with the new PSR-14
+:doc:`ModifyPageLayoutContentEvent <../12.0/Feature-96526-PSR-14EventForModifyingPageModuleContent>` event.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96550-TYPO3_CONF_VARSSYSUSdateFormatRemoved.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96550:
+
+=================================================================
+Breaking: #96550 - TYPO3_CONF_VARS['SYS']['USdateFormat'] removed
+=================================================================
+
+See :issue:`96550`
+
+Description
+===========
+
+The TYPO3 configuration had a boolean toggle
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['USdateFormat']` that
+changed the date rendering from "day-month-year" to "month-day-year"
+in a couple of places in the backend - most prominently when editing records.
+
+This configuration conflicts with option
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['ddmmyy']`, which is a broader approach
+to configure a system wide date rendering format, especially in combination with option
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['hhmm']`.
+
+To streamline date and time rendering in the backend and to eventually implement
+a user-based and timezone-aware solution, option :php:`USdateFormat` has been
+removed in favor of :php:`ddmmyy` from the configuration and is ignored now.
+
+Impact
+======
+
+Backend users of instances with this option set to :php:`true` will experience
+swapped day and month rendering when editing records in the backend.
+
+The option is removed automatically from :file:`LocalConfiguration.php`
+when upgrading to TYPO3 v12.
+
+Affected Installations
+======================
+
+Instances having :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['USdateFormat']` set to
+default :php:`false` see no difference and are not affected. Instances with this
+option set to :php:`true` are affected.
+
+The extension scanner will find matching candidates in case the option is used
+in extensions.
+
+Migration
+=========
+
+Extensions accessing :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['USdateFormat']`
+should assume :php:`false` to keep compatibility with previous TYPO3 versions,
+and should phase out the option usage.
+
+.. index:: Backend, LocalConfiguration, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96553-TYPO3V12SystemRequirements.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96553:
+
+================================================
+Breaking: #96553 - TYPO3 v12 system requirements
+================================================
+
+See :issue:`96553`
+
+Description
+===========
+
+The minimum PHP version required to run TYPO3 version v12 has been defined as 8.1.
+
+TYPO3 v12 supports these database products and versions:
+
+* MySQL 8.0 or higher
+* MariaDB 10.3 or higher
+* PostgreSQL 10.0 or higher
+* SQLite 3.8.3 or higher
+* Support for Microsoft SQL Server in any version is discontinued
+
+Impact
+======
+
+The TYPO3 Core codebase and extensions tailored for v12 and above can use
+features implemented with PHP up to and including 8.1. Running TYPO3 v12 with older PHP
+versions or database engines will trigger fatal errors.
+
+Affected Installations
+======================
+
+Hosting a TYPO3 instance based on version 12 may require an update of the
+PHP platform and the database engine.
+
+Migration
+=========
+
+TYPO3 v11 supports PHP 8.1 and database engines required by v12. This allows upgrading
+the platform in a first step and upgrading to TYPO3 v12 in a second step.
+
+.. index:: Database, PHP-API, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96575-UpdateToCodeMirror6.rst

@@ -0,0 +1,74 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96575-1663324432:
+
+=========================================
+Breaking: #96575 - Update to CodeMirror 6
+=========================================
+
+See :issue:`96575`
+
+Description
+===========
+
+TYPO3 Core now ships with CodeMirror v6.
+CodeMirror is used as editor in the TYPO3 Backend for editing
+HTML records, TypoScript templates and plaintext files in the file module.
+
+Impact
+======
+
+Existing CodeMirror v5 addons and modes need to be adapted for CodeMirror v6
+which brings a completely rewritten plugin infrastructure.
+
+Affected installations
+======================
+
+TYPO3 Installations with third-party extensions that register
+custom CodeMirror addons or modes.
+
+Migration
+=========
+
+Please consult https://codemirror.net/docs/migration/ for details on
+CodeMirror migration itself.
+
+The TYPO3 integration has been adapted to reflect the changed modes and
+addons in the `T3editor` configuration files:
+
+Adapt the mode configuration in :file:`Configuration/Backend/T3editor/Modes.php`
+to use :php:`JavaScriptModuleInstruction` statements that pick ES6 module
+for a specific language mode. A RequireJS module like
+:js:`codemirror/mode/css/css` is now shipped in `@codemirror/lang-css`:
+
+..  code-block:: php
+
+    use TYPO3\CMS\Core\Page\JavaScriptModuleInstruction;
+
+    return [
+        'css' => [
+            'module' => JavaScriptModuleInstruction::create('@codemirror/lang-css', 'css')->invoke(),
+            'extensions' => ['css'],
+        ],
+    ];
+
+Addons no longer bring :php:`cssFiles` or :php:`options`, but only consist
+of a :php:`module` and an optional :php:`keymap` statement, as the `options`
+interface is gone in CodeMirror v6 and stylesheets are to be embedded into
+JavaScript.
+
+See following example for the registration of the history addon via
+:file:`Configuration/Backend/T3editor/Modes.php`:
+
+..  code-block:: php
+
+    use TYPO3\CMS\Core\Page\JavaScriptModuleInstruction;
+
+    return [
+        'history' => [
+            'module' => JavaScriptModuleInstruction::create('@codemirror/commands', 'history')->invoke(),
+            'keymap' => JavaScriptModuleInstruction::create('@codemirror/commands', 'historyKeymap'),
+        ],
+    ];
+
+.. index:: Backend, JavaScript, NotScanned, ext:t3editor

Documentation/Changelog/12.0/Breaking-96604-RemovedModuleTemplate-addJavaScriptCode.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96604:
+
+==============================================================
+Breaking: #96604 - Removed ModuleTemplate->addJavaScriptCode()
+==============================================================
+
+See :issue:`96604`
+
+Description
+===========
+
+The backend module related class method :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->addJavaScriptCode()`
+has been removed.
+
+The method allowed to add JavaScript inline code to the document
+body of backend modules. This collides with `Content-Security-Policy` HTTP headers
+and needs to be avoided.
+
+The method has been marked :php:`@internal` in late TYPO3 v11 development and
+has been removed in v12.
+
+Impact
+======
+
+Calling the method in an instance triggers a fatal PHP error.
+
+Affected Installations
+======================
+
+The extension scanner finds usage candidates as weak match. In general,
+instances with extensions that come with own backend modules may be affected.
+
+Migration
+=========
+
+There are various ways to migrate away from inline JavaScript in backend modules, a modern TYPO3 v12
+solution is :doc:`JavaScript ES6 modules <Feature-96510-InfrastructureForJavaScriptModulesAndImportmaps>`.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96616-RemoveFrontendLoginModeForPages.rst

@@ -0,0 +1,59 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96616:
+
+=======================================================
+Breaking: #96616 - Remove Frontend Login Mode for pages
+=======================================================
+
+See :issue:`96616`
+
+Description
+===========
+
+In order to reduce complexity for frontend requests,
+the rarely used `frontend user login mode` functionality has been removed.
+
+It previously allowed to define branches, which should behave as if a user
+or usergroup was not logged in, even though a user was kept logged in as the cookie was
+not removed during such a request. This feature was only introduced back in 2004 by Kasper
+to overcome caching issues on typo3.org and is considered an edge-case feature,
+which is better suited in an extension solved via a PSR-15 middleware nowadays.
+
+As a consequence, next to the corresponding DB / TCA field :php:`pages.fe_login_mode`
+the following public methods have been removed:
+
+- :php:`\TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->hideActiveLogin()`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->checkIfLoginAllowedInBranch()`
+
+Additionally, the following TypoScript configuration has no effect anymore:
+
+- :typoscript:`config.sendCacheHeaders_onlyWhenLoginDeniedInBranch`
+
+Impact
+======
+
+The functionality is no longer part of TYPO3 Core. Calling the related methods
+in custom extension code will lead to a fatal PHP error. The extension scanner
+will detect usages as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations currently using the functionality or calling the
+mentioned methods in custom extension code, which is very unlikely.
+
+This can be checked by searching for database records in the DB "pages"
+table having "fe_login_mode > 0".
+
+Migration
+=========
+
+Remove any usage of the mentioned methods.
+
+In case you currently rely on the functionality, use the upgrade wizard
+provided by the install tool to fetch and load the public `fe_login_mode`
+extension from `TER <https://extensions.typo3.org/extension/fe_login_mode>`_.
+This extension provides the same functionality using a PSR-15 middleware.
+
+.. index:: Frontend, TCA, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96641-TypoLinkRelatedHooksRemoved.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96641:
+
+=================================================
+Breaking: #96641 - TypoLink related hooks removed
+=================================================
+
+See :issue:`96641`
+
+Description
+===========
+
+Following hooks, related to link generation with TYPO3's Frontend
+Link building technique `typoLink`, have been removed  in favor of
+the new PSR-14 events :php:`\TYPO3\CMS\Frontend\Event\AfterLinkIsGeneratedEvent`:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['typoLink_PostProc']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['getATagParamsPostProc']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['urlProcessing']['urlProcessors']`
+
+Especially the latter functionality was not available
+for all link types (only mail, file + external links).
+
+At the same time, some external links and mail links were not
+using `typoLink`, because internally the method :php:`$cObj->http_makelinks()`
+had been used.
+
+This architectural design flaw had been solved by introducing
+a unified Link Generation API ("LinkFactory").
+
+Impact
+======
+
+Using these hooks in extensions has no effect anymore in TYPO3 v12+.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using these hooks for
+modifying links. The extension scanner in the Upgrade module / Install
+tool will show affected occurrences.
+
+Migration
+=========
+
+In order to make TYPO3 extensions compatible with TYPO3 v11 and
+TYPO3 v12 simultaneously, the new PSR-14 event :php:`AfterLinkIsGeneratedEvent`
+should be added in addition to the existing hooks.
+
+The new :doc:`PSR-14 event <../12.0/Feature-96641-NewPSR-14EventForModifyingLinks>`
+contains all information about the link result and the configuration itself.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96659-RegistrationOfCObjectsViaTYPO3_CONF_VARS.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96659:
+
+===============================================================
+Breaking: #96659 - Registration of cObjects via TYPO3_CONF_VARS
+===============================================================
+
+See :issue:`96659`
+
+Description
+===========
+
+Since TYPO3 v12.0. custom Content Objects such as `TEXT` or `HMENU`
+are registered via the service configuration.
+
+The previous way of registering custom Content Objects via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['ContentObjects']`
+added in TYPO3 v7.2 (see :issue:`64386`) has been removed.
+
+Impact
+======
+
+TYPO3 installations using the previous way of registering custom or overridden
+Content Objects will not return the rendered frontend output for this specific
+Content Object anymore, which is a very rare case.
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions registering custom Content Objects.
+
+Migration
+=========
+
+Extensions registering custom Content Objects should now use the service
+configuration:
+
+..  code-block:: yaml
+
+    MyCompany\MyPackage\ContentObject\CustomContentObject:
+        tags:
+            - name: frontend.contentobject
+              identifier: 'MY_OBJ'
+
+Extensions can be made compatible with TYPO3 v7 - v12 by keeping the "old"
+way of registration in :file:`ext_localconf.php` and additionally add the new
+registration way, without any further changes.
+
+.. index:: Frontend, TypoScript, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96708-RemovedSupportForAccesskeysInHMENU.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96708:
+
+==========================================================
+Breaking: #96708 - Removed support for accesskeys in HMENU
+==========================================================
+
+See :issue:`96708`
+
+Description
+===========
+
+TYPO3's built-in support for menu generation, adding :html:`accesskey`
+HTML attributes to menu items has been removed.
+
+As stated by various sources such as
+
+* https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey#accessibility_concerns
+* https://webaim.org/standards/wcag/checklist#:~:text=accesskey%20should%20typically%20be%20avoided
+
+this feature should only be used by explicitly defining access keys when
+a use-case is given.
+
+TYPO3 menus previously used a random link title as an access key, when the
+TypoScript property :typoscript:`HMENU.accessKey = 1` was set.
+
+Along with the accessKey functionality, the public property
+:php:`TypoScriptFrontendController->accessKey` has been removed.
+
+Impact
+======
+
+Setting the TypoScript option has no effect anymore.
+
+Accessing the removed public property will trigger a PHP warning. The
+extension scanner will detect usages as weak match.
+
+Affected Installations
+======================
+
+TYPO3 installations using the :typoscript:`accessKey` feature of HMENU or
+accessing the :php:`accessKey` property of :php:`TypoScriptFrontendController`.
+
+TYPO3 installations using the global :html:`accesskey` HTML attribute in
+their own code will still work as before.
+
+Migration
+=========
+
+Using the :html:`accesskey` HTML attribute should be avoided in general, but
+if needed, integrators should add it to their templates in a sensible way,
+depending on the accessibility needs.
+
+.. index:: Frontend, TypoScript, PartiallyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96726-RequestHandlerFunctionalityOfExtbaseRemoved.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96726:
+
+==================================================================
+Breaking: #96726 - RequestHandler functionality of Extbase removed
+==================================================================
+
+See :issue:`96726`
+
+Description
+===========
+
+Extbase - TYPO3's MVC system has had a way to define "RequestHandlers", which
+were primarily introduced back in 2010 to distinguish between Frontend Plugins,
+Backend Modules, CLI commands and Fluid Widgets.
+
+In TYPO3 v8, CLI commands have been migrated to Symfony Console.
+
+Since TYPO3 v9, Backend Requests are not using RequestHandlers anymore.
+
+In TYPO3 v10, the registration of custom RequestHandlers has been moved from
+TypoScript to PHP files (during build time).
+
+In TYPO3 v11, Fluid Widgets have been removed.
+
+The only available support is for Frontend requests (plugin), which could have
+been overridden by custom implementations.
+
+From TYPO3 v12.0 onwards, Extbase Bootstrap for plugins is now calling the
+Extbase dispatcher directly, without loading possible RequestHandlers anymore.
+
+This change removes a layer for each request of a plugin, and thus, a layer
+of indirection.
+
+It is not possible anymore to implement custom RequestHandlers, as all related
+functionality has been removed.
+
+Impact
+======
+
+Registration of custom RequestHandlers will not have any effect anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions registering custom Extbase RequestHandlers.
+This can be checked if an extension provides a
+:file:`Configuration/Extbase/RequestHandlers.php` file or using the
+extension scanner, which will report any usage of the now removed
+:php:`\TYPO3\CMS\Extbase\Mvc\RequestHandlerInterface`.
+
+Migration
+=========
+
+It is recommended to avoid custom RequestHandlers, as their use case is
+limited. For TYPO3 v12-only support, custom RequestHandlers and their
+implementation can be fully removed and developed differently.
+
+For Frontend plugins, it is still possible to use a different bootstrap
+than the :php:`\TYPO3\CMS\Extbase\Core\Bootstrap` class, via TypoScript.
+
+For backend modules, custom :php:`routeTargets` can be defined in the
+module registration concept.
+
+Using the Decorator pattern is usually good practice to achieve such
+functionality.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/12.0/Breaking-96733-RemovedSupportForModuleHandlingBasedOnTBE_MODULES.rst

@@ -0,0 +1,113 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96733:
+
+===========================================================================
+Breaking: #96733 - Removed support for module handling based on TBE_MODULES
+===========================================================================
+
+See :issue:`96733`
+
+Description
+===========
+
+In previous TYPO3 versions, all available Backend modules were stored in the
+global array :php:`$TBE_MODULES`.
+
+Next to a very scattered and dated API to work with this array, it was still
+possible to modify entries of modules through this global array.
+
+With the introduction of the new Module Registration API, the global array is
+not filled anymore since TYPO3 v12.0.
+
+In addition, any previous functionality related to handling of the global array
+has been removed.
+
+The main and foremost important previous API piece
+:php:`TYPO3\CMS\Backend\Module\ModuleLoader` has been removed completely as it
+was usually populated with data of `$TBE_MODULES`.
+
+The PHP classes
+
+* :php:`TYPO3\CMS\Backend\Domain\Model\Module\BackendModule`
+* :php:`TYPO3\CMS\Backend\Domain\Repository\Module\BackendModuleRepository`
+* :php:`TYPO3\CMS\Backend\Module\ModuleStorage`
+
+which were related to building the Module Menu on the left side
+of the TYPO3 Backend have been removed as well. The new API based
+on the :php:`ModuleProvider` takes care of permission handling
+and returns objects of :php:`ModuleInterface`, the
+rendering is now based on a well-defined OOP-based approach, which
+is used throughout all places in TYPO3 Backend in a unified way.
+
+As for TYPO3 Backend Modules, based on Extbase, their additional information
+(allowed controllers and actions) was previously stored in a different
+global array
+:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['extbase']['extensions'][$extensionName]['modules'][$pluginName]['controllers']`
+which has been merged with the Module Registry API and has been removed as well.
+
+Because the registration of modules is now done in the extension's
+:file:`Configuration/Backend/Modules.php` file, the following
+API methods do no longer have any effect and will be removed in
+TYPO3 v13.0:
+
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addModule()`
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addNavigationComponent()`
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addCoreNavigationComponent()`
+- :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule()`
+
+The User TSconfig :typoscript:`options.hideModules.[moduleGroup]` has been
+removed. All modules are registered with a unique identifier. Therefore, the
+TSconfig :typoscript:`options.hideModules` should be used for all modules
+directly. This still allows to hide a whole group, e.g. `web`, next to
+regular modules, such as `web_layout`.
+
+Impact
+======
+
+Accessing or manipulating the now non-existent :php:`$GLOBALS[TBE_MODULES]`
+array will result in a PHP warning.
+
+Referencing any of the removed PHP classes will result in a PHP fatal error.
+
+Using one of the mentioned API methods won't have any effect.
+
+Affected Installations
+======================
+
+TYPO3 installations working with hooks or events effectively reading or
+manipulating the global array `$TBE_MODULES` or accessing any of the removed
+PHP classes / methods by third-party extensions.
+
+Any occurrences can be detected via the Extension Scanner.
+
+Migration
+=========
+
+Migrate to the new Module Registration API, and use the :php:`ModuleProvider`
+class to get allowed modules and work with the objects. The current module
+information (an implementation of :php:`ModuleInterface`) is stored in a
+TYPO3 Backend request within the `module` option of a TYPO3 Backend route,
+which can be accessed via :php:`$request->getAttribute('route')->getOption('module')`.
+
+As soon as the new TYPO3 :php:`BackendModuleValidator` PSR-15 middleware
+has validated the module for the current user, the :php:`ModuleInterface`
+object is also added to the current request and can then be accessed
+via :php:`$request->getAttribute('module')` in custom middlewares or
+components.
+
+.. note::
+
+    With the new module registration, the module identifier is also used
+    as the route identifier. Therefore, the `moduleName` option is removed
+    from the TYPO3 backend route object.
+
+The registration has to be moved from :file:`ext_tables.php` to the
+:file:`Configuration/Backend/Modules.php` file. See the
+:doc:`feature changelog <../12.0/Feature-96733-NewBackendModuleRegistrationAPI>`
+for more information regarding the new registration.
+
+Instead of :typoscript:`options.hideModules.web = layout`, use
+:typoscript:`options.hideModules = web_layout`.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96806-RemovedHookForModifyingButtonBar.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96806:
+
+========================================================
+Breaking: #96806 - Removed hook for modifying button bar
+========================================================
+
+See :issue:`96806`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Backend\Template\Components\ButtonBar']['getButtonsHook']`
+has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Backend\Template\Components\ModifyButtonBarEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-96806-PSR-14EventForModifyingButtonBar>`
+as a direct replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96812-NoFrontendTypoScriptBasedTemplateOverridesInTheBackend.rst

@@ -0,0 +1,256 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96812:
+
+=================================================================================
+Breaking: #96812 - No Frontend TypoScript based template overrides in the backend
+=================================================================================
+
+See :issue:`96812`
+
+Description
+===========
+
+A couple of Core extensions with backend module controllers allowed overriding Fluid
+templates using frontend TypoScript. The two documented extensions are EXT:dashboard
+and the backend page module. The Extbase based backend extensions EXT:belog, EXT:beuser
+and EXT:extensionmanager allowed this implicitly too, but this detail has never
+been directly documented.
+
+This functionality has been removed: All Core extensions, and in general all extensions
+that switch to the :doc:`simplified backend templating <Feature-96730-SimplifiedExtbackendModuleTemplateAPI>`
+no longer use the frontend TypoScript based override approach. This has been superseded
+by a general override strategy based on TSconfig, as described in :doc:`this changelog
+entry <Feature-96812-OverrideBackendTemplatesWithTSconfig>`.
+
+This change became necessary since configuring backend modules via frontend TypoScript
+is flawed by design: It on one hand forces backend modules to parse the full frontend
+TypoScript, which is a general performance penalty in the backend - the backend then
+scales with the amount of frontend TypoScript. Also, the implementation is based on
+the Extbase ConfigurationManager, which leads to the situation that casual non-Extbase
+backend modules have an indirect dependency to lots of Extbase code. But most importantly,
+frontend TypoScript is always bound to a page record. There is no concept in the frontend
+for the "root" page zero, since that page can not be rendered in the frontend. In the backend
+however, we have many modules that are not within page context: In general all modules that
+do not have a page tree. This gives the "Use frontend TypoScript to configure backend modules"
+approach some hard headaches: It forces the ConfigurationManager to still select "some" page as
+frontend TypoScript entry point. In practice, the first non-hidden tree-level-one page
+that has a sys_template record is selected. This strategy is both ugly and troublesome,
+and leads to the situation that backend module configuration had to be bound to this first page,
+which could easily explode when for instance pages are resorted - apart from the fact that
+this scenario is hard to understand and to debug.
+
+Impact
+======
+
+The combination of performance drawbacks, the tight Extbase coupling, and the
+"which frontend TypoScript should be parsed for page zero?" problematic leads to the decision
+to phase out the "frontend TypoScript for backend module configuration" approach that
+Extbase brought in.
+
+One part of this process is a generic backend approach to :doc:`override backend templates
+using TSconfig <Feature-96812-OverrideBackendTemplatesWithTSconfig>`. This has impact
+on EXT:dashboard widgets and page module template overrides.
+
+Affected Installations
+======================
+
+Instances with extensions that configure own EXT:dashboard widgets or override templates
+of existing dashboard widgets using Frontend TypoScript are affected, as well as instances
+that override page module templates as described in :doc:`this changelog entry <../10.3/Feature-90348-NewFluid-basedReplacementForPageLayoutView>`.
+
+Migration
+=========
+
+Page module template overrides
+------------------------------
+
+An instance sets frontend TypoScript like this:
+
+..  code-block:: typoscript
+
+    module.tx_backend.view.templateRootPaths.1644483508 = EXT:myext/Resources/Private/Templates/
+    module.tx_backend.view.partialRootPaths.1644483508 = EXT:myext/Resources/Private/Partials/
+
+If extension "myext" now delivered a template file such as :file:`Resources/Private/Templates/PageLayout/PageLayout.html`,
+that template file was used for rendering the page module instead of the default template.
+
+As described in this :doc:`changelog <Feature-96812-OverrideBackendTemplatesWithTSconfig>`,
+the new definition is now done using TSconfig. The extension "myext" with Composer name "myvendor/myext" can
+deliver a :file:`Configuration/page.tsconfig` file (see :doc:`changelog <Feature-96614-AutomaticInclusionOfPageTsConfigOfExtensions>`)
+with the below content to substitute the old definition and keep overriding template files at the current position:
+
+..  code-block:: typoscript
+
+    # Pattern: templates."composer-name"."something-unique" = "overriding-extension-composer-name":"entry-path"
+    templates.typo3/cms-backend.1644483508 = myvendor/myext:Resources/Private
+
+EXT:dashboard
+-------------
+
+Required changes regarding existing template overrides of the dashboard extension and the
+dashboard widget registration itself are a bit broader. Let's look at this in detail:
+
+Templating
+..........
+
+An extension delivers this TypoScript:
+
+..  code-block:: typoscript
+
+    module.tx_dashboard {
+        view {
+            templateRootPaths {
+                1644485473 = EXT:myext/Resources/Private/Templates/Dashboard/Widgets/
+            }
+        }
+    }
+
+This instructed the dashboard widget renderer to look up widget templates in this
+path, too. The new registration for extension "myext" with Composer name "myvendor/myext"
+using file :file:`Configuration/page.tsconfig`
+(see :doc:`changelog <Feature-96614-AutomaticInclusionOfPageTsConfigOfExtensions>`)
+could look like this:
+
+..  code-block:: typoscript
+
+    # Pattern: templates.typo3/cms-dashboard."something-unique" = "overriding-extension-composer-name":"entry-path"
+    templates.typo3/cms-dashboard.1644485473 = myvendor/myext:Resources/Private
+
+A widget template is then put to :file:`Resources/Private/Templates/Dashboard/Widgets/MyExtensionWidget.html`.
+Extensions that want to stay compatible with both TYPO3 Core v11 and v12 should simply define both the
+old way and the new way.
+
+Widget registration using Services.yaml
+.......................................
+
+This part (changing :file:`Services.yaml` and widgets PHP code) is not strictly needed
+for extensions that configure and deliver own widgets. Extension that work with TYPO3
+v11 just work in v12 as well. However, the registration and PHP code changed a bit,
+extensions that want to stay deprecation log free with v12 should adapt. The changes
+outlined below will be mandatory with v13.
+
+The registration of widgets using :file:`Services.yaml` should be changed a bit. It
+was previously documented that widgets can inject an instance of :php:`StandaloneView`.
+This approach was flawed: The :php:`StandaloneView` has an internal dependency to the
+current PSR-7 request. The request is not available via dependency injection since it is
+a heavily stateful runtime dependency. Injecting a view that depends on request is thus
+a violation and only worked with EXT:dashboard because :php:`StandaloneView` hides that
+dependency internally and creates a new request on the fly, which is a hack in that
+implementation that should be avoided.
+
+The view based on EXT:core :php:`ViewInterface` with its factory for backend views based
+on EXT:backend :php:`BackendViewFactory` makes the dependency to the request object explicit.
+As such, a "prepared" view can not be injected using DI anymore.
+
+This has impact on both the PHP implementation of widgets, as well as the widget
+dependency injection configuration.
+
+Let's say a widget has been registered like this:
+
+..  code-block:: yaml
+
+  # This is defined in EXT:dashboard Services.yaml already, extensions
+  # must not define this in their Services.yaml files again.
+  dashboard.views.widget:
+    class: 'TYPO3\CMS\Fluid\View\StandaloneView'
+    public: true
+    factory: ['TYPO3\CMS\Dashboard\Views\Factory', 'widgetTemplate']
+
+  # This is your custom widget registration in your extensions Services.yaml
+  dashboard.widget.sysLogErrors:
+    class: 'TYPO3\CMS\Dashboard\Widgets\BarChartWidget'
+    arguments:
+      $dataProvider: '@TYPO3\CMS\Dashboard\Widgets\Provider\SysLogErrorsDataProvider'
+      $view: '@dashboard.views.widget'
+      $buttonProvider: '@TYPO3\CMS\Dashboard\Widgets\Provider\SysLogButtonProvider'
+    tags:
+      ...
+
+The important line is :yaml:`$view: '@dashboard.views.widget'`: This instructs the DI
+to inject an instance of :php:`StandaloneView` using the EXT:dashboard :php:`Factory::widgetTemplate()`
+method for argument :php:`$view`. The :yaml:`dashboard.views.widget` is deprecated since
+TYPO3 Core v12 and should not be used anymore. It logs a deprecation message upon use
+during build-time and will be removed in v13 together with the :php:`Factory`.
+
+The new registration should be adapted to this, simply removing the :php:`$view` argument:
+
+..  code-block:: yaml
+
+  # This is your custom widget registration in your extensions Services.yaml
+  dashboard.widget.sysLogErrors:
+    class: 'TYPO3\CMS\Dashboard\Widgets\BarChartWidget'
+    arguments:
+      $dataProvider: '@TYPO3\CMS\Dashboard\Widgets\Provider\SysLogErrorsDataProvider'
+      $buttonProvider: '@TYPO3\CMS\Dashboard\Widgets\Provider\SysLogButtonProvider'
+    tags:
+      ...
+
+Now the PHP implementation. The above example references the :php:`BarChartWidget` class
+to take care of rendering. The class looked like this before (shortened):
+
+..  code-block:: php
+
+    class BarChartWidget implements WidgetInterface
+    {
+        public function __construct(
+            private readonly WidgetConfigurationInterface $configuration,
+            private readonly ChartDataProviderInterface $dataProvider,
+            private readonly StandaloneView $view,
+            private readonly $buttonProvider = null,
+            private readonly array $options = []
+        ) {
+        }
+
+        public function renderWidgetContent(): string
+        {
+            $this->view->setTemplate('Widget/ChartWidget');
+            $this->view->assignMultiple([...]);
+            return $this->view->render();
+        }
+    }
+
+Since :php:`StandaloneView` should not be injected anymore, we now inject the
+:php:`BackendViewFactory` instead and create a view using the factory in
+:php:`renderWidgetContent()`. The factory :php:`create()` method needs the request
+object. To get this, widgets should now implement :php:`RequestAwareWidgetInterface`,
+the EXT:dashboard framework will then :php:`setRequest()` the current request to the widget
+immediately after widget instantiation. The new code thus looks like this:
+
+..  code-block:: php
+
+    class BarChartWidget implements WidgetInterface, RequestAwareWidgetInterface
+    {
+        private ServerRequestInterface $request;
+
+        public function __construct(
+            private readonly WidgetConfigurationInterface $configuration,
+            private readonly ChartDataProviderInterface $dataProvider,
+            private readonly BackendViewFactory $backendViewFactory,
+            private readonly $buttonProvider = null,
+            private readonly array $options = []
+        ) {
+        }
+
+        public function setRequest(ServerRequestInterface $request): void
+        {
+            $this->request = $request;
+        }
+
+        public function renderWidgetContent(): string
+        {
+            // The second argument is the Composer 'name' of the extension that adds the widget.
+            // It is needed to instruct BackendViewFactory to look up templates in this package
+            // next to the default location 'typo3/cms-dashboard', too.
+            $view = $this->backendViewFactory->create($this->request, ['typo3/cms-dashboard', 'myVendor/myPackage']);
+            $view->assignMultiple([...]);
+            return $view->render('Widget/ChartWidget');
+        }
+    }
+
+The actual implementation in TYPO3 v12 is still slightly different to keep
+compatibility with extensions that re-use Core widgets and need v11 and v12
+compatibility at the same time. Those Core classes will be adapted in v13
+to the above outline version, though.
+
+.. index:: Backend, TSConfig, TypoScript, NotScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96829-RemovedBackendUtility-getFuncInput.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96829:
+
+=========================================================
+Breaking: #96829 - Removed BackendUtility->getFuncInput()
+=========================================================
+
+See :issue:`96829`
+
+Description
+===========
+
+Method :php:`BackendUtility::getFuncInput()` is incompatible with
+`Content-Security-Policy` HTTP headers due to its onchange JavaScript
+handler, and has been removed.
+
+Impact
+======
+
+Instances with extensions using the method will raise a fatal
+PHP error upon use.
+
+Affected Installations
+======================
+
+The method is part of very old-school backend module code and of limited use.
+TYPO3 Core code does not use it since at least v9, it is relatively unlikely
+backend modules of extensions still use this method. The extension scanner
+finds usages with a strong match.
+
+Migration
+=========
+
+No direct migration available. The input field HTML should most likely be inlined
+to a template and eventual JavaScript events should be handled with a JavaScript
+module.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96831-EnforceHTMLSanitizerDuringFrontendRendering.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96831:
+
+===================================================================
+Breaking: #96831 - Enforce HTML sanitizer during frontend rendering
+===================================================================
+
+See :issue:`96831`
+
+Description
+===========
+
+TYPO3 security fix `TYPO3-CORE-SA-2021-013 <https://typo3.org/security/advisory/typo3-core-sa-2021-013>`_
+introduced Composer package `typo3/html-sanitizer` to mitigate cross-site scripting vulnerabilities in
+rich-text content. In order to relax the strict invocation, a corresponding feature flag has been added
+in a follow-up release - which only was a temporary solution.
+
+The feature flag `security.frontend.htmlSanitizeParseFuncDefault` is dropped, and content processing via
+TypoScript :typoscript:`stdWrap.parseFunc` now enables HTML sanitization per default in case it has not been
+disabled explicitly in corresponding invocation.
+
+Sites that used a version prior to TYPO3 v12.0 received a corresponding deprecation message already.
+
+Impact
+======
+
+Rich-text content processed with TypoScript :typoscript:`stdWrap.parseFunc` is HTML sanitized per default.
+Feature flag `security.frontend.htmlSanitizeParseFuncDefault` does not have any effect anymore.
+
+Affected Installations
+======================
+
+All scenarios that use TypoScript :typoscript:`stdWrap.parseFunc`, a direct invocation via PHP of
+:php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer::parseFunc()` or Fluid
+view-helper :html:`<f:format.html>`.
+
+Migration
+=========
+
+The following documents already tackled and described the scenario and implications:
+
+* :doc:`9.5.x: Important: #94484 - Introduce HTML Sanitizer <../9.5.x/Important-94484-IntroduceHTMLSanitizer>`
+* :doc:`12.0: Breaking: #96520 - Enforce non-empty configuration in cObj::parseFunc <Breaking-96520-EnforceNon-emptyConfigurationInCObjparseFunc>`
+
+.. index:: Frontend, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96835-HttpsAsDefaultSchemeInPageRouter.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96835:
+
+========================================================
+Breaking: #96835 - https as default scheme in PageRouter
+========================================================
+
+See :issue:`96835`
+
+Description
+===========
+
+The fallback scheme in :php:`\TYPO3\CMS\Core\Routing\PageRouter::generateUri()` is set to `https` instead of `http` when linking to other pages.
+
+Impact
+======
+
+If the site configuration does not provide a scheme but only a domain (e.g. `www.domain.tld`), the scheme is set to `https`.
+
+Affected Installations
+======================
+
+All installations which use a site configuration without providing a scheme and which must not be delivered through `https`.
+
+Migration
+=========
+
+If `https` can't be used, the entry point must define the scheme, e.g. `http://www.domain.tld`.
+
+.. index:: Frontend, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96874-CKEditor-relatedPluginsAndConfiguration.rst

@@ -0,0 +1,106 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96874-1664488429:
+
+=============================================================
+Breaking: #96874 - CKEditor-related plugins and configuration
+=============================================================
+
+See :issue:`96874`
+
+Description
+===========
+
+TYPO3 v12 ships with CKEditor 5, which is a completely new, rewritten editor
+compared to CKEditor 4 which was shipped since TYPO3 v8.
+
+Any kind of plugin, which was written for CKEditor 4 is not compatible anymore.
+
+In addition, since CKEditor 5 does not grant HTML input the same way as before.
+
+Impact
+======
+
+Any plugin in CKEditor will not be loaded anymore in TYPO3 v12.
+
+It might be possible to have data loss when editing and saving data,
+especially since some configuration formats have been changed.
+
+Affected installations
+======================
+
+TYPO3 installations with custom extensions extending CKEditor with plugins,
+or relying on a specific logic to save data with specific contents
+(such as additional allowed HTML tags).
+
+Migration
+=========
+
+In general, it is advised to read the `CKEditor 4 to 5 migration <https://ckeditor.com/docs/ckeditor5/latest/installation/getting-started/migration-from-ckeditor-4.html#plugins>`__
+to understand the conceptual changes, also related to plugins.
+
+Writing a custom plugin for CKEditor 5 can be done in TypeScript or JavaScript,
+using the `CKEditor 5 plugin system <https://ckeditor.com/docs/ckeditor5/latest/installation/advanced/plugins.html>`__.
+
+Example - A timestamp plugin :js:`@my-vendor/my-package/timestamp-plugin.js`
+which adds a toolbar item to add the current timestamp into the editor.
+
+..  code-block:: javascript
+
+    import { Plugin } from '@ckeditor/ckeditor5-core';
+    import { ButtonView } from '@ckeditor/ckeditor5-ui';
+
+    export class Timestamp extends Plugin {
+      static pluginName = 'Timestamp';
+
+      init() {
+        const editor = this.editor;
+
+        // The button must be registered among the UI components of the editor
+        // to be displayed in the toolbar.
+        editor.ui.componentFactory.add(Timestamp.pluginName, () => {
+          // The button will be an instance of ButtonView.
+          const button = new ButtonView();
+
+          button.set({
+            label: 'Timestamp',
+            withText: true
+          });
+
+          // Execute a callback function when the button is clicked
+          button.on('execute', () => {
+            const now = new Date();
+
+            // Change the model using the model writer
+            editor.model.change(writer => {
+
+              // Insert the text at the user's current position
+              editor.model.insertContent(writer.createText(now.toString()));
+            });
+          });
+
+          return button;
+        });
+      }
+    }
+
+In the RTE configuration, this then needs to be added like this:
+
+.. code-block:: yaml
+
+  editor:
+    config:
+      importModules:
+        - { module: '@my-vendor/my-package/timestamp-plugin.js', exports: ['Timestamp'] }
+      toolbar:
+        items:
+          - bold
+          - italic
+          - '|'
+          - clipboard
+          - undo
+          - redo
+          - '|'
+          - timestamp
+
+.. index:: RTE, NotScanned, ext:rte_ckeditor

Documentation/Changelog/12.0/Breaking-96879-RemovedHookGetCacheTimeout.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96879:
+
+===================================================
+Breaking: #96879 - Hook "get_cache_timeout" removed
+===================================================
+
+See :issue:`96879`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['get_cache_timeout']`
+used in TYPO3 Frontend for changing the cache timeout of a page stored in the
+TYPO3 "pages" cache has been removed.
+
+Impact
+======
+
+If an extension has registered a hook in :file:`ext_localconf.php` it will not
+be executed anymore in TYPO3 v12 or later.
+
+Affected Installations
+======================
+
+TYPO3 installations using this hook in custom extensions.
+
+Migration
+=========
+
+Use the newly introduced PSR-14 event :ref:`ModifyCacheLifetimeForPageEvent <feature-96879-1663513042>`
+and register a custom event listener.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96889-RequirePHPMbstringAndIntl.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96889:
+
+================================================
+Breaking: #96889 - Require PHP mbstring and intl
+================================================
+
+See :issue:`96889`
+
+Description
+===========
+
+The two PHP extensions :php:`mbstring` and :php:`intl` are required to
+be loaded when running TYPO3 v12.
+
+:php:`mbstring` is a common extension that is either compiled directly
+into PHP or available as standard package in all distributions and
+operating systems. Similar for :php:`intl`. While there are symfony
+packages that mimic these extensions partially if not available, these
+"polyfill" packages are slower, and most importantly, they implement only
+parts of the native extensions. To further improve TYPO3 character set
+and internationalization handling, the system needs the full functionality.
+
+Impact
+======
+
+System environments not providing these PHP extensions may fail.
+
+Affected Installations
+======================
+
+The install tool "Environment Status" and the reports module notify
+about missing PHP extensions, and it is shown during the installation process.
+
+Migration
+=========
+
+Provide the extensions in the PHP.
+
+A debian / ubuntu based Linux host typically install such packages with
+a command similar to this:
+
+..  code-block:: bash
+
+    sudo apt install php8.1-mbstring php8.1-intl
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-96899-DisplayWarningMessagesHookRemoved.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96899:
+
+========================================================
+Breaking: #96899 - "displayWarningMessages" hook removed
+========================================================
+
+See :issue:`96899`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_befunc.php']['displayWarningMessages']`
+has been removed in favor of a new PSR-14 event
+:php:`\TYPO3\CMS\Backend\Controller\Event\ModifyGenericBackendMessagesEvent`.
+
+The hook was used to display messages in the About module.
+
+Impact
+======
+
+Registered hooks are not executed anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook, which is very
+unlikely. The extension scanner will report possible usages.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <Feature-96899-NewPSR-14EventModifyGenericBackendMessagesEvent>`
+as a direct replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-96904-ExtreportsReportsDoNotReceiveParentObject.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96904:
+
+===================================================================
+Breaking: #96904 - ext:reports reports do not receive parent object
+===================================================================
+
+See :issue:`96904`
+
+Description
+===========
+
+Extensions that add own reports in EXT:reports do not receive an instance
+of :php:`TYPO3\CMS\Reports\Controller\ReportController` as constructor
+argument anymore.
+
+Handing over "parent object" to single reports as manual constructor argument
+was pretty much useless since all state in :php:`ReportController`
+is :php:`protected`. Not having this constructor argument has the advantage
+that reports can now use dependency injection.
+
+Impact
+======
+
+Extensions that register own reports to the EXT:reports extension and type hint
+:php:`ReportController` as constructor argument will trigger a fatal PHP error
+since that argument is no longer provided by the API.
+
+Affected Installations
+======================
+
+Instances with extensions that add own reports to EXT:reports may be affected.
+
+Migration
+=========
+
+Do not expect to retrieve an instance of :php:`ReportController` as constructor
+argument anymore. Code before:
+
+..  code-block:: php
+
+    class MyClass implements ReportInterface
+    {
+        public function __construct(ReportController $reportController)
+        {
+            // ...
+        }
+    }
+
+..  code-block:: php
+
+    class MyClass implements ReportInterface
+    {
+        // No manual constructor argument anymore, but have a dependency injection as example.
+        public function __construct(private readonly SomeDependency $someDependency)
+        {
+        }
+    }
+
+Single reports are currently instantiated using :php:`GeneralUtility::makeInstance()`.
+To use dependency injection in own reports, a report class thus needs to be defined
+:yaml:`public: true` in a :file:`Configuration/Services.yaml` file. This may change with
+further TYPO3 v12 development if the reports registration is changed, though. If in doubt,
+just try to go without :yaml:`public: true`. If this leads to a fatal PHP error, add it.
+
+.. index:: Backend, PHP-API, NotScanned, ext:reports

Documentation/Changelog/12.0/Breaking-96935-RegisterLinkvalidatorLinktypesViaServiceConfiguration.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96935:
+
+=============================================================================
+Breaking: #96935 - Register linkvalidator linktypes via service configuration
+=============================================================================
+
+See :issue:`96935`
+
+Description
+===========
+
+Linkvalidator `linktypes` are now registered via service configuration, also see
+:doc:`feature changelog <Feature-96935-NewRegistrationForLinkvalidatorLinktype>`.
+Therefore the registration via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['checkLinks']`
+has been removed.
+
+Additionally, to be able to use autoconfiguration, the `linktype` identifier
+has to be provided by the service directly using the :php:`getIdentifier()`
+method, which is now required by the :php:`LinktypeInterface`.
+
+In case a custom `linktype` extends
+:php:`\TYPO3\CMS\Linkvalidator\Linktype\AbstractLinktype`,
+only the class property `$identifier` has to be set, e.g.
+:php:`protected string $identifier = 'my_linktype';`.
+
+Impact
+======
+
+Registration of custom `linktypes` via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['checkLinks']`
+is not evaluated anymore.
+
+The :php:`LinktypeInterface` is extended for
+:php:`public function getIdentifier(): string`.
+
+Affected Installations
+======================
+
+All TYPO3 installations using the old registration.
+
+All TYPO3 installations with custom `linktypes`, not implementing
+:php:`public function getIdentifier(): string`.
+
+Migration
+=========
+
+Remove :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['checkLinks']`
+from your :file:`ext_localconf.php` file.
+
+If :yaml:`autoconfigure` is not enabled in your :file:`Configuration/Services.(yaml|php)`,
+add the tag :yaml:`linkvalidator.linktype` manually to your `linktype` service.
+
+..  code-block:: yaml
+
+    Vendor\Extension\Linktype\MyCustomLinktype:
+      tags:
+        - name: linkvalidator.linktype
+
+Additionally, make sure to either implement
+:php:`public function getIdentifier(): string` or, in case your `linktype` extends
+:php:`AbstractLinktype`, to set the `$identifier` class property.
+
+.. index:: Backend, LocalConfiguration, PHP-API, FullyScanned, ext:linkvalidator

Documentation/Changelog/12.0/Breaking-96968-HookHeaderNoCacheRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96968:
+
+===============================================
+Breaking: #96968 - Hook "headerNoCache" removed
+===============================================
+
+See :issue:`96968`
+
+Description
+===========
+
+The previous TYPO3 Hook "headerNoCache" registered via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['headerNoCache']`
+has been removed in favor of a new PSR-14 event
+:php:`ShouldUseCachedPageDataIfAvailableEvent`.
+
+Impact
+======
+
+Hooks in third-party extensions will not be executed anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+Register a new PSR-14 event listener for
+:ref:`ShouldUseCachedPageDataIfAvailableEvent <feature-96968-1663513232>`
+in the extension's :file:`Services.yaml` to keep TYPO3 v12+ compatibility.
+
+Extensions can then provide compatibility with TYPO3 v11 and TYPO3 v12 at
+the same time.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96982-RemovedSupportForGlobalExtensions.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96982:
+
+========================================================
+Breaking: #96982 - Removed support for global extensions
+========================================================
+
+See :issue:`96982`
+
+Description
+===========
+
+Historically, TYPO3 installations could load extensions from :file:`typo3/ext/`
+where developers and site administrators could share extensions through
+multiple installations on the same server via symlinks.
+
+This feature was possible by enabling
+:php:`$GLOBALS[TYPO3_CONF_VARS][EXT][allowGlobalInstall]` which was disabled
+by default since TYPO3 4.0, as using this feature had several downsides with
+Non-Composer based installations. Features such as "Automatic Updates" are
+not possible having this functionality enabled.
+
+In Composer-based installations, this functionality was never supported in
+a proper way.
+
+This functionality including the feature toggle have been removed in TYPO3 v12.0.
+
+Impact
+======
+
+Extensions within the folder :file:`typo3/ext/` will be ignored in TYPO3 v12.0
+and will be automatically disabled.
+
+The global option to enable this feature will be removed from
+:file:`LocalConfiguration.php` automatically once the Install Tool / Maintenance module
+is loaded the next time, if the option is activated.
+
+Affected Installations
+======================
+
+TYPO3 installations having the global option enabled, and have loaded extensions
+in :file:`typo3/ext/`, which is unlikely in 2022.
+
+Migration
+=========
+
+It is recommended to either migrate to Composer Mode, or to use symlinks
+into :file:`typo3conf/ext/` (Local Extensions) to load the same extension for
+multiple TYPO3 installations at once.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/12.0/Breaking-96983-TableColumnSubType.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96983:
+
+=====================================
+Breaking: #96983 - TableColumnSubType
+=====================================
+
+See :issue:`96983`
+
+Description
+===========
+
+The class :php:`TYPO3\CMS\Core\Type\Enumeration\TableColumnSubType` has been
+removed. It has no use anymore, since TCA option `internal_type` is not
+evaluated. It was set for the Extbase class :php:`ColumnMap`, but even there it
+had no direct usage.
+
+Impact
+======
+
+In the rare case, that the class :php:`TableColumnSubType` is used in
+custom code, it will result in a PHP fatal error.
+
+Affected Installations
+======================
+
+All installations that use :php:`TableColumnSubType` directly in their custom
+code.
+
+Migration
+=========
+
+There is no migration, since this enumeration has no use.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/12.0/Breaking-96988-GlobalOptionAllowLocalInstallRemoved.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96988:
+
+============================================================
+Breaking: #96988 - Global Option "allowLocalInstall" removed
+============================================================
+
+See :issue:`96988`
+
+Description
+===========
+
+In previous TYPO3 version it was possible to disable the functionality to
+install extensions from :file:`typo3conf/ext/`.
+
+This was done by setting the global option
+:php:`$GLOBALS['TYPO3_CONF_VARS']['EXT']['allowLocalInstall']` to false.
+
+The usefulness of this functionality was only a side-effect and has lost it even
+more after the rise of the Composer Mode for TYPO3 Core.
+
+In addition, this option is only useful in the Extension Manager which is now
+protected with access for only "System Maintainers", only giving special users
+the power to modify the extension installation process, making TYPO3 more
+flexible than 15 years ago.
+
+Impact
+======
+
+Toggling the option (which was enabled by default) has no effect anymore. It is
+now always possible to install an extension available in :file:`typo3conf/ext/`
+for system maintainers with the Extension Manager module for Non-Composer Mode
+TYPO3 installations.
+
+Affected Installations
+======================
+
+TYPO3 Installations in Non-Composer Mode having this option turned off, which
+is very rare.
+
+Migration
+=========
+
+It is recommended to set proper access rights and only give users
+"System Maintainer" access which should modify the list of active extensions.
+
+.. index:: Backend, FullyScanned, ext:extensionmanager

Documentation/Changelog/12.0/Breaking-96996-HookCheckEnableFieldsRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96996:
+
+===================================================
+Breaking: #96996 - Hook "checkEnableFields" removed
+===================================================
+
+See :issue:`96996`
+
+Description
+===========
+
+The previous TYPO3 Hook "hook_checkEnableFields" registered via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_checkEnableFields']`
+has been removed in favor of a new PSR-14 event
+:php:`TYPO3\CMS\Core\Domain\Access\RecordAccessGrantedEvent`.
+
+Impact
+======
+
+Hooks in third-party extensions will not be executed anymore.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook. The
+extension scanner will notify about usages.
+
+Migration
+=========
+
+Register a new PSR-14 event listener for :ref:`RecordAccessGrantedEvent <feature-96996-1663513388>`
+in the extension's :file:`Services.yaml` to keep TYPO3 v12+ compatibility.
+
+Extensions can then provide compatibility with TYPO3 v11 and TYPO3 v12 at
+the same time.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-96998-ExtbaseValidatorInterfaceChanged.rst

@@ -0,0 +1,124 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-96998:
+
+======================================================
+Breaking: #96998 - Extbase validator interface changed
+======================================================
+
+See :issue:`96998`
+
+Description
+===========
+
+The Extbase related interface :php:`TYPO3\CMS\Extbase\Validation\Validator\ValidatorInterface`
+has been changed by requiring :php:`setOptions()` method and being more strict in general.
+
+Additionally, :php:`TYPO3\CMS\Extbase\Validation\Validator\AbstractValidator` signatures
+have been hardened.
+
+Furthermore, all default validators delivered by EXT:extbase and EXT:form are declared final.
+
+Following this, the framework no longer hands over :php:`options` array as constructor
+argument, and no abstract implements :php:`__construct()` anymore. Classes that implement
+:php:`ValidatorInterface` are automatically set "public" and "not-shared" by the framework,
+they do not need to set this themselves. See the
+:doc:`preparation in TYPO3 v11 <../11.5.x/Important-96332-ExtbaseValidatorsCanUseDependencyInjection>`
+for more details on this. As a result, Extbase validators can now use dependency injection.
+
+Impact
+======
+
+This has impact on custom Extbase validators which *may* need to adapt their method signatures.
+Extensions that don't follow this in TYPO3 v12 may trigger fatal PHP errors.
+
+Affected Installations
+======================
+
+Extensions with custom validators may be affected. In general, all extension classes that
+directly implement :php:`ValidatorInterface` or extend :php:`AbstractValidator` may be
+affected. The extension scanner can not find affected extensions, but IDE's should
+show violating classes.
+
+Migration
+=========
+
+The most casual case is that custom extension validators simply extend :php:`AbstractValidator`.
+Those just have to adjust their :php:`isValid()` method signature to :php:`isValid($value): void` to
+keep TYPO3 v11 & v12 compatibility. Read on for rare cases where this is not sufficient.
+
+First, it is no longer allowed to extend specific validators of EXT:extbase and EXT:form.
+Those are "leaf" classes, and extensions should not extend them, giving the Core more
+freedom to change those classes if needed. Extensions should instead extend the provided
+abstract classes like :php:`AbstractValidator` to implement own validators.
+
+Since most custom validators inherit :php:`AbstractValidator`, the most important change
+for these validator is a return type change of :php:`isValid()`:
+
+..  code-block:: php
+
+    public function isValid(mixed $value): void
+
+Extensions that need to stay compatible with v11 (PHP 7.4) and v12, will thus typically
+use a signature like below: Set the return type constraint, but omit the 'mixed' argument type:
+
+..  code-block:: php
+
+    public function isValid($value): void
+
+With a closer look at the :php:`ValidatorInterface`, the v11 version
+effectively looks like this:
+
+..  code-block:: php
+
+    interface ValidatorInterface
+    {
+        public function validate($value);
+        public function getOptions();
+    }
+
+This has been changed in v12 to this:
+
+..  code-block:: php
+
+    interface ValidatorInterface
+    {
+        public function validate(mixed $value): Result;
+        public function setOptions(array $options): void;
+        public function getOptions(): array;
+    }
+
+In any case, custom validators must implement :php:`setOptions()` now. The
+:php:`AbstractValidator` does that automatically, so this has little impact since
+most custom validators will extend :php:`AbstractValidator` anyways.
+
+Extensions tailored for TYPO3 v12 and above simply implement these. Extensions that
+need to keep compatibility with v11 and v12 need to adjust some additional type juggling.
+In general, implementing classes can *relax* method argument types (e.g. avoid :php:`mixed`
+to stay PHP 7.4 compatible), but *must follow* more restricted return type constraints of
+younger interfaces.
+
+A v11 & v12 compatible method signature looks like this (avoiding the :php:`mixed` keyword
+on :php:`validate`):
+
+..  code-block:: php
+
+    class MyValidator implements ValidatorInterface
+    {
+        public function setOptions(array $options): void
+        {
+            // ...
+        }
+
+        public function validate($value): Result
+        {
+            // ...
+        }
+
+        public function getOptions(): array
+        {
+            return $this->options;
+        }
+    }
+
+.. index:: PHP-API, NotScanned, ext:extbase, ext:form

Documentation/Changelog/12.0/Breaking-97065-TYPO3FrontendAlwaysRenderedInUTF-8.rst

@@ -0,0 +1,58 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97065:
+
+==========================================================
+Breaking: #97065 - TYPO3 Frontend always rendered in UTF-8
+==========================================================
+
+See :issue:`97065`
+
+Description
+===========
+
+For historical reasons, it was possible to change the actual rendering charset
+of TYPO3's Frontend Output to a specific character set, and also to modify the
+"renderCharset", which was removed in TYPO3 v8.0. Since TYPO3 v6, the default
+rendering output was set to "utf-8", and nowadays, it has become a niche
+to change the output rendering charset to a different value than UTF-8.
+
+For this reason, the TypoScript setting :typoscript:`config.metaCharset` has no effect
+anymore as all rendering for Frontend is "utf-8" and not changeable anymore.
+
+If this TypoScript setting was set to "utf-8" in previous installations,
+this line could have been removed anyways already.
+
+The public PHP property :php:`TypoScriptFrontendController->metaCharset` is
+removed, along with the public method
+:php:`TypoScriptFrontendController->convOutputCharset()`.
+
+Impact
+======
+
+TYPO3 installations with a different setting than "utf-8" will now output
+"utf-8" output at all times.
+
+TYPO3 extensions accessing the removed property will trigger a PHP warning, or
+calling the removed method :php:`convOutputCharset()` will see a fatal PHP error.
+
+Affected Installations
+======================
+
+TYPO3 installations using :typoscript:`config.metaCharset` set to a value other than
+`utf-8`, or accessing the removed property or method. The Extension Scanner
+in the Install Tool will detect usages of the removed property and method.
+
+Migration
+=========
+
+TYPO3 Installations with a different charset than UTF-8 should convert their own
+content in a custom middleware, as this specific use-case is not supported by
+TYPO3 Core anymore.
+
+TYPO3 installations with TypoScript option set :typoscript:`config.metaCharset = utf-8` can
+remove the TypoScript line in previous supported TYPO3 versions.
+
+Any usage of the removed property / method should be removed.
+
+.. index:: Frontend, PHP-API, TypoScript, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97091-TSFE-clear_previewHasBeenRemoved.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97091:
+
+=======================================================
+Breaking: #97091 - TSFE->clear_preview has been removed
+=======================================================
+
+See :issue:`97091`
+
+Description
+===========
+
+The method :php:`clear_preview` of the :php:`TypoScriptFrontendController` has been removed.
+
+Impact
+======
+
+Calling the method will result in a PHP Fatal Error.
+
+Affected Installations
+======================
+
+All installations calling the :php:`clear_preview` method
+
+Migration
+=========
+
+Build your own :php:`clear_preview` method:
+
+..  code-block:: php
+
+    $context = GeneralUtility::makeInstance(Context::class);
+    $GLOBALS['SIM_EXEC_TIME'] = $GLOBALS['EXEC_TIME'];
+    $GLOBALS['SIM_ACCESS_TIME'] = $GLOBALS['ACCESS_TIME'];
+    $context->setAspect(
+        'frontend.preview',
+        GeneralUtility::makeInstance(PreviewAspect::class)
+    );
+    $context->setAspect(
+        'date',
+        GeneralUtility::makeInstance(
+            DateTimeAspect::class,
+            (new \DateTimeImmutable())->setTimestamp($GLOBALS['SIM_EXEC_TIME'])
+        )
+    );
+    $context->setAspect(
+        'visibility',
+        GeneralUtility::makeInstance(VisibilityAspect::class)
+    );
+
+.. index:: Frontend, PHP-API, PartiallyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97126-RemoveTCEformsArrayKeyInFlexForm.rst

@@ -0,0 +1,79 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97126:
+
+========================================================
+Breaking: #97126 - Remove TCEforms array key in FlexForm
+========================================================
+
+See :issue:`97126`
+
+Description
+===========
+
+As a result of :doc:`#97126 <../12.0/Deprecation-97126-TCEformsRemovedInFlexForm>`
+the `TCEforms` key has been removed from the FlexForm array. Code, that deals
+with the FlexForm result array directly and accesses this key, may break.
+
+Impact
+======
+
+In rare cases, where custom extensions deal with the parsed FlexForm array
+structure directly and relying on the presence of the :php:`TCEforms` key, an
+undefined array key warning may appear and the logic won't work any longer.
+
+Affected Installations
+======================
+
+All installations, which deal with parsed FlexForm arrays directly and using the
+:php:`TCEforms` key.
+
+This **may** happen when:
+
+*  Using :php:`FlexFormTools->parseDataStructureByIdentifier()` directly
+*  Using or extending a :php:`FormDataProvider` and accessing the :php:`$result['processedTca']` array
+
+.. note::
+
+    Since a long time, the :php:`TCEforms` key has already been removed in the
+    :php:`TcaFlexPrepare` FormDataProvider. It is advised to set this provider
+    as a dependency, when relying on prepared FlexForm TCA, in custom providers.
+
+Migration
+=========
+
+Search your PHP code for the presence of the string `TCEforms` inside of arrays
+and remove it. In case you need to support two TYPO3 versions simultaneously,
+check if the key exists or not and adjust your array access accordingly.
+
+Real world example from EXT:news:
+
+Before:
+
+..  code-block:: php
+
+    if (!empty($categoryRestriction) && isset($structure['sheets']['sDEF']['ROOT']['el']['settings.categories'])) {
+        $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['TCEforms']['config']['foreign_table_where'] = $categoryRestriction . $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['TCEforms']['config']['foreign_table_where'];
+    }
+
+After:
+
+..  code-block:: php
+
+    if (!empty($categoryRestriction) && isset($structure['sheets']['sDEF']['ROOT']['el']['settings.categories'])) {
+        $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['config']['foreign_table_where'] = $categoryRestriction . $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['config']['foreign_table_where'];
+    }
+
+Supporting both TYPO3 v11 and v12+:
+
+..  code-block:: php
+
+    if (!empty($categoryRestriction) && isset($structure['sheets']['sDEF']['ROOT']['el']['settings.categories'])) {
+        if (isset($structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['TCEforms'])) {
+            $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['TCEforms']['config']['foreign_table_where'] = $categoryRestriction . $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['TCEforms']['config']['foreign_table_where'];
+        } else {
+            $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['config']['foreign_table_where'] = $categoryRestriction . $structure['sheets']['sDEF']['ROOT']['el']['settings.categories']['config']['foreign_table_where'];
+        }
+    }
+
+.. index:: FlexForm, TCA, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97131-RemovedCLICommandsRelatedToFilesInUploadsFolder.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97131:
+
+===========================================================================
+Breaking: #97131 - Removed CLI commands related to files in uploads/ folder
+===========================================================================
+
+See :issue:`97131`
+
+Description
+===========
+
+Historically, TYPO3 managed its actual files in a folder called
+:file:`uploads/` until the `File Abstraction Layer` has been introduced
+in TYPO3 v6.0. The old compatibility layer using :file:`uploads/` as
+file storage folder has been removed in TYPO3 v10.
+
+TYPO3 still has had some CLI commands which have now been
+removed as they do not serve any use anymore:
+
+* cleanup:multiplereferencedfiles
+* cleanup:lostfiles
+* cleanup:missingfiles
+
+Impact
+======
+
+Calling the CLI commands will result in an CLI exit code > 0,
+as they have been removed.
+
+Affected Installations
+======================
+
+TYPO3 installations still having CLI tools using the CLI commands,
+which serve no purpose anymore.
+
+Migration
+=========
+
+None.
+
+.. index:: CLI, NotScanned, ext:lowlevel

Documentation/Changelog/12.0/Breaking-97135-RemovedSupportForModuleHandlingBasedOnTBE_MODULES_EXT.rst

@@ -0,0 +1,127 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97135:
+
+===============================================================================
+Breaking: #97135 - Removed support for module handling based on TBE_MODULES_EXT
+===============================================================================
+
+See :issue:`97135`
+
+Description
+===========
+
+Previously it had been possible to add additional functionality to TYPO3
+backend modules, such as :guilabel:`Web > Info` or :guilabel:`Web > Template`,
+using the :php:`ExtensionManagementUtility::insertModuleFunction()` API method,
+which attached a new entry to the global :php:`TBE_MODULES_EXT` array.
+
+Since the introduction of the new
+:doc:`Module Registration API <Feature-96733-NewBackendModuleRegistrationAPI>`,
+all modules are registered in the dedicated :file:`Configuration/Backend/Modules.php`
+configuration file. Additional modules, or "third-level modules" are now also
+registered via the new mechanism.
+
+Therefore, the :php:`$GLOBALS['TBE_MODULES_EXT']` has been removed, while the
+corresponding :php:`ExtensionManagementUtility::insertModuleFunction()` API
+method has no effect.
+
+The related page TSconfig options :typoscript:`mod.web_info.menu.function`
+as well as :typoscript:`mod.web_ts.menu.function` have been removed in favor
+of the existing :typoscript:`hideModules` user TSconfig option and the module
+access logic, which due to the new registration, now also covers those modules.
+
+Additionally, the following hooks have been removed, because their use cases
+does no longer exist:
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Tstemplate\Controller\TypoScriptTemplateModuleController']['newStandardTemplateView']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Tstemplate\Controller\TypoScriptTemplateModuleController']['newStandardTemplateHandler']`
+
+Impact
+======
+
+The global :php:`TBE_MODULES_EXT` array does no longer exist and the
+:php:`ExtensionManagementUtility::insertModuleFunction()` API method no
+longer has any effect.
+
+The page TSconfig options :typoscript:`mod.web_info.menu.function`
+and :typoscript:`mod.web_ts.menu.function` are no longer evaluated.
+
+Using one of mentioned, :php:`TypoScriptTemplateModuleController` related
+hooks does no longer have any effect.
+
+Affected Installations
+======================
+
+All installations using the global :php:`TBE_MODULES_EXT` array or
+calling :php:`ExtensionManagementUtility::insertModuleFunction()` in
+custom extension code.
+
+All installations using one of the removed page TSconfig options or one
+of the removed hooks.
+
+Migration
+=========
+
+Register your "third-level" module in our extension's
+:file:`Configuration/Backend/Modules.php` file.
+
+Previous configuration in :file:`ext_tables.php`:
+
+..  code-block:: php
+
+    ExtensionManagementUtility::insertModuleFunction(
+        'web_info',
+        MyAdditonalInfoModuleController::class,
+        '',
+        'LLL:EXT:extkey/Resources/Private/Language/locallang.xlf:mod_title'
+    );
+
+Will now be registered in :file:`Configuration/Backend/Modules.php`:
+
+..  code-block:: php
+
+    'web_info_additional' => [
+        'parent' => 'web_info',
+        'access' => 'user',
+        'path' => '/module/web/info/additional',
+        'iconIdentifier' => 'module-my-icon-identifier',
+        'labels' => [
+            'title' => 'LLL:EXT:extkey/Resources/Private/Language/locallang.xlf:mod_title',
+        ],
+        'routes' => [
+            '_default' => [
+                'target' => MyAdditonalInfoModuleController::class . '::handleRequest',
+            ],
+        ],
+    ],
+
+To hide a "third-level" module in the doc header menu, use the user TSconfig
+:typoscript:`options.hideModules` option:
+
+..  code-block:: typoscript
+    :caption: **Page** TSconfig
+
+    # before
+    mod.web_info.menu.function.TYPO3\CMS\Info\Controller\TranslationStatusController = 0
+
+
+..  code-block:: typoscript
+    :caption: **User** TSconfig
+
+    # after
+    options.hideModules := addToList(web_info_translations)
+
+.. note::
+
+    While the previously used TSconfig options `mod.*.menu.function` are bound
+    to a page is the new `options.hideModules` option based on user and user
+    group level. This allows greater influence and furthermore allows to hide
+    any module, even if the module is not connected to a page.
+
+Additionally, use the module access logic to restrict access to those modules.
+
+Remove any registration of the mentioned hooks. There is no direct migration,
+since the use cases for those hooks do no longer exist.
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97174-RemovedHookForModifyingInfoModuleFooterContent.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97174:
+
+========================================================================
+Breaking: #97174 - Removed hook for modifying info module footer content
+========================================================================
+
+See :issue:`97174`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms/web_info/class.tx_cms_webinfo.php']['drawFooterHook']`
+has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Info\Controller\Event\ModifyInfoModuleContentEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97174-PSR-14EventForModifyingInfoModuleContent>`
+as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:info

Documentation/Changelog/12.0/Breaking-97187-RemovedHookForModifyingLinkExplanation.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97187:
+
+==============================================================
+Breaking: #97187 - Removed hook for modifying link explanation
+==============================================================
+
+See :issue:`97187`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['linkHandler']`
+has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Backend\Form\Event\ModifyLinkExplanationEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97187-PSR-14EventForModifyingLinkExplanation>`
+as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97188-RegisterElementBrowsersViaServiceConfiguration.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97188:
+
+======================================================================
+Breaking: #97188 - Register element browsers via service configuration
+======================================================================
+
+See :issue:`97188`
+
+Description
+===========
+
+The `element browsers` in EXT:backend are now registered via service
+configuration, see the :doc:`feature changelog <Feature-97188-NewRegistrationForElementBrowsers>`.
+Therefore the registration via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ElementBrowsers']`
+has been removed.
+
+Additionally, to be able to use autoconfiguration, the `element browser`
+identifier has to be provided by the service directly using the
+:php:`getIdentifier()` method, which is now required by the
+:php:`ElementBrowserInterface`.
+
+In case a custom `element browser` extends
+:php:`\TYPO3\CMS\Backend\Browser\AbstractElementBrowser`,
+only the class property `$identifier` has to be set, e.g.
+:php:`protected string $identifier = 'my_browser';`.
+
+Impact
+======
+
+Registration of custom `element browsers` via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ElementBrowsers']`
+is not evaluated anymore.
+
+The :php:`ElementBrowserInterface` is extended for
+:php:`public function getIdentifier(): string`.
+
+Affected Installations
+======================
+
+All TYPO3 installations using the old registration.
+
+All TYPO3 installations with custom `element browsers`, not implementing
+:php:`public function getIdentifier()`.
+
+Migration
+=========
+
+Remove :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ElementBrowsers']`
+from your :file:`ext_localconf.php` file.
+
+If :yaml:`autoconfigure` is not enabled in your :file:`Configuration/Services.(yaml|php)`,
+add the tag :yaml:`recordlist.elementbrowser` manually to your `element browser` service.
+
+..  code-block:: yaml
+
+    Vendor\Extension\Recordlist\MyBrowser:
+      tags:
+        - name: recordlist.elementbrowser
+
+Additionally, make sure to either implement
+:php:`public function getIdentifier(): string` or, in case your `element browser`
+extends :php:`AbstractElementBrowser`, to set the `$identifier` class property.
+
+.. index:: Backend, LocalConfiguration, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97201-RemovedHookForNewContentElementWizard.rst

@@ -0,0 +1,58 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97201:
+
+==============================================================
+Breaking: #97201 - Removed hook for new content element wizard
+==============================================================
+
+See :issue:`97201`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms']['db_new_content_el']['wizardItemsHook']`
+has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Backend\Controller\Event\ModifyNewContentElementWizardItemsEvent`.
+
+Additionally, the :php:`params` property of a wizard item has been
+removed, since it just duplicated the default values, configured with
+:php:`tt_content_defValues` and therefore previously required extension
+authors to provide the same information twice in two different formats.
+
+.. note::
+
+    The public methods :php:`getPageInfo()`, :php:`getColPos()`,
+    :php:`getSysLanguage()` and :php:`getUidPid()` have been removed
+    from the internal :php:`NewContentElementController` class, since
+    they were only added for the use in the now removed hook. This
+    information is now directly available in the new PSR-14 event.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore
+in TYPO3 v12.0+.
+
+The :php:`params` property on a wizard item is no longer evaluated.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+TYPO3 installations setting the :php:`params` property on a wizard item.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97201-PSR-14EventForModifyingNewContentElementWizardItems>`
+to allow greater influence in the functionality.
+
+Migrate the :php:`params` property to :php:`tt_content_defValues` or just
+remove :php:`params` in case the information had already been configured
+for both properties.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97210-TypesAddedToMethodSignaturesOrClassProperties.rst

@@ -0,0 +1,79 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97210:
+
+=======================================================================
+Breaking: #97210 - Types added to method signatures or class properties
+=======================================================================
+
+See :issue:`97210`
+
+Description
+===========
+
+The following PHP classes have had parameter and return types added to some or
+all of their method signatures. The types are consistent with existing
+docblock-documented type expectations and existing behavior.
+
+- :php:`\TYPO3\CMS\Adminpanel\ModuleApi\ModuleDataStorageCollection`
+- :php:`\TYPO3\CMS\Backend\Tree\SortedTreeNodeCollection`
+- :php:`\TYPO3\CMS\Backend\Tree\TreeNodeCollection`
+- :php:`\TYPO3\CMS\Core\Collection\AbstractRecordCollection`
+- :php:`\TYPO3\CMS\Core\LinkHandling\FileLinkHandler`
+- :php:`\TYPO3\CMS\Core\Log\LogRecord`
+- :php:`\TYPO3\CMS\Core\Messaging\FlashMessageQueue`
+- :php:`\TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider`
+- :php:`\TYPO3\CMS\Core\Resource\Collection\AbstractFileCollection`
+- :php:`\TYPO3\CMS\Core\Resource\MetaDataAspect`
+- :php:`\TYPO3\CMS\Core\Resource\Search\Result\EmptyFileSearchResult`
+- :php:`\TYPO3\CMS\Core\Routing\SiteRouteResult`
+- :php:`\TYPO3\CMS\Core\Utility\ArrayUtility`
+- :php:`\TYPO3\CMS\Core\Utility\ClassNamingUtility`
+- :php:`\TYPO3\CMS\Core\Utility\CsvUtility`
+- :php:`\TYPO3\CMS\Core\Utility\CommandUtility`
+- :php:`\TYPO3\CMS\Core\Utility\DebugUtility`
+- :php:`\TYPO3\CMS\Core\Utility\DiffUtility`
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility`
+- :php:`\TYPO3\CMS\Core\Utility\MailUtility`
+- :php:`\TYPO3\CMS\Core\Utility\MathUtility`
+- :php:`\TYPO3\CMS\Core\Utility\PathUtility`
+- :php:`\TYPO3\CMS\Core\Utility\RootlineUtility`
+- :php:`\TYPO3\CMS\Core\Utility\StringUtility`
+- :php:`\TYPO3\CMS\Core\Utility\VersionNumberUtility`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\Arguments`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyObjectStorage`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyLoadingProxy`
+- :php:`\TYPO3\CMS\Extbase\Persistence\ObjectStorage`
+- :php:`\TYPO3\CMS\Extbase\Persistence\QueryResult`
+
+The following PHP classes have added public class property types:
+
+- :php:`\TYPO3\CMS\Core\Utility\DiffUtility`
+
+Impact
+======
+
+Calling any of these methods with incompatible types now throws a :php:`\TypeError`,
+especially if the calling code is within :php:`declare(strict_types=1);` context.
+Before the result of such method calls was undefined or inconsistent.
+
+Affected Installations
+======================
+
+Code routines that are passing an invalid type will need to ensure they pass a correct type.
+
+If a code file is running with :php:`declare(strict_types=1);`, that includes, for instance,
+passing a numeric string to a method that expects an int or float. Those will need to be
+properly cast before being passed.
+
+The extension scanner will not find affected extensions.
+
+Migration
+=========
+
+Any code that is already passing the expected type to these methods will be unaffected.
+Code that is passing an incorrect type will need to pass the correct type, possibly
+including an explicit cast.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97214-UseUploadedFileObjectsInsteadOf_FILES.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97214:
+
+==============================================================
+Breaking: #97214 - Use UploadedFile objects instead of $_FILES
+==============================================================
+
+See :issue:`97214`
+
+Description
+===========
+
+The TYPO3 request already contains a "disentangled" array of UploadedFile
+objects. With this change, these UploadedFile objects are now used instead
+of the superglobal :php:`$_FILES` in Extbase requests.
+
+Additionally, the FAL ResourceStorage has been adjusted for handling
+UploadedFile objects and the ExtensionManager upload handling has been
+adjusted.
+
+The next step would be to further adjust FAL to use only PSR provided
+methods for handling uploaded files and implementing an API for file
+uploads in Extbase.
+
+Impact
+======
+
+The global :php:`$_FILES` object is not used in Extbase or the extension
+manager anymore, instead the PSR request is used.
+
+Affected Installations
+======================
+
+All installations extending the TYPO3 Core ResourceStorage object and
+overwriting the :php:`addUploadedFile` method.
+
+Migration
+=========
+
+Extension authors extending the TYPO3 Core resource storage and implementing
+their own handling of :php:`addUploadedFile` need to allow objects of type
+:php:`UploadedFile` in addition to the old array from global :php:`$_FILES`.
+
+To do so, switch the type annotation to :php:`array|UploadedFile` and add code that
+handles :php:`UploadedFile` objects and arrays.
+
+Example
+^^^^^^^
+
+..  code-block:: php
+
+    if ($uploadedFileData instanceof UploadedFile) {
+        $localFilePath = $uploadedFileData->getTemporaryFileName();
+        if ($targetFileName === null) {
+            $targetFileName = $uploadedFileData->getClientFilename();
+        }
+        $size = $uploadedFileData->getSize();
+    } else {
+        $localFilePath = $uploadedFileData['tmp_name'];
+        if ($targetFileName === null) {
+            $targetFileName = $uploadedFileData['name'];
+        }
+        $size = $uploadedFileData['size'];
+    }
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/12.0/Breaking-97230-RemovedHookForModifyingImageManipulationPreviewUrl.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97230:
+
+============================================================================
+Breaking: #97230 - Removed hook for modifying image manipulation preview URL
+============================================================================
+
+See :issue:`97230`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Backend/Form/Element/ImageManipulationElement']['previewUrl']`
+has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Backend\Form\Event\ModifyImageManipulationPreviewUrlEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97230-PSR-14EventForModifyingImageManipulationPreviewUrl>`
+as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97231-RemovedHookForManipulatingInlineElementControls.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97231:
+
+========================================================================
+Breaking: #97231 - Removed hook for manipulating inline element controls
+========================================================================
+
+See :issue:`97231`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tceforms_inline.php']['tceformsInlineHook']`
+has been removed in favor of the new PSR-14 events :php:`\TYPO3\CMS\Backend\Form\Event\ModifyInlineElementEnabledControlsEvent`
+and :php:`\TYPO3\CMS\Backend\Form\Event\ModifyInlineElementControlsEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore
+in TYPO3 v12.0+.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 events <../12.0/Feature-97231-PSR-14EventsForModifyingInlineElementControls>`
+to allow greater influence in the functionality.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97243-RemoveGlobalJQueryAccessViaWindow.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97243:
+
+===========================================================
+Breaking: #97243 - Remove global jQuery access via window.$
+===========================================================
+
+See :issue:`97243`
+
+Description
+===========
+
+The global :js:`window.$` accessor to the jQuery instance is now no longer
+provided.
+
+Global jQuery usage has been deprecated in :issue:`86438` with the suggestion to
+use JavaScript modules instead. With the integration of browser native ES6
+modules jQuery should now be loaded as a regular module.
+
+Impact
+======
+
+Loading the ES6 'jquery' module no longer has side effects, as the global
+scope :js:`window` is no longer polluted by writing to the property :js:`$`.
+This renders any :js:`jQuery.noConflict()` workarounds unneeded.
+
+Affected Installations
+======================
+
+All installations that use `$` to invoke jQuery in inline JavaScripts or
+custom JavaScript modules that miss to define their jQuery import, and
+implicitly used the global before.
+
+Migration
+=========
+
+Migrate to ES6 JavaScript modules and use :js:`import $ from 'jquery';` instead.
+
+.. index:: Backend, JavaScript, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97265-SimplifiedAccessModeSystem.rst

@@ -0,0 +1,117 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97265:
+
+================================================
+Breaking: #97265 - Simplified access mode system
+================================================
+
+See :issue:`97265`
+
+Description
+===========
+
+In preparation of a deployable backend access rights system based on
+configuration files, some rarely used details of the permission system
+have been streamlined and simplified:
+
+* The global configuration option :php:`TYPO3_CONF_VARS['BE']['explicitADmode']`
+  has been removed and is not evaluated anymore.
+
+* The only valid value for TCA config option :php:`authMode` on :php:`'type' => 'select'`
+  fields is now :php:`explicitAllow`. The values :php:`explicitDeny` and :php:`individual`
+  are invalid and no longer evaluated.
+
+* With removal of :php:`authMode' => 'individual'` for TCA select fields, the sixth
+  :php:`items` option is obsolete and removed. The values :php:`EXPL_ALLOW` and
+  :php:`EXPL_DENY` are without any effect.
+
+* Handling of TCA config option :php:`authMode_enforce` has been removed.
+
+* The fourth tuple of :sql:`be_groups` field :sql:`explicit_allowdeny` that was
+  previously set to either :sql:`ALLOW` or :sql:`DENY` is removed.
+
+* The fourth argument on :php:`BackendUserAuthentication->checkAuthMode()` has
+  been removed.
+
+Impact
+======
+
+Using any of the above removed options will trigger a PHP :php:`E_USER_DEPRECATED` error.
+Using :php:`explicitDeny` and :php:`individual` as value for TCA config option
+:php:`authMode` is no longer supported by the system and may need manual
+adaptions. Accessing :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']`
+may lead to a PHP warning level error.
+
+Affected Installations
+======================
+
+* Instances with extensions using :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']`.
+  The extension scanner will typically find affected instances.
+
+* Instances with TCA select fields using :php:`'authMode' => 'explicitDeny'`.
+
+* Instances with TCA select fields using :php:`'authMode' => 'individual'` and select
+  items being set to :php:`EXPL_ALLOW` or :php:`EXPL_DENY`. This is a very rarely used
+  option and it's unlikely modern extensions use this in practice: There is not a single
+  extension in the TER using this option combination and it's unlikely to be used in
+  custom extensions, either.
+
+* Instances manually dealing with the :sql:`explicit_allowdeny` of table :sql:`be_groups`
+  may be affected if they expect the fourth field being set to :sql:`ALLOW` or :sql:`DENY`.
+  This is unlikely since the Core provides an API for this field using
+  :php:`BackendUserAuthentication->checkAuthMode()`.
+
+* Instances calling :php:`BackendUserAuthentication->checkAuthMode()` with four instead of
+  three arguments. The extension scanner will find usages as weak match.
+
+* Instances using :php:`authMode_enforce` for :php:`'type' => 'select'` fields.
+
+Migration
+=========
+
+The majority of instances does not need to take care of anything. The values of the database
+field :sql:`explicit_allowdeny` for table :sql:`be_groups` are updated with an upgrade wizard.
+This should be executed. The following parts of this section outline options for rare cases
+if specific seldom used options are used.
+
+Accessing explicitADmode
+------------------------
+
+The handling of :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']` has been changed as
+if it is always set to :php:`explicitAllow`. Extensions should not assume this global array
+key being set anymore since TYPO3 Core v12. Extensions that need to stay compatible with v11
+and v12 should fall back: :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode'] ?? 'explicitAllow'`.
+
+Using authMode_enforce='strict'
+-------------------------------
+
+Extensions with select fields using :php:`authMode` previously had different handling
+if :php:`authMode_enforce => 'strict'` has been set: Let's say an editor accesses a record
+with an :php:`authMode` field being set to a value it has no access to. With :php:`authMode_enforce`
+*not* being set to :php:`strict`, the editor was still able to edit the record and set the value
+to something it had access to. With :php:`authMode_enforce` being set to :php:`strict`, the editor
+was not allowed to access the record. This has been streamlined: The backend interface no longer
+renders those records for the editor and an "access denied" message is rendered instead. To
+prevent this, a group this editor is member of needs to be adapted to allow access to this
+particular value in the "Explicitly allow field values" (:sql:`explicit_allowdeny`) field.
+
+Using authMode='explicitDeny'
+-----------------------------
+
+The "deny list" approach for single field values has been removed, the only allowed option
+for :php:`authMode` is :php:`explicitAllow`. Extensions using config value :php:`explicitDeny`
+should be adapted to switch to :php:`explicitAllow` instead. The upgrade wizard
+"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
+existing :sql:`be_groups` rows to the new format *drops* any :sql:`DENY` fields and instructs
+admins to set new access rights of affected backend groups.
+
+Using authMode='individual'
+---------------------------
+
+Handling of :php:`authMode` being set to :php:`individual` has been fully dropped. There is
+no Core-provided alternative. This has been an obscure setting since ever and there is no
+direct migration. Extension that rely on this handling need to find a substitution based on
+Core hooks, Core events or other existing Core API functionality.
+
+.. index:: Backend, Database, LocalConfiguration, PHP-API, TCA, PartiallyScanned, ext:core

Documentation/Changelog/12.0/Breaking-97305-IntroduceCSRF-likeLoginToken.rst

@@ -0,0 +1,70 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97305-1664100009:
+
+==================================================
+Breaking: #97305 - Introduce CSRF-like login token
+==================================================
+
+See :issue:`97305`
+
+Description
+===========
+
+:php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication` requires a
+CSRF-like request-token to continue with the authentication process and to
+create an actual server-side user session.
+
+The request-token has to be submitted by one of these ways:
+
+* HTTP body, e.g. in `<form>` via parameter `__request_token`
+* HTTP header, e.g. in XHR via header `X-TYPO3-RequestToken`
+
+Impact
+======
+
+Core user authentication is protected by a CSRF-like request-token, to
+mitigate `Login CSRF <https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html>`__.
+
+Custom implementations for login templates or client-side authentication
+handling have to be adjusted to submit the required request-token.
+
+Affected installations
+======================
+
+Sites having custom implementations for login templates or client-side authentication.
+
+Migration
+=========
+
+The :php:`\TYPO3\CMS\Core\Security\RequestToken` signed with a :php:`\TYPO3\CMS\Core\Security\Nonce`
+needs to be sent as JSON Web Token (JWT) to the server-side application handling of
+the Core user authentication process. The scope needs to be :php:`core/user-auth/be`
+or :php:`core/user-auth/fe` - depending on whether authentication is applied in
+the website's backend or frontend context.
+
+Example for overridden backend login HTML template (`ext:backend`)
+------------------------------------------------------------------
+
+..  code-block:: diff
+
+    --- a/typo3/sysext/backend/Resources/Private/Layouts/Login.html
+    +++ b/typo3/sysext/backend/Resources/Private/Layouts/Login.html
+     <input type="hidden" name="redirect_url" value="{redirectUrl}" />
+     <input type="hidden" name="loginRefresh" value="{loginRefresh}" />
+    +<input type="hidden" name="{requestTokenName}" value="{requestTokenValue}" />
+
+Example for overridden frontend login HTML template (`ext:felogin`)
+-------------------------------------------------------------------
+
+..  code-block:: diff
+
+    --- a/typo3/sysext/felogin/Resources/Private/Templates/Login/Login.html
+    +++ b/typo3/sysext/felogin/Resources/Private/Templates/Login/Login.html
+    -<f:form target="_top" fieldNamePrefix="" action="login">
+    +<f:form target="_top" fieldNamePrefix="" action="login" requestToken="{requestToken}">
+
+More details are explained in corresponding documentation on
+:ref:`Feature #87616: Introduce CSRF-like request-token handling <feature-97305-1664099950>`.
+
+.. index:: Backend, Fluid, Frontend, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97312-RemoveContextSensitiveHelp.rst

@@ -0,0 +1,86 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97312:
+
+================================================
+Breaking: #97312 - Remove context sensitive help
+================================================
+
+See :issue:`97312`
+
+Description
+===========
+
+The arguments for removing context sensitive help were:
+
+* The help was not really context sensitive, it only relied on tablename
+  and fieldname, if a field was used for different purposes in different
+  content types, the CSH always showed the same help
+* There was outdated information in CSH (e.g. Screenshots form TYPO3 4.x)
+  and nobody is available to update the information
+* Some CSH descriptions explained the same content with different words
+  which is confusing (e.g. tt_content - CType > Title: "Type" > CSH
+  Tooltip: "Select the kind of Page Content this element represents.
+  New options will appear when you save the record.")
+* Many CSH texts did not provide useful additional information
+  (e.g. tt_content - header > Title: "Header" > CSH Tooltip:
+  "Enter header text for the Content Element.")
+* The available online documentation https://docs.typo3.org/ improved
+  a lot and helps better than the CSH in most cases, as it is up to date
+* CSH was hidden for most users, as it was only available by clicking on
+  a label (no hint that help was available without hovering the label by
+  mouse, not available for keyboard users)
+* `description` is available for explanations when they are required.
+  Adding relevant information as `description` will help everyone as it is
+  visible.
+* The removal was already proposed in 2019 (see
+  https://decisions.typo3.org/t/drop-context-sensitive-help-in-core/511)
+  and most arguments against removal can be solved using the `description`
+  or by linking to the official documentation
+* Removal of CSH also removed a lot of outdated files (and results in
+  smaller footprint of the TYPO3 Core package)
+
+The route `help_cshmanual_popup` has been removed.
+
+Help buttons :php:`Components\Buttons\Action\HelpButton` only return an
+empty string and trigger a deprecation warning.
+
+The CSH descriptions are not loaded any longer for tables.
+
+All labels are adjusted to not contain :html:`<abbr>` tags inside any longer.
+
+The method :php:`cshItem()` of
+:php:`TYPO3\CMS\Backend\Utility\BackendUtility` always returns an empty
+string and triggers a deprecation warning.
+
+The TYPO3 Manual menu item has been removed and a link to the
+TYPO3 Online Documentation has been added to the menu.
+
+The backend display related TCA option
+:php:`$GLOBALS['TCA'][my_table]['interface']['always_description']`
+is not evaluated anymore.
+
+Impact
+======
+
+The context sensitive help is removed completely and only loading help
+items for SelectCheckboxElements is still supported.
+
+Affected Installations
+======================
+
+All installations that use CSH for own fields.
+
+Migration
+=========
+
+Important CSH texts need to be migrated to a TCA :php:`description`, to
+make the information available for all users.
+
+An example for a TCA description is the :php:`protected` column in the
+:php:`sys_redirect` TCA.
+
+The TCA option :php:`['interface']['always_description']` can be removed from
+any TCA definition.
+
+.. index:: Backend, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97320-RegisterReportAndStatusViaServiceConfiguration.rst

@@ -0,0 +1,159 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97320:
+
+=======================================================================
+Breaking: #97320 - Register Report and Status via Service Configuration
+=======================================================================
+
+See :issue:`97320`
+
+Description
+===========
+
+The `reports` and `status` in EXT:reports are now registered via service
+configuration, see the :doc:`feature changelog <Feature-97320-NewRegistrationForReportsAndStatus>`.
+Therefore the registration via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']`
+has been removed.
+
+Additionally, to be able to use autoconfiguration, the following interfaces have been extended:
+
+- :php:`TYPO3\CMS\Reports\ReportInterface`: :php:`getIdentifier`, :php:`getIconIdentifier`, :php:`getTitle`, :php:`getDescription`
+- :php:`TYPO3\CMS\Reports\StatusProviderInterface`: :php:`getLabel`
+
+Impact
+======
+
+Registration of custom `reports` via :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']`
+are not evaluated anymore.
+
+Registration of custom `status` via :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_reports']['status']['providers']`
+are not evaluated anymore.
+
+:php:`ReportInterface` and :php:`StatusProviderInterface`: are extended by the mentioned methods. If the required methods are not implemented it will lead to fatal errors.
+
+Affected Installations
+======================
+
+All TYPO3 installations using the old registration.
+
+All TYPO3 installations with custom `reports`, not implementing :php:`public function getIdentifier()`,
+:php:`public function getIconIdentifier()`, :php:`public function getTitle()`, :php:`public function getDescription()`
+
+All TYPO3 installations with custom `status`, not implementing
+:php:`public function getLabel()`
+
+Migration
+=========
+
+By implementing the required methods of the interfaces, the custom reports are fully backwards compatible.
+
+If TYPO3 v12+ is the only supported version, the configuration :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']` from the :file:`ext_localconf.php` file can be removed as well.
+
+Report
+------
+
+If :yaml:`autoconfigure` is not enabled in your :file:`Configuration/Services.(yaml|php)`,
+add the tag :yaml:`reports.report` manually to your `reports` service.
+
+..  code-block:: yaml
+
+    Vendor\Extension\Report\MyReport:
+      tags:
+        - name: reports.report
+
+The old registration can be removed, if support for TYPO3 v11 or lower is not
+necessary.
+
+..  code-block:: php
+
+    // Before in ext_localconf.php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['extension']['general'] = [
+        'title' => 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:title',
+        'description' => 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:description',
+        'icon' => 'EXT:extension/Resources/Public/Icons/Extension.svg',
+        'report' => \Vendor\Extension\Report::class
+    ];
+
+Additionally, make sure to implement all methods of :php:`TYPO3\CMS\Reports\ReportInterface`.
+
+..  code-block:: php
+
+    // Changes for the report
+
+    class Report implements ReportInterface
+    {
+        public function getReport(): string
+        {
+            return 'Full report';
+        }
+
+        public function getIdentifier(): string
+        {
+            return 'general';
+        }
+
+        public function getTitle(): string
+        {
+            return 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:title';
+        }
+
+        public function getDescription(): string
+        {
+            return 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:description';
+        }
+
+        public function getIconIdentifier(): string
+        {
+            return 'module-reports';
+        }
+    }
+
+Refer to the :ref:`Icon API <feature-94692-1657826754>`
+on how to register the icon.
+
+Status
+------
+
+If :yaml:`autoconfigure` is not enabled in your :file:`Configuration/Services.(yaml|php)`,
+add the tag :yaml:`reports.status` manually to your `status` service.
+
+..  code-block:: yaml
+
+    Vendor\Extension\Status\MyStatus:
+      tags:
+        - name: reports.report
+
+The old registration can be removed, if support for TYPO3 v11 or lower is not
+necessary.
+
+..  code-block:: php
+
+    // Before in ext_localconf.php
+
+    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_reports']['status']['providers']['label'] = [
+        \Vendor\Extension\Status::class,
+    ];
+
+Additionally, make sure to implement all methods of :php:`TYPO3\CMS\Reports\StatusProviderInterface`.
+
+..  code-block:: php
+
+    // Changes for the Status
+
+    class Status implements StatusProviderInterface
+    {
+        public function getStatus(): array
+        {
+            return [];
+        }
+
+        public function getLabel(): string
+        {
+            return 'label';
+        }
+    }
+
+.. index:: Backend, LocalConfiguration, PHP-API, FullyScanned, ext:reports

Documentation/Changelog/12.0/Breaking-97358-RemovedEvalintFromTCATypeDatetime.rst

@@ -0,0 +1,90 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97358:
+
+============================================================
+Breaking: #97358 - Removed eval=int from TCA type "datetime"
+============================================================
+
+See :issue:`97358`
+
+Description
+===========
+
+With :issue:`97232` the new TCA type :php:`datetime` has been introduced. To
+further improve the usage of the new dedicated TCA type and to further reduce
+complexity in the configuration, the :php:`eval=int` option has now been
+removed as well. All TCA type :php:`datetime` fields, which do not use a
+native database type (:php:`dbType`) are now always handled with :php:`int`.
+
+It is therefore recommended to represent them by an :sql:`integer` database
+field. To allow negative timestamps - used for dates before 1970 - the
+:sql:`integer` database fields are required to be defined as :sql:`signed`.
+This means, the :sql:`unsigned` definition must be omitted.
+
+.. note::
+
+    TYPO3 automatically creates database fields for all TCA type
+    :php:`datetime` columns, if those are not already manually
+    defined in the corresponding extension's :file:`ext_tables.sql` file.
+
+Impact
+======
+
+All TCA :php:`datetime` fields are now always handled with :php:`int`, as long
+as no native database type is used.
+
+TCA type :php:`datetime` was the last TCA type using :php:`eval=int`.
+Therefore, the :php:`int` option is no longer evaluated by neither FormEngine
+nor :php:`DataHandler`. This means, custom FormEngine elements, which do
+currently rely on this option being evaluated in any way, have to implement
+the necessary functionality by themselves now.
+
+Affected Installations
+======================
+
+All installations which use TCA type :php:`datetime` columns
+without a native database type (:php:`dbType`). Also installations, using
+a non :php:`int` default value in TCA.
+
+All installations, relying on evaluation of the :php:`eval=int` option
+for their custom FormEngine elements.
+
+Migration
+=========
+
+Remove :php:`eval=int` from any TCA column of type :php:`datetime`.
+
+Migrate necessary functionality, related to TCA option :php:`eval=int`,
+to your custom extension code, since FormEngine does no longer evaluate
+this option.
+
+Migrate :php:`default` values for TCA type :php:`datetime` fields
+to :php:`int` (e.g. `''` to `0`).
+
+Migrate corresponding database fields to :sql:`integer` where applicable.
+
+..  code-block:: sql
+
+    # Before
+    CREATE TABLE tx_ext_my_table (
+        datetime text
+    );
+
+    # After
+    CREATE TABLE tx_ext_my_table (
+        datetime int(11) DEFAULT '0' NOT NULL,
+    );
+
+.. note::
+
+    In case the corresponding TCA field defines :php:`eval=null`, the
+    :sql:`NOT NULL` definition must be omitted.
+
+.. note::
+
+    In case you don't need any manual configuration (e.g. a special default
+    value), you can omit the definition of the database field, since TYPO3
+    automatically creates those fields for TCA type :php:`datetime` columns.
+
+.. index:: Backend, Database, PHP-API, TCA, NotScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97449-RemovedHookForModifyingFlexFormParsing.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97449:
+
+===============================================================
+Breaking: #97449 - Removed hook for modifying flex form parsing
+===============================================================
+
+See :issue:`97449`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][FlexFormTools::class]['flexParsing']`,
+supporting the four hook methods
+
+- :php:`getDataStructureIdentifierPreProcess`
+- :php:`getDataStructureIdentifierPostProcess`
+- :php:`parseDataStructureByIdentifierPreProcess`
+- :php:`parseDataStructureByIdentifierPostProcess`
+
+has been removed in favor of four new dedicated :doc:`PSR-14 events <../12.0/Feature-97449-PSR-14EventsForModifyingFlexFormParsing>`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this hook.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the PSR-14 events as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97450-RemovedHookForModifyingVersionDifferences.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97450:
+
+=================================================================
+Breaking: #97450 - Removed hook for modifying version differences
+=================================================================
+
+See :issue:`97450`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['workspaces']['modifyDifferenceArray']`
+has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Workspaces\Event\ModifyVersionDifferencesEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97450-PSR-14EventForModifyingVersionDifferences>`
+as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97451-RemoveBackendControllerPageHooks.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97451:
+
+=======================================================
+Breaking: #97451 - Removed BackendController page hooks
+=======================================================
+
+See :issue:`97451`
+
+Description
+===========
+
+The hooks :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/backend.php']['constructPostProcess']`,
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/backend.php']['renderPreProcess']`, and
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/backend.php']['renderPostProcess']` have
+been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Backend\Controller\Event\AfterBackendPageRenderEvent`.
+
+Additionally, the :php:`BackendController->addCss()` method has been removed without replacement,
+as it is no longer used.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hooks are removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97451-PSR-14EventsForBackendPageController>`
+as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97452-RemovedEditFileControllerHooks.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97452:
+
+===================================================
+Breaking: #97452 - Removed EditFileController hooks
+===================================================
+
+See :issue:`97452`
+
+Description
+===========
+
+The hooks :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/file_edit.php']['preOutputProcessingHook']`
+and :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/file_edit.php']['postOutputProcessingHook']`
+have been removed, since adjusting the generated content can be achieved using template overrides
+and modifying the form data, used to generate the edit file form, can be done
+using the PSR-14 :php:`TYPO3\CMS\Filelist\Event\ModifyEditFileFormDataEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in TYPO3 v12.0+.
+The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using these hook in custom extension code. This is
+pretty unlikely, since both hooks were of limited use.
+
+Migration
+=========
+
+The form data modification, allowed by :php:`preOutputProcessingHook`, can be
+achieved with the new :ref:`PSR-14 ModifyEditFileFormDataEvent <feature-98521-1664890745>`.
+
+The content manipulation :php:`postOutputProcessingHook` hook can be substituted with a template override
+as outlined in :ref:`this changelog entry <feature-96812>`.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97454-RemoveLinkBrowserHooks.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97454-1657327622:
+
+=============================================
+Breaking: #97454 - Removed Link Browser hooks
+=============================================
+
+See :issue:`97454`
+
+Description
+===========
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['LinkBrowser']['hooks']`
+with its two functions :php:`modifyLinkHandlers()` and
+:php:`modifyAllowedItems()` has been removed in favor of two new PSR-14 events
+:php:`\TYPO3\CMS\Backend\Controller\Event\ModifyLinkHandlersEvent`
+and :php:`\TYPO3\CMS\Backend\Controller\Event\ModifyAllowedItemsEvent`.
+
+.. seealso::
+
+    *   :ref:`feature-97454-1657327622`
+    *   :ref:`t3coreapi:modifyLinkHandlers`
+    *   :ref:`t3coreapi:ModifyLinkHandlersEvent`
+    *   :ref:`t3coreapi:ModifyAllowedItemsEvent`
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore in
+TYPO3 v12.0+. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using this hook in custom extension code.
+
+Migration
+=========
+
+The hook is removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :ref:`PSR-14 event <feature-97454-1657327622>`
+as an improved replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97530-IndexedSearchOptionSearchSkipExtendToSubpagesCheckingRemoved.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97530-1651500260:
+
+===================================================================================
+Breaking: #97530 - Indexed Search option searchSkipExtendToSubpagesChecking removed
+===================================================================================
+
+See :issue:`97530`
+
+Description
+===========
+
+The TypoScript property :typoscript:`searchSkipExtendToSubpagesChecking`
+related to Indexed Search query results has been removed.
+
+Setting the option made Indexed Search bypass the check for validating pages
+related to TYPO3's :php:`extendToSubpages` Core feature. However, since the
+:php:`extendToSubpages` functionality has now been optimized via an alternative
+to :php:`getTreeList()`, the option is removed.
+
+Impact
+======
+
+Setting the option
+:typoscript:`plugin.tx_indexedsearch.settings.searchSkipExtendToSubpagesChecking`
+has no effect anymore.
+
+All search requests within indexed search will now respect the
+:php:`extendToSubpages` flag.
+
+Affected installations
+======================
+
+TYPO3 installations using Indexed Search having this option set.
+
+Migration
+=========
+
+If you still encounter using indexed search related to :php:`extendToSubpages` it is
+recommended to extend Indexed Search queries with custom hooks to manipulate
+the search query.
+
+.. index:: TypoScript, NotScanned, ext:indexed_search

Documentation/Changelog/12.0/Breaking-97550-TypoScriptOptionConfigdisableCharsetHeaderRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97550-1651697278:
+
+========================================================================
+Breaking: #97550 - TypoScript option config.disableCharsetHeader removed
+========================================================================
+
+See :issue:`97550`
+
+Description
+===========
+
+The TypoScript flag :typoscript:`config.disableCharsetHeader` has been completely removed
+from TYPO3 Core.
+
+This option was used to avoid sending HTTP headers of type `Content-Type` to
+the client. This flag was mainly used to overcome a technical limitation to
+override the Content-Type information back in TYPO3 v4.x.
+
+Impact
+======
+
+TYPO3 now always sends the `Content-Type` header to the client in the TYPO3
+Frontend.
+
+Affected installations
+======================
+
+TYPO3 installations having this option enabled via TypoScript.
+
+Migration
+=========
+
+It is not needed to set this option. Even when Extbase plugins return JSON-based
+Responses, the Content-Type header is already modified.
+
+In special cases, when custom headers are required, it is possible to modify
+the headers via a PHP-based PSR-15 middleware, or via TypoScript with
+"config.additionalHeaders".
+
+.. index:: TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97605-RemoveFieldResizeTextareas_MaxHeightFromUserSettings.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97605-1652214290:
+
+============================================================================
+Breaking: #97605 - Remove field resizeTextareas_MaxHeight from user settings
+============================================================================
+
+See :issue:`97605`
+
+Description
+===========
+
+The field :php:`resizeTextareas_MaxHeight` with the label *Maximum height of text areas in pixels* has been removed.
+
+The impact of the field is low and its removal simplifies the user settings module.
+
+Impact
+======
+
+The height of textareas is the same for every user.
+
+Affected installations
+======================
+
+Every TYPO3 installation.
+
+Migration
+=========
+
+There is no migration available. If this feature is needed, the rendering of a field can be modified by a custom :php:`FormElement`.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97701-RemovedTsConfigOptionDisableNewContentElementWizard.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97701-1655154047:
+
+=========================================================================
+Breaking: #97701 - TSconfig option disableNewContentElementWizard removed
+=========================================================================
+
+See :issue:`97701`
+
+Description
+===========
+
+The TSconfig option :typoscript:`mod.web_layout.disableNewContentElementWizard`
+has been used to explicitly disable the content element wizard. When set,
+a new Content Element of type "Text" was created by default, which was then
+changed to a different Content Type.
+
+Along with this the option :typoscript:`mod.newContentElementWizard.override` has
+been removed, as it served a similar purpose to override the route name itself.
+
+Impact
+======
+
+Both TSconfig options have no effect anymore. TYPO3 behaves as if the options
+were never set.
+
+Affected installations
+======================
+
+TYPO3 installations having one of these options explicitly enabled.
+
+Migration
+=========
+
+Remove the TSconfig settings as they have no effect anymore.
+
+Instead, use other TSconfig options to adapt the "New Content Element Wizard"
+to your needs. You can find according examples in
+:file:`EXT:frontend/Configuration/page.tsconfig`.
+
+It is also possible to create a custom backend route in your extension code
+to reimplement both functionalities in a custom TYPO3 Extension, if this option
+is still relevant for you.
+
+If you overwrite the Fluid template :file:`EXT:backend/Resources/Private/Partials/PageLayout/Record.html`
+you have to adjust your template accordingly and remove the "if" condition
+checking for `{item.column.context.drawingConfiguration.showNewContentWizard}`.
+
+.. index:: Backend, Fluid, TSConfig, PartiallyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-97729-SupportAttributeApprovedInXlfFiles.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97729-1654627167:
+
+==========================================================
+Breaking: #97729 - Respect attribute approved in XLF files
+==========================================================
+
+See :issue:`97729`
+
+Description
+===========
+
+The new option :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['lang']['requireApprovedLocalizations']`
+controls whether only approved translations are taken into account when parsing XLF files.
+
+This option is enabled by default for new and existing TYPO3 installations.
+
+Impact
+======
+
+If set to `true` - which is the default value - only approved translations are used.
+Any non-approved translation will be ignored.
+If the attribute approved is omitted, the translation is still taken into account.
+
+..  code-block:: xml
+
+    <trans-unit id="label2" approved="yes">
+      <source>This is label #2</source>
+      <target>Ceci est le libellé no. 2</target>
+    </trans-unit>
+
+Affected installations
+======================
+
+All TYPO3 translations using translations from XLF files.
+
+Migration
+=========
+
+Either set :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['lang']['requireApprovedLocalizations']`
+to `false` or add `approved="yes"` to all translations.
+
+.. index:: Backend, Fluid, Frontend, TCA, TypoScript, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97737-Page-relatedHooksInTSFERemoved.rst

@@ -0,0 +1,53 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97737-1654595331:
+
+=====================================================
+Breaking: #97737 - Page-related hooks in TSFE removed
+=====================================================
+
+See :issue:`97737`
+
+Description
+===========
+
+The following hooks, which were executed during the process of resolving page
+details of a frontend request have been removed:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['determineId-PreProcessing']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['fetchPageId-PostProcessing']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_preProcess']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['determineId-PostProc']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_postProcess']`
+
+They have been replaced by improved PSR-14 events.
+
+Impact
+======
+
+Extensions that hook into these places are not executing the PHP-code anymore.
+
+Affected installations
+======================
+
+TYPO3 installations with extensions using one of the hooks.
+
+Check the "Configuration" module to see if your TYPO3 installation is using
+one of the hooks by browsing :php:`$TYPO3_CONF_VARS[SC_OPTIONS]` or using the
+Extension Scanner.
+
+Migration
+=========
+
+The hooks are removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 events <../12.0/Feature-97737-PSR-14EventsWhenPageRootlineInFrontendIsResolved>`
+
+* :php:`BeforePageIsResolvedEvent`
+* :php:`AfterPageWithRootLineIsResolvedEvent`
+* :php:`AfterPageAndLanguageIsResolvedEvent`
+
+as an improved replacement.
+
+.. index:: Frontend, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97752-MailerAdapterInterfaceRemoved.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97752-1654761506:
+
+=================================================
+Breaking: #97752 - MailerAdapterInterface removed
+=================================================
+
+See :issue:`97752`
+
+Description
+===========
+
+The :php:`\TYPO3\CMS\Core\Mail\MailerAdapterInterface` has been removed,
+since the interface became unused in v7 due to removal of Core's
+:php:`SwiftMailerAdapter` implementation, which had been used as hook
+subscriber in the also removed :php:`MailUtility::mail()` method.
+
+Impact
+======
+
+Implementing the interface in custom extension code will trigger
+a PHP Error.
+
+Affected installations
+======================
+
+All installations implementing the interface in custom extension code,
+which is very unlikely. The extension scanner will report any usage as
+strong match.
+
+Migration
+=========
+
+Remove any usage of the interface in extension code.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/12.0/Breaking-97787-AbstractMessageGetSeverityReturnsContextualFeedbackSeverity.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97787-1657629392:
+
+====================================================================================
+Breaking: #97787 - AbstractMessage->getSeverity() returns ContextualFeedbackSeverity
+====================================================================================
+
+See :issue:`97787`
+
+Description
+===========
+
+The class :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage` and the extended
+class :php:`\TYPO3\CMS\Core\Messaging\FlashMessage` both have a method
+:php:`getSeverity()` to return a flash message's severity. The return type of
+the method is changed to return an instance of :php:`\TYPO3\CMS\Core\Type\ContextualFeedbackSeverity`.
+
+As this method isn't supposed to be used publicly, it is declared `internal` now.
+
+Impact
+======
+
+Relying on the return type of :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage->getSeverity()`
+being `int` will throw a :php:`TypeError` exception.
+
+There is no negative impact in the following cases:
+
+* Using the severity enum in Fluid for direct rendering
+* Using the severity enum in :php:`json_encode()`
+
+In these cases, the enum's value is automatically used.
+
+Affected installations
+======================
+
+All extensions using :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage->getSeverity()`
+in PHP are affected, if the integer type is expected.
+
+Migration
+=========
+
+If the integer type of :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage->getSeverity()`
+is expected, use the :php:`value` property of the :php:`ContextualFeedbackSeverity` enum:
+
+..  code-block:: php
+
+    $flashMessage = new \TYPO3\CMS\Core\Messaging\FlashMessage('This is a message');
+    $severityAsInt = $flashMessage->getSeverity()->value;
+
+The same applies to Fluid template, where the severity is used within another
+structure, e.g. as an array key:
+
+..  code-block:: html
+
+    <div class="x" class="{severityClassMapping.{status.severity.value}}">
+        <!-- stuff happens here -->
+    </div>
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97797-GFXSettingProcessor_path_lzwRemoved.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97797-1655730428:
+
+=========================================================
+Breaking: #97797 - GFX setting processor_path_lzw removed
+=========================================================
+
+See :issue:`97797`
+
+Description
+===========
+
+The global configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_path_lzw']`
+was used to compress GIF and TIFF files with a different ImageMagick version,
+as LZW compression was removed from the distributed ImageMagick binaries back in
+2004-2006.
+
+Since then, both GIF and TIFF have had reduced impact on the web we know today.
+
+For this reason, the value is removed. If GIF compression via LZW is wanted,
+it should be pointing to the main `processor_path` setting.
+
+Impact
+======
+
+Compression via LZW for GIF files is now only applied when the corresponding
+ImageMagick version, found in `processor_path` is supporting LZW compression.
+
+The GFX setting `processor_path_lzw` is not used anymore, and can safely be
+removed. When accessing the Install Tool, the setting is automatically removed
+from :file:`LocalConfiguration.php`.
+
+Affected installations
+======================
+
+TYPO3 installations actively using GIF compression or GIF thumbnails over PNG
+thumbnails (if `GFX/thumbnails_png` is set to false), which might result in
+GIF files with a larger file size.
+
+Migration
+=========
+
+It is recommended to switch to PNG thumbnails (TYPO3 setting `GFX/thumbnails_png`),
+or use an ImageMagick version supporting LZW compression for GIF files, if this
+functionality is explicitly needed.
+
+In addition, solutions such as `gifsicle` can be used instead to optimize
+GIF images.
+
+.. index:: Frontend, PartiallyScanned, ext:core

Documentation/Changelog/12.0/Breaking-97816-NewTypoScriptParserInFrontend.rst

@@ -0,0 +1,107 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97816-1664800747:
+
+====================================================
+Breaking: #97816 - New TypoScript parser in Frontend
+====================================================
+
+See :issue:`97816`
+
+Description
+===========
+
+The rewrite of the TypoScript parser has been enabled for Frontend
+rendering.
+
+See :ref:`breaking-97816-1656350406` and :ref:`feature-97816-1656350667`
+for more details on the new parser.
+
+
+Impact
+======
+
+The change has impact on Frontend caching, hooks, some classes and properties. In detail:
+
+* Hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Core/TypoScript/TemplateService']['runThroughTemplatesPostProcessing']`
+  is gone and substituted by :php:`AfterTemplatesHaveBeenDeterminedEvent`. See :ref:`feature-97816-1664801053` for more details.
+
+* The classes :php:`TYPO3\CMS\Core\TypoScript\TemplateService` and :php:`TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser`
+  have been marked as deprecated and shouldn't be used anymore.
+  An instance of :php:`TemplateService` is still kept as property :php:`TypoScriptFrontendController->tmpl` (:php:`$GLOBALS['TSFE']->tmpl)
+  as backwards compatible layer, and the most important properties within the class, namely especially :php:`TemplateService->setup` is
+  still set. To avoid using these properties, the Frontend request object will contain this state.
+  In rare cases, where extensions need to parse TypoScript on their own, they should switch to the Tokenizer and AstBuilder structures
+  of the new parser. Note these classes are still young and currently marked @internal, the API may still slightly change with further
+  v12 development.
+
+* The :php:`pagesection` cache has been removed. This was a helper cache that grew O(n) with the number of
+  called Frontend pages. The new :php:`typoscript` cache is used instead: This grows only O(n) with the
+  number of different sys_template and condition combinations and is a filesystem based :php:`PhpFrontend` implementation.
+  When upgrading, the database tables :sql:`cache_pagesection` and :sql:`cache_pagesections_tags` can be safely removed, the
+  install tool will also silently remove any existing entries from :file:`settings.php` that reconfigure the cache.
+
+* The Frontend rendering changed TypoScript cache behavior slightly, which may have an impact on integrators developing
+  and testing TypoScript in the Frontend. The short version is: When changing :sql:`sys_template` records, changes have
+  immediate effect, and when changing included TypoScript files, the Frontend browser tab should be reloaded using "shift-reload"
+  or the browser inspector should be opened and the "Disable cache" toggle turned on. Note when changes like this should
+  go live for everyone, Frontend caches must still be cleared using the Backend toolbar "Flush frontend caches" to have
+  an effect on "normal users" without active Backend login.
+
+  Some more details on this: Frontend TypoScript in general now uses caches across multiple pages, which
+  increases rendering performance. After calling a first page with empty caches, a second page call to a different
+  page will re-use most, if not all, TypoScript from cache entries created by the first page access.
+
+  This has impact on cache invalidation when developing Frontend TypoScript:
+  First, changing :sql:`sys_template` records always has immediate effect to all requests, even without clearing caches manually.
+  The system detects field changes of :sql:`sys_template` changes automatically, reloading a page in the Frontend will trigger
+  re-calculation of TypoScript and thus re-rendering of the page. Note this is only true for directly loaded :sql:`sys_template`
+  records. Changes on records included indirectly via the relatively seldom used :sql:`basedOn` field are *not* detected
+  automatically, and the same systematics as outlined below for file includes kicks in.
+
+  The cache behavior is slightly different for files included using :typoscript:`@import`, :typoscript:`<INCLUDE_TYPOSCRIPT: ...`
+  and for :sql:`sys_template` records included using the :sql:`basedOn` field. To suppress expensive filesystem calls in production,
+  the cache layer for included files is more aggressive and does *not* automatically trigger Frontend page re-rendering when included
+  TypoScript files are changed. There are however some ways to easily work around this as an integrator: When a backend user is
+  logged in, a Frontend call recognizes this since various functionality is bound to logged in Backend users in the Frontend, most notably
+  the ability to preview hidden pages or hidden content, and the admin panel functionality. When changing Frontend TypoScript in included
+  files, being logged in with a Backend user, and then pressing "shift-reload" for the Frontend page, this will trigger "no cache",
+  which forces content re-rendering including TypoScript re-calculation. Additionally, the "Browser Inspectors" in Chrome and
+  Firefox both have a "Disable cache" toggle, which sends the same HTTP header as done with "shift-reload", which will *also*
+  force re-rendering. Note integrators should still "Flush frontend caches" when changes in included TypoScript files should
+  go-live for all other Frontend requests and thus "normal users" as well.
+
+* The following properties and methods in :php:`TypoScriptFrontendController` have been set to :php:`@internal` and should not
+  be used any longer since they may vanish without further notice:
+
+  * :php:`TypoScriptFrontendController->no_cache`
+  * :php:`TypoScriptFrontendController->tmpl`
+  * :php:`TypoScriptFrontendController->pageContentWasLoadedFromCache`
+  * :php:`TypoScriptFrontendController->getFromCache_queryRow()`
+  * :php:`TypoScriptFrontendController->populatePageDataFromCache()`
+  * :php:`TypoScriptFrontendController->shouldAcquireCacheData()`
+  * :php:`TypoScriptFrontendController->acquireLock()`
+  * :php:`TypoScriptFrontendController->releaseLock()`
+
+* The following methods in :php:`TypoScriptFrontendController` have been removed:
+
+  * :php:`TypoScriptFrontendController->getHash()`
+  * :php:`TypoScriptFrontendController->getLockHash()`
+  * :php:`TypoScriptFrontendController->getConfigArray()`
+  * :php:`TypoScriptFrontendController->()`
+
+
+Affected installations
+======================
+
+Many instances will only recognize that the :php:`pagesection` cache is gone and should continue to work.
+Instances with extensions that use :php:`TemplateService` or :php:`TypoScriptParser`, or access the
+property :php:`TypoScriptFrontendController->tmpl` may need adaptions.
+
+
+Migration
+=========
+
+See the impact description above for some migration hints.
+
+.. index:: Database, Frontend, PHP-API, TypoScript, LocalConfiguration, PartiallyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97816-TypoScriptSyntaxChanges.rst

@@ -0,0 +1,326 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97816-1656350406:
+
+============================================
+Breaking: #97816 - TypoScript syntax changes
+============================================
+
+See :issue:`97816`
+
+Description
+===========
+
+TYPO3 v12 comes with a new TypoScript syntax parser that is more performant,
+more robust and allows better tooling in the Backend.
+
+The new parser is more forgiving in many places, but some seldom used syntax
+details have been removed, too. This documentation explains details that may
+be breaking for existing instances.
+
+Also see :ref:`the feature documentation <feature-97816-1656350667>`
+for an overview of syntax improvements.
+
+Impact
+======
+
+Using one of the constructs below stops working in v12 and needs
+TypoScript adaptions.
+
+Affected installations
+======================
+
+Instances using TypoScript as outlined below.
+
+Migration
+=========
+
+Streamlined constants usage
+---------------------------
+
+It has never been fully documented in which context "constants" :typoscript:`{$foo}`
+shall be used and which exact capabilities they have. The main TypoScript constants
+documentation within the :ref:`TypoScript Reference <t3tsref:typoscript-syntax-constants>` was partially
+outdated, and the :ref:`TSconfig documentation <t3tsref:Syntax>` claimed TSconfig
+is not constants aware at all, which isn't fully the case anymore. Let's sort out
+some details:
+
+* Nesting constants is **not** possible and never has been. A construct like
+  this is invalid syntax and is treated as string literal: :typoscript:`{$foo{$bar}}`
+
+* Recursive constants were possible with the old parser but are not supported with the new
+  parser anymore. This was never documented, the Backend Template module never showed them as
+  resolved, only the Frontend parsed recursive constants. The simple rule is now: Never
+  access a constant within another constant. Instances using a construct like the below one
+  need to untie constants.
+
+  ..  code-block:: typoscript
+
+      constants:
+      foo = fooValue
+      # This does not resolve to "fooValue" but is kept as string literal "{$foo}"
+      bar = {$foo}
+
+      setup:
+      # This does NOT resolve to "fooValue", but to the string literal "{$foo}"
+      myValue = {$bar}
+
+* Similar to the above restriction, constants can be used in Frontend TypoScript *setup* conditions,
+  but not in Frontend TypoScript *constants* conditions. As example, a :sql:`sys_template` record with
+  the below content set in the :sql:`constants` field always evaluates the condition to false:
+
+  .. code-block:: typoscript
+
+      my.constant = myValue
+      ['{$my.constant}' == 'myValue']
+        # Never executed since the above constant usage is NOT substituted to 'myValue'
+        other.constant = otherValue
+      [global]
+
+  If something like this is really needed, integrators can potentially work around by accessing
+  a :ref:`site setting <t3coreapi:sitehandling-settings>` directly in a constants condition:
+
+  .. code-block:: typoscript
+
+      The sites settings.yaml:
+      some:
+        setting: someValue
+
+      A sys_template record constants field within this site:
+      my.constant = myValue
+      [traverse(site('configuration'), 'settings/some/setting') == 'someValue']
+        # This works but is rather ugly to rely on
+        other.constant = otherValue
+      [global]
+
+* Constants are now restricted to "assignments" and "conditions". Using a constant to
+  substitute an "identifier" / "object path" is no longer allowed. This has never been
+  clarified in the docs before and instances abusing constants to specify object paths
+  should be seldom and need to resolve the situation with the new parser now:
+
+  This is supported:
+
+  ..  code-block:: typoscript
+
+      # Simple constant usage as assignment value:
+      foo = {$bar}
+      # Compiling a value with string literals and constants:
+      foo = I am {$bar}
+      # Using a constant in a condition:
+      [ myValue = {$bar} ]
+      # Using constant(s) in multiline assignments:
+      foo (
+          I am {$bar} and {$baz}
+      )
+
+  These constructs are *not* supported:
+
+  ..  code-block:: typoscript
+
+      # Using a constant as object path specification
+      {$bar} = myValue
+      # This is an object path specification, too, and not supported:
+      foo < {$bar}
+
+* PageTsConfig *does* support constant substitution: Site constants can be used
+  in PageTsconfig. This has been introduced with TYPO3 v10, see
+  :ref:`feature-91080-1657827157` for details.
+
+File includes are always top level
+----------------------------------
+
+File includes with :typoscript:`@import` and :typoscript:`<INCLUDE_TYPOSCRIPT:` within
+curly braces are not relative anymore. A construct like this is invalid:
+
+..  code-block:: typoscript
+
+    page = PAGE
+    page {
+        @import 'EXT:my_extension/Configuration/TypoScript/bar.typoscript'
+        20 = TEXT
+        20.value = bar
+    }
+
+With :file:`EXT:my_extension/Configuration/TypoScript/bar.typoscript` having this content:
+
+..  code-block:: typoscript
+
+    10 = TEXT
+    10.value = foo
+
+This *no longer* leads to this TypoScript:
+
+..  code-block:: typoscript
+
+    page = PAGE
+    page.10 = TEXT
+    page.10.value = foo
+    page.20 = TEXT
+    page.20.value = bar
+
+Instead, the following TypoScript will be calculated:
+
+..  code-block:: typoscript
+
+    page = PAGE
+    10 = TEXT
+    10.value = foo
+    20 = TEXT
+    20.value = bar
+
+This means :typoscript:`@import` and :typoscript:`<INCLUDE_TYPOSCRIPT:` basically break
+any curly braces level, resetting current scope to top level. While inclusion of files has
+never been documented to be valid within braces assignments, it still worked until TYPO3 v11.
+This is now disallowed and must not be used anymore.
+
+:typoscript:`<INCLUDE_TYPOSCRIPT:` with :typoscript:`DIR:` and relative paths
+always assumes the :file:`public/` directory as base directory now.
+(Formerly it was relative to the file holding the include statement.)
+
+@import is more restrictive with wildcards
+------------------------------------------
+
+The previous implementation of :typoscript:`@import` relied on Symfony Finder. This turned out
+to be a performance bottleneck, the new implementation is based on "native" PHP file and directory
+lookup logic. For performance, security and best practice considerations, :typoscript:`@import`
+is now a bit more restrictive than before, especially with wildcard :typoscript:`*` handling.
+
+Integrators are encouraged to switch from :typoscript:`<INCLUDE_TYPOSCRIPT:` to
+:typoscript:`@import` in TYPO3 v12 projects: The :typoscript:`<INCLUDE_TYPOSCRIPT:`
+is more complex and harder to handle, but a bit more permissive. Note :typoscript:`@import`
+can be placed within conditions bodies now: :typoscript:`@import` lines are only considered
+if the condition matches. This did not work with TYPO3 v11. It is likely that
+:typoscript:`<INCLUDE_TYPOSCRIPT:` will be deprecated with TYPO3 v13, integrators
+should adapt to :typoscript:`@import` when upgrading to TYPO3 v12 already.
+
+The following rules apply to :typoscript:`@import`:
+
+* Files *must* reside in extensions, the lookup pattern *must* start with :typoscript:`EXT`
+  if absolute. Including TypoScript snippets, for instance, from :file:`fileadmin` is *not* allowed
+  and never has been for :typoscript:`@import`.
+
+* File includes *may* be relative to the current file, and *must* be prefixed with :file:`./`
+  in this case. Subdirectories are allowed, path traversal using :file:`../` is not allowed.
+
+* Files *must* end with :file:`.typoscript` in frontend TypoScript. With TSconfig, both
+  :file:`.tsconfig` and :file:`.typoscript` are allowed, but :file:`.tsconfig` should be
+  preferred.
+
+* Directory includes are *not* recursive.
+
+* Directory traversal using :file:`../` is *not* allowed.
+
+* Wildcards for directories are *not* allowed. This has never been documented as working, and
+  is considered an unplanned side-effect of Symfony Finder. Few people used this undocumented
+  feature, it should be possible to restructure existing uses relatively easily.
+
+* Only a single wildcard :typoscript:`*` is allowed for filename patterns.
+
+Valid examples:
+
+..  code-block:: typoscript
+
+    @import 'EXT:my_extension/Configuration/TypoScript/bar.typoscript'
+
+    # Import all files in directory, ending with :file:`.typoscript`, or additionally
+    # :file:`.tsconfig` in TSconfig scope, in native operating system ascending order.
+    @import 'EXT:my_extension/Configuration/TypoScript/'
+
+    @import 'EXT:my_extension/Configuration/TypoScript/*.typoscript'
+    @import 'EXT:my_extension/Configuration/TypoScript/*.setup.typoscript'
+
+    # Import setupFoo.typoscript, setup.foo.typoscript and similar
+    @import 'EXT:my_extension/Configuration/TypoScript/setup*.typoscript'
+    @import 'EXT:my_extension/Configuration/TypoScript/setup*'
+
+    # If this is in file 'EXT:my_extension/Configuration/TypoScript/foo.typoscript',
+    # file 'EXT:my_extension/Configuration/TypoScript/bar.typoscript is included
+    @import './bar.typoscript`
+    # Relative sub directories includes are supported
+    @import './SubDirectory/bar.typoscript`
+    # Relative sub directories with wildcards are supported,
+    # this will include ./SubDirectory/foo.typoscript
+    @import './SubDirectory/*'
+
+Invalid examples:
+
+..  code-block:: typoscript
+
+    # fileadmin and friends not allowed
+    @import 'fileadmin/foo.typoscript'
+
+    # Tries to include foo.txt.typoscript, *not* foo.txt
+    @import 'EXT:my_extension/Configuration/TypoScript/foo.txt'
+
+    # Directory traversal is not allowed
+    @import 'EXT:my_extension/Configuration/TypoScript/Foo/../Bar/bar.typoscript'
+
+    # Directory wildcards are not allowed
+    @import 'EXT:my_extension/Configuration/TypoScript/*/foo.typoscript'
+
+    # Multiple wildcards in filename pattern are not allowed
+    @import 'EXT:my_extension/Configuration/TypoScript/foo.*.*.typoscript'
+
+
+UTF-8 BOM in TypoScript files
+-----------------------------
+
+The new TypoScript parser no longer ignores `UTF-8 BOM <https://en.wikipedia.org/wiki/Byte_order_mark>`_
+in included files: Having a Byte-order-mark in TypoScript files may create undesired
+results. They should be removed. UTF-8 BOM is disallowed in various other languages,
+for instance JSON and PHP. The new parser follows here. Modern editors typically don't
+add an UTF-8 BOM anymore.
+
+Instances can check if they use UTF-8 BOM with a Unix shell command:
+
+..  code-block:: bash
+
+    # find affected files
+    find . -type f -print0 | xargs -0 -n1 file {} | grep 'UTF-8 Unicode (with BOM)'
+    # remove UTF-8 BOM from a single file
+    sed -i '1s/^\xEF\xBB\xBF//' affectedFile.typoscript
+
+Support for \\n and \\r\\n linebreaks only
+------------------------------------------
+
+TypoScript sources must terminate single lines with either "\\n" (Unix ending: LineFeed),
+or "\\r\\n" (Windows ending: Carriage return, LineFeed). Ancient Mac, prior to Mac OS X
+used "\\r" as single linebreak character. This old linebreak type is no longer detected
+when parsing TypoScript and may lead to funny results, but chances are very low any
+instance is affected by this.
+
+Operator matching has higher precedence
+---------------------------------------
+
+The new parser looks for valid operators first, then parses things behind it.
+Consider this example:
+
+..  code-block:: typoscript
+
+    lib.nav.wrap =<ul id="nav">|</ul>
+
+This is ambiguous: The above :typoscript:`=<ul` could be interpreted both as an
+assignment :typoscript:`=` of the value :typoscript:`<ul`, or as a reference
+:typoscript:`=<` to the identifier :typoscript:`ul`.
+
+While the old parser interpreted this as an assignment, the new parser treats it
+as a reference.
+
+The above example aims for an assignment, though, which can be achieved by adding
+a whitespace between :typoscript:`=` and :typoscript:`<`:
+
+..  code-block:: typoscript
+
+    lib.nav.wrap = <ul id="nav">|</ul>
+
+Frontend TypoScript `temp.` top level object
+--------------------------------------------
+
+The Frontend TypoScript related top level object :typoscript:`temp` had special
+functionality until v12: Any TypoScript defined within was "temporary" at parse time
+and unset afterwards. It was not cached and could not be used as reference
+(:typoscript:`=<` operator). This special meaning has been removed, the key
+:typoscript:`temp` now works just like any other top level key.
+
+
+.. index:: Backend, Frontend, TSConfig, TypoScript, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-97862-HooksRelatedToGeneratingPageContentRemoved.rst

@@ -0,0 +1,78 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97862-1657195630:
+
+===================================================================
+Breaking: #97862 - Hooks related to generating page content removed
+===================================================================
+
+See :issue:`97862`
+
+Description
+===========
+
+The existing TYPO3 hooks in the process of generating a TYPO3 Frontend page
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-cached']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-all']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['usePageCache']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['insertPageIncache']`
+
+have been removed. These hooks have been used to execute custom PHP code after
+a page is generated in the TYPO3 frontend and ready to be stored in cache.
+
+Due to the removal of the hooks and the introduction of the new PSR-14 events
+the method signature of :php:`TypoScriptFrontendController->generatePage_postProcessing()`
+has been changed. The method now requires a :php:`ServerRequestInterface` as first
+argument.
+
+Impact
+======
+
+Extension code that hooks into these places will not be executed anymore in
+TYPO3 v12+.
+
+Extension code calling :php:`TypoScriptFrontendController->generatePage_postProcessing()`
+without providing a :php:`ServerRequestInterface` as first argument
+will trigger a PHP `ArgumentCountError`.
+
+Affected installations
+======================
+
+TYPO3 installations with custom extensions using these hooks such as static file
+generation or modifying the page content cache, which is highly likely in
+third-party extensions. The extension scanner will detect usages as
+strong match.
+
+Extensions, manually calling :php:`TypoScriptFrontendController->generatePage_postProcessing()`
+without providing a :php:`ServerRequestInterface` as first argument. The
+extension scanner will detect usages as weak match.
+
+Migration
+=========
+
+Use one of the two newly introduced
+:doc:`PSR-14 events <../12.0/Feature-97862-NewPSR-14EventsForManipulatingFrontendPageGenerationAndCacheBehaviour>`:
+
+* :php:`TYPO3\CMS\Frontend\Event\AfterCacheableContentIsGeneratedEvent`
+* :php:`TYPO3\CMS\Frontend\Event\AfterCachedPageIsPersistedEvent`
+
+Extensions using the hooks can be made compatible with TYPO3 v11 and TYPO3 v12
+by registering a PSR-14-based event listener while keeping the legacy hook
+in place.
+
+The :php:`AfterCacheableContentIsGeneratedEvent` acts as a replacement for
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-cached']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-all']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['usePageCache']`
+
+whereas the :php:`AfterCachedPageIsPersistedEvent` is the replacement for
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['insertPageIncache']`.
+
+Provide a :php:`ServerRequestInterface` as first argument when calling
+:php:`TypoScriptFrontendController->generatePage_postProcessing()` in custom
+extension code.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97926-ExtbaseQuerySettingsMethodsRemoved.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97926-1657726187:
+
+========================================================
+Breaking: #97926 - Extbase QuerySettings methods removed
+========================================================
+
+See :issue:`97926`
+
+Description
+===========
+
+Extbase's Persistence functionality is basing ORM queries on certain settings
+usually fetched from :php:`QuerySettingsInterface`, with a default
+implementation :php:`Typo3QuerySettings`.
+
+The interface itself has changed so that it now requires two new methods:
+
+:php:`QuerySettingsInterface::getLanguageAspect(): LanguageAspect`
+:php:`QuerySettingsInterface::setLanguageAspect(LanguageAspect $aspect)`
+
+The LanguageAspect covers both the overlay functionality and setting the
+language ID.
+
+For this reason, the following methods are removed from
+:php:`QuerySettingsInterface`:
+
+- :php:`QuerySettingsInterface::getLanguageOverlayMode()`
+- :php:`QuerySettingsInterface::setLanguageOverlayMode($languageOverlayMode)`
+- :php:`QuerySettingsInterface::getLanguageUid()`
+- :php:`QuerySettingsInterface::setLanguageUid($languageUid)`
+
+All adaptions have been made to the default implementation in
+:php:`Typo3QuerySettings`, however the removed methods from the interface are kept
+within the implementation to avoid fatal PHP errors.
+
+Impact
+======
+
+Any custom implementation of :php:`QuerySettingsInterface` needs to implement
+the newly defined methods of the interface.
+
+Affected installations
+======================
+
+TYPO3 installations with custom Extbase extensions dealing with QuerySettings
+that are adjusted with the methods used above.
+
+Migration
+=========
+
+Switch the affected extensions via PHP to calling the newly added methods, as this is
+how TYPO3 Core behaves the most reliable.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/12.0/Breaking-97927-RemovedTypoScriptOptionConfigdoctypeSwitch.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97927-1657730964:
+
+=================================================================
+Breaking: #97927 - Removed TypoScript option config.doctypeSwitch
+=================================================================
+
+See :issue:`97927`
+
+Description
+===========
+
+Previous TYPO3 versions allowed to set :typoscript:`config.doctypeSwitch`
+via TypoScript.
+
+If this option was set, the order of <?xml...> and <!DOCTYPE...> during the
+rendering of a Frontend page was reversed. This was needed in the past for
+Internet Explorer to be standards-compliant with XHTML. Otherwise IE's
+"Quirks Mode" was used.
+
+Nowadays, usages for both Internet Explorer (which is not supported anymore) and
+XHTML have been low, which is why the option is now removed from TYPO3 Core.
+
+Impact
+======
+
+Setting the option :typoscript:`config.doctypeSwitch` has no effect anymore, the
+XML declaration and doctype statement are kept as is.
+
+Affected installations
+======================
+
+TYPO3 installations with old templates having this TypoScript option set.
+
+Migration
+=========
+
+It is recommended to avoid using this functionality, and to switch to HTML5.
+
+.. index:: TypoScript, NotScanned, ext:frontend

Documentation/Changelog/12.0/Breaking-97945-RemovedWorkspaceServiceHooks.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-97945:
+
+=================================================
+Breaking: #97945 - Removed WorkspaceService hooks
+=================================================
+
+See :issue:`97945`
+
+Description
+===========
+
+The hooks :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Workspaces\Service\WorkspaceService']['hasPageRecordVersions']`
+and :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Workspaces\Service\WorkspaceService']['fetchPagesWithVersionsInTable']`,
+used to manipulate the state of versions for pages and tables have been removed.
+
+This information has been used to highlight pages in the page tree. This
+modification however can now be done using the new PSR-14
+:php:`\TYPO3\CMS\Backend\Controller\Event\AfterPageTreeItemsPreparedEvent`.
+
+Impact
+======
+
+Any hook implementation registered is not executed anymore since
+TYPO3 v12.0. The extension scanner will report possible usages.
+
+Affected Installations
+======================
+
+All TYPO3 installations using these hooks in custom extension code.
+
+Migration
+=========
+
+The hooks are removed without deprecation in order to allow extensions
+to work with TYPO3 v11 (using the hook) and v12+ (using the new event).
+
+Use the :doc:`PSR-14 event <../12.0/Feature-97945-PSR14AfterPageTreeItemsPreparedEvent>`
+as replacement.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:workspaces

Documentation/Changelog/12.0/Breaking-98016-RemovedTypoScriptFunctionHook.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-98016-1658731955:
+
+===================================================
+Breaking: #98016 - Removed TypoScript function hook
+===================================================
+
+See :issue:`98016`
+
+Description
+===========
+
+With the transition to the :ref:`new TypoScript parser <feature-97816-1656350667>`,
+the hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tsparser.php']['preParseFunc']`
+is no longer called.
+
+This hook has been used to implement own functions for the TypoScript "function" operator :typoscript:`:=`.
+
+Additional functions can now be implemented using the
+:php:`\TYPO3\CMS\Core\TypoScript\AST\Event\EvaluateModifierFunctionEvent`
+as described in :ref:`this Changelog <feature-98016-1658732423>`.
+
+Impact
+======
+
+With the continued implementation of the new TypoScript parser in TYPO3 v12,
+registered hook implementations are not executed anymore. The extension scanner
+will report possible usages.
+
+Affected installations
+======================
+
+Extensions registering own TypoScript function implementations like this:
+
+..  code-block:: typoscript
+
+    myValue := myCustomFunction(modifierArgument)
+
+Migration
+=========
+
+Implement the :ref:`new event <feature-98016-1658732423>`. Extensions that want to keep
+compatibility with both TYPO3 v11 and v12 can keep the old hook implementation without
+further deprecations.
+
+.. index:: PHP-API, TSConfig, TypoScript, FullyScanned, ext:core

Documentation/Changelog/12.0/Breaking-98024-TCA-option-cruserid-removed.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-98024:
+
+=================================================
+Breaking: #98024 - TCA option `cruser_id` removed
+=================================================
+
+See :issue:`98024`
+
+Description
+===========
+
+The TCA option in the :php:`ctrl` section of each TCA table :php:`cruser_id` has been
+removed, along with populating this system-related information within DataHandler
+and the auto-creation of the database field.
+
+The setting was used to fill the UID of the Backend User who originally created
+the affected row. However, this information is also available through TYPO3's
+History functionality, and does not need to be persisted twice.
+
+Several drawbacks came with this feature, which is why it was removed entirely:
+
+* Extbase did not support this functionality
+* When a record was created via the Frontend in the plugin, the userid was not available
+
+Information about a record ("Info Popup" or within Workspaces) is now fetched
+through TYPO3's History functionality.
+
+Impact
+======
+
+When creating new records, the value of the database field is not auto-populated.
+
+Also, when upgrading to TYPO3 v12, the database field is prepared to be removed.
+
+The option :php:`$GLOBALS['TCA'][$tableName]['ctrl']['cruser_id']` is also
+automatically removed during cache warmup from the final TCA listing.
+
+Affected Installations
+======================
+
+TYPO3 installations actively using this field for querying or filling, not using
+TYPO3 API, and accessing the database directly.
+
+Migration
+=========
+
+If the need for the information – that is who created the record – is needed,
+use the History functionality to fetch the creation details of a record.
+
+If this field is actively queried, it is recommended to add this field as a
+regular TCA column with a custom hook or PSR-14 event to fill this information.
+
+.. index:: Database, TCA, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-98032-SerializableInterfaceFullyRemoved.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-98032:
+
+=======================================================
+Breaking: #98032 - Serializable Interface fully removed
+=======================================================
+
+See :issue:`98032`
+
+Description
+===========
+
+The :php:`Serializable` interface has been deprecated, and is
+slated for removal entirely in PHP 9. The preferred
+serialization tool is the :php:`__serialize`/:php:`__unserialize`
+method pair.
+
+All serializable classes in TYPO3 Core already implement
+:php:`__serialize`/:php:`__unserialize`, which is automatically
+used by PHP in place of :php:`Serializable`. The now-vestigial
+:php:`Serializable` references have been removed.
+
+Impact
+======
+
+Generally none, unless a text string of an object serialized in TYPO3 v10
+or earlier (using :php:`Serializable`) is deserialized in TYPO3 v12, in
+which case it will not deserialize correctly due to the different
+string format used by :php:`Serializable`. That is extremely unlikely
+to happen.
+
+The use of :php:`Serializable` in extensions is not recommended anymore,
+and will be removed from PHP in version 9.
+
+Affected Installations
+======================
+
+None.
+
+Migration
+=========
+
+None needed.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/12.0/Breaking-98069-DebugConsoleRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-98069-1659536025:
+
+=======================================
+Breaking: #98069 - DebugConsole removed
+=======================================
+
+See :issue:`98069`
+
+Description
+===========
+
+The DebugConsole comes from ExtJS times and was triggered when e.g. a request
+failed to give a developer its response, including the stacktrace. Nowadays,
+browsers offer a console allowing to investigate requests. Also, PHP debuggers
+(e.g. xdebug) are commonly known and used, which makes the DebugConsole obsolete.
+
+Impact
+======
+
+Triggering the DebugConsole is not possible anymore. Also, the PHP method
+:php:`\TYPO3\CMS\Core\Utility\DebugUtility::debug()` always renders the plain
+debug output to the client.
+
+The 3rd argument :php:`$group` of the method
+:php:`\TYPO3\CMS\Core\Utility\DebugUtility::debug()` is removed.
+
+Affected installations
+======================
+
+All installations are affected.
+
+Migration
+=========
+
+No migration is available.
+
+.. index:: Backend, JavaScript, PHP-API, PartiallyScanned, ext:backend

Documentation/Changelog/12.0/Breaking-98089-RemovedFontAwesome.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-98089-1659734321:
+
+======================================
+Breaking: #98089 - Removed FontAwesome
+======================================
+
+See :issue:`98089`
+
+Description
+===========
+
+The node package `font-awesome` and the related CSS and font files have been
+removed from the TYPO3 backend. This also includes the icon provider class
+:php:`\TYPO3\CMS\Core\Imaging\IconProvider\FontawesomeIconProvider`.
+
+The configuration option :php:`icon-class` of login providers has no effect
+anymore.
+
+Impact
+======
+
+Using the aforementioned icon provider to register icons is not possible
+anymore. Also, any direct usage of :css:`fa-*` classes will not work anymore.
+
+Affected installations
+======================
+
+All installations relying on FontAwesome are affected.
+
+Migration
+=========
+
+Migrate to the `@typo3/icons` package if possible. If the TYPO3 installation
+still requires FontAwesome, install the polyfill extension `fontawesome_provider`.
+
+To install the extension via Composer, run the command
+:bash:`composer require friendsoftypo3/fontawesome-provider`.
+
+The extension will be available in TER soon as `fontawesome_provider <https://extensions.typo3.org/extension/fontawesome_provider>`__.
+
+.. index:: Backend, PHP-API, NotScanned, ext:core