TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/11.0/Breaking-23736-PageLanguageDetectionSetEarlierInFrontendRequestProcess.rst

@@ -0,0 +1,59 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-23736:
+
+==================================================================================
+Breaking: #23736 - Page Language detection set earlier in Frontend Request Process
+==================================================================================
+
+See :issue:`23736`
+
+Description
+===========
+
+Previous TYPO3 sites without Site Handling
+used TypoScript conditions like `[globalVar = GP:L = 1]` to switch
+between languages. For this, TYPO3's Frontend Request Process needed a parsed TypoScript before
+doing the language overlay of the currently visited page.
+
+This made it impossible to use conditions for accessing the translated page record like `[page["nav_title"] == "Bienvenue"]`,
+which was a long outstanding conceptual issue that was finally made possible through Site Handling.
+
+Now, the translated page is resolved directly after the actual page and rootline resolving.
+
+
+Impact
+======
+
+The translated page record (based on the fallback handling in the
+Site Configuration) is now available in :php:`$TSFE->page` at a much earlier stage of the Frontend Request process.
+
+This means, TypoScript conditions based on the page record (see example above) might be different.
+
+In addition, the two hooks
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_preProcess']` and
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_postProcess']`
+
+are called earlier, no TypoScript is available yet.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using the hooks mentioned
+above or that have language-specific "page-based" conditions.
+
+
+Migration
+=========
+
+Review the hooks or use a PSR-15 middleware to use the same place
+to extend TYPO3's Frontend Request process after TypoScript was
+initialized.
+
+Also, be sure to review any of the TypoScript conditions (possible
+via the `Web->Template` module) if they are related to values only
+available in the default language, which seems to be a very rare case however.
+
+.. index:: PHP-API, TypoScript, NotScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-29342-ImproveValidatorTask.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-29342:
+
+=========================================================
+Breaking: #29342 - Fluid Email Template for ValidatorTask
+=========================================================
+
+See :issue:`29342`
+
+Description
+===========
+
+In TYPO3 v10 `ext:linkvalidator` has been improved a lot. The
+:php:`\TYPO3\CMS\Linkvalidator\Task\ValidatorTask`, a scheduler task for reporting
+broken links via email, has been refactored now.
+
+The old marker template has been replaced by Fluid templates, which are now
+used for generating the report email. The marker template has been removed completely
+along with corresponding functionality.
+
+The following property of the :php:`ValidatorTask` class has been removed:
+
+* :php:`$emailTemplateFile`
+
+The following hooks have been removed and won't be executed anymore:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['reportEmailMarkers']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['buildMailMarkers']`
+
+The following properties of the :php:`ValidatorTask` class have changed their type:
+
+* :php:`$page` is now :php:`int`
+* :php:`$depth` is now :php:`int`
+* :php:`$emailOnBrokenLinkOnly` is now :php:`bool`
+* :php:`$configuration` is now :php:`string`
+
+
+Impact
+======
+
+It is no longer possible to set a custom marker based template file with
+:php:`emailTemplateFile`. Instead, the new field :php:`emailTemplateName` can be used to
+specify a Fluid template file, see Migration section below.
+
+
+Affected Installations
+======================
+
+All installations which use:
+
+* the scheduler task and provide a custom template file
+* one of the hooks mentioned above
+
+
+Migration
+=========
+
+Provide your custom templates using the new field :php:`emailTemplateName`
+in the scheduler task configuration and add your custom template
+path to :php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['templateRootPaths']`.
+
+Use the new PSR-14 event :php:`\TYPO3\CMS\Linkvalidator\Event\ModifyValidatorTaskEmailEvent` to adjust the
+:php:`\TYPO3\CMS\Linkvalidator\Result\LinkAnalyzerResult` along with the `FluidEmail` object.
+
+.. index:: Backend, CLI, NotScanned, ext:linkvalidator

Documentation/Changelog/11.0/Breaking-45512-NoTypeAttributesForStyleAndLinkTags.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-45512:
+
+=============================================================
+Breaking: #45512 - No type attributes for style and link tags
+=============================================================
+
+See :issue:`45512`
+
+Description
+===========
+
+It is recommended for :html:`<style>` and :html:`<link>` HTML tags
+to not use the "type" attribute anymore.
+
+These references state its recommended practice to omit them:
+
+- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link
+- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style
+
+For this reason, TYPO3 does not add this "type" attribute to the mentioned
+HTML elements anymore when rendering HTML.
+
+Impact
+======
+
+The attribute :html:`type` is removed from the HTML tags :html:`<style>` and :html:`<link>`
+by default for TYPO3 Backend and Frontend output.
+
+Affected Installations
+======================
+
+All installations of TYPO3 that use :html:`<style>` or :html:`<link>` tags are affected.
+The probability this has negative impact on the user experience is low, however.
+
+
+Migration
+=========
+
+If requested due to very old browser requirements for TYPO3 Frontend,
+the type attribute can be added via TypoScript options or Fluid
+AssetCollector attributes again.
+
+.. index:: Backend, Frontend, NotScanned, ext:core

Documentation/Changelog/11.0/Breaking-79565-RemovedUsergroup_cached_listDatabaseField.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-79565:
+
+=================================================================
+Breaking: #79565 - Removed "usergroup_cached_list" database field
+=================================================================
+
+See :issue:`79565`
+
+Description
+===========
+
+The database field :sql:`be_users.usergroup_cached_list` has been
+removed. It was populated by a list of all groups (including
+subgroups) the user belongs to, and stored when a user logged in.
+The field however was never updated when an admin added or removed a group
+from the users group list.
+
+
+Impact
+======
+
+The mentioned database field is removed, any direct SQL queries
+accessing or writing this field will result in a database error.
+
+The PHP entry is removed from
+:php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->user` array.
+Accessing the array key will result in warnings since PHP 8.0.
+
+Affected Installations
+======================
+
+TYPO3 installations using or querying this database field
+with third-party extensions.
+
+TYPO3 installations reading the array key from
+:php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->user` array.
+
+Migration
+=========
+
+Use the class :php:`\TYPO3\CMS\Core\Authentication\GroupResolver`
+to fetch all groups of a user directly.
+
+.. index:: Backend, PHP-API, NotScanned, ext:core

Documentation/Changelog/11.0/Breaking-89137-DatabaseFieldsT3verTstampAndT3verCountDropped.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-89137:
+
+=======================================================================
+Breaking: #89137 - Database fields t3ver_tstamp and t3ver_count removed
+=======================================================================
+
+See :issue:`89137`
+
+Description
+===========
+
+The two workspace related database fields :sql:`t3ver_tstamp` and :sql:`t3ver_count`
+have been dropped from all workspace aware database tables. Also, all code handling these
+fields has been removed from the code base.
+
+
+Impact
+======
+
+The core did not show these fields to the user. It's very unlikely extensions made use of them.
+Admins upgrading to TYPO3 v11 can usually assume zero impact for their site functionality.
+
+
+Affected Installations
+======================
+
+All instances are affected by this change, the database analyzer will propose to drop the fields
+from a lot of tables including :sql:`pages` and :sql:`tt_content`.
+
+
+Migration
+=========
+
+Use the database analyzer during upgrade to drop the fields from affected database tables.
+
+.. index:: Database, NotScanned, ext:workspaces

Documentation/Changelog/11.0/Breaking-90799-DependencyInjectionWithNonPublicPropertiesHasBeenRemoved.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-90799:
+
+===================================================================================
+Breaking: #90799 - Dependency injection with non-public properties has been removed
+===================================================================================
+
+See :issue:`90799`
+
+Description
+===========
+
+In TYPO3 v9, the (dependency) injection via :php:`@Inject` has been marked as deprecated for
+non-public properties. The reason was to avoid having the core use the PHP reflection
+api to make non-public properties writable from outside the class scope. Since there
+are other methods for dependency injection (constructor/setter injection), injection
+into non-public properties has now been removed.
+
+
+Impact
+======
+
+Non-public properties with :php:`@Inject` annotations will no longer trigger extbase
+dependency injection. Those properties will have their default state after object
+instantiation.
+
+
+Affected Installations
+======================
+
+All installations that use non-public properties for extbase dependency injection
+as seen in this example:
+
+.. code-block:: php
+
+   class Foo
+   {
+       /**
+        * @var Service
+        * @TYPO3\CMS\Extbase\Annotation\Inject
+        */
+       private $service;
+   }
+
+
+Migration
+=========
+
+When not using constructor/setter injection instead, switch to inject methods
+(recommended for compatibility with symfony dependency injection) or mark the
+property public (works with extbase dependency injection only):
+
+.. code-block:: php
+
+   class Foo
+   {
+       /**
+        * @var Service
+        * @TYPO3\CMS\Extbase\Annotation\Inject
+        */
+       public $service;
+   }
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Breaking-91473-DeprecatedFunctionalityRemoved.rst

@@ -0,0 +1,390 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91473:
+
+===================================================
+Breaking: #91473 - Deprecated functionality removed
+===================================================
+
+See :issue:`91473`
+
+Description
+===========
+
+The following PHP classes that have previously been marked as deprecated for v10 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\Configuration\TsConfigParser`
+- :php:`\TYPO3\CMS\Backend\Controller\File\CreateFolderController`
+- :php:`\TYPO3\CMS\Backend\Controller\File\EditFileController`
+- :php:`\TYPO3\CMS\Backend\Controller\File\FileUploadController`
+- :php:`\TYPO3\CMS\Backend\Controller\File\RenameFileController`
+- :php:`\TYPO3\CMS\Backend\Controller\File\ReplaceFileController`
+- :php:`\TYPO3\CMS\Backend\Template\DocumentTemplate`
+- :php:`\TYPO3\CMS\Core\Console\CommandRequestHandler`
+- :php:`\TYPO3\CMS\Core\Localization\Parser\LocallangXmlParser`
+- :php:`\TYPO3\CMS\Core\Routing\Aspect\PersistenceDelegate`
+- :php:`\TYPO3\CMS\Core\Routing\Legacy\PersistedAliasMapperLegacyTrait`
+- :php:`\TYPO3\CMS\Core\Routing\Legacy\PersistedPatternMapperLegacyTrait`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\AbstractFileCollection`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\FileMount`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\FolderBasedFileCollection`
+- :php:`\TYPO3\CMS\Extbase\Domain\Model\StaticFileCollection`
+- :php:`\TYPO3\CMS\Extbase\Domain\Repository\FileMountRepository`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Request`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverter\AbstractFileCollectionConverter`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverter\FolderBasedFileCollectionConverter`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverter\StaticFileCollectionConverter`
+- :php:`\TYPO3\CMS\Felogin\Controller\FrontendLoginController`
+- :php:`\TYPO3\CMS\Felogin\Hooks\CmsLayout`
+- :php:`\TYPO3\CMS\Fluid\ViewHelpers\Widget\AutocompleteViewHelper`
+- :php:`\TYPO3\CMS\Fluid\ViewHelpers\Widget\Controller\AutocompleteController`
+
+The following PHP interfaces that have previously been marked as deprecated for v10 and were now removed:
+
+- :php:`\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface`
+- :php:`\TYPO3\CMS\Core\Console\RequestHandlerInterface`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface`
+- :php:`\TYPO3\CMS\Core\Routing\Aspect\DelegateInterface`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectGetSingleHookInterface`
+
+The following PHP class aliases that have previously been marked as deprecated for v10 and were now removed:
+
+* :php:`TYPO3\CMS\Frontend\Page\PageRepository`
+* :php:`TYPO3\CMS\Frontend\Page\PageRepositoryGetPageHookInterface`
+* :php:`TYPO3\CMS\Frontend\Page\PageRepositoryGetPageOverlayHookInterface`
+* :php:`TYPO3\CMS\Frontend\Page\PageRepositoryGetRecordOverlayHookInterface`
+* :php:`TYPO3\CMS\Frontend\Page\PageRepositoryInitHookInterface`
+* :php:`TYPO3\CMS\Lowlevel\Utility\ArrayBrowser`
+
+The following PHP class methods that have previously been marked as deprecated for v10 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->createChangeLog`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->createMultipleDiff`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->getElementData`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->getHistoryData`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->getHistoryEntry`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->performRollback`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->setLastHistoryEntry`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->shouldPerformRollback`
+- :php:`\TYPO3\CMS\Core\Console\CommandRegistry->getIterator`
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->assemblePermissions`
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->process_uploads`
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->setTSconfigPermissions`
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService->getLabelsWithPrefix`
+- :php:`\TYPO3\CMS\Core\Html\RteHtmlParser->init`
+- :php:`\TYPO3\CMS\Core\Html\RteHtmlParser->RTE_transform`
+- :php:`\TYPO3\CMS\Core\Resource\File->_getMetaData`
+- :php:`\TYPO3\CMS\Core\Resource\FileRepository->searchByName`
+- :php:`\TYPO3\CMS\Core\Resource\Index\FileIndexRepository->findBySearchWordInMetaData`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactory->getInstance`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorage->checkFileAndFolderNameFilters`
+- :php:`\TYPO3\CMS\Core\Utility\BasicFileUtility->setFileExtensionPermissions`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController->emitBeforeCallActionMethodSignal`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->setUseCacheHash`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->getUseCacheHash`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->cImage`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->getAltParam`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->getBorderAttr`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->getImageSourceCollection`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->getImageTagTemplate`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->linkWrap`
+- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->sendNotifyEmail`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->isOutputting`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->processContentForOutput`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->reqCHash`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->settingLocale`
+- :php:`\TYPO3\CMS\Linkvalidator\Repository\BrokenLinkRepository->getNumberOfBrokenLinks`
+
+
+The following PHP static class methods that have previously been marked as deprecated for v10 and were now removed:
+
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getRawPagesTSconfig`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getViewDomain`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::TYPO3_copyRightNotice`
+- :php:`\TYPO3\CMS\Core\Localization\Locales::initialize`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::compressIPv6`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::flushDirectory`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::getApplicationContext`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::idnaEncode`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::IPv6Hex2Bin`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::IPv6Bin2Hex`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::isRunningOnCgiServerApi`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::linkThisUrl`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::milliseconds`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::presetApplicationContext`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::resetApplicationContext`
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::verifyFilenameAgainstDenyPattern`
+- :php:`\TYPO3\CMS\Core\Utility\VersionNumberUtility::convertIntegerToVersionNumber`
+- :php:`\TYPO3\CMS\Core\Utility\VersionNumberUtility::splitVersionRange`
+- :php:`\TYPO3\CMS\Core\Utility\VersionNumberUtility::raiseVersionNumber`
+- :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName`
+- :php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin`
+
+The following methods changed signature according to previous deprecations in v10 at the end of the argument list:
+
+- :php:`\TYPO3\CMS\Core\Database\ReferenceIndex->updateIndex` (argument 2 is now either null or ProgressListenerInterface, not boolean anymore)
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->doesRecordExist` (argument 3 is now an integer)
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->recordInfoWithPermissionCheck` (argument 3 is now an integer)
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService->includeLLFile` (arguments 2 and 3 are dropped)
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::findService` (arguments 3 :php:`$excludeServiceKeys` is now an array)
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction` (arguments 3 no expects an object or null)
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::getUrl` (arguments 2, 3 and 4 are dropped)
+- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstanceService` (arguments 3 :php:`$excludeServiceKeys` is now an array)
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper->__construct` (argument :php:`$query` is removed)
+- :php:`\TYPO3\CMS\Extbase\Persistence\Reflection\ObjectAccess->setProperty` (argument :php:`$forceDirectAccess` is removed)
+- :php:`\TYPO3\CMS\Extbase\Persistence\Reflection\ObjectAccess->getProperty` (argument :php:`$forceDirectAccess` is removed)
+- :php:`\TYPO3\CMS\Extbase\Persistence\Reflection\ObjectAccess->getPropertyInternal` (argument :php:`$forceDirectAccess` is removed)
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->__construct`
+
+The following public class properties have been dropped:
+
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->changeLog`
+- :php:`\TYPO3\CMS\Backend\History\RecordHistory->lastHistoryEntry`
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->defaultPermissions`
+- :php:`\TYPO3\CMS\Core\DataHandling\DataHandler->pMap`
+- :php:`\TYPO3\CMS\Core\TypoScript\TemplateService->forceTemplateParsing`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->cHash`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->cHash_array`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->divSection`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->domainStartPage`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->fePreview`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->forceTemplateParsing`
+- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->sys_language_isocode`
+
+The following class methods have changed visibility:
+
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService->debugLL()`
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService->getLLL()`
+
+The following class properties have changed visibility:
+
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService->LL_files_cache`
+- :php:`\TYPO3\CMS\Core\Localization\LanguageService->LL_labels_cache`
+
+The following ViewHelpers have changed:
+
+- :html:`<f:form>` ViewHelper argument "noCacheHash" is dropped
+- :html:`<f:link.action>` ViewHelper argument "noCacheHash" is dropped
+- :html:`<f:link.page>` ViewHelper argument "noCacheHash" is dropped
+- :html:`<f:link.typolink>` ViewHelper argument "useCacheHash" is dropped
+- :html:`<f:uri.action>` ViewHelper argument "noCacheHash" is dropped
+- :html:`<f:uri.page>` ViewHelper argument "noCacheHash" is dropped
+- :html:`<f:uri.typolink>` ViewHelper argument "useCacheHash" is dropped
+- :html:`<f:widget.link>` ViewHelper argument "useCacheHash" is dropped
+- :html:`<f:widget.uri>` ViewHelper argument "useCacheHash" is dropped
+- :html:`<f:widget.autocomplete>` ViewHelper is removed
+
+The following TypoScript options have been dropped:
+
+- Extbase TypoScript option `requireCHashArgumentForActionArguments` for any plugin
+- `typolink.useCacheHash`
+- `typolink.addQueryString.method = POST`
+- `typolink.addQueryString.method = POST,GET`
+- `typolink.addQueryString.method = GET,POST`
+
+The following constants have been dropped:
+
+- :php:`FILE_DENY_PATTERN_DEFAULT`
+- :php:`PHP_EXTENSIONS_DEFAULT`
+- :php:`TYPO3_copyright_year`
+- :php:`TYPO3_URL_DONATE`
+- :php:`TYPO3_URL_EXCEPTION`
+- :php:`TYPO3_URL_GENERAL`
+- :php:`TYPO3_URL_LICENSE`
+- :php:`TYPO3_URL_WIKI_OPCODECACHE`
+
+The following class constants have been dropped:
+
+- :php:`\TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider::SIGNAL_PostProcessTreeData`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface::SIGNAL_PreProcessStorage`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface::SIGNAL_PostProcessStorage`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileCreate`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileReplace`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileSetContents`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileCreate`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileReplace`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileSetContents`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreGeneratePublicUrl`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_SanitizeFileName`
+- :php:`\TYPO3\CMS\Core\Resource\Service\FileProcessingService::SIGNAL_PreFileProcess`
+- :php:`\TYPO3\CMS\Core\Resource\Service\FileProcessingService::SIGNAL_PostFileProcess`
+- :php:`\TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::FORMAT_PLAINTEXT`
+- :php:`\TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::FORMAT_HTML`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss`
+
+The following global options are ignored:
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXT']['runtimeActivatedPackages']`
+
+The following global variables have been removed:
+
+- :php:`$GLOBALS['LOCAL_LANG']`
+
+The following hooks have been removed:
+
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['cObjTypeAndClassDefault']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['cObjTypeAndClass']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['extLinkATagParamsHandler']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['typolinkLinkHandler']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-output']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['isOutputting']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_eofe']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageIndexing']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['tslib_fe-contentStrReplace']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['beforeRedirect']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['forgotPasswordMail']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_confirmed']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_error']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['loginFormOnSubmitFuncs']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['logout_confirmed']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed']`
+- :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['postProcContent']`
+
+The following signals have been removed:
+
+- :php:`PackageManagement::packagesMayHaveChanged`
+- :php:`\TYPO3\CMS\Backend\Backend\ToolbarItems\SystemInformationToolbarItem::getSystemInformation`
+- :php:`\TYPO3\CMS\Backend\Backend\ToolbarItems\SystemInformationToolbarItem::loadMessages`
+- :php:`\TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::getPageRenderer`
+- :php:`\TYPO3\CMS\Backend\Controller\EditDocumentController::preInitAfter`
+- :php:`\TYPO3\CMS\Backend\Controller\EditDocumentController::initAfter`
+- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfigPreInclude`
+- :php:`\TYPO3\CMS\Beuser\Controller\BackendUserController::switchUser`
+- :php:`\TYPO3\CMS\Core\Database\SoftReferenceIndex::setTypoLinkPartsElement`
+- :php:`\TYPO3\CMS\Core\Database\ReferenceIndex::shouldExcludeTableFromReferenceIndex`
+- :php:`\TYPO3\CMS\Core\Imaging\IconFactory::buildIconForResourceSignal`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface::SIGNAL_PreProcessStorage`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceFactoryInterface::SIGNAL_PostProcessStorage`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileCreate`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileReplace`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFileSetContents`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PostFolderRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileCreate`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileReplace`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFileSetContents`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderAdd`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderCopy`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderDelete`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderMove`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreFolderRename`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_PreGeneratePublicUrl`
+- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::SIGNAL_SanitizeFileName`
+- :php:`\TYPO3\CMS\Core\Resource\Service\FileProcessingService::SIGNAL_PreFileProcess`
+- :php:`\TYPO3\CMS\Core\Resource\Service\FileProcessingService::SIGNAL_PostFileProcess`
+- :php:`\TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider::PostProcessTreeData`
+- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::tcaIsBeingBuilt`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Dispatcher::afterRequestDispatch`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController::beforeCallActionMethod`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper::afterMappingSingleRow`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Backend::beforeGettingObjectData`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Backend::afterGettingObjectData`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Backend::endInsertObject`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Backend::afterUpdateObject`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Backend::afterPersistObject`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Backend::afterRemoveObject`
+- :php:`\TYPO3\CMS\Extensionmanager\Utility\InstallUtility::afterExtensionInstall`
+- :php:`\TYPO3\CMS\Extensionmanager\Utility\InstallUtility::afterExtensionUninstall`
+- :php:`\TYPO3\CMS\Extensionmanager\Utility\InstallUtility::afterExtensionT3DImport`
+- :php:`\TYPO3\CMS\Extensionmanager\Utility\InstallUtility::afterExtensionStaticSqlImport`
+- :php:`\TYPO3\CMS\Extensionmanager\Utility\InstallUtility::afterExtensionFileImport`
+- :php:`\TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService::willInstallExtensions`
+- :php:`\TYPO3\CMS\Extensionmanager\ViewHelper\ProcessAvailableActionsViewHelper::processActions`
+- :php:`\TYPO3\CMS\Install\Service\SqlExpectedSchemaService::tablesDefinitionIsBeingBuilt`
+- :php:`\TYPO3\CMS\Impexp\Utility\ImportExportUtility::afterImportExportInitialisation`
+- :php:`\TYPO3\CMS\Lang\Service\TranslationService::postProcessMirrorUrl`
+- :php:`\TYPO3\CMS\Linkvalidator\LinkAnalyzer::beforeAnalyzeRecord`
+- :php:`\TYPO3\CMS\Seo\Canonical\CanonicalGenerator::beforeGeneratingCanonical`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss`
+- :php:`\TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss`
+
+The following features are now always enabled:
+
+- `felogin.extbase`
+
+The following features have been removed:
+
+- All install tool upgrade wizards upgrading from v8 to v9
+- CLI Command Configuration definition via :file:`Commands.php`
+- Pi-based plugin for "felogin" (CType `login`)
+- XML-based (TYPO3-custom XML format) label parsing
+
+The following database fields have been removed:
+
+- :sql:`sys_template.sitetitle`
+- :sql:`pages.legacy_overlay_uid`
+
+The following Backend route identifiers have been removed:
+
+- `xMOD_tximpexp`
+
+The following global JavaScript variables have been removed:
+
+- :js:`T3_THIS_LOCATION`
+- :js:`T3_RETURN_URL`
+
+The following global JavaScript functions have been removed:
+
+- :js:`jumpExt`
+- :js:`jumpToUrl`
+- :js:`rawurlencode`
+- :js:`str_replace`
+- :js:`openUrlInWindow`
+- :js:`setFormValueOpenBrowser`
+- :js:`setFormValueFromBrowseWin`
+- :js:`setHiddenFromList`
+- :js:`setFormValueManipulate`
+- :js:`setFormValue_getFObj`
+
+The following JavaScript modules have been removed:
+
+- :js:`jquery.clearable`
+- :js:`md5`
+
+Impact
+======
+
+Instantiating or requiring the PHP classes or calling the PHP methods directly will trigger PHP :php:`E_ERROR` errors.
+
+.. index:: Backend, CLI, FlexForm, Fluid, Frontend, JavaScript, LocalConfiguration, PHP-API, TCA, TSConfig, TypoScript, PartiallyScanned

Documentation/Changelog/11.0/Breaking-91562-CObjectTEMPLATERemoved.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91562:
+
+===========================================
+Breaking: #91562 - cObject TEMPLATE removed
+===========================================
+
+See :issue:`91562`
+
+Description
+===========
+
+The cObject :typoscript:`TEMPLATE`, used for rendering marker-based templates
+has been removed along with the PHP class :php:`TYPO3\CMS\Frontend\ContentObject\TemplateContentObject`.
+
+The successor :typoscript:`FLUIDTEMPLATE` is widely used since TYPO3 v7,
+and acts as a replacement for marker-based templates.
+
+
+Impact
+======
+
+Using TypoScript with :typoscript:`page.10 = TEMPLATE` will result in a PHP
+error when rendering the frontend.
+
+Referencing the PHP class will result in a fatal PHP error.
+
+
+Affected Installations
+======================
+
+TYPO3 installation still using :typoscript:`TEMPLATE` cObject in their TypoScript.
+
+
+Migration
+=========
+
+Refactor TypoScript templates to not use the cObject :typoscript:`TEMPLATE` anymore.
+
+In case you can not or want not make the switch to :typoscript:`FLUIDTEMPLATE`, install
+the extension `modern_template_building` from the official
+TYPO3 Extension Repository at https://extensions.typo3.org/, which acts as a drop-in replacement, and also ships the cObject :typoscript:`FILE`
+which is highly useful for :typoscript:`TEMPLATE` cObjects.
+
+The extension is compatible with TYPO3 v9+.
+
+.. index:: TypoScript, FullyScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-91563-PHP-basedJSCSSInclusionsForFrontendRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91563:
+
+=====================================================================
+Breaking: #91563 - PHP-based JS + CSS inclusions for Frontend removed
+=====================================================================
+
+See :issue:`91563`
+
+Description
+===========
+
+In the past, TYPO3's :php:`TSFE` object allowed to manually add CSS or JavaScript snippets via PHP code with the following method and properties:
+
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->setJS()`
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->additionalJavaScript`
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->additionalCSS`
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->JSCode`
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->inlineJS`
+
+These have been removed due to better APIs like :php:`PageRenderer` (available since TYPO3 v4.5) and :php:`AssetCollector` (available since TYPO3 v10).
+
+
+Impact
+======
+
+Accessing the method and properties will have no effect and trigger PHP errors.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this functionality directly to inject custom CSS or JavaScript.
+
+
+Migration
+=========
+
+Use the :php:`AssetCollector` API in PHP to add JavaScript and CSS code or use files directly.
+
+.. index:: PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-91578-IrreRelatedJavaScriptHasBeenRemoved.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91578:
+
+===========================================================
+Breaking: #91578 - IRRE related JavaScript has been removed
+===========================================================
+
+See :issue:`91578`
+
+Description
+===========
+
+The JavaScript functions :js:`TBE_EDITOR.fieldChanged_fName` and its legacy
+alias :js:`TBE_EDITOR_fieldChanged_fName`, used to extract the table name, field
+name and uid from the incoming field name, have been removed.
+
+
+Impact
+======
+
+Calling any of the removed function will trigger a JavaScript error.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions calling these functions are affected.
+
+
+Migration
+=========
+
+No migration is possible as this is IRRE-related code only.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-91606-DatetimeOperationsInFormEngineRemoved.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91606:
+
+=============================================================
+Breaking: #91606 - Date/time operations in FormEngine removed
+=============================================================
+
+See :issue:`91606`
+
+Description
+===========
+
+FormEngine supported to add or subtract a date or time range (depending on the
+field type) by appending e.g. `+5` or `-42` to the field values. These kind of
+operations have been removed as they are rather unknown and clumsy to use.
+
+
+Impact
+======
+
+Using these operations doesn't have any effect anymore.
+
+
+Affected Installations
+======================
+
+All installations of TYPO3 are affected.
+
+
+Migration
+=========
+
+There is no migration possible.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-91740-DeprecatedIconIdentifierRemoved.rst

@@ -0,0 +1,132 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91740:
+
+=====================================================
+Breaking: #91740 - Deprecated icon identifier removed
+=====================================================
+
+See :issue:`91740`
+
+Description
+===========
+
+The following deprecated icon identifiers have been removed from the Icon API:
+
++-------------------------------------------+-------------------------------------------+
+| Deprecated identifier                     | New identifier                            |
++===========================================+===========================================+
+| module-web                                | modulegroup-web'                          |
++-------------------------------------------+-------------------------------------------+
+| module-site                               | modulegroup-site'                         |
++-------------------------------------------+-------------------------------------------+
+| module-file                               | modulegroup-file'                         |
++-------------------------------------------+-------------------------------------------+
+| module-tools                              | modulegroup-tools'                        |
++-------------------------------------------+-------------------------------------------+
+| module-system                             | modulegroup-system'                       |
++-------------------------------------------+-------------------------------------------+
+| module-help                               | modulegroup-help'                         |
++-------------------------------------------+-------------------------------------------+
+| module-workspaces-action-preview-link     | actions-version-workspaces-preview-link'  |
++-------------------------------------------+-------------------------------------------+
+| generate-ws-preview-link                  | actions-version-workspaces-preview-link'  |
++-------------------------------------------+-------------------------------------------+
+| extensions-workspaces-generatepreviewlink | 'actions-version-workspaces-preview-link' |
++-------------------------------------------+-------------------------------------------+
+| extensions-extensionmanager-update-script | 'actions-refresh'                         |
++-------------------------------------------+-------------------------------------------+
+| extensions-scheduler-run-task             | actions-play'                             |
++-------------------------------------------+-------------------------------------------+
+| extensions-scheduler-run-task-cron        | actions-clock'                            |
++-------------------------------------------+-------------------------------------------+
+| status-warning-lock                       | warning-lock'                             |
++-------------------------------------------+-------------------------------------------+
+| status-warning-in-use                     | warning-in-use'                           |
++-------------------------------------------+-------------------------------------------+
+| status-status-reference-hard              | status-reference-hard'                    |
++-------------------------------------------+-------------------------------------------+
+| status-status-reference-soft              | status-reference-soft'                    |
++-------------------------------------------+-------------------------------------------+
+| status-status-edit-read-only              | status-edit-read-only'                    |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-advanced-password            | form-advanced-password'                   |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-checkbox                     | form-checkbox'                            |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-content-element              | form-content-element'                     |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-date-picker                  | form-date-picker'                         |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-duplicate                    | actions-duplicate'                        |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-email                        | form-email'                               |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-fieldset                     | form-fieldset'                            |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-file-upload                  | form-file-upload'                         |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-finisher                     | form-finisher'                            |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-form-element-selector        | actions-variable-select'                  |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-gridcontainer                | form-gridcontainer'                       |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-gridrow                      | form-gridrow'                             |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-hidden                       | form-hidden'                              |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-image-upload                 | form-image-upload'                        |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-insert-after                 | actions-form-insert-after'                |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-insert-in                    | actions-form-insert-in'                   |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-multi-checkbox               | form-multi-checkbox'                      |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-multi-select                 | form-multi-select'                        |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-number                       | form-number'                              |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-page                         | form-page'                                |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-password                     | form-password'                            |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-radio-button                 | form-radio-button'                        |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-single-select                | form-single-select'                       |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-static-text                  | form-static-text'                         |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-summary-page                 | form-summary-page'                        |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-telephone                    | form-telephone'                           |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-text                         | form-text'                                |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-textarea                     | form-textarea'                            |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-url                          | form-url'                                 |
++-------------------------------------------+-------------------------------------------+
+| t3-form-icon-validator                    | form-validator'                           |
++-------------------------------------------+-------------------------------------------+
+
+Impact
+======
+
+Loading any removed icon will result in getting the icon identifier
+`default-not-found`.
+
+
+Affected Installations
+======================
+
+All installations using these deprecated icons are affected.
+
+
+Migration
+=========
+
+Use the icon identifiers as listed in the table above.
+
+.. index:: Backend, PHP-API, NotScanned, ext:core

Documentation/Changelog/11.0/Breaking-91782-LockToDomain.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91782:
+
+======================================================================================================
+Breaking: #91782 - lockToDomain feature for frontend users / groups and backend users / groups removed
+======================================================================================================
+
+See :issue:`91782`
+
+Description
+===========
+
+TYPO3 Core shipped with a feature called "lockToDomain" for frontend and backend users which made the user login only valid if
+the exact given HTTP_HOST matches the filled domain.
+
+A similar functionality with the same name for groups existed, which only added the group to a specific user during a session,
+if the user was accessing a TYPO3 site under a specific domain.
+
+Both features have been removed.
+
+Impact
+======
+
+Frontend users or backend users that have this option set previously, will now be able to login independent of the defined HTTP_HOST
+header sent with the login page.
+
+Regardless of any setting of the "lockToDomain" setting of a specific group, all groups added
+to a user are now applied during login of a user, both for frontend and backend.
+
+
+Affected Installations
+======================
+
+TYPO3 Installations using this feature in their database records are affected. Following SQL SELECT statements help to identify records
+with a value for the features, which indicates those users and groups will now be able to log in without the domain restriction.
+
+Frontend Users:
+
+.. code-block:: sql
+
+   SELECT uid, pid, username FROM fe_users WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
+
+Backend Users:
+
+.. code-block:: sql
+
+   SELECT uid, pid, username FROM be_users WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
+
+Frontend Groups:
+
+.. code-block:: sql
+
+   SELECT uid, pid, username FROM fe_groups WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
+
+Backend Groups:
+
+.. code-block:: sql
+
+   SELECT uid, pid, username FROM be_groups WHERE lockToDomain != '' AND lockToDomain IS NOT NULL;
+
+
+Migration
+=========
+
+Any installations needing this feature should build this in
+custom extensions extending TCA and a custom Authentication Service.
+
+In addition, if such a feature is needed for frontend users
+or groups, it is recommended to use the storagePid option to limit
+frontend user login by Storage Folders.
+
+.. index:: Database, TCA, NotScanned, ext:core

Documentation/Changelog/11.0/Breaking-91906-StoreTransOrigDiffSourceFieldAsJson.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91906:
+
+================================================================
+Breaking: #91906 - Store TransOrigDiffSourceField as json string
+================================================================
+
+See :issue:`91906`
+
+Description
+===========
+
+The TCA field :php:`['tableName']['ctrl']['transOrigDiffSourceField']` - often set to
+:php:`l18n_diffsource` - stores the state of the source language record a translated
+record has been created from. This is used if content in the source language
+of a record has been changed to hint editors for a potentially needed update
+of the translated record.
+
+The storage format of this field has been changed from a PHP serialized string
+to a json encoded string.
+
+Impact
+======
+
+Usages of this field can be expected to be core internal. The impact on existing
+instances in low since it's unlikely that an extension uses the field content.
+
+
+Affected Installations
+======================
+
+Installations with multi language sites are affected and should run the
+upgrade wizard.
+
+
+Migration
+=========
+
+Run "Admin Tools" -> "Upgrade" -> "Upgrade Wizard" -> "Migrate transOrigDiffSourceField field to json encoded string."
+to adapt existing rows to the new storage format.
+
+.. index:: Database, NotScanned, ext:core

Documentation/Changelog/11.0/Breaking-91909-SysCollectionDatabaseTablesMovedIntoExternalExtension.rst

@@ -0,0 +1,59 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91909:
+
+===============================================================================
+Breaking: #91909 - sys_collection database tables moved into external extension
+===============================================================================
+
+See :issue:`91909`
+
+Description
+===========
+
+The generic :sql:`sys_collection` database table and its MM table :sql:`sys_collection_entries`, which
+holds information of connected records to a "Record Collection" have
+been removed from TYPO3 Core.
+
+This feature was added as a more generic approach of the `sys_file_collection`
+definition along with the File Abstraction Layer in TYPO3 v6.0. The file collection
+allows to create a group of files (e.g. from a folder, or from a category).
+
+However, the more generic API was never picked up in TYPO3 Core since 2012.
+
+The database table, the TCA definition (for editing the records
+in the database), and the PHP API are now available in a separate
+extension installable via the TYPO3 Extension Repository (https://extensions.typo3.org)
+or via composer ("friendsoftypo3/legacy-collections").
+
+The third-party extension can be used as a 1:1 drop-in replacement
+for the removed Core functionality.
+
+
+Impact
+======
+
+It is not possible to modify / edit :sql:`sys_collection` records anymore in the TYPO3 Backend.
+
+The database tables are not defined anymore, neither is the TCA definition.
+
+Accessing the PHP API class will result in fatal PHP errors.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using the database tables belonging to the :sql:`sys_collection` feature
+which is very unlikely.
+
+
+Migration
+=========
+
+Use the upgrade wizard or install the `legacy_collections` extension
+to re-add the functionality - but only if it is needed.
+
+As the PHP classes have a class alias, everything should work
+as before.
+
+.. index:: Database, TCA, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-91974-ConfigurationOptionIPmaskMountGroupsRemoved.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-91974:
+
+=================================================================
+Breaking: #91974 - Configuration Option IPmaskMountGroups removed
+=================================================================
+
+See :issue:`91974`
+
+Description
+===========
+
+The global configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['FE'][IPmaskMountGroups]` has been removed. It allowed to automatically assign
+groups to users visiting the TYPO3 Frontend from specific IP addresses / networks.
+
+This is especially handy to show content only in Intranet/Extranet
+sites where internal members see restricted content automatically.
+
+However, showing content based on certain contexts is usually solved with a much more flexible way through third-party extensions
+such as EXT:contexts. Third-party extensions allow even for automatic login based on IP-addresses, which should be used instead.
+
+
+Impact
+======
+
+The mentioned option is automatically removed from :file:`LocalConfiguration.php`
+on upgrade, and not evaluated anymore.
+
+
+Affected Installations
+======================
+
+Installations having the global configuration setting set in
+:file:`typo3conf/LocalConfiguration.php` or :file:`typo3conf/AdditionalConfiguration.php`, mostly related to intranet / extranet websites.
+
+
+Migration
+=========
+
+If this functionality explicitly is required, it can be provided by a third-party extension, or a custom extension registering
+a AuthenticationService ("getGroupsFE") to assign the groups on a more specific approach.
+
+.. index:: LocalConfiguration, FullyScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-92060-DroppedClassTYPO3CMSBackendViewPageTreeView.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92060:
+
+========================================================================
+Breaking: #92060 - Dropped class TYPO3\\CMS\\Backend\\View\\PageTreeView
+========================================================================
+
+See :issue:`92060`
+
+Description
+===========
+
+Class :php:`TYPO3\CMS\Backend\View\PageTreeView` has been dropped without substitution.
+
+
+Impact
+======
+
+Extensions using or extending this class will throw fatal PHP errors.
+
+
+Affected Installations
+======================
+
+This core internal class has been unused for a while. There is little
+chance some extension depends on it. The extension scanner finds affected
+extensions with a strong match.
+
+
+Migration
+=========
+
+If still needed, copy the class code from an older core version to the affected extension,
+adapt namespace and usages.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92118-TCACtrlThumbnailSettingDropped.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92118:
+
+=====================================================
+Breaking: #92118 - TCA ctrl thumbnail setting dropped
+=====================================================
+
+See :issue:`92118`
+
+Description
+===========
+
+The TCA setting :php:`$GLOBALS['TCA'][$aTableName]['ctrl']['thumbnail']` has been dropped.
+
+
+Impact
+======
+
+Setting the control field for a custom table has no effect anymore.
+
+
+Affected Installations
+======================
+
+The setting has been used in the :guilabel:`List` module for tables with image fields to render a preview
+of attached images. It has been used for :php:`tt_content` in core versions until TYPO3 v7.
+There are probably not many extensions using the setting. The :guilabel:`List` module will
+no longer show preview images for rendered rows.
+
+
+Migration
+=========
+
+Drop this setting during extension clean up. The setting is simply ignored, no PHP error will be thrown.
+
+.. index:: TCA, NotScanned, ext:recordlist

Documentation/Changelog/11.0/Breaking-92128-DatabaseRecordListDropHookToModifySearchFields.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92128:
+
+=======================================================================
+Breaking: #92128 - DatabaseRecordList: Drop hook to modify searchFields
+=======================================================================
+
+See :issue:`92128`
+
+Description
+===========
+
+The TCA configuration :php:`searchFields` in the `ctrl` section was introduced in TYPO3 4.6.
+This configuration allows defining search columns.
+Those columns are taken into account by the search in the TYPO3 backend.
+
+To enable a smooth transition between TYPO3 4.5 and 4.6, the hook
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['mod_list']['getSearchFieldList']` was introduced as well. It allowed
+to manipulate the :php:`searchFields` for the list modules search.
+
+As this transition should be finished now, the hook has been removed.
+
+Impact
+======
+
+The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['mod_list']['getSearchFieldList']`
+isn't evaluated anymore.
+
+
+Affected Installations
+======================
+
+All installations using this hook.
+
+
+Migration
+=========
+
+Set the search fields in the following TCA configuration:
+:php:`['ctrl']['searchFields'] = 'list, of, search, columns'`
+
+.. index:: Backend, PHP-API, FullyScanned, ext:recordlist

Documentation/Changelog/11.0/Breaking-92132-LastRemainsOfGlobalsSOBERemoved.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92132:
+
+=======================================================
+Breaking: #92132 - Last remains of globals SOBE removed
+=======================================================
+
+See :issue:`92132`
+
+Description
+===========
+
+The :php:`$GLOBALS['SOBE']` object has been used as a controller to
+sub module communication. It's usage has been reduced in previous core versions
+already. It is now fully removed.
+
+
+Impact
+======
+
+Backend extensions that rely on :php:`$GLOBALS['SOBE']` may behave differently.
+
+
+Affected Installations
+======================
+
+Some old backend extensions may still rely on :php:`$GLOBALS['SOBE']` being set.
+The extension scanner will find usages.
+
+
+Migration
+=========
+
+Do not rely on :php:`$GLOBALS['SOBE']` being set anymore, hand over arguments to other classes directly.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92206-RemoveWorkspaceSwappingOfElements.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92206:
+
+========================================================
+Breaking: #92206 - Remove workspace swapping of elements
+========================================================
+
+See :issue:`92206`
+
+Description
+===========
+
+When using workspaces, putting modified content into the live workspace can be achieved by two methods:
+
+1. Publishing
+Content is replaced with the live version, and the current live version is removed.
+
+2. Swapping
+Content is switched (swapped) with the live version, making the current live version the previously versioned content.
+
+Especially when doing
+
+* partial swapping
+* multiple swapping
+* swapping newly created content
+
+TYPO3 will leave the workspace in an inconsistent state.
+
+The swapping mechanism was therefore removed, leaving "Publishing" the only option to select for editors to push content from a workspace into the live website.
+
+
+Impact
+======
+
+The database field :sql:`sys_workspace.swap_modes` and the TCA option :php:`sys_workspace.swap_modes` are removed.
+
+The Workspace module only shows the "Publish" option, as "Swap" is removed.
+
+The auto-publishing feature now always publishes instead of optionally swaps content.
+
+
+Affected Installations
+======================
+
+TYPO3 installations which use workspaces with the swapping option
+activated.
+
+
+Migration
+=========
+
+All draft content is using the publishing mechanism, whereas there
+is no migration needed.
+
+.. index:: Database, TCA, NotScanned, ext:workspaces

Documentation/Changelog/11.0/Breaking-92238-ServiceInjectionInExtbaseValidators.rst

@@ -0,0 +1,88 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92238:
+
+==========================================================
+Breaking: #92238 - Service injection in Extbase validators
+==========================================================
+
+See :issue:`92238`
+
+Description
+===========
+
+With the deprecation and removal of objectManager usage in TYPO3, Extbase does not
+use the objectManager to create validator instances any more.
+
+.. note::
+
+    This has been mitigated with recent TYPO3 v11 core releases: Extbase validators
+    can use dependency injection again. See :doc:`this changelog <../11.5.x/Important-96332-ExtbaseValidatorsCanUseDependencyInjection>`
+    for details.
+    Additionally, all validators delivered by EXT:extbase and EXT:form will be marked
+    :php:`final` in v12. Extensions can no longer extend validators but must extend abstract
+    classes or implement the interfaces directly.
+
+Impact
+======
+
+Validators that use dependency injection will experience non injected services for affected properties.
+
+
+Affected Installations
+======================
+
+All installations that use dependency injection in Extbase validators.
+
+
+Migration
+=========
+
+
+Instead of injecting services to the validator, use :php:`GeneralUtility::makeInstance`
+to create an instance of required services.
+
+Given the following example for a service injection in a validator:
+
+.. code-block:: php
+
+    /**
+     * @var ConfigurationManagerInterface
+     */
+    protected $configurationManager;
+
+    /**
+     * @param ConfigurationManagerInterface $configurationManager
+     */
+    public function injectConfigurationManager(ConfigurationManagerInterface $configurationManager)
+    {
+        $this->configurationManager = $configurationManager;
+    }
+
+Since the configurationManager is required globally in the class, :php:`GeneralUtility::makeInstance`
+is used in the constructor of the validator to create an instance of the service.
+
+.. code-block:: php
+
+    /**
+     * @var ConfigurationManagerInterface
+     */
+    protected $configurationManager;
+
+    public function __construct(array $options = [])
+    {
+        $this->configurationManager = GeneralUtility::makeInstance(ConfigurationManagerInterface::class);
+        parent::__construct($options);
+    }
+
+In order to create instances of services that require dependency injection and which
+are not already instantiated in the service container, it is required to declare those
+services as :php:`public: true` in the :php:`Configuration/Services.yaml` of the given extension.
+
+.. code-block:: yaml
+
+    Vendor\MyExtension\Services\MyService:
+      public: true
+
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Breaking-92289-DecoupleLogicOfResourceFactoryIntoStorageRepository.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92289:
+
+===========================================================================
+Breaking: #92289 - Decouple logic of ResourceFactory into StorageRepository
+===========================================================================
+
+See :issue:`92289`
+
+Description
+===========
+
+The :php:`ResourceFactory` class was initially created for the File Abstraction Layer (FAL)
+as a Factory class, which created PHP objects.
+
+However, in the recent years, it became apparent that it is more useful to
+separate the concerns of the creation and retrieving of existing information.
+
+For this reason, the :php:`StorageRepository` class is now handling the creation of
+:php:`ResourceStorage` objects. This layer accesses the Database and the needed Driver
+objects and configuration.
+
+The :php:`StorageRepository` class does not extend from :php:`AbstractRepository` anymore,
+and is available standalone.
+
+Most of the logic in the :php:`ResourceFactory` concerning Storages has been moved to
+:php:`StorageRepository`, which has a lot of options available now.
+
+The following methods within :php:`ResourceFactory` have been marked
+as internal, and are kept for backwards-compatibility without deprecation:
+
+* :php:`ResourceFactory->getDefaultStorage()`
+* :php:`ResourceFactory->getStorageObject()`
+* :php:`ResourceFactory->convertFlexFormDataToConfigurationArray()`
+* :php:`ResourceFactory->createStorageObject()`
+* :php:`ResourceFactory->createFolderObject()`
+* :php:`ResourceFactory->getFileObjectByStorageAndIdentifier()`
+* :php:`ResourceFactory->getStorageObjectFromCombinedIdentifier()`
+
+The following method has been removed
+
+* :php:`ResourceFactory->getDriverObject()`
+
+
+Impact
+======
+
+Calling the removed method will throw a fatal error.
+
+Checking :php:`StorageRepository` for an instance of :php:`AbstractRepository`
+will have different results.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with specific third-party extensions working with the FAL
+API directly might use the existing functionality.
+
+
+Migration
+=========
+
+Migrate to the :php:`StorageRepository` API in the third-party extension code.
+
+.. index:: FAL, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92352-NewDefaultPositionForRedirectMiddleware.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92352:
+
+===============================================================
+Breaking: #92352 - New default position for redirect middleware
+===============================================================
+
+See :issue:`92352`
+
+Description
+===========
+
+TYPO3 10 introduced the feature toggle `rearrangedRedirectMiddlewares` to rearrange the middlewares
+:php:`typo3/cms-redirects/redirecthandler` and :php:`typo3/cms-frontend/base-redirect-resolver`. If enabled, the
+the :php:`typo3/cms-redirects/redirecthandler` is executed first.
+
+This order has the advantage that any redirect would work regardless whether the request made it through the
+:php:`typo3/cms-frontend/base-redirect-resolver`. While this might cause problems in some scenarios it is by
+far the better default.
+
+Therefore the feature switch has been removed now and the above described order is the new default.
+
+Impact
+======
+
+By putting the :php:`typo3/cms-frontend/base-redirect-resolver` last, redirects are always resolved even if no
+configured base URL was requested. In most cases this is considered to be a bugfix. However, redirect behavior might
+change.
+
+Custom middlewares that have been put in between the two above mentioned middlewares most likely will lead to a circular
+dependency exception now. Such custom middlewares have to be revisited and registered differently.
+
+Affected Installations
+======================
+
+All installations that need the :php:`typo3/cms-frontend/base-redirect-resolver` executed before the
+:php:`typo3/cms-redirects/redirecthandler` or that have the feature switch turned off and registered
+a custom middleware in between the two or with one of the two as a position definition via `after` or `before`.
+
+Migration
+=========
+
+Manually check the position of your custom middlewares and adapt accordingly.
+
+If needed the order of the middlewares can be switched back manually as described in the documentation.
+
+.. index:: Frontend, NotScanned, ext:redirects

Documentation/Changelog/11.0/Breaking-92457-ExtensionRepositoryDatabaseTableRemoved.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92457:
+
+==============================================================
+Breaking: #92457 - Extension Repository database table removed
+==============================================================
+
+See :issue:`92457`
+
+Description
+===========
+
+The existing extension manager had functionality to add
+multiple repositories by adding new database rows into the
+database table :sql:`tx_extensionmanager_domain_model_repository`.
+
+Because this functionality has been superseded by a configurable
+and more robust Remote API, where the configuration of possible
+additional TER endpoints are not stored in the database anymore,
+the database table is removed.
+
+
+Impact
+======
+
+Accessing :sql:`tx_extensionmanager_domain_model_repository` will
+result in a SQL error, as existing TYPO3 installations will drop this
+database table in the Database Compare View during upgrade.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions accessing this
+database table, which is highly unlikely.
+
+Also, TYPO3 installations depending on additional repositories
+rather than the official TYPO3 Extension Repository (TER) at
+extensions.typo3.org, will not work anymore.
+
+
+Migration
+=========
+
+Additional Extension Repositories (remotes) have to be added in
+:file:`Configuration/Services.yaml` using the :yaml:`extension.remote` tag.
+
+.. code-block:: yaml
+
+  extension.remote.myremote:
+    class: 'TYPO3\CMS\Extensionmanager\Remote\TerExtensionRemote'
+    arguments:
+      $identifier: 'myremote'
+      $options:
+         remoteBase: 'https://my_own_remote/'
+    tags:
+      - name: 'extension.remote'
+        enabled: true
+
+.. index:: Database, FullyScanned, ext:extensionmanager

Documentation/Changelog/11.0/Breaking-92497-WorkspacesMovePlaceholdersRemoved.rst

@@ -0,0 +1,111 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92497:
+
+========================================================
+Breaking: #92497 - Workspaces: Move Placeholders removed
+========================================================
+
+See :issue:`92497`
+
+Description
+===========
+
+Workspaces had a so-called Move Placeholder since TYPO3 4.2, which
+indicated that a versioned record (the move pointer) was moved to a
+new location - either to a new page or to a different sorting position.
+
+When querying records in a workspace, the Move Placeholder was included in the
+initial database query, and then reverted to the actual live record
+(to get the original PID), and then overloaded with the versioned record
+(Move Pointer) containing other modified fields.
+
+The main two fields of this Move Placeholder record were the PID
+and the sorting, referring to the newly moved location. All
+other fields were insignificant. An additional field "t3ver_move_id" contained
+the actual live record ID.
+
+Move Placeholders were identified by having the following field values:
+
+* t3ver_state = 3 - indicating the type Move Placeholder
+* t3ver_wsid = the workspace ID where a record was moved
+* t3ver_oid = 0, in order to fetch them from the database together with live records
+* pid = new Page location
+* sorting (optional) = the new sorting location
+* t3ver_move_id = the live version which was moved in the workspace
+
+The Move Pointer is indicated like this:
+
+* t3ver_state = 4 - indicating the type Move Pointer
+* t3ver_wsid = the workspace ID where a record was moved
+* t3ver_oid = the live version which was moved in the workspace
+* pid = new Page location
+* sorting (optional) = the new sorting location
+
+Due to a significant change in TYPO3 v10, the Move Pointer (versioned record)
+now also has the new PID, which was previously set to "-1", indicating a
+versioned record. However, since all information is now also available in
+the Move Pointer, the move placeholder database record is not needed anymore.
+
+Move Placeholders are now neither evaluated, nor created by TYPO3 Core anymore,
+and remaining move placeholders are removed with an Upgrade Wizard.
+
+The TCA setting :php:`$TCA[$table][ctrl][shadowColumnsForMovePlaceholders]`
+is not evaluated anymore and removed at TCA building-time.
+
+The main benefits of this change:
+
+* fewer database queries when fetching records within a workspace
+* more consistent handling with versioned records
+* less complexity within TYPO3's internal API
+* fewer database records when working with TYPO3's Workspaces feature
+
+
+Impact
+======
+
+When querying database records in a workspace, all Move Pointer records
+are now fetched directly instead of the Move Placeholder records.
+This is all done with the existing API methods in :php:`PageRepository`, :php:`BackendUtility`
+and the Doctrine DBAL Workspace Restriction.
+
+When moving a record in a workspace, Move Placeholders are not created anymore,
+making them obsolete, as all information is now stored in the Move Pointer.
+
+The constant :php:`VersionState::MOVE_PLACEHOLDER` is obsolete.
+
+Lots of internal functionality regarding move placeholders has been removed.
+
+The ctrl section :php:`$TCA[$table][ctrl][shadowColumnsForMovePlaceholders]` is automatically removed
+from any table with a deprecation notice.
+
+The database field :sql:`t3ver_move_id` is obsolete and not created
+automatically for workspace enabled tables anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using Workspaces which also hooks into the
+workspaces-internal process via third-party extensions.
+
+Any TYPO3 extension not using the Doctrine DBAL restrictions for handling
+Workspaces.
+
+
+Migration
+=========
+
+Run the upgrade wizard to remove any obsolete Move Placeholder records.
+
+Use the TYPO3 API to read and write data from the database, including the
+WorkspaceRestriction and the Versioning Overlay methods.
+
+Remove the setting :php:`$TCA[$table][ctrl][shadowColumnsForMovePlaceholders]`
+which is not evaluated anymore to avoid deprecation notices.
+
+The database analyzer suggests the removal of database field :sql:`t3ver_move_id`
+for various tables. The field can be safely dropped after the upgrade wizard
+has been executed.
+
+.. index:: Database, PHP-API, TCA, FullyScanned, ext:workspaces

Documentation/Changelog/11.0/Breaking-92499-AdminPanelDoesNotPreviewHiddenFrontendUserGroups.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92499:
+
+==========================================================================
+Breaking: #92499 - AdminPanel does not preview hidden Frontend User Groups
+==========================================================================
+
+See :issue:`92499`
+
+Description
+===========
+
+Admin Panel previously allowed to also render a page with frontend groups that
+were hidden / disabled. This feature has been removed,
+in order to ensure consistency for the authentication process.
+
+The property :php:`AbstractUserAuthentication::showHiddenRecords` which
+was used to transfer this information is removed.
+
+
+Impact
+======
+
+The Admin Panel selector now only shows a list of active groups
+to simulate from.
+
+Using the removed PHP property :php:`AbstractUserAuthentication::showHiddenRecords` will result
+in a PHP notice.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with Admin Panel activated and Frontend Groups
+that are disabled.
+
+
+Migration
+=========
+
+It is recommended to include groups where no user is assigned to
+for simulation purposes, if this feature is needed to preview
+content.
+
+.. index:: Frontend, ext:adminpanel, FullyScanned

Documentation/Changelog/11.0/Breaking-92502-MakeExtbaseHandlePSR7ResponsesOnly.rst

@@ -0,0 +1,75 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92502:
+
+===========================================================
+Breaking: #92502 - Make Extbase handle PSR-7 responses only
+===========================================================
+
+See :issue:`92502`
+
+Description
+===========
+
+Extbase does no longer handle/return extbase responses whose api was defined by the
+interface :php:`TYPO3\CMS\Extbase\Mvc\ResponseInterface`. Instead, Extbase does create a `PSR-7`
+compatible response object (see :php:`Psr\Http\Message\ResponseInterface`) and passes
+it back through the request handling stack.
+
+Since `PSR-7` requires response objects to be immutable, it no longer makes sense to expose the response object
+to the user via :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController::$response`
+and :php:`TYPO3\CMS\Extbase\Mvc\Controller\ControllerContext->getResponse()`.
+
+
+The following interface has been removed and is no longer usable:
+
+- :php:`TYPO3\CMS\Extbase\Mvc\ResponseInterface`
+
+The following class has been removed and is no longer usable:
+
+- :php:`TYPO3\CMS\Extbase\Mvc\Response`
+
+
+Impact
+======
+
+Since interface :php:`TYPO3\CMS\Extbase\Mvc\ResponseInterface` and  class :php:`TYPO3\CMS\Extbase\Mvc\Response`
+have been removed, they can no longer be used.
+
+Affected Installations
+======================
+
+All installations that:
+
+* declared classes that implemented the interface :php:`TYPO3\CMS\Extbase\Mvc\ResponseInterface`
+* instantiated or extended class :php:`TYPO3\CMS\Extbase\Mvc\Response`
+* accessed the request object through :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController::$response` or :php:`TYPO3\CMS\Extbase\Mvc\Controller\ControllerContext->getResponse()`
+
+Migration
+=========
+
+To regain full control over the response object, a PSR-7 compatible response object SHOULD be created in the
+controller action and returned instead of returning a string or void.
+
+Example:
+
+.. code-block:: php
+
+   public function listAction()
+   {
+       // do your action stuff
+       return $this->htmlResponse();
+   }
+
+.. note::
+
+    If no argument is given to :php:`$this->htmlResponse()`, the current view
+    is automatically rendered, and applied as content for the PSR-7 Response.
+    For more information about this topic, please refer to the corresponding
+    :doc:`changelog <../11.0/Deprecation-92784-ExtbaseControllerActionsMustReturnResponseInterface>`.
+
+Further: Method :php:`TYPO3\CMS\Extbase\Mvc\Response::addAdditionalHeaderData()`
+had been used to add additional header data such as css or js to the global TypoScriptFrontendController.
+This has to be done via :php:`TYPO3\CMS\Core\Page\AssetCollector` now.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Breaking-92513-MethodSignatureChangeOfTYPO3CMSExtbaseMvcControllerControllerInterfaceprocessRequest.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92513:
+
+=======================================================================================================================
+Breaking: #92513 - Method signature change of TYPO3\\CMS\\Extbase\\Mvc\\Controller\\ControllerInterface::processRequest
+=======================================================================================================================
+
+See :issue:`92513`
+
+Description
+===========
+
+The signature of method :php:`TYPO3\CMS\Extbase\Mvc\Controller\ControllerInterface::processRequest`
+changed in the regard that no longer :php:`$request` and :php:`$response` are passed into it.
+Instead, only a :php:`$request` argument is needed. Additionally, that method now requires to return a response.
+
+
+Impact
+======
+
+This change affects all classes that either implement said interface directly (presumably none)
+and those classes (controllers) that override method :php:`processRequest()`
+of class :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController`. Those, that override said method
+will experience the following fatal error:
+
+`Declaration of ... must be compatible with TYPO3\CMS\Extbase\Mvc\Controller\ControllerInterface::processRequest(TYPO3\CMS\Extbase\Mvc\RequestInterface $request): TYPO3\CMS\Extbase\Mvc\ResponseInterface`.
+
+
+Affected Installations
+======================
+
+All installations that override method :php:`processRequest()` of class :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController`.
+
+
+Migration
+=========
+
+There are two steps to migrate:
+
+- Remove the now superfluous :php:`$response` argument
+- Return a response object.
+
+The latter is usually achieved by calling :php:`return parent::processRequest($request)` instead of just :php:`parent::processRequest($request)`.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Breaking-92529-AllFluidWidgetFunctionalityRemoved.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92529:
+
+=========================================================
+Breaking: #92529 - All Fluid widget functionality removed
+=========================================================
+
+See :issue:`92529`
+
+Description
+===========
+
+First things first: All fluid widgets and all widget functionality have been removed!
+
+The most important issue of fluid widgets is, that they initiate sub requests to a
+controller from inside the view and output their content. Those sub requests bring
+another layer of complexity to the TYPO3 world that is impossible to handle properly
+as many bug reports show. TYPO3 already uses some kind of namespacing for url query
+arguments to separate arguments for different plugins on a single page. Widgets
+introduced another layer which made it necessary to yet again introduce namespacing
+in the existing namespace.
+
+To make fluid widgets work, they need to work on the request object of the parent
+plugin, i.e. the one that renders the view which holds the widget. This is a problem
+regarding our efforts using PSR-7 request objects in Extbase which are immutable
+by definition.
+
+A special kind of widget is the ajax widget which introduced even more complexity.
+One example was the already removed auto complete widget. The widget could be used
+to fetch values from the database for autocompletion while entering a textfield in
+a form. In order to perform that kind of magic, fluid came with a new page type (7076)
+for handling incoming ajax requests. Since that endpoint didn't know about the specifics
+of the widget that should be rendered, the widget context had to be serialized before
+the ajax request, bound to the user with a unique id and stored in the users session
+data just to be unserialized moments later to have a back reference to initiating request.
+
+The fluid widgets violated the design pattern "separation of concern" to a degree
+that they caused more trouble than benefit. Therefore, fluid widgets have been
+removed from TYPO3 core.
+
+Impact
+======
+
+- All fluid templates that used an existing widget will no longer work as expected.
+- Also, all custom widgets of users will no longer work and have to be replaced
+  with custom solutions.
+
+
+Affected Installations
+======================
+
+All installations that either used widgets defined by the core or those installations
+that created own widgets.
+
+
+Migration
+=========
+
+There is no simple migration strategy for all widgets but the most common
+functionality (pagination) can be solved with a new pagination core api. The main
+difference compared to a widget is that the pagination has to be initialized
+in the controller action and not in the view.
+
+For all other widgets, custom solutions have to be found.
+
+.. index:: Fluid, PHP-API, NotScanned, ext:fluid

Documentation/Changelog/11.0/Breaking-92532-SupportForExtension-in-extensionInstallationInExtensionManagerRemoved.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92532:
+
+===============================================================================================
+Breaking: #92532 - Support for extension-in-extension installation in Extension Manager removed
+===============================================================================================
+
+See :issue:`92532`
+
+Description
+===========
+
+The installation process within the Extension Manager allowed extensions to be
+installed having custom dependencies to other extensions in
+:file:`EXT:my_extension/Initialisation/Extensions/third_party_ext`.
+
+This feature was originally introduced for the Introduction Package,
+which had a few more dependencies until TYPO3 v9.
+
+As this (undocumented) feature was not used in public for any other extensions,
+and since Extension Manager can fetch dependencies from TER directly as well,
+this feature is removed.
+
+
+Impact
+======
+
+If an extension is installed which contains other extensions as
+dependencies in :file:`Initialisation/Extensions/*` they are now ignored
+on installation, and instead looked up in the remote TYPO3 Extension Repository,
+as with any other depending extension.
+
+
+Affected Installations
+======================
+
+TYPO3 extensions using this dependency management as "Extension-in-Extension"
+functionality.
+
+
+Migration
+=========
+
+Upload the proper extension into https://extensions.typo3.org and remove
+the folder :file:`Initialisation/Extensions` from any custom extensions.
+
+.. index:: PHP-API, FullyScanned, ext:extensionmanager

Documentation/Changelog/11.0/Breaking-92558-DatabaseFieldBe_userscreatedByActionRemoved.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92558:
+
+==================================================================
+Breaking: #92558 - Database Field be_users.createdByAction removed
+==================================================================
+
+See :issue:`92558`
+
+Description
+===========
+
+The database field :sql:`be_users.createdByAction` which was used
+as a type of history for the extracted `sys_action` extension,
+has been removed from TYPO3 Core.
+
+
+Impact
+======
+
+Accessing or writing to this database field directly will result
+in a SQL error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using this database field directly.
+
+
+Migration
+=========
+
+Re-add this field manually if needed, otherwise it is recommended
+to put such information in the History functionality of TYPO3 Core.
+
+.. index:: Database, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92559-RemovedPer-userIPLockingForBackendUsers.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92559:
+
+================================================================
+Breaking: #92559 - Removed per-user IP locking for backend users
+================================================================
+
+See :issue:`92559`
+
+Description
+===========
+
+TYPO3 has installation-wide options to allow so-called "IP Locking"
+for Frontend User Sessions and Backend User Sessions ("lockIP").
+
+Since TYPO3 v10, this feature is disabled by default, as some ISPs
+allow for so-called Happy Eyeballs [https://en.wikipedia.org/wiki/Happy_Eyeballs]
+to switch between IPv4 and IPv6, where a fixed IP Address per user session
+cannot be guaranteed and is not proven as a useful measure for locking
+a session anymore.
+
+TYPO3 Core however had another specific BE-user feature, *if* the IP locking
+features enabled for Backend users, it could be again *disabled*
+for a specific user. This was previously built as a workaround
+for users who did not have a specific IP address. This specific
+feature, disabling IP locking for a specific Backend user, has
+been removed as it lacks comprehensible use cases in the current
+internet world, especially nowadays where home office and constantly
+changing IP addresses are normal.
+
+Impact
+======
+
+The additional checkbox when editing a backend user is removed,
+including its Database field :sql:`be_users.disableIPlock` and its TCA
+definition.
+
+Accessing the field via a direct database request will result in a
+SQL error. Accessing the TCA information will trigger a PHP notice.
+
+If the system-wide setting is activated for backend users, it will apply
+to any Backend user regardless of custom settings.
+
+Affected Installations
+======================
+
+TYPO3 installations which use the IP locking mechanism for Backend
+users (see :php:`$TYPO3_CONF_VARS[BE][lockIP]` and
+:php:`$TYPO3_CONF_VARS[BE][lockIPv6]`) but explicitly deactivate
+it for a specific backend user, which is highly unlikely.
+
+The latter can be identified via a SQL query:
+
+:sql:`SELECT count(uid) AS amount FROM be_users WHERE deleted=0 AND disableIPlock=1`.
+
+
+Migration
+=========
+
+It is possible that this option was set by accident from administrators.
+If not and some IP locking problems exist for certain backend users, it is
+recommended to either remove the IP locking of backend users completely
+via the Settings module (set system-wide options "lockIP" and "lockIPv6" to "0")
+or add the functionality for your specific use case as custom extension, e.g. by
+hooking into the authentication process and using the
+:php:`\TYPO3\CMS\Core\Authentication\IpLocker` API.
+
+.. index:: Backend, Database, TCA, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92560-BackendEditorsCanAlwaysDeletePagesRecursive.rst

@@ -0,0 +1,59 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92560:
+
+====================================================================
+Breaking: #92560 - Backend editors can always delete pages recursive
+====================================================================
+
+See :issue:`92560`
+
+Description
+===========
+
+The feature to deny editors from deleting pages that have sub pages has been
+removed. This has been an optional setting on a per-user basis and is now not
+only enabled by default but the restriction has been fully removed.
+
+
+Impact
+======
+
+Editors can always delete full page trees.
+
+
+Affected Installations
+======================
+
+All instances are affected.
+
+
+Migration
+=========
+
+In case an editor deletes an entire tree by accident, administrators can and
+should use the recycler extension to resurrect page trees.
+
+Additionally, administrators can and should set access rights of important key
+pages to disallow editors from deleting them. More complex use cases can be
+handled with a dedicated DataHandler hook.
+
+Another good solution is to configure and restrict users to a workspace to
+implement a sophisticated review process for pending live content changes.
+
+On PHP level, the property :php:`DataHandler->deleteTree` has been dropped.
+Setting this property will raise a PHP warning level error. Extensions may be
+affected by this. The extension scanner will find usages with a weak match.
+
+Furthermore, on PHP level, the backend user uc setting :php:`uc['recursiveDelete']`
+has been dropped and is of no use anymore within the TYPO3 core.
+
+Finally, the User TSconfig for setting a default value, overriding the value or
+disabling the field, has also no effect anymore. Therefore, the following
+settings within custom TSconfig should be removed:
+
+* :typoscript:`setup.default.recursiveDelete`
+* :typoscript:`setup.override.recursiveDelete`
+* :typoscript:`setup.fields.recursiveDelete.disabled`
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92582-ResizableTextAreaUserSettingDropped.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92582:
+
+===========================================================
+Breaking: #92582 - Resizable text area user setting dropped
+===========================================================
+
+See :issue:`92582`
+
+Description
+===========
+
+The user setting "Make text areas flexible" has been dropped and is
+no longer available for editors.
+
+When editing records in the backend, text areas now always grow in height up to
+the maximum height defined by the 'maximum text area height' in user settings.
+
+
+Impact
+======
+
+The backend is a little less restricted for editors.
+
+
+Affected Installations
+======================
+
+All instances are affected.
+
+
+Migration
+=========
+
+The option has been removed, there is no migration path.
+
+The following User TSconfig settings are obsolete and should be removed:
+
+* :typoscript:`setup.default.resizeTextareas_Flexible`
+* :typoscript:`setup.override.resizeTextareas_Flexible`
+* :typoscript:`setup.fields.resizeTextareas_Flexible.disabled`
+
+.. index:: Backend, TSConfig, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92590-RemovedSupportForExtensionUploadOfT3xFiles.rst

@@ -0,0 +1,68 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92590:
+
+====================================================================
+Breaking: #92590 - Removed support for extension upload of t3x files
+====================================================================
+
+See :issue:`92590`
+
+Description
+===========
+
+With the inception of the concept of Extensions, the Extension
+Manager in TYPO3 and the TYPO3 Extension Repository (TER) on
+https://extensions.typo3.org, the file format `t3x` ("TYPO3 eXtension")
+was created.
+
+The proprietary format was introduced because the lack of support
+for zip handling in PHP4 in 2004. However, the format was proven
+to be cumbersome for developers and zip was bundled with most PHP5 versions.
+
+For this reason, the TYPO3 Ecosystem started to support extensions as regular
+`zip` archives during TYPO3 v6 development.
+
+The zip format for extension downloading and uploading was used more and more
+in favor of the `t3x` data format, so today the TER only offers the download of
+`zip` files via the Web GUI.
+
+However, TYPO3's Extension Manager still supported uploading
+`.t3x` files even though files were not created by the Extension Manager
+anymore since TYPO3 v6 - downloading an extension via the Extension Manager only
+created an archive of the `.zip` format of the extension.
+
+The feature of uploading files with a `t3x` format (identified by the
+file extension `.t3x`) has been removed.
+
+Both TER and the Extension Manager for downloading extensions still support `t3x`
+under the hood for legacy reasons, but this is not exposed to end-users,
+integrators or developers anymore.
+
+
+Impact
+======
+
+Uploading a `t3x`-based extension file in the Extension Manager will result in
+an error message.
+
+
+Affected Installations
+======================
+
+TYPO3 installations where administrators still handle `t3x` files for uploading
+extensions, which is highly unlikely and only applies for
+TYPO3 installations not installed via Composer.
+
+
+Migration
+=========
+
+When using a public extension, it is recommended to download the
+`zip` variant from https://extensions.typo3.org.
+
+When a `.t3x` file is provided by a third party, it is possible to upload the
+extension in the Extension Manager of an older TYPO3 Core version
+(e.g. TYPO3 v10), and then download the extension there as a `.zip` file.
+
+.. index:: Backend, NotScanned, ext:extensionmanager

Documentation/Changelog/11.0/Breaking-92598-Workspace-overlaysAuto-fixThePIDValueForMovedRecords.rst

@@ -0,0 +1,72 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92598:
+
+==============================================================================
+Breaking: #92598 - Workspace-overlays auto-fix the PID value for moved records
+==============================================================================
+
+See :issue:`92598`
+
+Description
+===========
+
+When handling versioned records while reading data from the database,
+the common behavior is to apply a "workspace overlay". When using the TYPO3 API
+in both classes like:
+
+* :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository->getRecord()`
+* :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getRecordWSOL()`
+
+the currently live records are fetched from the database and being overlayed with
+possible versioned record in a specific workspace by replacing all selected fields
+with the versioned values.
+
+However, the fields "uid" and "pid" of the live record were kept, and the values
+of the versioned record were stored in "_ORIG_uid" and "_ORIG_pid"
+when a record was successfully overlaid.
+
+This was necessary in the past, because the versioned records did not contain
+a meaningful "pid" value ("pid=-1") so in order to keep a useful value,
+the live value was kept.
+
+The meaning of "_ORIG_pid" has now changed:
+
+* All versioned records contain the same "pid" as the live record, so the
+  "_ORIG_pid" value is not needed anymore.
+* However, when a record is moved to another page in a workspace, the PID changes.
+  Handling this case is drastically simpler now. In order to work with the
+  modified data in moved versions, the "pid" field now contains the value of
+  the new page in a workspace, and the "_ORIG_pid" field contains
+  the value of the live record's "pid" field.
+  This behavior is now streamlined with what :php:`fixVersioningPid()` was doing.
+  Therefore :php:`fixVersioningPid()` has been marked as deprecated.
+
+Impact
+======
+
+When using workspaces and the API methods, the "_ORIG_pid" field is only set
+for moved records where a workspace overlay has been properly applied.
+
+The "pid" field now always contains the actual pid of a versioned record in
+the workspace, where as the "_ORIG_pid" contains the live record pid value.
+
+In other words: if a moved record has been overlaid, the "_ORIG_pid" and "pid" field values
+are now switched.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom code regarding workspaces that dealt with
+the value "_ORIG_pid" for resolving moved records in a workspace.
+
+Migration
+=========
+
+The change helps to reduce the complexity when dealing with workspace overlays,
+so existing PHP code probably does not need to check for "_ORIG_pid" anymore,
+and extension developers can just safely use the overlay methods and directly
+use the "pid" field, knowing that the "pid" field contains the value of the
+record within the workspace.
+
+.. index:: PHP-API, NotScanned, ext:workspaces

Documentation/Changelog/11.0/Breaking-92609-UseControllerClassesWhenRegisteringPluginsmodules.rst

@@ -0,0 +1,89 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92609:
+
+==========================================================================
+Breaking: #92609 - Use controller classes when registering plugins/modules
+==========================================================================
+
+See :issue:`92609`
+
+Description
+===========
+
+Configuring plugins and modules via the following methods has changed in two important ways.
+
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin`
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule`
+
+Both methods expect to be provided with the arguments :php:`$extensionName` and :php:`$controllerActions`.
+:php:`configurePlugin` also allows the argument :php:`$nonCacheableControllerActions`.
+
+The first important change targets the :php:`$extensionName` argument.
+During the switch from underscore class names :php:`Tx_Extbase_Foo_Bar` to actual namespaced classes
+:php:`TYPO3\CMS\Extbase\Foo\Bar`, a vendor `TYPO3\CMS` has been introduced which had to be respected
+during the configuration of plugins. To make that possible the argument :php:`$extensionName` has been
+prepended with the vendor name, concatenated with dots.
+
+Before:
+
+.. code-block:: php
+
+   <?php
+
+   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
+       'TYPO3.CMS.Form', // $extensionName
+       'Formframework',
+       ['FormFrontend' => 'render, perform'],
+       ['FormFrontend' => 'perform'],
+       \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT
+   );
+
+Setting the vendor name has been marked as deprecated and must be omitted. Instead, the vendor name will be derived
+from the controller class namespace, which leads to the second important change.
+
+Both arguments :php:`$controllerActions` and :php:`$nonCacheableControllerActions` used controller aliases as
+array keys. The alias was the controller class name without the namespace and without the :php:`Controller`
+suffix. There were a lot of conventions and a custom autoloader mechanism before the introduction
+of the composer autoloader, which made it necessary to put controllers in a specific directory and to name
+the controller accordingly. As this is no longer the case, there is no need to guess the controller class name
+any longer. Instead, the configuration/registration is now done with fully qualified controller class names.
+
+After:
+
+.. code-block:: php
+
+   <?php
+
+   \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
+       'Form',
+       'Formframework',
+       [\TYPO3\CMS\Form\Controller\FormFrontendController::class => 'render, perform'],
+       [\TYPO3\CMS\Form\Controller\FormFrontendController::class => 'perform'],
+       \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT
+   );
+
+
+Impact
+======
+
+Using non fully qualified class names during plugin/module registration will lead to malfunctioning plugins/modules at best.
+Probably an Exception will be thrown or a fatal error occurs during plugin/module dispatching.
+
+
+Affected Installations
+======================
+
+All installations that use these methods:
+
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin()`
+* :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule()`
+
+
+Migration
+=========
+
+* Omit the vendor name in argument :php:`$extensionName`
+* Use fully qualified class names as array keys in arguments :php:`$controllerActions` and :php:`$nonCacheableControllerActions`
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Breaking-92678-CssClassCheckboxInvertRemoved.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92678:
+
+====================================================
+Breaking: #92678 - CSS class checkbox-invert removed
+====================================================
+
+See :issue:`92678`
+
+Description
+===========
+
+FormEngine used to have a class `checkbox-invert` for the styling
+of an item with enabled flag `invertStateDisplay`. Now the checkbox value
+itself is inverted. Therefore the class has been removed as it is not needed
+any more.
+
+
+Impact
+======
+
+Using the class doesn't have any effect on styling anymore.
+
+
+Affected Installations
+======================
+
+Standard installations of TYPO3 are not affected. Only installations that
+use the class `checkbox-invert` for customizations are affected.
+
+
+Migration
+=========
+
+There is no migration required if only the invertStateDisplay configuration
+is used. If CSS styling or JavaScript in the backend relies on the
+class `checkbox-invert` present custom code needs to be added to make it
+available again.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92693-RemoveLinkHandlerLinktypeInLinkvalidator.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92693:
+
+===============================================================
+Breaking: #92693 - Remove LinkHandler Linktype in Linkvalidator
+===============================================================
+
+See :issue:`92693`
+
+Description
+===========
+
+Linkvalidator ships with several link type classes that are used to check
+specific links such as ExternalLinktype, Filelinktype etc.
+
+The link type LinkHandler is no longer used by default (see Page TSconfig
+:typoscript:`mod.linkvalidator.linktypes`). It was used to check links of the extension
+"linkhandler" which is now outdated. The latest version supports TYPO3 4.1.0.
+
+LinkHandler functionality was integrated into the core in TYPO3 8, but the
+format of the links has changed since then.
+
+The LinkHandler link type expects links which start with "record:" -
+a syntax that is now outdated.
+
+Links to records are successfully checked in the InternalLinktype class.
+
+Impact
+======
+
+It is no longer possible to use the "linkhandler" link type. Setting this
+in the configuration will not have any effect.
+
+
+Affected Installations
+======================
+
+There should be no affected installations as the linkhandler extension and
+the corresponding format of the links has long been outdated.
+
+Migration
+=========
+
+Normally, no migration is necessary.
+
+You should remove the linkhandler link type from the page TSconfig configuration:
+
+.. code-block:: diff
+
+   - :typoscript:`mod.linkvalidator.linktypes = db,file,external,linkhandler`
+   + :typoscript:`mod.linkvalidator.linktypes = db,file,external`
+
+You should no longer use :typoscript:`linkhandler.reportHiddenRecords = 0`.
+
+.. code-block:: diff
+
+   - :typoscript:`mod.linkvalidator.linkhandler.reportHiddenRecords = 0`
+
+.. index:: Backend, NotScanned, ext:linkvalidator

Documentation/Changelog/11.0/Breaking-92791-NewPlaceholderRecordsRemovedInWorkspaces.rst

@@ -0,0 +1,106 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92791:
+
+==================================================================
+Breaking: #92791 - "New Placeholder" records removed in Workspaces
+==================================================================
+
+See :issue:`92791`
+
+Description
+===========
+
+When creating a new record in a workspace, TYPO3 created two database
+entries: A "new placeholder" which served as a pseudo-live pendant with
+no content but only the target PID value to be added, and a "versioned
+record" which – until TYPO3 v10 – had the PID value "-1". On publishing
+the contents of both records were exchanged (except the PID) and the
+versioned record was removed.
+
+Since TYPO3 v10 the "new placeholder" had little information to be kept
+alive. Only on publishing, the behaviour was simple, as the publishing process
+as described above worked the same way as for other "versioned records" like
+modifying a live record, or moving records.
+
+Apart from having two database records created where only one contained
+user input, there were some conceptual drawbacks with having a placeholder record:
+Sorting, and type fields had to be configured via a special
+:php:`$TCA[$table][ctrl][shadowColumnsForNewPlaceholders]` TCA option, which wasn't kept in sync when
+modifying the versioned record.
+
+Both record types were identified in the database as the following:
+
+New Placeholder Record
+**********************
+
+* t3ver_state => 1 - identifying as "new placeholder"
+* t3ver_wsid => the ID of the workspace it was created
+* t3ver_oid => 0 - as it should behave as the "online version"
+* pid => the PID where the record should be published in (same with "sorting", when set)
+
+New Versioned Record
+********************
+
+* t3ver_state => -1 - identifying as "new record created in workspace"
+* t3ver_wsid => the ID of the workspace it was created
+* t3ver_oid => ID of the New Placeholder Record
+* pid => the PID where the record should be published in (same with "sorting", when set)
+
+The placeholder record was queried when reading the database while in a workspace
+with other live records. It was then overlaid by the versioned record.
+
+TYPO3 v11 does not create placeholder records anymore, but instead creates
+one record containing all information. When fetching records
+from the database, the new versioned records are added directly, so no overlays
+need to happen anymore, which speeds up performance when querying the
+database via the TYPO3 Database via API classes such as :php:`PageRepository` or
+:php:`BackendUtility`.
+
+Impact
+======
+
+No records with :sql:`t3ver_state=-1` are found in the TYPO3 installation anymore.
+
+When using the Doctrine DBAL API with Workspace Restrictions within a workspace,
+the new versions are included in the SQL query result.
+
+DataHandler will not create placeholders anymore, making the TCA option
+:php:`$TCA[$table][ctrl][shadowColumnsForNewPlaceholders]` obsolete.
+
+Using methods like :php:`getWorkspaceVersionOfRecord` on a new versioned record
+will return the same record again, as there is no "workspace version" of this
+record anymore.
+
+The CLI command `cleanup:versions` is adapted as the option
+`--action=unused_placeholders` is removed.
+
+In addition, records overlaid via the TYPO3 API classes that have been
+newly created in a workspace do not carry the :sql:`ORIG_uid` information anymore
+which keeps the UID of the versioned record.
+
+Affected Installations
+======================
+
+TYPO3 installations using Workspaces with newly created records that haven't
+been published yet, or with third-party extensions directly querying, resolving
+or writing based on :sql:`t3ver_state` database fields, which is very uncommon.
+
+Migration
+=========
+
+An upgrade wizard is used to migrate possibly left-over "placeholder" records
+within the database. This is only needed when workspaces are in use and there
+are records in the database that are newly created and have not been
+published.
+
+A TCA migration will automatically remove and log any usages of the TCA option
+:php:`$TCA[$table][ctrl][shadowColumnsForNewPlaceholders]`.
+
+It is highly recommend to use the TYPO3 API methods within Extbase, :php:`PageRepository`
+and :php:`BackendUtility` to ensure records are resolved properly.
+
+At any times, it is recommended to use the :php:`WorkspaceRestriction` of TYPO3's
+implementation of Doctrine DBAL in conjunction with Workspace overlays.
+
+.. index:: Database, FullyScanned, ext:workspaces

Documentation/Changelog/11.0/Breaking-92801-RemovedFailedLoginFunctionalityFromUserAuthenticationObject.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92801:
+
+=======================================================================================
+Breaking: #92801 - Removed "Failed Login" functionality from User Authentication object
+=======================================================================================
+
+See :issue:`92801`
+
+Description
+===========
+
+The functionality to send an email to a defined sender was previously hard-coded
+into the API class :php:`AbstractUserAuthentication` and activated specifically for
+Backend Users via the option :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['warning_email_addr']`.
+
+With some custom implementation it was also possible to use a hook to
+enable this for frontend users, but the API was not clean.
+
+The backend-user specific logic is now extracted into a hook, so it is possible
+to replace this functionality with a custom notification API.
+
+For this reason, the following public properties and methods within
+:php:`AbstractUserAuthentication` and its subclasses have been removed:
+
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->warningEmail`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->warningPeriod`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->warningMax`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->checkLogFailures()`
+
+Impact
+======
+
+Using one of the public properties in custom PHP will trigger a PHP Warning.
+
+Calling the public PHP method will result in a fatal PHP error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions and custom PHP code that is
+related to failed login notifications, and rely on the existing login
+notification code.
+
+
+Migration
+=========
+
+As the properties were public, they made it possible to override the
+warningMax / warningPeriod values via hooks and middlewares in PHP.
+
+Instead it is recommended to override this functionality via a hook the same way
+the new hook in EXT:backend is registered within PHP.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92802-DatabaseBasedAuthenticationTimeoutFieldRemoved.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92802:
+
+===========================================================================
+Breaking: #92802 - User-database-based authentication timeout field removed
+===========================================================================
+
+See :issue:`92802`
+
+Description
+===========
+
+The :php:`AbstractUserAuthentication` object had the possibility to
+theoretically use a database field where a session timeout value
+for the session storage could be set. This was never implemented but
+rather separated into a separate property called :php:`sessionTimeout`.
+
+This functionality, together with the public property
+:php:`auth_timeout_field`, has been removed.
+
+
+Impact
+======
+
+Setting the property via a custom extension will result in a PHP warning, as
+the property does not exist anymore.
+
+In addition, this property is never evaluated anymore when determining the
+session timeout.
+
+
+Affected Installations
+======================
+
+TYPO3 installations that used third-party code to modify the session timeout
+value based on a database field, which relied on the public property for
+implementation purposes.
+
+
+Migration
+=========
+
+Use a custom implementation with custom hooks or custom authentication provider
+to achieve the same results.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92807-RemovedFeatureForKeepingSessionDataOnFrontendUserLogout.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92807:
+
+===================================================================================
+Breaking: #92807 - Removed feature for keeping session data on frontend user logout
+===================================================================================
+
+See :issue:`92807`
+
+Description
+===========
+
+When a frontend user logged out, the session data was kept
+and transferred to an anonymous session when the feature
+flag :php:`security.frontend.keepSessionDataOnLogout` was enabled.
+
+Since this functionality is insecure, and was only introduced
+to keep backwards-compatibility in a security release, the feature
+has been removed completely.
+
+
+Impact
+======
+
+When logging out as a frontend user, all session data is now
+actively removed and not kept as a new anonymous session.
+
+
+Affected Installations
+======================
+
+TYPO3 installations having this feature enabled and actively
+using this feature, e.g. in cart functionality.
+
+
+Migration
+=========
+
+It is recommended to build the web application in a way that
+the session data is not needed, and instead a frontend user
+should know that their session data is lost upon log out.
+
+Make sure to bind user-specific data either to the
+frontend user itself, or re-implement this functionality
+yourself by using a :php:`logoff()` hook for transferring sessions
+to anonymous sessions.
+
+.. index:: Frontend, PHP-API, NotScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-92837-RemoveSettingModweb_layoutdisableAdvanced.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92837:
+
+=================================================================
+Breaking: #92837 - Removed setting mod.web_layout.disableAdvanced
+=================================================================
+
+See :issue:`92837`
+
+Description
+===========
+
+The TSconfig setting :typoscript:`mod.web_layout.disableAdvanced` has been used to disable the
+"clear cache"-button in the page module.
+
+Since this behaviour can be triggered through various other ways like the context menu or
+by just saving the page record, this feature has been removed completely.
+
+
+Impact
+======
+
+The setting :typoscript:`mod.web_layout.disableAdvanced` is not evaluated anymore and the "clear cache"-button
+is always shown.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using the setting :typoscript:`mod.web_layout.disableAdvanced`.
+
+
+Migration
+=========
+
+There is no migration possible.
+
+.. index:: Backend, TSConfig, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92838-AdditionalWorkspaceServicesDropped.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92838:
+
+========================================================
+Breaking: #92838 - Additional workspace services dropped
+========================================================
+
+See :issue:`92838`
+
+Description
+===========
+
+Back in the ExtJS era, the workspace backend module had two PHP classes designed
+for extensions to add additional columns and JavaScript handling to the module.
+With the transition to a native JavaScript implementation of the workspace module
+in TYPO3 v8, this stopped working. The related PHP classes have now been removed.
+
+
+Impact
+======
+
+There was one specific customer this feature has been implemented for. It does
+not use it anymore. Considering the fact the feature has been broken since years,
+there should be little to no impact for any instance.
+
+The following classes and interfaces have been removed:
+
+* :php:`TYPO3\CMS\Workspaces\ColumnDataProviderInterface`
+* :php:`TYPO3\CMS\Workspaces\Service\AdditionalColumnService`
+* :php:`TYPO3\CMS\Workspaces\Service\AdditionalResourceService`
+
+
+Affected Installations
+======================
+
+Instances with extensions using above classes or interfaces. The extension
+scanner will find usages with a strong match.
+
+
+Migration
+=========
+
+No migration available.
+
+.. index:: Backend, JavaScript, PHP-API, FullyScanned, ext:workspaces

Documentation/Changelog/11.0/Breaking-92853-MethodCanProcessRequestHasBeenRemoved.rst

@@ -0,0 +1,58 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92853:
+
+============================================================
+Breaking: #92853 - Method canProcessRequest has been removed
+============================================================
+
+See :issue:`92853`
+
+Description
+===========
+
+Method :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController->canProcessRequest()`
+had been called to check if the currently passed in request could be handled by
+the controller. This allowed to handle additional request types other than the
+default one Extbase delivers. This would have only be useful if a user implemented
+a request which didn't extend the Extbase request and therefore didn't necessarily
+comply with its API. This however would have only been possible if the user
+registered a custom request handler, violating the method signature of
+:php:`TYPO3\CMS\Extbase\Mvc\RequestHandlerInterface->handleRequest()`.
+
+Back in 2012 this was an option to use Flow and Extbase interchangeably which was
+never possible, and to allow Extbase Command Controllers via a CLI Request object,
+which was removed in TYPO3 v10.
+
+To unify the request/response handling and making it PSR-7 compatible, this check
+has simply been removed along with its exception
+:php:`\TYPO3\CMS\Extbase\Mvc\Exception\UnsupportedRequestTypeException`.
+
+Impact
+======
+
+Actually very little if this feature had been used to have the controller handle
+custom requests that extend the Extbase request. Custom requests with a different
+api than the one needed by the framework will result in fatal errors.
+
+
+Affected Installations
+======================
+
+All installations with Extbase controllers that have overridden property
+:php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController::$supportedRequestTypes`
+or method :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController->canProcessRequest()`
+and all installations which used :php:`\TYPO3\CMS\Extbase\Mvc\Exception\UnsupportedRequestTypeException`
+in some way.
+
+
+Migration
+=========
+
+There isn't that one code migration path. If you intend to extend (XClass) the
+request object to add further properties/methods, you can still do so and nothing
+actually changes. If you violated the api, implemented custom request builders
+and handlers that handled requests with a different api than the one needed by
+the framework, you will encounter fatal errors eventually.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Breaking-92940-GlobalOptionLockBeUserToDBmountsRemoved.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92940:
+
+===============================================================
+Breaking: #92940 - Global option "lockBeUserToDBmounts" removed
+===============================================================
+
+See :issue:`92940`
+
+Description
+===========
+
+The system-wide setting :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['lockBeUserToDBmounts']`
+which was active by default, was used to allow any non-administrator to access
+all pages in a TYPO3 installation without considering "Web Mounts" / "DB Mounts"
+regardless of their permissions.
+
+It was recommended to keep this setting turned on at any time due to several
+security reasons.
+
+This setting itself breaks TYPO3's internal permission concept and was never
+implemented in all relevant places of TYPO3.
+
+For this reason, the setting and all its usages are removed.
+
+
+Impact
+======
+
+Activating or deactivating this option has no effect anymore as TYPO3 Core API
+is working as this option was enabled at any time.
+
+
+Affected Installations
+======================
+
+TYPO3 installations that have this option disabled in their system-wide
+configuration in the :file:`LocalConfiguration.php` file.
+
+
+Migration
+=========
+
+None, as this feature was removed for security purposes, re-adding this feature
+is not recommended.
+
+All usages in custom TYPO3 extensions can be removed.
+
+.. index:: Backend, LocalConfiguration, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92941-LockToIPUserTsConfigOptionRemoved.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92941:
+
+=========================================================
+Breaking: #92941 - "lockToIP" UserTsConfig option removed
+=========================================================
+
+See :issue:`92941`
+
+Description
+===========
+
+The UserTsConfig setting :typoscript:`options.lockToIP` which allowed Backend
+users or usergroups to only be valid when the user was accessing
+TYPO3 with a certain IP address / range list, is removed.
+
+Due to the IPv4/IPv6 dilemma "Happy Eyeballs" this feature only
+has little use, and should be handled outside the Application instead,
+but certainly not work on a per user/group basis.
+
+This option was only used when the global option
+:php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['enabledBeUserIPLock']` was enabled, and
+could be disabled as system-wide setting where the UserTsConfig setting was
+never evaluated anymore.
+
+The global toggle was also removed, as it did not serve any other purposes.
+
+Side note: From a TYPO3-internal request workflow this feature was never part of
+the authentication process, as this usually happened after a successful user
+login or session activation had happened, overruling any previous Authentication
+Services registered. This was due to some ancient architectural decisions
+18 years ago when this feature was added.
+
+
+Impact
+======
+
+When the UserTsConfig setting :typoscript:`options.lockToIP` is set, it will not be
+evaluated anymore.
+
+When set, the global configuration flag will be automatically removed when the
+Install Tool is accessed.
+
+
+Affected Installations
+======================
+
+TYPO3 installations actively using this option in any UserTsConfig field or
+file for Backend users or Backend user groups.
+
+
+Migration
+=========
+
+If this functionality is still needed (mostly in Intranets), this needs to be
+implemented as a third-party authentication service to validate an authenticated
+user or group to be added to the current user / groups or via a custom PSR-15
+middleware.
+
+.. index:: TSConfig, PartiallyScanned, ext:backend

Documentation/Changelog/11.0/Breaking-92989-AbstractUserAuthentication-loginFailureRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92989:
+
+===================================================================
+Breaking: #92989 - AbstractUserAuthentication->loginFailure removed
+===================================================================
+
+See :issue:`92989`
+
+Description
+===========
+
+The public PHP property :php:`loginFailure` of the PHP class :php:`AbstractUserAuthentication` has
+been removed. This property stored information if a login attempt was made
+but was not successful.
+
+
+Impact
+======
+
+Accessing or setting the property from third-party code via PHP has no effect
+anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom code in PHP accessing or setting this property,
+which is highly unlikely as this property only had limited use and the existing
+hook is better suited for doing custom work.
+
+
+Migration
+=========
+
+If this information is needed, it is recommended to use the hook
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauth.php']['postLoginFailureProcessing']`
+which allows to run custom PHP code if a login attempt has been made which was
+not successful.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92990-AbstractUserAuthentication-svConfigRemoved.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92990:
+
+===============================================================
+Breaking: #92990 - AbstractUserAuthentication->svConfig removed
+===============================================================
+
+See :issue:`92990`
+
+Description
+===========
+
+The public property :php:`svConfig` of the PHP class :php:`AbstractUserAuthentication` is removed.
+
+It served as a short-hand for :php:`$GLOBALS['TYPO3_CONF_VARS']['SVCONF']['auth']`, which was common in TYPO3 v4 days, but is
+useless nowadays. This property is removed in favor of a local
+variable allowing for further refactoring of the Authentication
+process in the future.
+
+
+Impact
+======
+
+Accessing or setting the property has no effect anymore,
+and will trigger a PHP warning.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions with PHP code accessing the property related to authentication, which is highly unlikely.
+
+
+Migration
+=========
+
+Manipulate the global array :php:`$GLOBALS['TYPO3_CONF_VARS']['SVCONF']['auth']` directly instead,
+preferably in :file:`AdditionalConfiguration.php` or in an extensions :file:`ext_localconf.php` file.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-92993-GenericSearchStatisticsFromIndexedSearchRemoved.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92993:
+
+========================================================================
+Breaking: #92993 - Generic search statistics from indexed search removed
+========================================================================
+
+See :issue:`92993`
+
+Description
+===========
+
+When using TYPO3 Cores built-in Frontend Search ("Indexed Search"), search
+statistics were written which were never evaluated, but might contain
+user-specific information about logged-in users and their previously used sessions,
+which might be conflicting with privacy policies.
+
+The IP Address could be masked via Indexed Search Extension Setting
+:php:`trackIpInStatistic` which is now removed, along the database table
+:sql:`index_search_stat`.
+
+
+TYPO3 also stores statistics on the searched word, which is evaluated
+in the TYPO3 Backend, and kept.
+
+
+Impact
+======
+
+Searching within Indexed Search will only track the searched words, but not
+additional meta data anymore.
+
+The database table :sql:`index_search_stat` is not available anymore, along with the
+Extension setting to disable IP address tracking, as nothing is tracked anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using Indexed Search and accessing this information.
+
+
+Migration
+=========
+
+It is recommended to use a more generic and sophisticated analytics tool like
+Matomo or Google Analytics to track searched terms.
+
+.. index:: Database, NotScanned, ext:indexed_search

Documentation/Changelog/11.0/Breaking-92997-Authentication-relatedHTTPCacheHeadersAreEmittedOnlyByPSR-15Middlewares.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-92997:
+
+===================================================================================================
+Breaking: #92997 - Authentication-related HTTP cache headers are emitted only by PSR-15 middlewares
+===================================================================================================
+
+See :issue:`92997`
+
+Description
+===========
+
+In previous TYPO3 versions, when a user session was initiated or set
+(e.g. due to login or cookie), class :php:`AbstractUserAuthentication` was instructed
+to send HTTP headers immediately via the PHP function :php:`header()`.
+
+These headers were sent directly to the client without having a chance to
+manipulate a response, or simulate this behavior via proper tests in a testing
+suite.
+
+These HTTP headers for not caching a HTTP response were already attached to the
+PSR-7 Response when an active Backend user was available in Frontend and Backend
+requests, but not when a Frontend user was logged in.
+
+The internal methods in class :php:`AbstractUserAuthentication` are removed.
+
+Impact
+======
+
+These headers are now only sent via the PSR-7 Response object, and emitted at
+the very end of a Request/Response lifecycle in a TYPO3 Application (for Frontend
+and Backend Requests), and not via the :php:`header()` function anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions manipulating HTTP headers or the
+options within class :php:`AbstractUserAuthentication` to send such headers.
+
+
+Migration
+=========
+
+If any changes regarding the PSR-7 Response headers are needed, it is
+recommended to build a custom PSR-15 middleware in a TYPO3 Extension.
+
+.. index:: Backend, Frontend, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93002-SupportForSessionTransferViaFE_SESSION_KEYRemoved.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93002:
+
+==========================================================================
+Breaking: #93002 - Support for session transfer via FE_SESSION_KEY removed
+==========================================================================
+
+See :issue:`93002`
+
+Description
+===========
+
+TYPO3s Frontend Session Handling has had a custom feature by setting a custom
+GET variable called :html:`FE_SESSION_KEY` to inject an existing session into a
+Frontend Request without having a cookie sent as response.
+
+This seldom used feature, which was limited to Frontend sessions only, and
+required knowledge of third-party integrations for TYPO3s encryption key to
+create such a session key is removed.
+
+Features for integrating sessions should instead be built with custom
+AuthenticationServices, e.g. for Single-Sign-On functionality.
+
+
+Impact
+======
+
+Calling TYPO3s Frontend with :html:`FE_SESSION_KEY` as GET parameter has no effect
+anymore and will not pick up an existing session.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using this :html:`FE_SESSION_KEY` which is very rare and unlikely
+to be used.
+
+
+Migration
+=========
+
+Build a custom Authentication Service to log in and use user session instead
+in a third-party extension.
+
+.. index:: Frontend, NotScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-93003-LimitationOfPageRendererToOnlyRenderFullPage.rst

@@ -0,0 +1,55 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93003:
+
+======================================================
+Breaking: #93003 - PageRenderer renders only full page
+======================================================
+
+See :issue:`93003`
+
+Description
+===========
+
+TYPO3s main API class to build a full HTML page for Frontend
+and Backend rendering - :php:`PageRenderer` - previously allowed
+to only render the header or footer separately, which was built
+due to historical reasons when rendering content.
+
+This is however obsolete and TYPO3 Core only renders full pages in
+Frontend and Backend internally.
+
+For this reason, PageRenderer's :php:`render` method does not accept
+any method arguments anymore and always renders the complete HTML page.
+
+In addition, the constants
+
+* :php:`PageRenderer::PART_COMPLETE`
+* :php:`PageRenderer::PART_HEADER`
+* :php:`PageRenderer::PART_FOOTER`
+
+are now marked as protected and should not be accessed from outside
+the PHP class anymore.
+
+
+Impact
+======
+
+Calling :php:`PageRenderer->render()` does not respect any given
+method argument.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions manipulating the underlying
+API to render the page.
+
+
+Migration
+=========
+
+It is recommended for third-party extensions to use custom hooks to
+process or manipulate header or footer parts.
+
+.. index:: Backend, Frontend, PartiallyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93023-ReworkedSessionHandling.rst

@@ -0,0 +1,154 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Breaking-93023-ReworkedSessionHandling:
+
+============================================
+Breaking: #93023 - Reworked session handling
+============================================
+
+See :issue:`93023`
+
+Description
+===========
+
+The overall session handling within TYPO3 Core has been overhauled. This was
+done to separate the actual User object, the Authentication process and the
+session handling.
+
+The main result of this refactoring is the user authentication objects such as
+:php:`BackendUserAuthentication` and :php:`FrontendUserAuthentication`
+do not longer contain the session data directly. Instead, this is now encapsulated
+in a :php:`UserSession` object which is handled by the new
+:php:`UserSessionManager`.
+
+Furthermore, the user authentication objects internally do not longer know about
+a specific session backend implementation, since this is also wrapped by the
+:php:`UserSessionManager`. This also means it is not possible to create sessions
+outside of the new session manager anymore.
+
+For this purpose, there are several changes within the user authentication
+classes which are described below.
+
+The array :php:`AbstractUserAuthentication->user` previously contained the logged-in
+user record (from be_users / fe_users database table) AND the session record
+prefixed via :php:`ses_*` array properties. This has been removed, to separate
+the functionality. Instead, all session properties are placed inside the
+:php:`UserSession` object, accessible via e.g. :php:`$GLOBALS[BE_USER]->getSession()`.
+
+The following public properties within :php:`AbstractUserAuthentication` and
+its subclasses have been removed:
+
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->id`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->hash_length`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->sessionTimeout`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->gc_time`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->gc_probability`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->newSessionID`
+
+The following public methods within :php:`AbstractUserAuthentication` and its
+subclasses have been removed:
+
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->getNewSessionRecord()`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->getSessionId()`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->isExistingSessionRecord()`
+
+The following public property within :php:`AbstractUserAuthentication` has
+changed their visibility to :php:`protected`:
+
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->lifetime`
+
+The following public methods within :php:`AbstractUserAuthentication` and its
+subclasses have changed their return type:
+
+*  :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->createUserSession()`
+   now returns :php:`TYPO3\CMS\Core\Session\UserSession` and the first parameter
+   :php:`$tempuser` is now type-hinted :php:`array`.
+
+The following public properties within :php:`FrontendUserAuthentication` have
+been removed:
+
+*  :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->sesData_change`
+
+The following database fields have been removed:
+
+*  :sql:`be_sessions.ses_backuserid`
+*  :sql:`fe_sessions.ses_anonymous`
+
+
+Impact
+======
+
+Accessing a dropped property or calling a dropped method will raise a fatal PHP
+error.
+
+Accessing a property whose visibility was changed to :php:`protected` will also
+raise a fatal PHP error if no deprecation functionality is in place. See
+:ref:`changelog-Deprecation-93023-ReworkedSessionHandling` for more information.
+
+Calling a method whose parameter signature changed with a wrong type will raise
+a PHP type error.
+
+Directly querying a dropped database field will raise a doctrine dbal exception.
+
+
+Affected Installations
+======================
+
+All TYPO3 installations with custom extensions directly accessing or calling
+the changed properties or methods.
+
+
+Migration
+=========
+
+The :php:`sessionTimeout` property is now set internally to the value of the
+global configuration :php:`(int)$GLOBALS['TYPO3_CONF_VARS'][$loginType]['sessionTimeout'];`.
+This value can also be set dynamically in e.g. a middleware if needed. Because
+it is only needed for User Session objects, it is now resolved within
+the :php:`UserSessionManager` object.
+
+:php:`gc_time` is still set to `86400` by default and will be overwritten
+with the value from :php:`sessionTimeout` (see above) if greater than `0`.
+
+Since it's very unlikely that :php:`gc_probability` will be changed in
+custom code there is no direct way to set a custom value anymore. It's now
+directly set to `1` in the consuming method
+:php:`UserSessionManager->collectGarbage()`. If your custom code however rely
+on another value you can call :php:`UserSessionManager->collectGarbage()`
+in your code by providing a custom value as first argument for
+:php:`$garbageCollectionProbability`.
+
+The property :php:`newSessionID` is now available in :php:`UserSession->isNew()`.
+
+Use the :php:`UserSessionManager->elevateToFixatedUserSession()` as a
+replacement for :php:`getNewSessionRecord()` to migrate an anonymous session
+to a user-bound session.
+
+If you directly call :php:`createUserSession()` in your custom code make sure
+to pass an :php:`array` as argument for :php:`$tempuser` and to handle the
+returned :php:`UserSession` object accordingly.
+
+Use :php:`UserSession->dataWasUpdated()` as replacement for
+:php:`FrontendUserAuthentication->sesData_change`.
+
+The :sql:`be_sessions.ses_backuserid` field was migrated into the session data
+and is now available inside :php:`UserSession->data`, which can be accessed
+using :php:`get()` or :php:`getAll()`. Since this value is only present in
+"switch-user" sessions, it's very unlikely that custom code is directly
+accessing it. If you however perform database queries using this field,
+then they have to be adjusted accordingly.
+
+The :sql:`fe_sessions.ses_anonymous` field is not needed anymore since this
+information can also be obtained using the :sql:`fe_sessions.ses_userid` field.
+If it's lower or equals `0` the session is an anonymous one. If you perform
+database queries using this field, change it to use :sql:`ses_userid` instead.
+If a session is anonymous can furthermore be checked using
+:php:`UserSession->isAnonymous()`.
+
+Related
+=======
+
+-  :ref:`changelog-Deprecation-93023-ReworkedSessionHandling`
+-  :ref:`changelog-Feature-93023-IntroduceUserSessionAndUserSessionManager`
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93029-DroppedDeletedFieldFromSys_refindex.rst

@@ -0,0 +1,75 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93029:
+
+==========================================================
+Breaking: #93029 - Dropped deleted field from sys_refindex
+==========================================================
+
+See :issue:`93029`
+
+Description
+===========
+
+The database field :sql:`deleted` has been removed from table
+:sql:`sys_refindex`. Therefore, the table does no longer store
+relations between soft deleted records.
+
+Following properties and methods of class
+:php:`TYPO3\CMS\Core\Database\ReferenceIndex` have been set to
+protected:
+
+* :php:`temp_flexRelations`
+* :php:`relations` - not scanned by extension scanner
+* :php:`hashVersion`
+* :php:`getWorkspaceId()` - not scanned by extension scanner
+* :php:`getRelations_procDB()`
+* :php:`setReferenceValue_dbRels()`
+* :php:`setReferenceValue_softreferences()`
+* :php:`isReferenceField()` - not scanned by extension scanner
+
+Following methods of class :php:`TYPO3\CMS\Core\Database\ReferenceIndex`
+have been removed:
+
+* :php:`generateRefIndexData()`
+* :php:`createEntryData()`
+* :php:`createEntryData_dbRels()`
+* :php:`createEntryData_softreferences()`
+
+
+Impact
+======
+
+Accessing the properties of class :php:`ReferenceIndex` or calling
+dropped or protected methods will raise fatal PHP errors.
+
+Querying the :sql:`deleted` field of table :sql:`sys_refindex` will raise a
+doctrine dbal exception.
+
+
+Affected Installations
+======================
+
+The hash sums of existing table rows change. The reference index
+should be updated, typically by using the CLI command
+:php:`bin/typo3 referenceindex:update`
+
+Codewise, instances with extensions that query table :sql:`sys_refindex`
+or use class :php:`ReferenceIndex` may be affected. The extension
+scanner helps to find some usages.
+
+
+Migration
+=========
+
+Use the CLI command :php:`bin/typo3 referenceindex:update` to update
+the reference index.
+
+The :sql:`sys_refindex.deleted` field should be dropped from database
+queries.
+
+When accessing class :php:`ReferenceIndex`, use the main API method
+:php:`->updateRefIndexTable()`, plus a couple of other less often
+used methods.
+
+.. index:: Database, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93041-RemoveTypoScriptOptionAddQueryStringmethod.rst

@@ -0,0 +1,70 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93041:
+
+=================================================================
+Breaking: #93041 - Remove TypoScript option addQueryString.method
+=================================================================
+
+See :issue:`93041`
+
+Description
+===========
+
+The TypoScript option :typoscript:`addQueryString.method` has been removed.
+
+If omitted, this added all parameters from the PHP `$_SERVER[QUERY_STRING]`
+value, which was used heavily in PHP 3 / PHP 4 times, instead of the more
+"modern" `$_GET` parameters, which was set via `addQueryString.method = GET`.
+
+However, the latter solution was / is the default for working in PSR-7
+requests, and with routing. The option itself is removed, in order to
+have TYPO3 use the same values throughout TYPO3 Core, making `method = GET`
+the default and thus, the only option.
+
+To further streamline TYPO3s source code, the underlying PHP method
+:php:`ContentObjectRenderer->getQueryArguments()` now only accepts exactly
+one argument.
+
+All Fluid arguments related to that setting, or Extbase UriBuilder methods
+do not change any behavior anymore related to building an Uri.
+
+Impact
+======
+
+Calling :php:`UriBuilder->setAddQueryStringMethod()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Calling :php:`ContentObjectRenderer->getQueryArguments()` with more
+than one argument will have no effect anymore.
+
+Setting the TypoScript option :typoscript:`addQueryString.method` will
+have no effect anymore.
+
+Using the :html:`addQueryStringMethod` argument in the following
+ViewHelpers will trigger a deprecation notice:
+
+* :html:`<f:form>`
+* :html:`<f:link.action>`
+* :html:`<f:link.page>`
+* :html:`<f:link.typolink>`
+* :html:`<f:uri.action>`
+* :html:`<f:uri.page>`
+* :html:`<f:uri.typolink>`
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation
+
+* with extensions calling Extbase's :php:`UriBuilder->setAddQueryStringMethod()` method
+* with extensions calling :php:`ContentObjectRenderer->getQueryArguments()` with more then one argument
+* with custom templates setting the :html:`addQueryStringMethod` argument in Fluid using one of the mentioned ViewHelper.
+
+
+Migration
+=========
+
+Remove any usages within the Fluid templates or Extension code.
+
+.. index:: Frontend, TypoScript, FullyScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-93047-RemovedPropertySendNoCacheHeadersInAbstractUserAuthentication.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93047:
+
+====================================================================================
+Breaking: #93047 - Removed property sendNoCacheHeaders in AbstractUserAuthentication
+====================================================================================
+
+See :issue:`93047`
+
+Description
+===========
+
+The public property :php:`sendNoCacheHeaders` of class :php:`AbstractUserAuthentication` which was
+enabled by default, but disabled in Frontend User objects, ensured that appropriate
+HTTP headers telling the client that this HTTP request is not allowed to be
+cached by the client.
+
+This property is removed, as this is now built into PSR-15 middlewares for
+both Frontend and Backend users since TYPO3 v10.
+
+
+Impact
+======
+
+Setting the property :php:`sendNoCacheHeaders` has no effect anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions dealing with session
+handling, using this property, which is very unlikely.
+
+
+Migration
+=========
+
+Use a PSR-15 middleware to set headers depending on your needs,
+if TYPO3s default header evaluation does not fit your requirements
+in Frontend Requests.
+
+.. index:: Backend, Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-93048-BackendURLRewrites.rst

@@ -0,0 +1,108 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Breaking-93048-BackendURLRewrites:
+
+=======================================
+Breaking: #93048 - Backend URL rewrites
+=======================================
+
+See :issue:`93048`
+
+Description
+===========
+
+To introduce human readable urls to the TYPO3 backend, a new rewrite
+rule for the backend is necessary. Therefore the rewrite process
+should not longer be stopped if the  :file:`typo3/` directory is accessed,
+like it was configured for a long time. Instead, all requests below
+:file:`/typo3/` which do not exist, are now redirected to the TYPO3 Backend
+entry point.
+
+Further do the Backend URLs now not longer require the :html:`&route=`
+parameter since its value is now part of the URL. For example the
+main entry point changed from :html:`/typo3/index.php?route=%2Fmain` to
+:html:`/typo3/main`.
+
+The :html:`&route=` parameter will however be still applied to the URL
+for backwards compatibility.
+
+
+Impact
+======
+
+Accessing the backend without changing the webserver configuration
+will usually lead to a `404 - Not found` response.
+
+Custom backend links which are not build using the :php:`UriBuilder`
+API also may lead to a `404 - Not found` response.
+
+Using relative paths for backend links, e.g. for icons / images, will
+may not longer work as expected.
+
+Extensions relying on the `&route=` parameter to be set will still work
+but break at least in v12 when this parameter will finally be removed.
+
+
+Affected Installations
+======================
+
+All installations are affected.
+
+
+Migration
+=========
+
+There is a silent update in place which automatically updates the
+webserver configuration file when accessing the install tool, at
+least for Apache and Microsoft IIS webservers.
+
+Note: This does not work if you are not using the default configuration,
+which is shipped with Core and automatically applied during the TYPO3
+installation process, as basis. No worries, some custom adjustments like
+redirects do not prevent the update. Only the default rewrite rules must
+be in place.
+
+If you however use a fully custom configuration, especially when using
+a custom entry point for the backend, you may have to perform the
+necessary changes manually. Therefore, please have a look at the changes
+to the default :file:`.htaccess` configuration, for reference.
+
+Apache Config before:
+
+.. code-block:: none
+
+   RewriteRule ^(?:typo3/|fileadmin/|typo3conf/|typo3temp/|uploads/) - [L]
+
+Apache Config after:
+
+.. code-block:: none
+
+   RewriteRule ^(?:fileadmin/|typo3conf/|typo3temp/|uploads/) - [L]
+
+   RewriteCond %{REQUEST_FILENAME} !-f
+   RewriteCond %{REQUEST_FILENAME} !-d
+   RewriteCond %{REQUEST_FILENAME} !-l
+   RewriteRule ^typo3/(.*)$ %{ENV:CWD}typo3/index.php [QSA,L]
+
+For Nginx, add following block:
+
+.. code-block:: none
+
+    location /typo3/ {
+        absolute_redirect off;
+        try_files $uri /typo3/index.php$is_args$args;
+    }
+
+Additionally, make sure to use the public :php:`UriBuilder` API for
+all custom generated backend links.
+
+Finally, check custom backend modules for the use of relative paths,
+because they may not longer work as expected.
+
+
+Related
+=======
+
+- :ref:`changelog-Feature-93048-IntroduceBackendURLRewrites`
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-93056-RemovedHooksWhenRetrievingBackendUserGroups.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93056:
+
+====================================================================
+Breaking: #93056 - Removed hooks when retrieving Backend user groups
+====================================================================
+
+See :issue:`93056`
+
+Description
+===========
+
+When the user groups of a backend user are loaded, two hooks
+(before and after fetching) were in place to modify the
+list of groups.
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauthgroup.php']['fetchGroupQuery']`
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauthgroup.php']['fetchGroups_postProcessing']`
+
+This functionality is replaced by a new PHP :php:`GroupResolver` class,
+the hooks have been removed, and a new Event has been added instead.
+
+
+Impact
+======
+
+Using those hooks has no effect anymore, as the hooks are never called in TYPO3 v11.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using these hooks,
+which is usually around enhancing the permission system or custom
+group resolving.
+
+
+Migration
+=========
+
+When user groups are loaded, for example when a backend editors' groups and permissions
+are calculated, a new PSR-14 event :php:`AfterGroupsResolvedEvent` is fired.
+
+The hooks have been removed without deprecation in order to allow
+extensions to make their extension compatible with TYPO3 v10 (using the hooks),
+and TYPO3 v11 (use the PSR-14 instead).
+
+.. index:: PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.0/Breaking-93062-VariousGroup-relatedPublicPropertiesInBE_USERRemoved.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93062:
+
+=============================================================================
+Breaking: #93062 - Various group-related public properties in BE_USER removed
+=============================================================================
+
+See :issue:`93062`
+
+Description
+===========
+
+The PHP API class :php:`BackendUserAuthentication` was built back in
+PHP4 days and had a few public properties which have been removed.
+
+Their purpose was to store data between methods while resolving
+groups, where there are other methods containing all group-related
+information already anyways.
+
+- :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication->groupList`
+- :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication->includeGroupArray`
+
+
+Impact
+======
+
+Accessing or setting these properties will raise a PHP warning.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions accessing these
+:php:`BackendUserAuthentication` properties, which is highly unlikely,
+or because they were built 10 years ago, still accessing these properties.
+
+
+Migration
+=========
+
+Use :php:`BackendUserAuthentication->userGroupsUID` (array of group UIDs) instead,
+which contains the groups in the proper order on how they were resolved.
+
+If this is not needed directly, it is usually highly recommended to use the
+Context API's "backend.user" aspect to retrieve groups of a
+backend user.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93073-AbstractUserAuthentication-forceSetCookieRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93073:
+
+=====================================================================
+Breaking: #93073 - AbstractUserAuthentication->forceSetCookie removed
+=====================================================================
+
+See :issue:`93073`
+
+Description
+===========
+
+The public property :php:`forceSetCookie`
+is removed from the PHP class :php:`AbstractUserAuthentication`.
+
+This property served to ensure that a cookie should be added
+at any times, which is useful for time-based cookies, which only
+happen in Frontend user sessions. This property is now moved as a protected
+property into the :php:`FrontendUserAuthentication` class and used in this class
+solely to reduce the complexity of the internal logic as well as outside API.
+
+
+Impact
+======
+
+Setting this property has no effect anymore, setting this property on a Frontend User object will trigger a PHP warning.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions and special cookie handling, which is very unlikely.
+
+
+Migration
+=========
+
+If custom functionality for setting cookies is needed, it is highly
+recommended to send cookies manually via a PSR-15 middleware.
+
+.. index:: Backend, Frontend, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93077-RemovedUnneededConfigurationsInPageLayoutView.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93077:
+
+====================================================================
+Breaking: #93077 - Removed unneeded configurations in PageLayoutView
+====================================================================
+
+See :issue:`93077`
+
+Description
+===========
+
+The following TSconfig settings have been removed in favor of strong defaults and less configuration:
+
+- :typoscript:`mod.web_layout.disableIconToolbar`
+- :typoscript:`mod.web_layout.disableSearchBox`
+
+
+Impact
+======
+
+The settings :typoscript:`mod.web_layout.disableIconToolbar` and :typoscript:`mod.web_layout.disableSearchBox` are
+not evaluated anymore and the edit button and the search box are always shown in the page module.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using the settings :typoscript:`mod.web_layout.disableIconToolbar` or :typoscript:`mod.web_layout.disableSearchBox`.
+
+
+Migration
+=========
+
+There is no migration possible.
+
+.. index:: Backend, TSConfig, NotScanned, ext:backend

Documentation/Changelog/11.0/Breaking-93080-RelationHandlerInternalsProtected.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93080:
+
+======================================================
+Breaking: #93080 - RelationHandler internals protected
+======================================================
+
+See :issue:`93080`
+
+Description
+===========
+
+Various properties and methods of class
+:php:`TYPO3\CMS\Core\Database\RelationHandler` have been set to protected:
+
+* :php:`$firstTable` - internal
+* :php:`$secondTable` - internal
+* :php:`$MM_is_foreign` - internal
+* :php:`$MM_oppositeField` - internal
+* :php:`$MM_oppositeTable` - internal
+* :php:`$MM_oppositeFieldConf` - internal
+* :php:`$MM_isMultiTableRelationship` - internal
+* :php:`$currentTable` - internal
+* :php:`$MM_match_fields` - internal
+* :php:`$MM_hasUidField` - internal
+* :php:`$MM_insert_fields` - internal
+* :php:`$MM_table_where` - internal
+
+
+* :php:`getWorkspaceId()` - internal
+* :php:`setUpdateReferenceIndex()` - still public but deprecated, logs deprecation on use.
+* :php:`readList()` - use class state after calling start()
+* :php:`sortList()` - use class state after calling start()
+* :php:`readMM()` - use class state after calling start()
+* :php:`readForeignField()` - use class state after calling start()
+* :php:`updateRefIndex()` - internal
+* :php:`isOnSymmetricSide()` - internal
+
+
+Impact
+======
+
+Calling above properties or methods will raise a PHP fatal error.
+
+
+Affected Installations
+======================
+
+It is quite unlikely many extensions are affected by this API change.
+The extension scanner finds affected extensions as weak matches.
+
+
+Migration
+=========
+
+Above properties and methods are considered internal, there shouldn't be any
+need to call them. Instances with extensions using those should be refactored
+to for instance call :php:`start()` instead of an additional call to :php:`readList()`.
+
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Breaking-93081-RemovedFetchingTranslationFileMirrorFromTypo3org.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93081:
+
+==========================================================================
+Breaking: #93081 - Removed fetching translation file mirror from typo3.org
+==========================================================================
+
+See :issue:`93081`
+
+Description
+===========
+
+The process of downloading translation of XLF files has been simplified.
+The URL `https://localize.typo3.org/xliff/` is always used instead of download a static XML
+file from typo3.org and persisting the URL in the registry.
+
+
+Impact
+======
+
+The URL `https://localize.typo3.org/xliff/` is always used and typo3.org is not contacted anymore.
+
+If any extension has overridden the information in the registry, this path won't be taken into account anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation which uses a different URL to fetch translations of TYPO3 core or any extension.
+
+
+Migration
+=========
+
+Use the existing event :php:`ModifyLanguagePackRemoteBaseUrlEvent` to change the URL used to fetch translations.
+
+.. index:: Backend, Frontend, NotScanned, ext:install

Documentation/Changelog/11.0/Breaking-93083-Classext_updatephpHandlingRemoved.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93083:
+
+========================================================
+Breaking: #93083 - class.ext_update.php handling removed
+========================================================
+
+See :issue:`93083`
+
+Description
+===========
+
+Handling of old :file:`class.ext_update.php` update scripts has been
+dropped: The core introduced a much more solid API for extensions to
+perform upgrades with the release of TYPO3 v9. That API matured
+and many extensions use it in favor of the clumsy
+:file:`class.ext_update.php` solution. Removal of this functionality
+within the extension manager has been long overdue and is finally done
+with TYPO3 v11.
+
+
+Impact
+======
+
+The :file:`class.ext_update.php` was an old way for extensions to
+perform upgrade steps. The TYPO3 core no longer supports this API.
+
+
+Affected Installations
+======================
+
+Some old-style extensions may still rely on this script. It's usage
+has been discouraged since the new upgrade wizards API.
+
+
+Migration
+=========
+
+Migrate :file:`class.ext_update.php` to the :ref:`upgrade wizard API of the
+Install Tool <t3coreapi:upgrade-wizards>`.
+
+
+.. index:: PHP-API, NotScanned, ext:extensionmanager

Documentation/Changelog/11.0/Breaking-93093-ReworkShortcutPHPAPI.rst

@@ -0,0 +1,129 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Breaking-93093-ReworkShortcutPHPAPI:
+
+==========================================
+Breaking: #93093 - Rework Shortcut PHP API
+==========================================
+
+See :issue:`93093`
+
+Description
+===========
+
+The Shortcut PHP API used to store the full URL of the shortcut target
+in the :sql:`sys_be_shortcuts` table. It turned out that
+this is not working well, but error-prone and laborious. For example, all
+created shortcuts are automatically invalid as soon as the corresponding
+module changed its route path. Furthermore the :sql:`url` column included
+the token which was actually never used but regenerated on every link
+generation, e.g. when reloading the backend. Since even the initial
+`returnUrl` was stored in the database, a shortcut which linked to
+FormEngine has returned to this initial url.
+
+All these characteristics oppose the introduction of speaking urls for
+the TYPO3 backend. Therefore, the internal handling and registration of
+the Shortcut PHP API was reworked.
+
+A shortcut record does now not longer store the full url of the shortcut
+target but instead only the modules route identifier and the necessary
+arguments (parameters) for the URL.
+
+The fields :sql:`module_name` and :sql:`url` of the :php:`sys_be_shortcuts`
+table have been replaced with:
+
+* :sql:`route` - Contains the route identifier of the module to link to
+* :sql:`arguments` - Contains all necessary arguments (parameters) for the link as JSON encoded string
+
+The :sql:`arguments` field not longer stores any of the
+following parameters:
+
+* `route`
+* `token`
+* `returnUrl`
+
+Shortcuts are usually created by the JavaScript function
+:js:`TYPO3.ShortcutMenu.createShortcut()` which performs an AJAX call to
+:php:`ShortcutController->addAction()`. The parameter signature of the
+JavaScript function has been changed and the :php:`addAction()`
+method does now feature an additional result string `missingRoute`, in case
+no :js:`routeIdentifier` was provided in the AJAX call.
+
+The parameter signature changed as followed:
+
+.. code-block:: javascript
+
+   // Old signature:
+   public createShortcut(
+      moduleName: string,
+      url: string,
+      confirmationText: string,
+      motherModule: string,
+      shortcutButton: JQuery,
+      displayName: string,
+   )
+
+   // New signature:
+   public createShortcut(
+      routeIdentifier: string,
+      routeArguments: string,
+      displayName: string,
+      confirmationText: string,
+      shortcutButton: JQuery,
+   )
+
+The :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton`
+API for generating such links now provides a new public method
+:php:`setRouteIdentifier()` which replaces the deprecated
+:php:`setModuleName()` method. See
+:ref:`changelog-Deprecation-93093-DeprecateMethodNameInShortcutPHPAPI` for
+all deprecations done during the rework.
+
+
+Impact
+======
+
+Directly calling :js:`TYPO3.ShortcutMenu.createShortcut()` with the old
+parameter signature will result in a JavaScript error.
+
+Already created shortcuts won't be available prior to running the provided
+upgrade wizard.
+
+The columns :sql:`module_name` and :sql:`url` have been removed. Directly
+querying these columns will raise a doctrine dbal exception.
+
+
+Affected Installations
+======================
+
+Installations with created shortcuts.
+
+Installations with custom extensions directly calling
+:js:`TYPO3.ShortcutMenu.createShortcut()` with the old parameter signature.
+
+Installations with custom extensions, directly using the database columns
+:sql:`module_name` and :sql:`url` or relying on them being filled.
+
+Installations with custom extensions using deprecated functionality of
+the Shortcut PHP API.
+
+
+Migration
+=========
+
+Update the database schema (only "Add fields to tables") and run the
+`shortcutRecordsMigration` upgrade wizard either in the install tool or on
+CLI with
+:bash:`./typo3/sysext/core/bin/typo3 upgrade:run shortcutRecordsMigration`.
+Remove the unused :sql:`module_name` and :sql:`url` columns only after running
+the wizard.
+
+Change any call to :js:`TYPO3.ShortcutMenu.createShortcut()` to use the new
+parameter signature.
+
+Migrate custom extension code to use :sql:`route` and :sql:`arguments` instead
+of :sql:`module_name` and :sql:`url`.
+
+Migrate any call to deprecated functionality of the Shortcut PHP API.
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:backend

Documentation/Changelog/11.0/Breaking-93108-ReworkedInternalUserGroupFetchingForFrontendUsers.rst

@@ -0,0 +1,70 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93108:
+
+===========================================================================
+Breaking: #93108 - Reworked internal user group fetching for frontend users
+===========================================================================
+
+See :issue:`93108`
+
+Description
+===========
+
+Frontend users now support the same loading mechanism for usergroups as
+backend users, making it easier to exchange functionality by unifying the
+code base.
+
+In previous versions, the Authentication Service was used to fetch groups and
+enable groups, which can be achieved via the :php:`AfterGroupsResolved` PSR-14 event.
+
+Fetching groups and permissions belongs to authorization, and not authentication
+(identities), where this removal is conceptually suited outside of
+authentication services.
+
+The respective methods and properties
+
+* :php:`TYPO3\CMS\Core\Authentication\AuthenticationService->getGroups()`
+* :php:`TYPO3\CMS\Core\Authentication\AuthenticationService->getSubGroups()`
+* :php:`TYPO3\CMS\Core\Authentication\AuthenticationService->db_groups`
+
+have been removed.
+
+At the same time, much of the PHP 4-based code base from frontend users
+within :php:`FrontendUserAuthentication` has been marked as internal or removed
+completely, allowing this information not to be read or modified from the
+outside anymore.
+
+* :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->TSdataArray`
+* :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->userTS`
+* :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->userTSUpdated`
+* :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->userData_change`
+
+
+Impact
+======
+
+The authentication services "subtype", "getGroupsFE" and "authGroupsFE" are never
+executed anymore.
+
+Accessing the properties will trigger a PHP warning.
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions handling group related authentication
+services, e.g. LDAP extensions.
+
+
+Migration
+=========
+
+Use the mentioned PSR-14 event to load custom groups from different sources or
+based on rules, or use a custom PSR-15 middleware to inject custom groups,
+not based on a specific user, but related to a request.
+
+It is possible to keep extensions compatible with TYPO3 v10 and v11 by keeping
+the AuthenticationService "getGroupsFE" subtype, and adding the PSR-14 event to
+an extension.
+
+.. index:: Frontend, FullyScanned, ext:frontend

Documentation/Changelog/11.0/Breaking-93110-IndexedSearchDoesNotProvideHookForEXTcrawlerAnymore.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-93110:
+
+===============================================================================
+Breaking: #93110 - Indexed search does not provide hook for EXT:crawler anymore
+===============================================================================
+
+See :issue:`93110`
+
+Description
+===========
+
+Indexed search had an explicit dependency on an old API of
+the third-party extension "crawler". This cross-dependency did
+not allow either component to move forward.
+
+In order to build a new solution, legacy code has been removed
+without substitution for the time being, where as new code
+will be added during further TYPO3 v11 development.
+
+
+Impact
+======
+
+TYPO3 v11 does not use existing EXT:crawler hooks and APIs anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using EXT:crawler and EXT:indexed_search.
+
+
+Migration
+=========
+
+None until a more flexible solution is provided, however
+this only affects the maintainers of EXT:crawler.
+
+.. index:: PHP-API, NotScanned, ext:indexed_search

Documentation/Changelog/11.0/Breaking-94861-DeprecatedFormMixinsRemoved.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-94861:
+
+=================================================
+Breaking: #94861 - Deprecated form mixins removed
+=================================================
+
+See :issue:`94861`
+
+Description
+===========
+
+The deprecated EXT:form setup mixins from :yaml:`TYPO3.CMS.Form.mixins.*` have been removed.
+
+
+Impact
+======
+
+Form setup inheriting mixins from :yaml:`TYPO3.CMS.Form.mixins.*` will not work properly anymore.
+
+
+Affected Installations
+======================
+
+All installations using the deprecated form setup mixins are affected.
+
+
+Migration
+=========
+
+Embed the essential parts from :yaml:`TYPO3.CMS.Form.mixins.*` or migrate them to custom mixins.
+
+.. index:: Backend, Frontend, NotScanned, ext:form

Documentation/Changelog/11.0/Deprecation-89938-DeprecatedLanguageModeInTypo3QuerySettings.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-89938:
+
+=========================================================
+Deprecation: #89938 - Language mode in Typo3QuerySettings
+=========================================================
+
+See :issue:`89938`
+
+Description
+===========
+
+The following methods have been marked as deprecated and will be removed in TYPO3 v12.
+
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings::setLanguageMode()`
+- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings::getLanguageMode()`
+
+
+Impact
+======
+
+Calling these methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Calling these methods as of TYPO3 v12 will result in a fatal error.
+
+
+Affected Installations
+======================
+
+All installations that call the mentioned methods.
+
+
+Migration
+=========
+
+The deprecated methods have been used in combination with the non consistent translation handling of
+Extbase. As that handling mode disappeared, there is no need to migrate these method calls and just
+stop calling those instead.
+
+For more information regarding this change, see issue :issue:`87264`
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.0/Deprecation-91606-GlobalDatetimePickerInitialization.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-91606:
+
+===========================================================
+Deprecation: #91606 - Global Datetime Picker initialization
+===========================================================
+
+See :issue:`91606`
+
+Description
+===========
+
+Initializing all datetime pickers at once by invoking
+:js:`DateTimePicker.initialize()` without passing an element has been marked as
+deprecated.
+
+
+Impact
+======
+
+Initializing all datetime pickers at once will trigger a deprecation warning in
+the browser's console.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions calling :js:`DateTimePicker.initialize()` without any
+arguments are affected.
+
+
+Migration
+=========
+
+Initialize the datetime picker by passing an input element to the
+:js:`.initialize()` method.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-91911-OptionElOfTypeJQueryInFormEnginesetSelectOptionFromExternalSource.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-91911:
+
+=============================================================================================
+Deprecation: #91911 - optionEl of type jQuery in FormEngine.setSelectOptionFromExternalSource
+=============================================================================================
+
+See :issue:`91911`
+
+Description
+===========
+
+The 6th argument :js:`optionEl` of the method
+:js:`FormEngine.setSelectOptionFromExternalSource()` now accepts objects of type
+`HTMLOptionElement`.
+
+In the same run, passing a jQuery object has been marked as deprecated.
+
+
+Impact
+======
+
+jQuery objects automatically get converted to their native HTMLElement object.
+Calling the method with passing a jQuery object will log a deprecation warning
+to the browser's console.
+
+
+Affected Installations
+======================
+
+All installations passing a jQuery object as :js:`optionEl` to
+:js:`FormEngine.setSelectOptionFromExternalSource()` are affected.
+
+
+Migration
+=========
+
+Pass a native HTMLOptionElement to
+:js:`FormEngine.setSelectOptionFromExternalSource()`.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-92062-MigrateRecordListControllerHooksToAnPSR-14Event.rst

@@ -0,0 +1,68 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92062:
+
+========================================================================
+Deprecation: #92062 - Migrate RecordListController hooks to PSR-14 event
+========================================================================
+
+See :issue:`92062`
+
+Description
+===========
+
+The following hooks have been marked as deprecated:
+
+* :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']`
+
+Both hooks were used to add content before or after the main content of the list module.
+
+Impact
+======
+
+Using the hooks still works as before, but trigger a PHP :php:`E_USER_DEPRECATED` error.
+The hooks will be removed and stop working in TYPO3 v12.
+Please migrate to the PSR-14 event: :php:`TYPO3\CMS\Recordlist\Event\RenderAdditionalContentToRecordListEvent`.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions that hook into the RecordListController.
+
+
+Migration
+=========
+
+The functionality of both hooks has been migrated to the following PSR-14 event:
+:php:`TYPO3\CMS\Recordlist\Event\RenderAdditionalContentToRecordListEvent`.
+
+The event class contains the following relevant public methods:
+
+* :php:`getRequest`
+  Returns the request object from the list module request.
+* :php:`addContentAbove`
+  Add additional content as string as it is to be shown above the main content.
+* :php:`addContentBelow`
+  Add additional content as string as it is to be shown below the main content.
+
+The event object is used as parameter for the event listener method (default is :php:`__invoke`).
+
+The listener needs to be registered in the extension: :file:`EXT:myext/Configuration/Services.yaml`.
+
+Example:
+
+.. code-block:: yaml
+
+   My\Extension\Provider\MyAdditionalContentProvider:
+      tags:
+         - name: event.listener
+           identifier: 'my-additional-content'
+           event: TYPO3\CMS\Recordlist\Event\RenderAdditionalContentToRecordListEvent
+
+
+Please have a look at :php:`TYPO3\CMS\SysNote\Provider\RecordListProvider` as an example for the
+listener implementation.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:recordlist

Documentation/Changelog/11.0/Deprecation-92080-DeprecatedQueryGeneratorAndQueryView.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92080:
+
+==================================================
+Deprecation: #92080 - QueryGenerator and QueryView
+==================================================
+
+See :issue:`92080`
+See :issue:`92129`
+
+Description
+===========
+
+The classes :php:`TYPO3\CMS\Core\Database\QueryGenerator` and
+:php:`TYPO3\CMS\Core\Database\QueryView` have been marked as deprecated.
+
+
+Impact
+======
+
+Using the classes will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Both classes have been used within the backend only, the method
+:php:`getTreelist()` has been used occasionally by backend extensions to recursively
+fetch children of pages. Even if they are quite inflexible, some extensions may rely
+on them. The extension scanner will find class usages with a strong match.
+
+
+Migration
+=========
+
+As most simple solutions, the :php:`getTreeList` method could be copied over to an own extension.
+
+.. index:: Backend, PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Deprecation-92132-DeprecatedShortcutPHPAPI.rst

@@ -0,0 +1,60 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92132-1668719172:
+
+======================================
+Deprecation: #92132 - Shortcut PHP API
+======================================
+
+See :issue:`92132`
+
+Description
+===========
+
+Some methods related to shortcut / bookmark handling in TYPO3 Backend have been marked as deprecated:
+
+* :php:`TYPO3\CMS\Backend\Template\ModuleTemplate->makeShortcutIcon()`
+* :php:`TYPO3\CMS\Backend\Template\ModuleTemplate->makeShortcutUrl()`
+* :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->getSetVariables()`
+* :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->getGetVariables()`
+* :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setGetVariables()`
+* :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setSetVariables()`
+
+See also:
+
+- :ref:`changelog-Deprecation-93060-ShortcutTitleMustBeSetByControllers`
+- :ref:`changelog-Deprecation-93093-DeprecateMethodNameInShortcutPHPAPI`
+
+
+Impact
+======
+
+Using those methods directly or indirectly will trigger PHP :php:`E_USER_DEPRECATED` errors.
+
+
+Affected Installations
+======================
+
+Extensions with backend modules that show the shortcut button in the doc header may
+be affected. The extension scanner will find all PHP usages as weak match.
+
+
+Migration
+=========
+
+The new method :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setArguments()` has been
+introduced. This method expects the full set of arguments and values to create a shortcut to a specific view, example:
+
+.. code-block:: php
+
+   $buttonBar = $this->moduleTemplate->getDocHeaderComponent()->getButtonBar();
+   $pageId = (int)($request->getQueryParams()['id'] ?? 0);
+   $shortCutButton = $buttonBar->makeShortcutButton()
+       ->setRouteIdentifier('page_preview')
+       ->setDisplayName('View page ' . $pageId)
+       ->setArguments([
+          'id' => $pageId,
+       ]);
+   $buttonBar->addButton($shortCutButton, ButtonBar::BUTTON_POSITION_RIGHT);
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-92132-DeprecatedViewHelperFbebuttonsshortcut.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92132:
+
+======================================================
+Deprecation: #92132 - ViewHelper f:be.buttons.shortcut
+======================================================
+
+See :issue:`92132`
+
+Description
+===========
+
+The Fluid ViewHelper `f:be.buttons.shortcut` has been marked as deprecated.
+
+Additionally, the argument `getVars` of `ext:backend` related
+ViewHelper `be:moduleLayout.button.shortcutButton` has been marked as deprecated.
+
+
+Impact
+======
+
+Using ViewHelper `f:be.buttons.shortcut` and using argument `getVars` of
+ViewHelper `be:moduleLayout.button.shortcutButton` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+The ViewHelpers are occasionally used in backend module context to render the
+shortcut / bookmark icon in the doc header. Some custom backend extensions may be affected.
+
+
+Migration
+=========
+
+Use `ext:backend` related ViewHelper `be:moduleLayout.button.shortcutButton`
+with argument `arguments` instead, or use the :php:`ButtonBar->makeShortcutButton()` API in PHP directly.
+
+.. index:: Fluid, NotScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-92386-DeprecatedExtbasePropertyInjection.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92386:
+
+================================================
+Deprecation: #92386 - Extbase property injection
+================================================
+
+See :issue:`92386`
+
+Description
+===========
+
+Since core dependency injection is in place and is about to replace the extbase dependency injection completely,
+using property injection via the :php:`@Extbase\Inject` annotation has been marked as deprecated.
+
+
+Impact
+======
+
+Classes that use extbase property injection will experience non injected services for properties that have a :php:`@Extbase\Inject` annotation.
+
+
+Affected Installations
+======================
+
+All installations that use extbase property injection via annotation :php:`@Extbase\Inject`.
+
+
+Migration
+=========
+
+Extbase property injection can be replaced by one of the following methods:
+
+- constructor injection: works both with core and extbase dependency injection and is well suited to make extensions compatible for multiple TYPO3 versions.
+- setter injection: Basically the same as constructor injection. Both the core and extbase DI can handle setter injection and both are supported in different TYPO3 versions.
+- (core) property injection: This kind of injection can be used but it requires the configuration of services via a :file:`Services.yaml` in the :file:`Configuration` folder of an extension.
+
+
+Given the following example for a :php:`@Extbase\Inject` annotation based injection:
+
+.. code-block:: php
+
+   /**
+    * @var MyService
+    * @Extbase\Inject
+    */
+   protected $myService;
+
+
+This service injection can be changed to constructor injection by adding the
+service as constructor argument and removing the :php:`@Extbase\Inject` annotation:
+
+.. code-block:: php
+
+   /**
+    @var MyService
+    */
+   protected $MyService;
+
+   public function __construct(MyService $MyService) {
+      $this->myService = $myService;
+   }
+
+Please consult the dependency-injection_ documentation for more information.
+
+.. _dependency-injection: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/DependencyInjection/Index.html
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/11.0/Deprecation-92435-DeprecatedStandaloneViewForEmailFinisher.rst

@@ -0,0 +1,82 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92435:
+
+======================================================
+Deprecation: #92435 - StandaloneView for EmailFinisher
+======================================================
+
+See :issue:`92435`
+
+Description
+===========
+
+The :php:`EmailFinisher` class of EXT:form was extended for the possibility to use
+FluidEmail in TYPO3 v10. Therefore the previously used StandaloneView has now been marked as
+deprecated along with the configuration option :yaml:`templatePathAndFilename`.
+
+
+Impact
+======
+
+Using the StandaloneView will trigger a PHP :php:`E_USER_DEPRECATED` error. Using
+:yaml:`templatePathAndFilename` for custom templates will also trigger a
+PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations not already using FluidEmail for the EXT:form EmailFinisher.
+
+
+Migration
+=========
+
+Adjust your finisher configuration to use FluidEmail by setting :yaml:`useFluidEmail: true`.
+
+Before:
+
+.. code-block:: yaml
+
+    finishers:
+       -
+         identifier: EmailToReceiver
+         options:
+           useFluidEmail: false
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         useFluidEmail: true
+
+For custom templates, replace :yaml:`templatePathAndFilename` with :yaml:`templateName`
+and :yaml:`templateRootPaths`.
+
+Before:
+
+.. code-block:: yaml
+
+    finishersDefinition:
+      EmailToReceiver:
+        options:
+          templatePathAndFilename: EXT:sitepackage/Resources/Private/Templates/Email/ContactForm.html
+
+After:
+
+.. code-block:: yaml
+
+   finishersDefinition:
+     EmailToReceiver:
+       options:
+         templateName: ContactForm
+         templateRootPaths:
+           100: 'EXT:sitepackage/Resources/Private/Templates/Email/'
+
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/11.0/Deprecation-92551-GeneralUtilityMethodsRelatedToPagesl18n_cfgBehavior.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92551:
+
+===============================================================================
+Deprecation: #92551 - GeneralUtility methods related to pages.l18n_cfg behavior
+===============================================================================
+
+See :issue:`92551`
+
+Description
+===========
+
+The methods
+
+* :php:`GeneralUtility::hideIfNotTranslated()`
+* :php:`GeneralUtility::hideIfDefaultLanguage()`
+
+have been marked as deprecated in favor of a new BitSet-based PHP class
+:php:`TYPO3\CMS\Core\Type\Bitmask\PageTranslationVisibility`.
+
+
+Impact
+======
+
+Calling both methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installation with custom third-party extensions calling
+these methods for explicit and special page translation handling.
+
+
+Migration
+=========
+
+Instead of :php:`GeneralUtility::hideIfDefaultLanguage()` use
+
+.. code-block:: php
+
+   $pageTranslationVisibility = new PageTranslationVisibility((int)$page['l18n_cfg'] ?? 0)
+   $pageTranslationVisibility->shouldBeHiddenInDefaultLanguage()
+
+
+Instead of :php:`GeneralUtility::hideIfNotTranslated()` use
+
+.. code-block:: php
+
+   $pageTranslationVisibility = new PageTranslationVisibility((int)$page['l18n_cfg'] ?? 0)
+   $pageTranslationVisibility->shouldHideTranslationIfNoTranslatedRecordExists()
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Deprecation-92583-DeprecateLastArgumentsOfWrapClickMenuOnIcon.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92583:
+
+===============================================================
+Deprecation: #92583 - 3 last arguments of wrapClickMenuOnIcon()
+===============================================================
+
+See :issue:`92583`
+
+Description
+===========
+
+:php:`BackendUtility::wrapClickMenuOnIcon()` has a boolean flag to let the method
+return an array with tag parameters instead of a fully build HTML tag as string.
+As this are two completely different things and cause problems when analysing
+return types it should not be done in the same method.
+
+Calling :php:`BackendUtility::wrapClickMenuOnIcon()` with the 7th and last argument
+:php:`$returnTagParameters` set to :php:`true` has been marked as deprecated alongside the 5th
+and 6th arguments that are already unused.
+
+A new method has been introduced that returns the aforementioned array.
+
+
+Impact
+======
+
+Calling :php:`BackendUtility::wrapClickMenuOnIcon()` with more than 4 arguments
+will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions calling :php:`BackendUtility::wrapClickMenuOnIcon()` with more
+than 4 arguments are affected.
+
+
+Migration
+=========
+
+Arguments 5 and 6 can be safely removed as they are already unused.
+
+If :php:`$returnTagParameters` was set to :php:`true` the newly introduced method
+:php:`BackendUtility::getClickMenuOnIconTagParameters()` should be called to
+retrieve the array with the tag parameters.
+
+Example
+=======
+
+.. code-block:: php
+
+   $parameters = BackendUtility::getClickMenuOnIconTagParameters($tableName, $uid, 'tree');
+
+
+.. index:: Backend, FullyScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-92598-Workspace-relatedMethodsFixVersioningPid.rst

@@ -0,0 +1,71 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92598:
+
+==================================================================
+Deprecation: #92598 - Workspace-related methods "fixVersioningPid"
+==================================================================
+
+See :issue:`92598`
+
+Description
+===========
+
+The two workspace-related methods
+
+* :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository->fixVersioningPid()`
+* :php:`TYPO3\CMS\Backend\Utility\BackendUtility::fixVersioningPid()`
+
+have been marked as deprecated, as they are not needed in TYPO3 v11 anymore.
+
+Both methods served to replace the value of a record's "pid" of
+a live version with the actual "pid" value of a versioned record.
+
+Since TYPO3 v11 this is only different for versioned records which
+have been moved, where the live record has e.g. a PID value of 13
+but in a workspace the record was moved to PID 20. In order to
+correctly resolve e.g. a page path or a rootline, these methods
+helped to modify the "pid" value.
+
+However, as TYPO3 v11 does not use Move Placeholders anymore,
+and move pointers (records moved in a workspace) already contain
+the newly moved location as "pid" value, the extra database
+call is not needed.
+
+
+Impact
+======
+
+Calling these methods in custom PHP code will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom PHP code respecting versioned
+records with these methods. This usually does not apply to
+Extbase-related extensions or extensions that do not consider
+moved records in Workspaces (yet).
+
+
+Migration
+=========
+
+The API methods:
+
+* :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository->versionOL()`
+* :php:`TYPO3\CMS\Backend\Utility\BackendUtility::workspaceOL()`
+* :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getRecordWSOL()`
+
+now override the "pid" value of the moved records directly, and
+keep the live "pid" value in "_ORIG_pid".
+
+It is highly recommended to use these methods.
+
+If it is needed to manually find the online PID for a versioned record, it is
+recommended to just fetch the live record (stored in :sql:`t3ver_oid`) via
+typical Doctrine-based database queries and load the PID value from there,
+or use the overlay methods as described to get both values.
+
+
+.. index:: PHP-API, FullyScanned, ext:workspaces

Documentation/Changelog/11.0/Deprecation-92607-DeprecatedGeneralUtilityuniqueList.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92607:
+
+================================================
+Deprecation: #92607 - GeneralUtility::uniqueList
+================================================
+
+See :issue:`92607`
+
+Description
+===========
+
+Since longer than a decade, the :php:`GeneralUtility::uniqueList()` method does not
+accept an :php:`array` as first argument anymore. The second
+parameter is unused just as long. Both throw an :php:`InvalidArgumentException` upon usage.
+
+As the method doesn't belong to :php:`GeneralUtility` at all, a new refactored
+version was added to :php:`StringUtility`. Therefore, the exceptions were removed
+along with the unused second parameter. The first parameter is now type hinted
+:php:`string` and the return type :php:`string` was added. The
+PHPDoc was updated accordingly.
+
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom third-party extensions calling this method.
+
+
+Migration
+=========
+
+Use the new :php:`StringUtility::uniqueList()` method instead and ensure you
+pass a valid string as first argument and omit the second argument.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Deprecation-92784-ExtbaseControllerActionsMustReturnResponseInterface.rst

@@ -0,0 +1,145 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92784:
+
+==============================================================================
+Deprecation: #92784 - Extbase controller actions must return ResponseInterface
+==============================================================================
+
+See :issue:`92784`
+
+Description
+===========
+
+Until now, Extbase controller actions could return either nothing (void), null, a string, or an object that implements :php:`__toString()`.
+
+From now on Extbase expects actions to return an instance of :php:`Psr\Http\Message\ResponseInterface`.
+
+
+Impact
+======
+
+All actions that do not return an instance of :php:`Psr\Http\Message\ResponseInterface` trigger a PHP :php:`E_USER_DEPRECATED` error and will fail as of TYPO3 v12.
+
+
+Affected Installations
+======================
+
+All installations that use Extbase controller actions which don't return an instance of :php:`Psr\Http\Message\ResponseInterface`.
+
+
+Migration
+=========
+
+Since the core follows not only PSR-7 (https://www.php-fig.org/psr/psr-7/)
+but also PSR-17 (https://www.php-fig.org/psr/psr-17/),
+the PSR-17 factories should be used. Both the :php:`$responseFactory` as
+well as the :php:`$streamFactory` are available in all extbase controllers.
+The :php:`$responseFactory` can be used to create a blank response object
+whose content and headers can be set freely. The content can therefore be
+set using the :php:`$streamFactory`.
+
+Example:
+
+.. code-block:: php
+
+   use Psr\Http\Message\ResponseInterface;
+
+   public function listAction(): ResponseInterface
+   {
+       $items = $this->itemRepository->findAll();
+       $this->view->assign('items', $items);
+
+       return $this->responseFactory->createResponse()
+           ->withAddedHeader('Content-Type', 'text/html; charset=utf-8')
+           ->withBody($this->streamFactory->createStream($this->view->render()));
+   }
+
+This example only shows the most common use case. It causes html with a :html:`Content-Type: text/html` header and
+HTTP status code `200 OK` to be returned as the response to the client.
+
+.. tip::
+
+   Using the factory is a clean architectural solution but it's a lot of new code for a migration
+   from returning nothing at all. To ease the migration path the method :php:`htmlResponse(string $html = null)`
+   has been introduced which makes a quite small change possible.
+   When called without an argument, said method renders the current view.
+
+   .. code-block:: php
+
+      public function listAction(): ResponseInterface
+      {
+          $items = $this->itemRepository->findAll();
+          $this->view->assign('items', $items);
+
+          return $this->htmlResponse();
+      }
+
+
+Of course you are free to adjust this response object before returning it.
+
+Example:
+
+.. code-block:: php
+
+   public function listAction(): ResponseInterface
+   {
+       $items = $this->itemRepository->findAll();
+       $this->view->assign('items', $items);
+
+       return $this->responseFactory
+           ->createResponse()
+           ->withHeader('Cache-Control', 'must-revalidate')
+           ->withHeader('Content-Type', 'text/html; charset=utf-8')
+           ->withStatus(200, 'Super ok!')
+           ->withBody($this->streamFactory->createStream($this->view->render()));
+   }
+
+.. tip::
+
+    To adjust the content of an already created PSR-7 response object,
+    :php:`$response->getBody()->write()` can be used.
+
+.. tip::
+
+   Since Extbase uses PSR-7 responses, you should make yourself familiar with its API.
+   Documentation and more information regarding PSR-7 responses can be found here: https://www.php-fig.org/psr/psr-7/#33-psrhttpmessageresponseinterface
+
+In case you are using the :php:`JsonView` in your extbase controller, you may
+want to ease the migration path with the new :php:`jsonResponse(string $json = null)`
+method. Similar to :php:`htmlResponse()`, this method creates a PSR-7 Response
+with the :html:`Content-Type: application/json` header and http code `200 Ok`.
+If argument :php:`$json` is omitted, the current view is rendered automatically.
+
+Example:
+
+.. code-block:: php
+
+   public function listApiAction(): ResponseInterface
+   {
+       $items = $this->itemRepository->findAll();
+       $this->view->assign('value', [
+            'items' => $items
+        ]);
+
+       return $this->jsonResponse();
+   }
+
+Above example is equivalent to:
+
+.. code-block:: php
+
+   public function listApiAction(): ResponseInterface
+   {
+       $items = $this->itemRepository->findAll();
+       $this->view->assign('value', [
+            'items' => $items
+        ]);
+
+       return $this->responseFactory
+           ->createResponse()
+           ->withHeader('Content-Type', 'application/json; charset=utf-8')
+           ->withBody($this->streamFactory->createStream($this->view->render()));
+   }
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Deprecation-92815-ActionControllerForward.rst

@@ -0,0 +1,80 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92815:
+
+=================================================
+Deprecation: #92815 - ActionController::forward()
+=================================================
+
+See :issue:`92815`
+
+Description
+===========
+
+Method :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController::forward()` has been marked as deprecated
+in favor of returning a :php:`TYPO3\CMS\Extbase\Http\ForwardResponse` in a controller action.
+
+
+Impact
+======
+
+Calling :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController::forward()`,
+which itself throws a `TYPO3\CMS\Extbase\Mvc\Exception\StopActionException` to initiate abortion
+of the current request and to initiate a new request, will also trigger PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations using method :php:`TYPO3\CMS\Extbase\Mvc\Controller\ActionController::forward()`.
+
+
+Migration
+=========
+
+Instead of calling the helper method, a controller action must return a :php:`TYPO3\CMS\Extbase\Http\ForwardResponse`.
+
+Before:
+
+.. code-block:: php
+
+   <?php
+
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class FooController extends ActionController
+   {
+      public function listAction()
+      {
+           // do something
+
+           $this->forward('show');
+      }
+
+      // more actions here
+   }
+
+After:
+
+.. code-block:: php
+
+   <?php
+
+   use Psr\Http\Message\ResponseInterface;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+   use TYPO3\CMS\Extbase\Http\ForwardResponse;
+
+   class FooController extends ActionController
+   {
+      public function listAction(): ResponseInterface
+      {
+           // do something
+
+           return new ForwardResponse('show');
+      }
+
+      // more actions here
+   }
+
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/11.0/Deprecation-92922-UseOfRecordUidInAbstractTreeViewgetIcon.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92922:
+
+======================================================================
+Deprecation: #92922 - Use of record uid in AbstractTreeView::getIcon()
+======================================================================
+
+See :issue:`92922`
+
+Description
+===========
+
+To increase the type safety through the whole TYPO3 core and to properly
+reflect the expected value for the parameter (based on its name),
+calling :php:`AbstractTreeView::getIcon()` with a record uid as first
+argument has been marked as deprecated.
+
+Note: Using a record uid had actually no benefit (performance wise)
+since the method fetched the record internally in that case anyways,
+but without adding any restrictions or respecting any overlays e.g.
+for workspaces.
+
+
+Impact
+======
+
+Calling the method with an :php:`integer` for parameter :php:`$row`
+will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations calling this method with an :php:`integer` for
+parameter :php:`$row`.
+
+
+Migration
+=========
+
+Provide the full record row as first argument.
+
+.. index:: Backend, PHP-API, NotScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-92947-DeprecateTYPO3_MODEAndTYPO3_REQUESTTYPEConstants.rst

@@ -0,0 +1,191 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-92947:
+
+================================================================
+Deprecation: #92947 - TYPO3_MODE and TYPO3_REQUESTTYPE constants
+================================================================
+
+See :issue:`92947`
+
+Description
+===========
+
+The following global constants have been marked as deprecated:
+
+* :php:`TYPO3_MODE`
+* :php:`TYPO3_REQUESTTYPE`
+* :php:`TYPO3_REQUESTTYPE_FE`
+* :php:`TYPO3_REQUESTTYPE_BE`
+* :php:`TYPO3_REQUESTTYPE_CLI`
+* :php:`TYPO3_REQUESTTYPE_AJAX`
+* :php:`TYPO3_REQUESTTYPE_INSTALL`
+
+
+Impact
+======
+
+The main issues with constants :php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE` is, that they
+are NOT constant: Their value depends on the context they are called from. They usually indicate
+if a TYPO3 frontend or backend request is executed. Since constants can't be re-defined, this
+is a blocker if a single TYPO3 PHP call wants to execute multiple requests to both the
+frontend or backend application in one process. This is used by the core testing framework
+already and various core features and extensions will benefit from it, too.
+
+There is no other solution than to phase out :php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE`. The
+new API to substitute them is only available at a later point during TYPO3 bootstrap, so a couple of
+details have to be considered when switching away from usage of those constants in extensions.
+
+Extension developers are highly encouraged to drop usage when making extensions TYPO3 v11 ready.
+The constants are only deprecated, their usage is not breaking, yet. To simplify the transition,
+the new API has been added to TYPO3 v10, too - it is available since TYPO3 10.4.11. Switching to the
+new API early is thus easily possible for extensions that support v10 and v11 in the same version,
+without a TYPO3 version check.
+
+
+Affected Installations
+======================
+
+Many extensions use especially the :php:`TYPO3_MODE` constant. The extension scanner will
+find the corresponding usages.
+
+
+Migration
+=========
+
+:php:`TYPO3_REQUESTTYPE_*` constants
+------------------------------------
+
+* :php:`TYPO3_REQUESTTYPE_FE` - Use :php:`ApplicationType->isFrontend()` instead, see below.
+* :php:`TYPO3_REQUESTTYPE_BE` - Use :php:`ApplicationType->isBackend()` instead, see below.
+* :php:`TYPO3_REQUESTTYPE_CLI` - Use :php:`Environment::isCli()` instead.
+* :php:`TYPO3_REQUESTTYPE_AJAX` - Extensions should barely need this at all. If really required,
+  using :php:`strpos($request->getQueryParams()['route'] ?? '', '/ajax/') === 0` could be used
+  as alternative to find out if a request is a backend ajax request. A better solution however
+  is to refactor consuming code to not depend on this distinction between backend and backend-ajax
+  at all - the TYPO3 core may drop this separation at some point in the future, too.
+* :php:`TYPO3_REQUESTTYPE_INSTALL` - Extensions should never use this. There is only a small
+  number of places in the install tool extensions can extend. Those should have a proper API
+  to separate code from other use cases. A specific check for an install tool scope should not
+  be required.
+
+
+:php:`TYPO3_MODE` usage as global script file security gate
+-----------------------------------------------------------
+
+TYPO3 still has some extension PHP script files executed in global context without class or
+callable encapsulation, namely :file:`ext_localconf.php`, :file:`ext_tables.php` and
+files within :file:`Configuration/TCA/Overrides/`. When those files are located within
+the public document root of an instance and called via HTTP directly, they may error out and
+render error messages. This can be a security risk. To prevent this, those files MUST have a
+security gate as first line. This typically looks like::
+
+   defined('TYPO3_MODE') or die();
+
+These calls should be changed to use the new constant :php:`TYPO3` instead. It is simply defined
+to :php:`true` in early TYPO3 bootstrap and can be used for this purpose::
+
+   defined('TYPO3') or die();
+
+
+Other usages of :php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE` in bootstrap script files
+----------------------------------------------------------------------------------------
+
+The new API class :php:`ApplicationType` MUST NOT be used in the extension related early bootstrap
+script files :file:`ext_localconf.php`, :file:`ext_tables.php` and :file:`Configuration/TCA/*`.
+
+The reason is simple: The frontend and backend :php:`Application` classes are the first objects
+within TYPO3 bootstrap that "know" which kind of application is executed. They add this information
+to the PSR-7 request object as attribute :php:`applicationType`. The helper class
+:php:`ApplicationType` - the main substitution for :php:`TYPO3_MODE` - operates on this. :php:`TCA`
+related extension files and :php:`ext_*` script files however are executed *before* the Application
+object has been started, and before the request object is set in globals. The information if a frontend
+or backend is called does not exist at this point in time, so the helper class :php:`ApplicationType`
+can't be used.
+
+This change is in line with a general core bootstrap strategy: A mid-term goal is to have a static
+framework state after bootstrap, that does not depend on the executed application type. In the future,
+executed code which must change the static state, after the Application object has been set up, will
+have better opportunities to reset this state before the Application emits a response. Extensions should
+bow to this goal and should drop application related state changes in bootstrap related files.
+
+
+:php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE` in :file:`Configuration/TCA/*` files
+...................................................................................
+
+For extensions which use :php:`TYPO3_MODE` or :php:`TYPO3_REQUESTTYPE` in :php:`TCA` related files in
+:file:`Configuration/TCA/*`, the situation is simple: This is not allowed for a while already.
+:php:`$GLOBALS['TCA']` state MUST NOT depend on those constants. The :php:`TCA` state is cached after
+first call and this cache is used in all applications. If extensions still use those constants in these
+files, the :php:`TCA` state depends on whether a first frontend or backend application call is done with
+empty caches, which leads to bugs. Extension developers MUST drop this usage in those files.
+
+
+:php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE` in :file:`ext_localconf.php` and :file:`ext_tables.php` files
+............................................................................................................
+
+As outlined above, class :php:`ApplicationType` MUST NOT be used in these files as substitution for
+usages of :php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE`. There are a couple of strategies to avoid
+this. All of them lead to the situation that framework state changes are always registered and
+necessary switches, depending on the executed application, are done at a later point in time.
+
+One example has been realized with core issue :issue:`92848`: This changed the registration of additional
+JavaScript for the PageRenderer in backend scope to a hook implementation. The hook has later been
+changed to use the :php:`ApplicationType` helper class instead (see below). The idea is that a hook registration
+that changes :php:`GLOBALS['TYPO3_CONF_VARS']` or other globals can *always* be done. The decision,
+if something should be applied, is determined later, when the hook is called.
+
+Another example is the change for issue :issue:`92952`: It is the same strategy - something is always
+registered, the decision if it should actually *do* stuff is postponed to a point when the registered code
+is executed.
+
+
+:php:`TYPO3_MODE` and :php:`TYPO3_REQUESTTYPE` usages in class files
+--------------------------------------------------------------------
+
+Some generic extension classes not involved in TYPO3 bootstrap still need to execute different things
+if they are executed in frontend or backend scope. A use cases is for instance the need to calculate
+different resource paths depending on frontend or backend.
+
+This code should use the new :php:`ApplicationType` class.
+
+Before::
+
+    if (TYPO3_MODE === 'FE') {
+        ...
+    }
+
+After::
+
+    use TYPO3\CMS\Core\Http\ApplicationType;
+    ...
+    if (ApplicationType::fromRequest($request)->isFrontend()) {
+        ...
+    }
+
+This needs the PSR-7 request that is handed over by the Application specific request handlers to single
+controllers. Code that needs this switch should be refactored to receive this request object if it is
+not available already. However, some extension code (especially core hooks) do not provide the request
+object, yet. In those cases, it is ok to fall back to the request object that has been registered as
+:php:`$GLOBALS['TYPO3_REQUEST']` by the TYPO3 core. This is always set by the :php:`RequestHandler` that
+is called before a controller action is executed. It should be noted that falling back to
+:php:`$GLOBALS['TYPO3_REQUEST']` is a technical debt in itself, the TYPO3 core will try to reduce the need
+for this fallback over time. A call using this fallback looks like::
+
+    if (ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isFrontend())
+        ...
+    }
+
+As a last use case, there may be low level code executed by a CLI command controller, sometimes using
+classes that are also used in frontend or backend scope. Some of these CLI calls do not set up a request
+object at all. The core will change this over time with upcoming patches, but some use cases may remain
+that are called by CLI directly without a PSR-7 request. The fact that a request object may be missing
+and still a detection for frontend or backend application type is needed can lead to this code::
+
+   if (($GLOBALS['TYPO3_REQUEST'] ?? null) instanceof ServerRequestInterface
+       && ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isFrontend()
+   ) {
+       ...
+   }
+
+.. index:: Backend, CLI, Frontend, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/11.0/Deprecation-93023-ReworkedSessionHandling.rst

@@ -0,0 +1,70 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Deprecation-93023-ReworkedSessionHandling:
+
+===============================================
+Deprecation: #93023 - Reworked session handling
+===============================================
+
+See :issue:`93023`
+
+Description
+===========
+
+As described in :ref:`changelog-Breaking-93023-ReworkedSessionHandling`
+the whole session handling in the TYPO3 Core was reworked by moving it
+out of the user authentication classes.
+
+Therefore some properties and methods within :php:`AbstractUserAuthentication`
+and its subclasses have been marked as deprecated:
+
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->createSessionId()`
+*  :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->fetchUserSession()`
+
+
+Impact
+======
+
+Accessing :php:`id` or calling :php:`isExistingSessionRecord()`
+respectively :php:`getSessionId()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Calling :php:`createSessionId()` or :php:`fetchUserSession()` will not
+trigger a PHP :php:`E_USER_DEPRECATED` error but will still be reported by the extension
+scanner.
+
+
+Affected Installations
+======================
+
+All TYPO3 installations with custom extensions directly accessing or calling
+the deprecated properties or methods.
+
+
+Migration
+=========
+
+Creating a new session is now handled by the :php:`UserSessionManager`.
+Therefore the identifier is set internally on creation of a new session
+and should not longer be called directly. Use e.g.
+:php:`UserSessionManager->createAnonymousSession()` or
+:php:`UserSessionManager->regenerateSession()` to create a new session
+and then access :php:`UserSession->getIdentifier()`.
+
+Use :php:`UserSessionManager->isSessionPersisted()` instead of
+:php:`isExistingSessionRecord()` to check if a session is already persisted.
+
+Use the :php:`UserSessionManager` to create a new session and then directly
+access the :php:`UserSession` instead of calling :php:`fetchUserSession()`.
+
+Use :php:`UserSession->getIdentifier()` instead of :php:`getSessionId()`. To
+access this information from an user authentication object, call
+:php:`$userAuthentication->getSession()->getIdentifier()`.
+
+Related
+=======
+
+*  :ref:`changelog-Breaking-93023-ReworkedSessionHandling`
+*  :ref:`changelog-Feature-93023-IntroduceUserSessionAndUserSessionManager`
+
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Deprecation-93038-ReferenceIndexRuntimeCache.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-93038:
+
+==================================================
+Deprecation: #93038 - ReferenceIndex runtime cache
+==================================================
+
+See :issue:`93038`
+
+Description
+===========
+
+Two methods of class :php:`ReferenceIndex` have been marked as deprecated:
+
+* :php:`ReferenceIndex->enableRuntimeCache()`
+* :php:`ReferenceIndex->disableRuntimeCache()`
+
+
+Impact
+======
+
+Calling these methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Instances with extensions calling above methods are affected. The extension
+scanner locates candidates.
+
+
+Migration
+=========
+
+The method calls can be dropped, cache handling is done internally.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/11.0/Deprecation-93060-ShortcutTitleMustBeSetByControllers.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Deprecation-93060-ShortcutTitleMustBeSetByControllers:
+
+===============================================================
+Deprecation: #93060 - Shortcut title must be set by controllers
+===============================================================
+
+See :issue:`93060`
+
+Description
+===========
+
+Previously the class :php:`ShortcutRepository` automatically generated a
+shortcut title based on the given arguments. This generation was never reliable,
+especially for custom extension code, since the repository
+does not know about controller specific logic. Therefore, this functionality
+has now been marked as deprecated. Backend controllers which add a shortcut button to
+their module header are now required to also set the desired title.
+
+
+Impact
+======
+
+Adding a new shortcut button without defining the :php:`$displayName` triggers a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations using the shortcut button API without defining the
+:php:`$displayName` property.
+
+
+Migration
+=========
+
+Define the title with
+:php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setDisplayName()`.
+
+.. index:: Backend, PHP-API, NotScanned, ext:backend

Documentation/Changelog/11.0/Deprecation-93093-DeprecateMethodNameInShortcutPHPAPI.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _changelog-Deprecation-93093-DeprecateMethodNameInShortcutPHPAPI:
+
+====================================================
+Deprecation: #93093 - MethodName in Shortcut PHP API
+====================================================
+
+See :issue:`93093`
+
+Description
+===========
+
+Since :issue:`92723` the TYPO3 backend uses symfony routing for resolving
+internal endpoints, e.g. modules. This will allow human readable urls and also
+deep-linking in the future. To achieve this, the shortcut PHP API had to
+be reworked to be fully compatible with the new routing.
+See :ref:`changelog-Breaking-93093-ReworkShortcutPHPAPI` for more information
+regarding the rework.
+
+In the course of the rework, following methods within :php:`ShortcutButton`
+have been marked as deprecated:
+
+* :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->setModuleName()`
+* :php:`TYPO3\CMS\Backend\Template\Components\Buttons\Action\ShortcutButton->getModuleName()`
+
+Impact
+======
+
+Using those methods directly or indirectly will trigger PHP :php:`E_USER_DEPRECATED` errors.
+
+
+Affected Installations
+======================
+
+Installations with custom extensions, adding a shortcut button in the module
+header of their backend modules using the mentioned methods. The extension
+scanner will find all PHP usages as weak match.
+
+
+Migration
+=========
+
+Use the new methods :php:`ShortcutButton->setRouteIdentifier()` and
+:php:`ShortcutButton->getRouteIdentifier()` as replacement. Please note
+that these methods require the route identifier of the backend module
+which may differ from the module name. To find out the route identifier,
+the "Backend Routes" section within the configuration module can be used.
+
+Before:
+
+.. code-block:: php
+
+   $shortCutButton = $buttonBar
+       ->makeShortcutButton()
+       ->setModuleName('web_list');
+
+After:
+
+.. code-block:: php
+
+   $shortCutButton = $buttonBar
+       ->makeShortcutButton()
+       ->setRouteIdentifier('web_list');
+
+.. index:: Backend, PHP-API, FullyScanned, ext:backend

Documentation/Changelog/11.0/Feature-29342-ImproveValidatorTask.rst

@@ -0,0 +1,136 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-29342:
+
+=======================================
+Feature: #29342 - Improve ValidatorTask
+=======================================
+
+See :issue:`29342`
+
+Description
+===========
+
+The :php:`\TYPO3\CMS\Linkvalidator\Task\ValidatorTask` scheduler task for
+reporting broken links via email which still used marker templates, has been
+improved. This is achieved by switching to `FluidEmail`, extending the task
+configuration along with the mails content for more detailed reports, code
+refactoring and introduction of strict types for both
+
+:php:`\TYPO3\CMS\Linkvalidator\Task\ValidatorTask` and
+:php:`\TYPO3\CMS\Linkvalidator\Task\ValidatorTaskAdditionalFieldProvider`.
+
+The task configuration got the following new fields:
+
+* `languages` Comma separated list of language uids
+* `emailTemplateName` Name of the fluid template
+
+With `languages` it's now possible to limit the report to specified system
+languages. This is useful if multiple tasks for different groups of recipients
+should be registered.
+
+With `emailTemplateName` it is possible to use different custom templates for each
+task. The template path must be set in :php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['templateRootPaths']`. Additionally
+the used `SystemEmail` layout can be changed by setting your custom layout
+path in :php:`$GLOBALS['TYPO3_CONF_VARS']['MAIL']['layoutRootPaths']`. If no
+`emailTemplateName` is set or the specified input is invalid, the task
+automatically uses the default template name on task execution.
+
+The following new PSR-14 event has been introduced:
+
+:php:`\TYPO3\CMS\Linkvalidator\Event\ModifyValidatorTaskEmailEvent`
+
+This event can be used to manipulate the :php:`\TYPO3\CMS\Linkvalidator\Result\LinkAnalyzerResult`,
+which contains all information from the linkvalidator API. Also the `FluidEmail`
+object can be adjusted here. This allows to e.g. pass additional information to
+the view by using :php:`$fluidEmail->assign()` or dynamically adding mail information
+such as the receivers list. The added values in the event take precedence over the
+:typoscript:`modTSconfig` configuration. The event contains the full :typoscript:`modTSconfig`
+to access further information about the actual configuration of the task when
+assigning new values to `FluidEmail`.
+
+Note: As it's now also possible to set the recipient addresses dynamically using
+the event, the `email` field in the task configuration can remain empty but will
+be added, if defined, on top of already defined recipients from the event. All
+other values such as `subject`, `from` or `replyTo` will only be set according to
+`modTSconfig` if not already defined through the event.
+
+An example implementation of the PSR-14 event:
+
+.. code-block:: php
+
+   <?php
+   declare(strict_types=1);
+   namespace Vendor\Extension\EventListener;
+
+   use TYPO3\CMS\Linkvalidator\Event\ModifyValidatorTaskEmailEvent;
+
+   class ModifyValidatorTaskEmail
+   {
+      public function modify(ModifyValidatorTaskEmailEvent $event): void
+      {
+         $linkAnalyzerResult = $event->getLinkAnalyzerResult();
+         $fluidEmail = $event->getFluidEmail();
+         $modTSconfig = $event->getModTSconfig();
+
+         if ($modTSconfig['mail.']['fromname'] === 'John Smith') {
+            $fluidEmail->assign('myAdditionalVariable', 'foobar');
+         }
+
+         $fluidEmail->subject(
+            $linkAnalyzerResult->getTotalBrokenLinksCount() . ' new broken links'
+         );
+
+         $fluidEmail->to(new Address('custom@mail.com'));
+      }
+   }
+
+.. code-block:: yaml
+
+   Vendor\Extension\EventListener\ModifyValidatorTaskEmail:
+      tags:
+         - name: event.listener
+         identifier: 'modify-validation-task-email'
+         event: TYPO3\CMS\Linkvalidator\Event\ModifyValidatorTaskEmailEvent
+         method: 'modify'
+
+The :php:`\TYPO3\CMS\Linkvalidator\Result\LinkAnalyzerResult` contains following
+information by default:
+
+* :php:`$oldBrokenLinkCounts` Amount of broken links from the last run, separated by type (e.g. all, internal)
+* :php:`$newBrokenLinkCounts` Amount of broken links from this run, separated by type (e.g. all, internal)
+* :php:`$brokenLinks` List of broken links with the raw database row
+* :php:`$differentToLastResult` Whether the broken links count changed
+
+The :php:`brokenLinks` property gets further processed internally to provide additional
+information for the email. Following additional information is provided by default:
+
+* :php:`full_record` The full record, the broken link was found in (e.g. pages or tt_content)
+* :php:`record_title` Value of the :php:`full_record` title field
+* :php:`record_type` The title of the record type (e.g. "Page" or "Page Content")
+* :php:`language_code` The language code of the broken link
+* :php:`real_pid` The real page id of the record the broken link was found in
+* :php:`page_record` The whole page row of records parent page
+
+More can be added using the PSR-14 event.
+
+Additionally to the already existing content the email now includes a list of all
+broken links fetched according to the task configuration. This list consists of
+following columns:
+
+* `Record` The :php:`record_uid` and :php:`record_title`
+* `Language` The :php:`language_code` and language id
+* `Page` The :php:`real_pid` and :php:`page_record.title` of the parent page
+* `Record Type` The :php:`record_type`
+* `Link Target` The :php:`target`
+* `Link Type` Type of the broken link (Either `internal`, `external` or `file`)
+
+
+Impact
+======
+
+The main improvement is the more detailed report which is delivered by `FluidEmail`,
+using the default `SystemEmail` layout. Along with the new PSR-14 event, extension authors
+are now able to fully customize the content of the report as needed.
+
+.. index:: Backend, CLI, NotScanned, ext:linkvalidator

Documentation/Changelog/11.0/Feature-83814-AddSystemNotesCreationButtonToModulesButtonBar.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-83814:
+
+========================================================================
+Feature: #83814 - Add system notes creation button to modules button bar
+========================================================================
+
+See :issue:`83814`
+
+Description
+===========
+
+System notes can be used to add internal information about a page in the backend.
+The corresponding notes are being displayed in several modules, depending on the
+records configuration, above or below the module content. Previously, one had
+to always switch to the list module and usually also to the "new record" wizard
+to create such notes. To improve the usability, a new button is added to the
+button bar in the top right of page, list and info module. This allows to
+directly create a new :php:`sys_note` record for the current page.
+
+The new button can be disabled via page TSconfig:
+
+.. code-block:: typoscript
+
+   mod.SHARED.disableSysNoteButton = 1
+
+
+Impact
+======
+
+It's now possible to create system notes directly in the corresponding modules
+using the button in the modules top right button bar.
+
+.. index:: Backend, TSConfig, ext:backend

Documentation/Changelog/11.0/Feature-87301-SecureCookiesEnabledByDefault.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-87301:
+
+===================================================
+Feature: #87301 - Secure cookies enabled by default
+===================================================
+
+See :issue:`87301`
+
+Description
+===========
+
+In previous TYPO3 installations an option existed to define
+whether a cookie was shared between HTTP and HTTPS requests.
+
+This allowed to have the same cookie available for HTTPS and non-HTTPS, when a site was available on both ports / protocols.
+
+In order to enhance security, the option is removed and the feature
+provides sensible defaults in the current state of the web, where
+it is recommended to run sites with HTTPS, or if this is not possible
+to use HTTP, but not using a mixed mode, which also has SEO downsides.
+
+
+Impact
+======
+
+The new defaults are:
+
+* If a website is running on HTTPS, the cookie is only exposed via HTTPS.
+* If a website is running on HTTP, the cookie is available for HTTPS as well, but not vice-versa.
+
+The TYPO3 Configuration option :php:`$TYPO3_CONF_VARS[SYS][cookieSecure]` is removed when upgrading TYPO3 installations.
+
+.. index:: LocalConfiguration, ext:core

Documentation/Changelog/11.0/Feature-88276-TypoScriptConditionForPageLayout.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-88276:
+
+======================================================
+Feature: #88276 - TypoScript Condition for page layout
+======================================================
+
+See :issue:`88276`
+
+Description
+===========
+
+A new condition enables integrators to check for the defined backend layout of a page including the
+inheritance of the field *Backend Layout (subpages of this page)*
+
+.. code-block:: typoscript
+
+    # Using backend_layout records
+    [tree.pagelayout == 2]
+        page.1 = TEXT
+        page.1.value = Layout 2
+    [END]
+
+    # Using TsConfig provider of Backend Layouts
+    [tree.pagelayout == "pagets__Home"]
+        page.1 = TEXT
+        page.1.value = Layout Home
+    [END]
+
+This condition is available for both frontend and backend.
+
+Impact
+======
+
+Change TypoScript or TsConfig based on the backend layout of a page.
+
+.. index:: Frontend, Backend, TypoScript, ext:frontend

Documentation/Changelog/11.0/Feature-89496-MakeContextMenuUsableViaKeyboard.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-89496:
+
+======================================================
+Feature: #89496: Make context menu usable via keyboard
+======================================================
+
+See :issue:`89496`
+
+Description
+===========
+
+The context menus are now usable via keyboard. Pressing Shift+F10
+will open the context menu for the focused element. It is also possible to use arrows, home and end keys
+in order to navigate through the menu. Besides that, using enter and
+space keys will active items or open submenus.
+
+This change follows the best practices as described in WAI-ARIA Authoring Practices 1.1,
+see the `W3 document`_ for further reading.
+
+.. _W3 document: https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard-interaction-12
+
+Impact
+======
+
+Added :html:`tabindex`, :html:`role`, and :html:`aria-*` attributes to context menus
+as advised in WAI-ARIA Authoring Practices 1.1. Screen readers are now
+able to recognize the context menu properly.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/11.0/Feature-91712-RedirectModuleCleanupSchedulerTask.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91712:
+
+======================================================================
+Feature: #91712 - Cleanup scheduler task and CLI command for redirects
+======================================================================
+
+See :issue:`91712`
+
+Description
+===========
+
+A new CLI command (which can also run as scheduler task) has been added to cleanup existing redirects periodically under given conditions.
+
+In the scheduler task settings it is possible to set the following options:
+
+- Age of records in days ( query usage: createdon < :age )
+- Domain(s) comma separated ( query usage: source_host IN (:domains) )
+- Hit Count ( query usage: hitcount < :hitCount )
+- Status code(s) comma separated ( query usage: target_statuscode IN (:statusCodes) ) (multiple values allowed)
+- Path pattern ( query usage: source_path LIKE :path )
+
+Depending on the settings, the query will look like:
+
+- :sql:`protected = 0 AND (hitcount < :hitCount) AND (createdon < :age) AND (source_host IN (:domains))`
+- :sql:`protected = 0 AND (hitcount < 30) AND (createdon < 123456789) AND (source_host IN ('example.org', 'example.com'))`
+
+.. tip::
+
+   A new boolean flag "protected" has been introduced, which will be added as a pre-condition to all queries.
+   This flag can be set for any redirect to prevent deletion in the cleanup process.
+
+For the CLI command, the same options exist:
+
+- :bash:`bin/typo3 redirects:cleanup --domain foo.com --domain bar.com --age 90 --hitCount 100 --path "/foo/bar%" --statusCode 302 --statusCode 303`
+- :bash:`bin/typo3 redirects:cleanup -d foo.com -d bar.com -a 90 -c 100 -p "/foo/bar%" -s 302 -s 303`
+
+The options of this command in detail:
+
+-  `-d, --domain[=DOMAIN]          Cleanup redirects matching provided domain(s) (multiple values allowed)`
+-  `-s, --statusCode[=STATUSCODE]  Cleanup redirects matching provided status code(s) (multiple values allowed)`
+-  `-a, --days[=DAYS]              Cleanup redirects older than provided number of days`
+-  `-c, --hitCount[=HITCOUNT]      Cleanup redirects matching hit counts lower than given number`
+-  `-p, --path[=PATH]              Cleanup redirects matching given path (as database like expression)`
+
+.. index:: Backend, CLI, Frontend, ext:redirects

Documentation/Changelog/11.0/Feature-91719-CustomErrorMessagesInRegularExpressionValidator.rst

@@ -0,0 +1,63 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91719:
+
+=====================================================================
+Feature: #91719 - Custom error messages in RegularExpressionValidator
+=====================================================================
+
+See :issue:`91719`
+
+Description
+===========
+
+The :php:`RegularExpressionValidator` can now return a custom validation error message
+to help the user providing valid input.
+
+
+Impact
+======
+
+A new option :php:`errorMessage` has been introduced to the validator.
+
+Example:
+
+.. code-block:: php
+
+   class MyModel extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity
+   {
+       /**
+        * @var string
+        * @TYPO3\CMS\Extbase\Annotation\Validate(
+        *    "RegularExpression",
+        *    options={
+        *       "regularExpression": "/^SO[0-9]$/",
+        *       "errorMessage": "explain how to provide a valid value"
+        *    }
+        * )
+        */
+       protected $customField;
+   }
+
+It is also possible to provide a translation key to render a localized message:
+
+.. code-block:: php
+
+   class MyModel extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity
+   {
+       /**
+        * @var string
+        * @TYPO3\CMS\Extbase\Annotation\Validate(
+        *    "RegularExpression",
+        *    options={
+        *       "regularExpression": "/^SO[0-9]$/",
+        *       "errorMessage": "LLL:EXT:my_extension/path/to/xlf:translation.key"
+        *    }
+        * )
+        */
+       protected $customField;
+   }
+
+If no :php:`errorMessage` is provided, the default message will be displayed in case of a validation error.
+
+.. index:: Frontend, ext:extbase

Documentation/Changelog/11.0/Feature-91738-IntroduceWrapperForSessionStorage.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-91738:
+
+======================================================
+Feature: #91738 - Introduce wrapper for sessionStorage
+======================================================
+
+See :issue:`91738`
+
+Description
+===========
+
+TYPO3 now ships a new module acting as wrapper for :js:`sessionStorage`. It
+behaves similar to :js:`localStorage`, except that the stored data is dropped
+after the browser session has ended.
+
+
+Impact
+======
+
+The module :js:`TYPO3/CMS/Core/Storage/BrowserSession` is available to be used
+to store data in the :js:`sessionStorage`.
+
+API Methods
+-----------
+
+* `get(key)` To fetch the data behind the key.
+* `set(key, value)` To set/override a key with any arbitrary content.
+* `isset(key)` (bool) checks if the key is in use.
+* `unset(key)` To remove a key from the storage.
+* `clear()` to empty all data inside the storage.
+* `unsetByPrefix(prefix)` to empty all data inside the storage with their keys starting with a prefix
+
+.. index:: JavaScript, ext:core