TYPO3 v15 dev-main snapshot ()

Documentation/Changelog-10-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v10-byType:
+
+==========================
+10.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v10-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/10.*/Breaking-*
+
+..  _changelog-v10-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/10.*/Feature-*
+
+..  _changelog-v10-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/10.*/Deprecation-*
+
+..  _changelog-v10-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/10.*/Important-*

Documentation/Changelog-10.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+..  _changelog-v10:
+
+=============
+ChangeLog v10
+=============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+.. toctree::
+   :titlesonly:
+
+   Changelog/10.4.x/Index
+   Changelog/10.4/Index
+   Changelog/10.3/Index
+   Changelog/10.2/Index
+   Changelog/10.1/Index
+   Changelog/10.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-10-combined

Documentation/Changelog-11-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v11-byType:
+
+==========================
+11.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v11-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/11.*/Breaking-*
+
+..  _changelog-v11-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/11.*/Feature-*
+
+..  _changelog-v11-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/11.*/Deprecation-*
+
+..  _changelog-v11-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/11.*/Important-*

Documentation/Changelog-11.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+..  _changelog-v11:
+
+=============
+ChangeLog v11
+=============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+.. toctree::
+   :titlesonly:
+
+   Changelog/11.5.x/Index
+   Changelog/11.5/Index
+   Changelog/11.4/Index
+   Changelog/11.3/Index
+   Changelog/11.2/Index
+   Changelog/11.1/Index
+   Changelog/11.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-11-combined

Documentation/Changelog-12-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v12-byType:
+
+==========================
+12.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v12-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/12.*/Breaking-*
+
+..  _changelog-v12-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/12.*/Feature-*
+
+..  _changelog-v12-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/12.*/Deprecation-*
+
+..  _changelog-v12-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/12.*/Important-*

Documentation/Changelog-12.rst

@@ -0,0 +1,29 @@
+.. include:: /Includes.rst.txt
+
+..  _changelog-v12:
+
+=============
+ChangeLog v12
+=============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+..  toctree::
+    :titlesonly:
+
+    Changelog/12.4.x/Index
+    Changelog/12.4/Index
+    Changelog/12.3/Index
+    Changelog/12.2/Index
+    Changelog/12.1/Index
+    Changelog/12.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-12-combined

Documentation/Changelog-13-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v13-byType:
+
+==========================
+13.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v13-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/13.*/Breaking-*
+
+..  _changelog-v13-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/13.*/Feature-*
+
+..  _changelog-v13-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/13.*/Deprecation-*
+
+..  _changelog-v13-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/13.*/Important-*

Documentation/Changelog-13.rst

@@ -0,0 +1,28 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v13:
+
+=============
+ChangeLog v13
+=============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+..  toctree::
+    :titlesonly:
+
+    Changelog/13.4.x/Index
+    Changelog/13.4/Index
+    Changelog/13.3/Index
+    Changelog/13.2/Index
+    Changelog/13.1/Index
+    Changelog/13.0/Index
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-13-combined

Documentation/Changelog-14-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v14-byType:
+
+==========================
+14.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v14-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/14.*/Breaking-*
+
+..  _changelog-v14-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/14.*/Feature-*
+
+..  _changelog-v14-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/14.*/Deprecation-*
+
+..  _changelog-v14-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/14.*/Important-*

Documentation/Changelog-14.rst

@@ -0,0 +1,29 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v14:
+
+=============
+ChangeLog v14
+=============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+..  toctree::
+    :titlesonly:
+
+
+    Changelog/14.3.x/Index
+    Changelog/14.3/Index
+    Changelog/14.2/Index
+    Changelog/14.1/Index
+    Changelog/14.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-14-combined

Documentation/Changelog-15-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v15-byType:
+
+==========================
+15.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v15-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/15.*/Breaking-*
+
+..  _changelog-v15-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/15.*/Feature-*
+
+..  _changelog-v15-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/15.*/Deprecation-*
+
+..  _changelog-v15-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/15.*/Important-*

Documentation/Changelog-15.rst

@@ -0,0 +1,24 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v15:
+
+=============
+ChangeLog v15
+=============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+..  toctree::
+    :titlesonly:
+
+    Changelog/15.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-15-combined

Documentation/Changelog-7-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v7-byType:
+
+==========================
+7.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v7-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/7.*/Breaking-*
+
+..  _changelog-v7-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/7.*/Feature-*
+
+..  _changelog-v7-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/7.*/Deprecation-*
+
+..  _changelog-v7-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/7.*/Important-*

Documentation/Changelog-7.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+..  _changelog-v7:
+
+============
+ChangeLog v7
+============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+.. toctree::
+   :titlesonly:
+
+   Changelog/7.6.x/Index
+   Changelog/7.6/Index
+   Changelog/7.5/Index
+   Changelog/7.4/Index
+   Changelog/7.3/Index
+   Changelog/7.2/Index
+   Changelog/7.1/Index
+   Changelog/7.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-7-combined

Documentation/Changelog-8-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v8-byType:
+
+==========================
+8.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v8-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/8.*/Breaking-*
+
+..  _changelog-v8-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/8.*/Feature-*
+
+..  _changelog-v8-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/8.*/Deprecation-*
+
+..  _changelog-v8-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/8.*/Important-*

Documentation/Changelog-8.rst

@@ -0,0 +1,32 @@
+.. include:: /Includes.rst.txt
+
+..  _changelog-v8:
+
+============
+ChangeLog v8
+============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+.. toctree::
+   :titlesonly:
+
+   Changelog/8.7.x/Index
+   Changelog/8.7/Index
+   Changelog/8.6/Index
+   Changelog/8.5/Index
+   Changelog/8.4/Index
+   Changelog/8.3/Index
+   Changelog/8.2/Index
+   Changelog/8.1/Index
+   Changelog/8.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-8-combined

Documentation/Changelog-9-combined.rst

@@ -0,0 +1,55 @@
+..  include:: /Includes.rst.txt
+
+..  _changelog-v9-byType:
+
+==========================
+9.x Changes by type
+==========================
+
+This lists all changes to the TYPO3 Core of minor versions grouped by their type.
+
+..  contents:: Table of contents
+
+..  _changelog-v9-bc:
+Breaking Changes
+================
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/9.*/Breaking-*
+
+..  _changelog-v9-feat:
+Features
+========
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/9.*/Feature-*
+
+..  _changelog-v9-dep:
+Deprecations
+============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    Changelog/9.*/Deprecation-*
+
+..  _changelog-v9-imp:
+Important notes
+===============
+
+..  menu::
+    :maxdepth: 3
+    :titlesonly:
+    :glob:
+
+    /Changelog/9.*/Important-*

Documentation/Changelog-9.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+..  _changelog-v9:
+
+============
+ChangeLog v9
+============
+
+Every change to the TYPO3 Core which might affect your site is documented here.
+
+.. toctree::
+   :titlesonly:
+
+   Changelog/9.5.x/Index
+   Changelog/9.5/Index
+   Changelog/9.4/Index
+   Changelog/9.3/Index
+   Changelog/9.2/Index
+   Changelog/9.1/Index
+   Changelog/9.0/Index
+
+
+Also available
+--------------
+
+..  toctree::
+    :maxdepth: 1
+    :titlesonly:
+
+    Changelog-9-combined

Documentation/Changelog/.htaccess

@@ -0,0 +1,11 @@
+# Apache < 2.3
+<IfModule !mod_authz_core.c>
+	Order allow,deny
+	Deny from all
+	Satisfy All
+</IfModule>
+
+# Apache ≥ 2.3
+<IfModule mod_authz_core.c>
+	Require all denied
+</IfModule>

Documentation/Changelog/10.0/Breaking-21638-LockIPPropertyRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-21638:
+
+======================================================================
+Breaking: #21638 - AbstractUserAuthentication::lockIP property removed
+======================================================================
+
+See :issue:`21638`
+
+Description
+===========
+
+The IP-locking-functionality is extended from IPv4 only to now also support IPv6. A separate IpLocker-functionality was added.
+
+The public property :php:`lockIP` in :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication` is now removed.
+It usually shouldn't have been accessed directly and supported IPv4 only.
+
+
+Impact
+======
+
+Extensions relying on :php:`lockIP` won't be able to perform their task anymore.
+This might for example be the case when :php:`lockIP` was set dynamically, depending on the REMOTE_ADDR.
+
+
+Affected Installations
+======================
+
+Every 3rd party extension depending on the formerly public :php:`lockIP` property is affected.
+
+
+Migration
+=========
+
+Set :php:`lockIP` and :php:`lockIPv6` in :php:`TYPO3_CONF_VARS` - for FE or BE depending on the use case.
+Use the new :php:`\TYPO3\CMS\Core\Authentication\IpLocker` API.
+
+.. index:: Backend, Frontend, LocalConfiguration, NotScanned

Documentation/Changelog/10.0/Breaking-81950-RemoveLeftoverWorkspacesUnpublishingFunctionality.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-81950:
+
+========================================================================
+Breaking: #81950 - Remove leftover workspaces unpublishing functionality
+========================================================================
+
+See :issue:`81950`
+
+Description
+===========
+
+A property within workspaces for "unpublishing" published records has been disabled since TYPO3 4.5.
+
+This functionality allowed to restore a published workspace which was published at a given time, to revert the changes on another
+time, but had side-effects if changes were made between publishing and unpublishing.
+
+However, this functionality was not visible to TYPO3 out of the box, but only available with a possible third-party integration
+since TYPO3 4.5. The feature was therefore removed from TYPO3 Core.
+
+The (hidden) database field :sql:`sys_workspace.unpublish_time` was removed.
+
+
+Impact
+======
+
+Using the functionality will not work anymore, operating on the database with this field will result in a SQL error.
+
+
+Affected Installations
+======================
+
+Any installation using the workspace functionality with automatic publishing and a third-party extension for unpublishing.
+
+
+Migration
+=========
+
+If this feature is required for an installation, the field should be re-added by the third-party extension in TCA (which was missing)
+and the database which was using the functionality. On top, a custom auto-unpublishing CLI command should be created.
+
+.. index:: Database, NotScanned, ext:workspaces

Documentation/Changelog/10.0/Breaking-86862-DefaultLayoutOfExtfluid_styled_contentDoesNotUseSpacelessViewHelperAnymore.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-86862:
+
+=======================================================================================================
+Breaking: #86862 - Default Layout of ext:fluid_styled_content does not use spaceless viewHelper anymore
+=======================================================================================================
+
+See :issue:`86862`
+
+Description
+===========
+
+The default layout file of ext:fluid_styled_content removed all white space characters in the whole output, which led
+to occasional issues with the generated markup. This general removal of whitespace characters has been removed.
+It is in the hand of the integrator to apply white space character removal on their own on sensible places using template override functionality.
+
+
+Impact
+======
+
+Markup of pages rendered using ext:fluid_styled_content will contain more white space characters.
+This might influence the visual output.
+
+
+Affected Installations
+======================
+
+Each instance using ext:fluid_styled_content as rendering template.
+
+
+Migration
+=========
+
+Review and adjust the markup generated for your front end. In case you did not experience any issues before,
+you can override the default template and reintroduce the spaceless viewHelper, or apply it in other sections of the output where it will be helpful.
+
+.. index:: Fluid, Frontend, RTE, NotScanned, ext:fluid_styled_content

Documentation/Changelog/10.0/Breaking-87009-UseMultipleTranslationFilesByDefaultInEXTform.rst

@@ -0,0 +1,82 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87009:
+
+========================================================================
+Breaking: #87009 - Use multiple translation files by default in EXT:form
+========================================================================
+
+See :issue:`87009`
+
+Description
+===========
+
+All :yaml:`translationFile` options in EXT:form setup and form definitions have been renamed to :yaml:`translationFiles`.
+
+The following default translation files are now registered at index :yaml:`10` in all locations:
+
+* :file:`EXT:form/Resources/Private/Language/locallang.xlf`
+* :file:`EXT:form/Resources/Private/Language/Database.xlf`
+
+
+Impact
+======
+
+Extending form setup or form definitions with additional translation files does not require adding the default translation files anymore.
+
+The option :yaml:`translationFile` does not work anymore and must be migrated to :yaml:`translationFiles`.
+
+Opening and saving a form with the form editor once also performs the migration of the corresponding form definition and makes it permanent.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and its :yaml:`translationFile` option.
+
+
+Migration
+=========
+
+In your custom form configuration, migrate the single value :yaml:`translationFile` option to the multi value :yaml:`translationFiles` option.
+
+Given that all default translation files of EXT:form are registered at index :yaml:`10` it is recommended to use a higher index for custom translation files.
+
+Single file
+-----------
+
+Before:
+
+.. code-block:: yaml
+
+   translationFile: path/to/locallang.xlf
+
+After:
+
+.. code-block:: yaml
+
+   translationFiles:
+     20: path/to/locallang.xlf
+
+
+Multiple files
+--------------
+
+Before:
+
+.. code-block:: yaml
+
+   translationFile:
+     10: EXT:form/Resources/Private/Language/locallang.xlf
+     20: path/to/locallang.xlf
+     25: path/to/other/locallang.xlf
+
+After:
+
+.. code-block:: yaml
+
+   translationFiles:
+     20: path/to/locallang.xlf
+     25: path/to/other/locallang.xlf
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/10.0/Breaking-87305-UseConstructorInjectionInDataMapper.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87305:
+
+==========================================================
+Breaking: #87305 - Use constructor injection in DataMapper
+==========================================================
+
+See :issue:`87305`
+
+Description
+===========
+
+Class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper` does no longer use setter injection. Instead, constructor injection is used.
+
+
+Impact
+======
+
+The method signature of the constructor changed. This means:
+
+- The amount of constructor arguments increased
+- The order of arguments possibly changed
+
+
+Affected Installations
+======================
+
+All installations that create instances of the class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper` using :php:`GeneralUtility::makeInstance` or :php:`ObjectManager->get`.
+
+
+Migration
+=========
+
+If possible, do not create instances yourself. Avoid :php:`GeneralUtility::makeInstance` and :php:`ObjectManager->get`. Instead use dependency injection, preferably constructor injection:
+
+.. code-block:: php
+
+   public function __constructor(\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper $object)
+   {
+       $this->property = $object;
+   }
+
+If dependency injection is not possible, check the dependencies and instantiate objects via the object manager:
+
+.. code-block:: php
+
+   $object = $objectManager->get(
+       \TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper::class,
+       $objectManager->get(\TYPO3\CMS\Extbase\Reflection\ReflectionService::class),
+       // ...
+   );
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87511-RemoveNamespacesViewObjectNamePatternProperty.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87511-1668719172:
+
+===================================================================
+Breaking: #87511 - Remove $namespacesViewObjectNamePattern property
+===================================================================
+
+See :issue:`87511`
+
+Description
+===========
+
+Property :php:`$namespacesViewObjectNamePattern` of class
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` has been
+removed without replacement.
+
+Impact
+======
+
+Overriding the property :php:`$namespacesViewObjectNamePattern` in
+controllers that extend :php:`ActionController` will no longer trigger
+the instantiation of another view object, derived from the pattern.
+
+Affected Installations
+======================
+
+All extensions that override the property :php:`$namespacesViewObjectNamePattern`.
+
+Migration
+=========
+
+If an action needs a template object other than the default
+:php:`\TYPO3\CMS\Fluid\View\TemplateView`, the property :php:`$defaultViewObjectName`
+needs to be overridden.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87511-RemoveViewFormatToObjectNameMapProperty.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87511:
+
+=============================================================
+Breaking: #87511 - Remove $viewFormatToObjectNameMap property
+=============================================================
+
+See :issue:`87511`
+
+Description
+===========
+
+Property :php:`$viewFormatToObjectNameMap` of class
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` has been
+removed without replacement.
+
+Impact
+======
+
+Overriding the property :php:`$viewFormatToObjectNameMap` in
+controllers that extend :php:`ActionController` will no longer trigger
+the instantiation of another view object, derived from the mapping.
+
+Affected Installations
+======================
+
+All extensions that override the property :php:`$viewFormatToObjectNameMap`.
+
+Migration
+=========
+
+If an action needs a template object other than the default
+:php:`\TYPO3\CMS\Fluid\View\TemplateView`, the property :php:`$defaultViewObjectName`
+needs to be overridden.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87558-ConsolidateExtbaseCaches.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87558:
+
+=============================================
+Breaking: #87558 - Consolidate extbase caches
+=============================================
+
+See :issue:`87558`
+
+Description
+===========
+
+The caches of extbase have been consolidated as both of them shared the same caching frontend.
+Cache identifiers `extbase_reflection` and `extbase_datamapfactory_datamap` do no longer exist.
+
+A single cache `extbase` is pre-configured and used for class schemata and data maps instead.
+
+
+Impact
+======
+
+Adjusting the cache configuration of either `extbase_reflection`
+or `extbase_datamapfactory_datamap` will no longer have any effect.
+
+The installation may throw an error depending on the php error level configuration, if the no longer existing
+cache keys are written to without initializing them first.
+
+The following global settings do no longer exist:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_reflection']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_datamapfactory_datamap']`
+
+The following code code might throw an error depending on the php error level configuration:
+
+.. code-block:: php
+
+   $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['SYS']['cacheConfigurations']['extbase_reflection']['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
+
+
+Affected Installations
+======================
+
+All installations that override the configuration of the caches `extbase_reflection` and `extbase_datamapfactory_datamap`.
+
+
+Migration
+=========
+
+Override new cache `extbase` in the same manner the former caches were overridden.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87567-GlobalVariableTBE_TEMPLATERemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87567:
+
+========================================================
+Breaking: #87567 - Global variable $TBE_TEMPLATE removed
+========================================================
+
+See :issue:`87567`
+
+Description
+===========
+
+The global variable :php:`$GLOBALS[TBE_TEMPLATE]` used in TYPO3 Backend which was available
+for legacy reasons for old backend modules as an instance of :php:`DocumentTemplate` a.k.a. `alt_doc`
+has been removed.
+
+The according PSR-15 middleware, which was marked as internal, is also removed.
+
+
+Impact
+======
+
+Calling any method or property on :php:`$GLOBALS[TBE_TEMPLATE]` will trigger a PHP :php:`E_ERROR` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with older extensions using the global variable.
+
+
+Migration
+=========
+
+Instantiate the :php:`DocumentTemplate` class directly in the controller of the module, or migrate
+to :php:`ModuleTemplate` which is available since TYPO3 v7.
+
+.. index:: PHP-API, FullyScanned, ext:backend

Documentation/Changelog/10.0/Breaking-87583-RemoveObsoleteAPCCacheBackendImplementation.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87583:
+
+===================================================================
+Breaking: #87583 - Remove obsolete APC Cache Backend implementation
+===================================================================
+
+See :issue:`87583`
+
+Description
+===========
+
+The Caching framework backend implementation :php:`TYPO3\CMS\Core\Cache\Backend\ApcBackend` has
+been removed. The APCu PHP extension has superseded in PHP 7.x.
+
+Impact
+======
+
+The PHP APC extension works until PHP 5.x. APCu can be used as "drop-in" replacement since TYPO3 8
+LTS which supports PHP 7.0+.
+
+Affected Installations
+======================
+
+Any installation which has been updated, and any legacy APC cache backend is configured (see
+:file:`LocalConfiguration.php`).
+
+Migration
+=========
+
+Use APCu implementation, which is implemented via :php:`TYPO3\CMS\Core\Cache\Backend\ApcuBackend`
+instead of :php:`TYPO3\CMS\Core\Cache\Backend\ApcBackend` in your caching framework configuration.
+
+Example before:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['backend'] = \TYPO3\CMS\Core\Cache\Backend\ApcBackend::class;`
+
+Example after:
+
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['backend'] = \TYPO3\CMS\Core\Cache\Backend\ApcuBackend::class;`
+
+
+.. index:: Backend, PHP-API, ext:core, NotScanned

Documentation/Changelog/10.0/Breaking-87594-HardenExtbase.rst

@@ -0,0 +1,101 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87594:
+
+=================================
+Breaking: #87594 - Harden extbase
+=================================
+
+See :issue:`87594`
+
+Description
+===========
+
+While hardening Extbase classes, method signatures changed due to an enforced strict type mode and introduced type hints for scalars.
+The change of signatures is considered breaking for the following methods of the following interfaces and their implementations and for the following classes and their derivatives:
+
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::getUid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::setPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::getPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_isNew`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_setProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_getProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_getProperties`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface::_getCleanProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::getUid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::setPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::getPid`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_isNew`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_setProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_getProperty`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_getProperties`
+- :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject::_getCleanProperty`
+- :php:`\TYPO3\CMS\Extbase\Service\ImageService::applyProcessingInstructions`
+- :php:`\TYPO3\CMS\Extbase\Service\ImageService::getImageUri`
+- :php:`\TYPO3\CMS\Extbase\Service\ImageService::getImage`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getSupportedSourceTypes()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getSupportedTargetType()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getTargetTypeForSource()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getPriority()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::canConvertFrom()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getSourceChildPropertiesToBeConverted()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::getTypeOfChildProperty()`
+- :php:`\TYPO3\CMS\Extbase\Property\TypeConverterInterface::convertFrom()`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::__construct`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getMessage`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getCode`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getArguments`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::getTitle`
+- :php:`\TYPO3\CMS\Extbase\Error\Message::render`
+- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::getContentObject`
+- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::getConfiguration`
+- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::isFeatureEnabled`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::reset()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::build()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::uriFor()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAbsoluteUriScheme()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryStringMethod()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setArgumentPrefix()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setArguments()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setArgumentsToBeExcludedFromQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setCreateAbsoluteUri()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setFormat()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setLinkAccessRestrictedPages()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setNoCache()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setSection()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setTargetPageType()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setTargetPageUid()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setUseCacheHash()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getAddQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getAddQueryStringMethod()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getArguments()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getArgumentsToBeExcludedFromQueryString()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getCreateAbsoluteUri()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getFormat()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getLinkAccessRestrictedPages()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getNoCache()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getSection()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getTargetPageUid()`
+- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::getUseCacheHash()`
+
+
+Impact
+======
+
+PHP might throw a fatal error if the method signature(s) of your implementations/derivatives aren't compatible with the interface(s) and/or parent class(es).
+
+
+Affected Installations
+======================
+
+- All installations that use classes that implement mentioned interfaces and their methods.
+- All installations that use classes that inherit mentioned classes and overwrite their methods.
+
+
+Migration
+=========
+
+Methods need to be adjusted to be compatible with the parent class and/or interface signature.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-87623-ReplaceConfigpersistenceclassesTyposcriptConfiguration.rst

@@ -0,0 +1,100 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87623:
+
+==============================================================================
+Breaking: #87623 - Replace config.persistence.classes typoscript configuration
+==============================================================================
+
+See :issue:`87623`
+
+Description
+===========
+
+The configuration of classes in the context of the Extbase persistence is no longer possible via typoscript.
+All typoscript concerning the configuration of classes in that context needs to be converted to php, residing
+in :file:`EXT:extension/Configuration/Extbase/Persistence/Classes.php`.
+
+
+Impact
+======
+
+Unless converted to php, the configuration in typoscript does no longer have any effect and therefore the following things do no longer work:
+
+- Overwriting table names for models whose table name derived by conventions differ from the desired one.
+- The mapping of database field names to model property names
+- The definition of model sub classes which is necessary for a proper implementation of single table inheritance.
+
+
+Affected Installations
+======================
+
+All installations that configure persistence related classes via typoscript.
+
+
+Migration
+=========
+
+Every extension that used typoscript for such configuration must provide a php configuration class called:
+:file:`EXT:extension/Configuration/Extbase/Persistence/Classes.php`
+
+The migration is best described by an example:
+
+.. code-block:: typoscript
+
+   config.tx_extbase {
+       persistence {
+           classes {
+               TYPO3\CMS\Extbase\Domain\Model\FileMount {
+                  mapping {
+                     tableName = sys_filemounts
+                     columns {
+                        title.mapOnProperty = title
+                        path.mapOnProperty = path
+                        base.mapOnProperty = isAbsolutePath
+                     }
+                  }
+               }
+           }
+       }
+   }
+
+This configuration will look like this, defined in php:
+
+.. code-block:: php
+
+   <?php
+   declare(strict_types = 1);
+
+   return [
+       \TYPO3\CMS\Extbase\Domain\Model\FileMount::class => [
+           'tableName' => 'sys_filemounts',
+           'properties' => [
+               'title' => [
+                   'fieldName' => 'title'
+               ],
+               'path' => [
+                   'fieldName' => 'path'
+               ],
+               'isAbsolutePath' => [
+                   'fieldName' => 'base'
+               ],
+           ],
+       ],
+   ];
+
+A few things are noteworthy here:
+
+- The typoscript node :typoscript:`mapping` has been dropped and all sub nodes like :typoscript:`tableName` and :typoscript:`columns` are now located directly
+  in the top node, i.e. the class name.
+- The mapping of columns changed due to the fact that :typoscript:`mapOnProperty` has been dropped and the mapping direction changed.
+  With typoscript the top nodes were called like the class names which indicates the mapping direction model to table. But
+  then, one had to define a mapping by columns instead of properties, which means, the mapping directions was reversed,
+  forcing you to map database table fields on properties. This was quite confusing and the configuration is now eased as
+  one can always think in the model to table mapping direction.
+- The load order of these files is determined by the load order of extensions. If multiple extensions override mapping
+  configuration of the same extbase domain classes, extension load order should be specified by :file:`ext_emconf.php`
+  constraints or dependencies using the :php:`suggests` or :php:`depends` keywords. See
+  :ref:`ext_emconf.php file<t3coreapi:extension-declaration>` for details.
+
+.. index:: TypoScript, NotScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87627-RemovePropertyExtensionNameOfAbstractController.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87627:
+
+======================================================================
+Breaking: #87627 - Remove Property extensionName of AbstractController
+======================================================================
+
+See :issue:`87627`
+
+Description
+===========
+
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController::$extensionName`
+has been removed and is no longer available in subclasses of
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController`, i.e.
+:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` and their derivates.
+
+
+Impact
+======
+
+Accessing the missing property :php:`$extensionName` will throw a fatal error.
+
+
+Affected Installations
+======================
+
+All installations that read from :php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController::$extensionName`.
+
+
+Migration
+=========
+
+The extension name is set in and available through the request object that is available in the controller.
+See :php:`\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController::$request` and :php:`\TYPO3\CMS\Extbase\Mvc\Request::getControllerExtensionName()`
+for more information.
+
+.. index:: PHP-API, NotScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87936-TCAForSysHistoryRemoved.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87936:
+
+==============================================
+Breaking: #87936 - TCA for sys_history removed
+==============================================
+
+See :issue:`87936`
+
+Description
+===========
+
+The TCA definition for :sql:`sys_history` database table was removed. It was never shown in TYPO3 Backend,
+and only in use for the BElog module as Extbase Domain Model. However, this relationship between
+logs and sys_history was decoupled in TYP3 v9.0.
+
+The database field :sql:`pid` which was "0" at all times, is now removed.
+
+
+Impact
+======
+
+Accessing :php:`$GLOBALS[TCA][sys_history]` will trigger a PHP :php:`E_WARNING`, and the contents of the array
+are not available anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with extensions accessing the global array by making use of
+:sql:`sys_history`.
+
+
+Migration
+=========
+
+If still needed, an extension should deliver the full TCA definition of :sql:`sys_history`.
+
+.. index:: Database, TCA, FullyScanned, ext:core

Documentation/Changelog/10.0/Breaking-87937-TCAOption_selicon_field_path_removed.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87937:
+
+==========================================================
+Breaking: #87937 - TCA option "selicon_field_path" removed
+==========================================================
+
+See :issue:`87937`
+
+Description
+===========
+
+The TCA option :php:`$GLOBALS['TCA'][$myTable]['ctrl']['selicon_field_path']` was removed.
+
+The option allowed to show icons in select items when using :php:`$myTable` as a foreign table
+in relations, and was bound to using :php:`selicon_field` as a legacy file (:php:`internal_type=file`).
+
+
+Impact
+======
+
+It is now only possible to use :php:`selicon_field` in inline relations towards :php:`sys_file_reference`.
+Setting the :php:`selicon_field_path` has no effect anymore and a PHP :php:`E_USER_DEPRECATED` error will be triggered.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with an extension providing TCA with :php:`selicon_field_path`.
+
+
+Migration
+=========
+
+Remove the option :php:`selicon_field_path` and use an inline relation to file references in :php:`selicon_field` instead.
+
+.. index:: TCA, PartiallyScanned, ext:core

Documentation/Changelog/10.0/Breaking-87957-DoNotMagicallyRegisterValidators.rst

@@ -0,0 +1,164 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87957:
+
+=================================================================================
+Breaking: #87957 - Validators are not registered automatically in Extbase anymore
+=================================================================================
+
+See :issue:`87957`
+
+Description
+===========
+
+There were several validators that Extbase applies automatically. One example are domain validators that are registered
+if created in a specific directory. Another one is the type validator which is created if a validator with a specific
+name exists.
+
+The method :php:`TYPO3\CMS\Extbase\Utility\ClassNamingUtility::translateModelNameToValidatorName` has
+been removed without substitution. This leads to no automatically registered validators anymore.
+
+Domain Validators
+=================
+
+Given that there is a model :php:`\TYPO3\CMS\Extbase\Domain\Model\BackendUser`, extbase searched for a validator named
+:php:`\TYPO3\CMS\Extbase\Domain\Validator\BackendUserValidator`. The `Model` part of the namespace had been replaced
+with `Validator` and another `Validator` string had been added to the actual class name. In this example, `BackendUser`
+has been replaced with `BackendUserValidator`.
+
+If such a validator class existed it had been magically applied and used during the validation of the model.
+
+Example::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Domain\Validator;
+
+   use TYPO3\CMS\Extbase\Validation\Validator;
+
+   class BlogValidator implements ValidatorInterface
+   {
+      public function validate($value);
+      {
+         // ...
+      }
+   }
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use ExtbaseTeam\BlogExample\Domain\Model\Blog;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      public function showAction(Blog $blog)
+      {
+         // ...
+      }
+   }
+
+In this example there is a model validator :php:`ExtbaseTeam\BlogExample\Domain\Validator\BlogValidator` defined for
+model :php:`ExtbaseTeam\BlogExample\Domain\Model\Blog`, which had been automatically registered before calling action
+:php:`ExtbaseTeam\BlogExample\Controller\BlogController::showAction`.
+
+From now on the validator needs to be registered manually.
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use ExtbaseTeam\BlogExample\Domain\Model\Blog;
+   use TYPO3\CMS\Extbase\Annotation as Extbase;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      /**
+       * @Extbase\Validate(param="blog", validator="ExtbaseTeam\BlogExample\Domain\Validator\BlogValidator")
+       */
+      public function showAction(Blog $blog)
+      {
+         // ...
+      }
+   }
+
+
+Type Validators
+===============
+
+Given that there is any kind of simple type param or property that is to be validated, e.g. a property of a model or an
+action method param, extbase tried to apply a validator for that param/property derived from its type. If there was an
+action param of type string, extbase searched for a `StringValidator` in the namespace
+`TYPO3\CMS\Extbase\Validation\Validator`. The :php:`TYPO3\CMS\Extbase\Validation\Validator\StringValidator` does
+actually exist, as well as :php:`TYPO3\CMS\Extbase\Validation\Validator\IntegerValidator` and others.
+
+If a validator for a specific type existed it had been magically applied and used during the validation of models and
+action arguments.
+
+Example:
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      public function showAction(int $blogUid)
+      {
+         // ...
+      }
+   }
+
+In this example there is a simple type param, extbase automatically registered a type validator for. First, `int` had
+been normalized to `integer`, then :php:`ucfirst($type)` had been called, resulting in `Integer` and then extbase looked
+for a :php:`TYPO3\CMS\Extbase\Validation\Validator\IntegerValidator`. As this Validator exists, it had been
+automatically registered.
+
+If this behaviour is desired, the validator needs to be registered manually from now on.
+
+::
+
+   <?php
+   namespace ExtbaseTeam\BlogExample\Controller;
+
+   use TYPO3\CMS\Extbase\Annotation as Extbase;
+   use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
+
+   class BlogController extends ActionController
+   {
+      /**
+       * @Extbase\Validate(param="blogUid", validator="TYPO3\CMS\Extbase\Validation\Validator\IntegerValidator")
+       */
+      public function showAction(int $blogUid)
+      {
+         // ...
+      }
+   }
+
+
+Impact
+======
+
+With these mentioned validators no longer being applied automatically, developers actively need to apply those
+validators if needed. Most developers might want to register existing domain validators manually while leaving the type
+validators unregistered. This however will vary from project to project.
+
+
+Affected Installations
+======================
+
+All installations that use the extbase validation framework.
+
+
+Migration
+=========
+
+There is no automatic migration. Validators need to be re-applied manually if needed.
+
+.. index:: PHP-API, PartiallyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-87989-TCAOptionSetToDefaultOnCopyRemoved.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-87989:
+
+========================================================
+Breaking: #87989 - TCA option setToDefaultOnCopy removed
+========================================================
+
+See :issue:`87989`
+
+Description
+===========
+
+The special TCA option :php:`$TCA[$tableName]['ctrl']['setToDefaultOnCopy']` is removed.
+
+It allowed to reset a certain field to its default value when copying a record.
+
+
+Impact
+======
+
+Having the setting set in TCA will trigger a PHP :php:`E_USER_DEPRECATED` error when building TCA.
+
+Copying records with this TCA setting enabled, will now keep the copied state and avoid side-effects.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with active usage of `sys_action` or other extensions using this TCA setting.
+
+
+Migration
+=========
+
+This option was only there for resetting some `sys_action` values to default, which
+can easily be achieved by a hook if needed. If an extension author uses this setting,
+this should be achieved with proper DataHandler hooks.
+
+.. index:: TCA, PartiallyScanned, ext:core

Documentation/Changelog/10.0/Breaking-88129-RenameFeloginFlexformFields.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88129:
+
+==================================================
+Breaking: #88129 - Renamed felogin flexform fields
+==================================================
+
+See :issue:`88129`
+
+Description
+===========
+
+In preparation to :issue:`84262` the felogin flexform field definition has been changed
+and all field names are now prefixed with `settings.`. This has been done to easily access all
+of the flexform values in the later extbase controller via :php:`$this->settings['foo']` and also in
+the fluid templates via :html:`{settings.foo}`.
+
+
+Impact
+======
+
+Any PageTsConfig that overrides felogin flexform fields will be ignored.
+
+
+Affected Installations
+======================
+
+All installations with a felogin plugin need to migrate their flexform database values.
+PageTsConfig that overrides the flexform needs to be adjusted.
+
+
+Migration
+=========
+
+An update wizard is provided to easily update all used felogin plugins. To migrate the flexform values, execute
+`Migrate felogin plugins to use prefixed flexform keys`.
+
+All PageTsConfig that overrides felogin flexform fields e.g. :typoscript:`TCEFORM.tt_content.pi_flexform.login.sDEF.showForgotPassword.disabled = 1`
+needs to add the `settings.` prefix to the keys.
+Note the escaping backslash! :typoscript:`TCEFORM.tt_content.pi_flexform.login.sDEF.settings\.showForgotPassword.disabled = 1`.
+
+.. index:: FlexForm, NotScanned, ext:felogin

Documentation/Changelog/10.0/Breaking-88143-Version-relatedDatabaseFieldT3ver_idRemoved.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88143:
+
+====================================================================
+Breaking: #88143 - Version-related database field "t3ver_id" removed
+====================================================================
+
+See :issue:`88143`
+
+Description
+===========
+
+The database field for all workspace-enabled database tables :sql:`t3ver_id` is removed. It previously
+contained an incrementing numeric value when using incrementing versioning - the versioning concept
+which was in place before Workspaces were introduced in TYPO3 v4.0.
+
+Since the legacy versioning was removed in TYPO3 v9, the field is removed and not automatically
+created for new installations anymore.
+
+
+Impact
+======
+
+Creating SQL statements in custom extensions explicitly selecting this field will result in SQL
+errors.
+
+In addition, when upgrading TYPO3 to v10.0 this field will be removed by the Database Analyzer
+Tool in the Install Tool for all TYPO3 core database tables and extensions using the automatic
+creation of database fields.
+
+
+Affected Installations
+======================
+
+All installations with custom extensions explicitly requesting this field.
+
+
+Migration
+=========
+
+Search in any extension in `typo3conf/ext` for :sql:`t3ver_id` to see any usages, and remove the field
+from any queries, database definitions in :file:`ext_tables.sql` files.
+
+.. index:: Database, NotScanned, ext:workspaces

Documentation/Changelog/10.0/Breaking-88182-JsfuncInlineJsHasBeenDropped.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88182:
+
+====================================================
+Breaking: #88182 - jsfunc.inline.js has been dropped
+====================================================
+
+See :issue:`88182`
+
+Description
+===========
+
+The JavaScript file :file:`jsfunc.inline.js` which was responsible for FormEngine's subcomponent IRRE has been
+superseded by the rewritten :php:`TYPO3\CMS\Backend\Form\Container\InlineControlContainer` component.
+
+
+Impact
+======
+
+Requesting the file :file:`typo3/sysext/backend/Resources/Public/JavaScript/jsfunc.inline.js` will cause a 404 error.
+Calling any method of the global :js:`inline` object will throw an error since the object doesn't exist anymore.
+
+
+Affected Installations
+======================
+
+All installations of TYPO3 are affected.
+
+
+Migration
+=========
+
+There is no migration available in most cases, since the :php:`TYPO3\CMS\Backend\Form\Container\InlineControlContainer` component is now event-driven.
+
+One exception is the former :js:`inline.delayedImportElement()` method, since this part is now based on
+`postMessage`. For this approach, a small helper utility :js:`TYPO3/CMS/Backend/Utility/MessageUtility` has
+been added.
+
+See the example for a possible migration:
+
+.. code-block:: javascript
+
+   // Previous code from DragUploader
+   window.inline.delayedImportElement(
+       irre_object,
+       'sys_file',
+       file.uid,
+       'file',
+   );
+
+   // New code
+   require(['TYPO3/CMS/Backend/Utility/MessageUtility'], function(MessageUtility) {
+       const message = {
+           objectGroup: irre_object,
+           table: 'sys_file',
+           uid: file.uid,
+       };
+       MessageUtility.send(message);
+   });
+
+The :js:`MessageUtility.send()` method automatically gets the current domain of the request and attaches it to
+the postMessage. :js:`MessageUtility.verifyOrigin()` must be used to check whether the incoming request was sent
+by the current TYPO3 backend to avoid possible security issues.
+
+.. index:: Backend, JavaScript, TCA, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88366-RemovedCf_PrefixOfCacheTables.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88366:
+
+=================================================
+Breaking: #88366 - Removed prefix of cache tables
+=================================================
+
+See :issue:`88366`
+
+Description
+===========
+
+In addition, when the Typo3DatabaseBackend now accesses and creates tables without the ``cf_``
+prefix ("cf" = Caching Framework), so caches in the database are simply called `cache_rootline`
+for instance.
+
+
+Impact
+======
+
+Accessing the database tables directly with a ``cf_`` prefix will not work on the TYPO3 managed
+cache tables.
+
+
+Affected Installations
+======================
+
+Any TYPO3 instance using the Caching Framework with a Typo3DatabaseBackend.
+
+
+Migration
+=========
+
+Use the Caching Framework directly.
+
+In addition, run through the Database Table Analyzer of the Configuration module to
+re-create any database tables of the Caching Framework.
+
+.. index:: Database, NotScanned, ext:core

Documentation/Changelog/10.0/Breaking-88376-RemovedObsoletePageNotFound_handlingSettings.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88376:
+
+====================================================================
+Breaking: #88376 - Removed obsolete "pageNotFound_handling" settings
+====================================================================
+
+See :issue:`88376`
+
+Description
+===========
+
+The following global TYPO3 settings, usually set within :file:`LocalConfiguration.php` have been removed:
+
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling_statheader']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling_accessdeniedheader']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageUnavailable_handling']`
+* :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['pageUnavailable_handling_statheader']`
+
+These settings are effectively replaced by the error handling of the newly introduced Site Handling
+which is more flexible and robust, and is used instead of these options when Site Handling was
+enabled in TYPO3 v9. For TYPO3 v10 Site Handling is a requirement, making these options useless.
+
+
+Impact
+======
+
+Setting any of the options will have no effect any more. Executing the Silent Upgrade Wizard
+will remove the settings automatically.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations having these settings overridden in :file:`LocalConfiguration.php`
+file of an installation.
+
+
+Migration
+=========
+
+Access the install tool to automatically update the :file:`LocalConfiguration.php` file and remove the
+settings.
+
+Ensure to set up Site Handling with proper error handlers. Avoid accessing these settings but
+rather use the available :php:`TYPO3\CMS\Frontend\Controller\ErrorController` class, when trying to manually trigger a 404/500
+in the Frontend (e.g. custom plugin) instead.
+
+.. index:: Frontend, LocalConfiguration, PartiallyScanned, ext:frontend

Documentation/Changelog/10.0/Breaking-88411-TBE_EDITORtypo3formRemoved.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88411:
+
+===============================================
+Breaking: #88411 - TBE_EDITOR.typo3form removed
+===============================================
+
+See :issue:`88411`
+
+Description
+===========
+
+The global object :js:`TBE_EDITOR.typo3form` and its backward layers :js:`typo3FormFieldSet` and :js:`typo3FormFieldGet`
+have been removed.
+
+
+Impact
+======
+
+Any extension relying on this code will not work anymore.
+
+
+Affected Installations
+======================
+
+All installations using the removed code are affected.
+
+
+Migration
+=========
+
+No direct migration possible. Refer to the FormEngine JavaScript API.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88427-JsfuncevalfieldjsHasBeenRemoved.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88427:
+
+=======================================================
+Breaking: #88427 - jsfunc.evalfield.js has been removed
+=======================================================
+
+See :issue:`88427`
+
+Description
+===========
+
+The file :file:`jsfunc.evalfield.js`, responsible for form value evaluation and validation, has been removed. This job is
+now done by :js:`TYPO3/CMS/Backend/FormEngineValidation` since TYPO3 7.4.
+
+
+Impact
+======
+
+Extensions still relying on this file and its API will not work anymore.
+
+
+Affected Installations
+======================
+
+All installations with third party extensions using this API are affected.
+
+
+Migration
+=========
+
+In most cases no migration is necessary, unless this API is used in a custom built form. In such case, migrate to
+FormEngine API to automatically use the new API.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88458-RemovedFrontendTrackUserFtuFunctionality.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88458:
+
+==================================================================
+Breaking: #88458 - Removed Frontend Track User "ftu" functionality
+==================================================================
+
+See :issue:`88458`
+
+Description
+===========
+
+The "ftu" feature, used to transfer sessions via GET parameter, has been removed.
+
+The implementation and the functionality exposed some security concerns, if enabled via TypoScript
+:typoscript:`config.ftu` as sessions could have been taken over by link sharing, although this was mitigated
+in the past by a security change.
+
+
+Impact
+======
+
+The following public properties now trigger PHP :php:`E_WARNING` when accessed:
+
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->get_name`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->getFallBack`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->getMethodEnabled`
+* :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->get_URL_ID`
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->getMethodUrlIdToken`
+
+The TypoScript setting :typoscript:`config.ftu` has no effect anymore.
+
+The global configuration setting :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['get_url_id_token']` is not
+set anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using the :typoscript:`config.ftu` functionality.
+
+
+Migration
+=========
+
+Remove any usages to the properties or options, and use a custom session handling without
+handing over Session IDs in plaintext via GET parameters. Suggested alternatives for instance are
+JWT payloads or OTP links for starting a session.
+
+For cookie-less session handling, a custom functionality depending on the use-case has to be
+implemented as TYPO3 extension.
+
+.. index:: Frontend, LocalConfiguration, PHP-API, TypoScript, PartiallyScanned

Documentation/Changelog/10.0/Breaking-88496-MethodGetSwitchableControllerActionsHasBeenRemoved.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88496:
+
+=========================================================================
+Breaking: #88496 - Method getSwitchableControllerActions has been removed
+=========================================================================
+
+See :issue:`88496`
+
+Description
+===========
+
+The abstract method :php:`\TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager::getSwitchableControllerActions`
+has been removed in favor of :php:`\TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager::getControllerConfiguration`.
+While the method name changes, the expected implemented functionality stays the same.
+
+
+Impact
+======
+
+Method :php:`getSwitchableControllerActions` will no longer be called. Instead :php:`getControllerConfiguration` is expected
+to be implemented by classes that extend :php:`TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager`.
+
+
+Affected Installations
+======================
+
+All installations that have custom configuration managers that extend :php:`TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager`.
+
+
+Migration
+=========
+
+Rename method :php:`getSwitchableControllerActions` to :php:`getControllerConfiguration` to be TYPO3 >= 10 compatible.
+
+To stay compatible with both version 10 and lower, simply implement both methods and call :php:`getSwitchableControllerActions` from within :php:`getControllerConfiguration`.
+
+Example::
+
+   protected function getSwitchableControllerActions($extensionName, $pluginName)
+   {
+       return $this->getControllerConfiguration($extensionName, $pluginName);
+   }
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-88498-GlobalDataForTimeTrackerStatisticsRemoved.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88498:
+
+=================================================================
+Breaking: #88498 - Global data for TimeTracker statistics removed
+=================================================================
+
+See :issue:`88498`
+
+Description
+===========
+
+The TimeTracker used some global variables to store :php:`microtime()` when a Frontend request was started
+and ended, as information for the Admin Panel and as HTTP Header, if debug mode is enabled for Frontend.
+
+This information is now encapsulated within the TimeTracker object, making the following global variables
+obsolete:
+
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_start']`
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_end']`
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_BE_USER_start']`
+* :php:`$GLOBALS['TYPO3_MISC']['microtime_BE_USER_end']`
+
+This also results in having :php:`$GLOBALS['TYPO3_MISC']` to not be set anymore.
+
+
+Impact
+======
+
+Accessing the global variables will trigger a PHP :php:`E_WARNING` error, as they do not exist anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with an extension working with any of the global variables.
+
+
+Migration
+=========
+
+Remove the usages and either use the newly introduced :php:`TimeTracker->finish()` to calculate data, or set
+your own variables, if microtime is needed.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Breaking-88500-RTEImageHandlingFunctionalityDropped.rst

@@ -0,0 +1,66 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88500:
+
+===========================================================
+Breaking: #88500 - RTE image handling functionality dropped
+===========================================================
+
+See :issue:`88500`
+
+Description
+===========
+
+With the replacement of CKEditor as RTE instead of RTEHtmlArea in TYPO3 v8, the native
+and very incomplete functionality of having images within the RTE was unused.
+
+It is still possible to use HTMLArea in further versions (if adopted), however the
+handling of images is removed.
+
+This includes:
+
+* RTE processing mode ("ts_images")
+* SoftReference Index for handling inline images
+* Removed public method :php:`ImportExport->getRTEoriginalFilename()`
+* Removed public method :php:`RteHtmlParser->TS_images_rte()`
+* Removed CLI command "cleanup:rteimages" and relevant command class
+* The configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['RTE_imageStorageDir']`
+
+
+Impact
+======
+
+Images within an RTE field are not processed at all anymore, not part of the CLI.
+
+Calling the CLI script, using the PHP methods or the PHP CLI command class directly
+within PHP, will result in a PHP :php:`E_ERROR` error.
+
+Accessing the configuration option will trigger a PHP :php:`E_NOTICE` error, as it is
+silently removed, if customary set in :file:`LocalConfiguration.php`.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using images within CKEditor (with plugins) or still
+using RTEHtmlArea.
+
+Any TYPO3 installation triggering the CLI command, handling RTE images via EXT:impexp
+or directly handling functionality from the CLI command PHP class.
+
+
+Migration
+=========
+
+If necessary, it is recommended to add this functionality to a custom extension
+where this functionality can live on. It is important however, that most of the
+added functionality of TYPO3 in the last years was not supported (image cropping
+inside RTE was not possible via the Image Cropper of FAL).
+
+It is recommended to move all images within an RTE to proper relations, or to
+use extensions like `rte_ckeditor_image` from https://extensions.typo3.org.
+
+If any fork of RTEHtmlArea is still used in TYPO3 v10.0, the image functionality for
+SoftRefParser, CLI command and the processing mode should be added there.
+
+.. index:: CLI, PHP-API, RTE, PartiallyScanned

Documentation/Changelog/10.0/Breaking-88525-RemoveCreateDirsDirectiveOfExtensionInstallationEm_confphp.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88525:
+
+========================================================================================
+Breaking: #88525 - Remove "createDirs" directive of extension installation / em_conf.php
+========================================================================================
+
+See :issue:`88525`
+
+Description
+===========
+
+Every TYPO3 extension has a file called :file`ext_emconf.php` where important information regarding
+dependencies, current version and loading order are stored.
+
+The directive :php:`createDirs` that was responsible to create a list of folders in the file structure
+during extension installation has been dropped.
+
+The option was available before any File Abstraction Layer. As the :file:`uploads/` folder is not
+created by default by TYPO3 anymore, this directive is not supported anymore as well, as TYPO3 strives
+to support unified file handling for content files, volatile files (file uploads within :file:`typo3temp/var/`)
+or within Extensions directly. The Environment API, introduced in TYPO3 v9, should support for PHP-based
+APIs to choose / create a correct folder location.
+
+
+Impact
+======
+
+Extensions having this directive set will not have this folder available at installation time
+of the extension. The folder will not be created for newly installed extensions, existing extensions
+when upgrading from previous TYPO3 versions, will continue to exist.
+
+
+Affected Installations
+======================
+
+Any TYPO3 extension having this property within :file:`ext_emconf.php` set.
+
+
+Migration
+=========
+
+When an extension supports TYPO3 v10+ only, this directive can be removed.
+
+If an extension needs a special directory, this should be created via PHP when it is needed
+via e.g. :php:`GeneralUtility::mkdir_deep()`.
+
+.. index:: PHP-API, NotScanned, ext:extensionmanager

Documentation/Changelog/10.0/Breaking-88527-OverridingCustomValuesInUserAuthenticationDerivatives.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88527:
+
+==============================================================================
+Breaking: #88527 - Overriding custom values in User Authentication derivatives
+==============================================================================
+
+See :issue:`88527`
+
+Description
+===========
+
+Due to some restructuring of :php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication` and its direct sub-classes
+:php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication` (a.k.a. :php:`$BE_USER`) and :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication`,
+various settings are now directly initiated and set in the respective constructor of each PHP class.
+
+Following this, the properties :php:`sessionTimeout`, :php:`gc_time` and :php:`sessionDataLifetime` are set already
+when the constructor is called. Before this was the case when :php:`start()` was called.
+
+In addition, the property :php:`loginType` must be set for any subclass on instantiation. Previously
+this was possible to be set just before :php:`start()` was called.
+
+The previous behavior allowed to override certain parameters to be evaluated just before :php:`start()`.
+
+
+Impact
+======
+
+Setting any global variables between the constructor method and :php:`start()` will have no effect, as
+this is transferred and evaluated at the public properties already when the constructor is called.
+
+Subclassing :php:`AbstractUserAuthentication` without setting :php:`loginType` will trigger an exception
+on instantiation.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation where a custom UserAuthentication instantiation or sub-class is in place, and the setting
+order was changed between calling the constructor and the method :php:`start()`, which is considered a very rare case.
+
+
+Migration
+=========
+
+Consider using a proper subclass and a custom constructor method, or set all properties properly before
+the constructor is called (default values of class members).
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88540-ChangedRequestWorkflowForFrontendRequests.rst

@@ -0,0 +1,106 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88540:
+
+=================================================================
+Breaking: #88540 - Changed Request Workflow for Frontend Requests
+=================================================================
+
+See :issue:`88540`
+
+Description
+===========
+
+The "Frontend Request Workflow" is the PHP code responsible for
+setting up various functionality when the TYPO3 Frontend (= rendering of the website)
+is booted and the content is built. This includes Login/Permission Check, resolving
+the current site + language, and checking the page + rootline, then
+parsing TypoScript, which will then lead to building content (or taken from
+cache), until the actual output is returned.
+
+Since TYPO3 v9, this is all built via PSR-15 middlewares, the PSR-15 Request Handler,
+and the global TypoScriptFrontendController (TSFE).
+
+For TYPO3 v10.0, various changes were made in order to separate concerns / logic
+from each other, allowing to easily exchange certain components with
+other / extended functionality.
+
+The following changes have been made:
+
+Storing session data from a Frontend User Session / Anonymous session is now triggered within the Frontend User
+(`typo3/cms-frontend/authentication`) Middleware, at a later point - once the page was generated. Up until TYPO3 v9, this
+was part of the RequestHandler logic right after content was put together. This was due to legacy reasons of the
+previous hook execution order.
+
+Resolving the actual site - that is the site configuration plus the language - now happens before Frontend
+and Backend User Authentication. This is important to understand to be able to define further settings within
+Site Handling configuration in the future. Site and Site Language Resolving is now 100% independent of any permission
+settings. Evaluating if a language is active is evaluated separately.
+
+Backend User Authentication (:php:`$BE_USER`) is now started before Frontend User Authentication (`fe_user`), previously
+this was the other way around. Frontend Users are now stored in the request object via the `frontend.user` attribute,
+instead of :php:`$TSFE->fe_user`, until :php:`$TSFE` is instantiated.
+
+Once all site + permission/authentication functionality has been set up, Routing now tries to detect
+the target page ID and the URL parameters (`PageResolver` middleware) and evaluates the result, so-called
+"Page Arguments" directly afterwards (`PageArgumentValidator` middleware). This effectively validates the cHash
+logic.
+
+All of the mentioned parts above do not depend on :php:`TSFE` anymore. In fact, they are 100% independent of
+any TSFE-related code. :php:`TSFE` is instantiated after all site resolving, authentication, page resolving and argument
+validation is done.
+
+The new request workflow looks like this (simplified):
+
+#. Evaluation of Normalized Parameters (a.k.a. :php:`getIndpEnv`) & Evaluation of "Maintenance Mode" functionality
+#. Handling registered eID scripts depending on GET parameter `eID`
+#. Resolving Site configuration and Language from URL if possible
+#. Resolving logged-in Backend User Authentication for previewing hidden pages or languages
+#. Authentication of Website Users ("Frontend Users")
+#. Executing various static routes and redirect functionality
+#. Resolving Target Page ID and URL parameters based on Routing, Validation of Page Arguments based on "cHash"
+#. Setting up global :php:`$TSFE` object, injecting previously resolved settings into TSFE.
+#. Resolving the Rootline for the page
+#. Parsing and Evaluation of TypoScript Instructions to render the page content
+#. Build the content (cached / uncached)
+#. Return the Response (PSR-7) to the base application and output headers + content.
+
+In addition, :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` now expects the following constructor arguments:
+
+#. Context API object (previously a copy of :php:`$TYPO3_CONF_VARS`, until TYPO3 v8, then, unused)
+#. :php:`TYPO3\CMS\Core\Site\Entity\SiteInterface` object (previously the Page ID)
+#. :php:`TYPO3\CMS\Core\Site\Entity\SiteLanguage` object (previously the Page Type)
+#. :php:`TYPO3\CMS\Core\Routing\PageArguments` object (previously the no_cache GET parameter)
+#. :php:`TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication` object (previously the cHash parameter)
+
+Impact
+======
+
+Hooks that depend on certain functionality being made before or after a hook is
+called will likely have a different behavior when a Frontend Session is used within Hooks.
+
+Anything related to regular plugins / content / TypoScript is not affected.
+
+
+Affected Installations
+======================
+
+Any hooks from third party extensions that run
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_eofe']`
+and depend on the frontend session data being written.
+
+Any TYPO3 extensions using middlewares in the frontend.
+
+Migration
+=========
+
+Consider using a PSR-15 middleware instead of using a hook, or explicitly call :php:`storeSessionData()` within
+the PHP hook if necessary.
+
+If an existing middleware was used, ensure that it's loaded in TYPO3 v10 at the proper location, as the
+`typo3-cms/frontend/tsfe` middleware is loaded at a very late point.
+
+Ensure to use proper objects for the constructor arguments on :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` when instantiating
+the object on your own.
+
+.. index:: Frontend, PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88564-PageTSconfigSettingTSFEconstantsRemoved.rst

@@ -0,0 +1,45 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88564:
+
+================================================================
+Breaking: #88564 - PageTSconfig setting "TSFE.constants" removed
+================================================================
+
+See :issue:`88564`
+
+Description
+===========
+
+The PageTSconfig / UserTSconfig :typoscript:`TSFE.constants`, which allowed to override settings constants
+on a per-tree level page was introduced in TYPO3 at the very beginning, long before TSconfig had conditions.
+
+It was used to share TypoScript-based configuration between frontend / backend, and on a per-page/tree level.
+
+However, this has been superseded for a long time by using proper configuration files which
+can be loaded at any time, for example when :file:`ext_localconf.php` of an extension is loaded.
+
+Therefore, the option has been removed.
+
+
+Impact
+======
+
+Setting :typoscript:`TSFE.constants` in PageTSconfig or UserTSconfig has no effect, as it is not evaluated
+anymore.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation using :typoscript:`TSFE.constants` in their PageTSconfig.
+
+
+Migration
+=========
+
+It is recommended to include TypoScript conditions in setup/constants, also since constants+setup
+are evaluated in Backend context for Extbase modules. This option is not needed anymore and
+can be substituted by simple constants in `sys_template` or any Extension inclusion files as well.
+
+.. index:: TSConfig, NotScanned

Documentation/Changelog/10.0/Breaking-88574-4thParameterOfPageRepository-enableFieldsRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88574:
+
+========================================================================
+Breaking: #88574 - 4th parameter of PageRepository->enableFields removed
+========================================================================
+
+See :issue:`88574`
+
+Description
+===========
+
+The fourth parameter of :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository->enableFields()` was meant to filter out versioned records
+which are in Live Workspace (versioning, not workspaces). Although the method has largely been superseded
+with Doctrine DBAL's Restrictions, it is still used in some places.
+
+With the introduction of the Context API, new PageRepository instances can be created to fetch multiple variants
+of certain aspects, instead of modifying existing public properties. Therefore the fourth argument has been removed.
+
+
+Impact
+======
+
+Calling the method above with the fourth parameter set to true has no effect anymore, and will
+trigger a PHP :PHP:`E_NOTICE` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation dealing with non-workspace versioning in Frontend requests with third-party extension
+still relying on non-workspace versioning.
+
+
+Migration
+=========
+
+The fourth parameter on any method call can be removed (if set to "false"), or should be replaced with a
+separate instance of :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository` with a custom Context.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/10.0/Breaking-88583-DatabaseFieldSys_languagestatic_lang_isocodeRemoved.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88583:
+
+==========================================================================
+Breaking: #88583 - Database field sys_language.static_lang_isocode removed
+==========================================================================
+
+See :issue:`88583`
+
+Description
+===========
+
+The database field :sql:`static_lang_isocode` is a reference to a language within the third-party
+extension `static_info_tables`. This was tightly coupled to TYPO3 Core until Site Handling was
+introduced to add meaning and meta-data to a language on a per-site level.
+
+The field is not in use by the TYPO3 Core anymore, so the database definition is removed as well.
+
+
+Impact
+======
+
+Migrating to TYPO3 v10.0 will remove the field in the Database Analyzer.
+
+
+Affected Installations
+======================
+
+Multilingual TYPO3 installations without the TYPO3 Extension `static_info_tables` but with usages of the
+database field, which is very unlikely.
+
+
+Migration
+=========
+
+The field can safely be removed in the Database Analyzer if it is not used by an extension.
+
+If the field is still needed, it is recommended to install the extension `static_info_tables`.
+
+If the data from the database field is used, it is recommended to fetch all metadata for a language
+via the Site Configuration and the `SiteLanguage` API instead.
+
+.. index:: Database, NotScanned

Documentation/Changelog/10.0/Breaking-88638-StreamlinedSoftRefParserReferenceLookup.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88638:
+
+=============================================================
+Breaking: #88638 - Streamlined SoftRefParser reference lookup
+=============================================================
+
+See :issue:`88638`
+
+Description
+===========
+
+The Soft Reference Parser is a registry to allow to find parsers (PHP Objects),
+for a given Parser Type (images, internal links, email links) to keep track of
+referenced records within arbitrary data (e.g. RTE text-fields).
+
+Parsers can be added or overridden via the hook registry
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['GLOBAL']['softRefParser'][$parserType]`.
+
+Previously, the API method for fetching the proper parsers
+:php:`TYPO3\CMS\Backend\Utility\BackendUtility::softRefParserObj()` kept a runtime cache of created objects
+per type within a global PHP array (:php:`T3_VAR`). This allowed to create objects
+only once, even if there are multiple necessary parts required.
+
+TYPO3's Core SoftRefParser does not keep any state, but the class now has a
+:php:`SingletonInterface`, which means that the object is now a re-used object
+as before.
+
+
+Impact
+======
+
+Calling the SoftRefParser factory method does not keep state of the parser
+objects via :php:`$GLOBALS['T3_VAR']['softRefParser']` anymore.
+
+Instead, :php:`SingletonInterface` is recommended for re-using SoftRefParser objects
+if they need to keep state.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions that use the API with custom parsers,
+or the global variable directly.
+
+
+Migration
+=========
+
+Replace the global variable access via the API call to :php:`TYPO3\CMS\Backend\Utility\BackendUtility`, if this
+is applicable.
+
+If a custom parser is in use, it is recommended to evaluate whether it contains
+re-usable data and switch to :php:`SingletonInterface` instead.
+
+.. index:: Backend, FullyScanned

Documentation/Changelog/10.0/Breaking-88640-DatabaseFieldSys_templatenextLevelAndTypoScriptSublevel-InheritanceRemoved.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88640:
+
+========================================================================================================
+Breaking: #88640 - Database field "sys_template.nextLevel" and TypoScript sublevel - inheritance removed
+========================================================================================================
+
+See :issue:`88640`
+
+Description
+===========
+
+The database field :sql:`nextLevel` of the database table :sql:`sys_template` where TypoScript configuration
+is stored, has been removed.
+
+The field :sql:`nextLevel` was introduced in TYPO3 v3.x before TypoScript could be imported from
+external files.
+
+Nowadays, TypoScript conditions should be used much more instead of this :sql:`nextLevel` feature,
+which is kind of a pseudo-condition.
+
+
+Impact
+======
+
+The database field is removed, and not evaluated anymore in TypoScript compilation.
+
+Requesting the database field in custom database queries will result in an SQL error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations that have :sql:`sys_template` records with this flag activated,
+or querying this database field in third-party extensions.
+
+
+Migration
+=========
+
+Check for existing :sql:`sys_template` records having this flag activated by executing
+this SQL command:
+
+:sql:`SELECT * FROM sys_template WHERE nextLevel>0 AND deleted=0;`
+
+before updating TYPO3 Core.
+
+Replace the sys_template record (the uid of the record is stored in the "nextLevel" field) with a condition e.g. :typoscript:`[tree.level > 1]` to add TypoScript for subpages.
+
+.. index:: Database, NotScanned

Documentation/Changelog/10.0/Breaking-88643-RemovedSwiftmailerswiftmailerDependency.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88643:
+
+=============================================================
+Breaking: #88643 - Removed swiftmailer/swiftmailer dependency
+=============================================================
+
+See :issue:`88643`
+
+Description
+===========
+
+TYPO3's dependency swiftmailer has been removed in favor of new symfony-based
+components "mime" and "mailer".
+
+This means that all SwiftMailer-related PHP code has been removed.
+
+
+Impact
+======
+
+Custom SwiftMailer plugins or transports cannot be used without further
+migration anymore and will result in a fatal :php:`E_ERROR`.
+
+Using SwiftMailer-specific API by using TYPO3's :php:`TYPO3\CMS\Core\Mail\MailMessage` class might result
+in fatal :php:`E_ERROR` when sending out emails.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extension sending out emails or extending
+TYPO3's email sending capabilities.
+
+
+Migration
+=========
+
+Search the third-party extensions' code for occurrences of MailMessage or
+parts starting with `\Swift_` and migrate to symfony/mime or symfony/mailer
+APIs, which are included in TYPO3 v10.0.
+
+If required, SwiftMailer code can be installed via composer (when running TYPO3 via composer)
+via `composer require swiftmailer/swiftmailer`.
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/10.0/Breaking-88646-RemovedInheritanceOfAbstractServiceFromAbstractAuthenticationService.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88646:
+
+============================================================================================
+Breaking: #88646 - Removed inheritance of AbstractService from AbstractAuthenticationService
+============================================================================================
+
+See :issue:`88646`
+
+Description
+===========
+
+The PHP :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService` class is used for any kind of Authentication
+or Authorization towards Backend Users and Frontend Users.
+
+It was previously based on :php:`TYPO3\CMS\Core\Service\AbstractService` for any kind of Service API, which
+also includes manipulating files and execution of external applications, which is
+there for legacy reasons since TYPO3 3.x, where the Service API via :php:`GeneralUtility::makeInstanceService` was added.
+
+In order to refactor the Authentication API, the :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService`
+class does not inherit from :php:`TYPO3\CMS\Core\Service\AbstractService` anymore. Instead, the most required
+methods for executing a service is added to the Abstract class directly.
+
+
+Impact
+======
+
+Any calls or checks on the :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService` class or methods, properties or constants that reside within
+:php:`TYPO3\CMS\Core\Service\AbstractService` will result in PHP :php:`E_ERROR` or :php:`E_WARNING`.
+
+Since :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService` is used for most custom Authentication APIs,
+this could affect some of the hooks or custom authentication providers available.
+
+
+Affected Installations
+======================
+
+TYPO3 installations that have custom Authentication providers for frontend or backend
+users / groups - e.g. LDAP or Two-Factor-Authentication.
+
+
+Migration
+=========
+
+If your custom Authentication Service extends from :php:`TYPO3\CMS\Core\Authentication\AbstractAuthenticationService`
+but requires methods or properties from :php:`TYPO3\CMS\Core\Service\AbstractService`, ensure to copy over the
+necessary methods/properties/constants into your custom Authentication provider.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88657-PopupConfigurationInFormEngineDropped.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88657:
+
+============================================================
+Breaking: #88657 - Popup configuration in FormEngine dropped
+============================================================
+
+See :issue:`88657`
+
+Description
+===========
+
+The options :typoscript:`options.popupWindowSize` and :typoscript:`options.rte.popupWindowSize` used to configure popup sizes have been
+removed.
+
+
+Impact
+======
+
+These options are not evaluated anymore.
+
+
+Affected Installations
+======================
+
+All installations using 3rd party extensions relying on the options are affected.
+
+
+Migration
+=========
+
+In most cases it's fine to remove the configuration.
+
+In the unlikely case one is negatively affected by this change, fetch the configuration from backend user's TSConfig and
+use it where it is required.
+
+.. index:: Backend, RTE, TSConfig, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88660-GLOBALST3_VARRemoved.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88660:
+
+===========================================
+Breaking: #88660 - $GLOBALS[T3_VAR] removed
+===========================================
+
+See :issue:`88660`
+
+Description
+===========
+
+The global variable :php:`$GLOBALS['T3_VAR']` previously used to hold global state for special
+use cases - previously used within Service API via :php:`GeneralUtility::makeInstanceService()`
+and to magically inject special hard-coded local indexed search files, has been removed.
+
+The overall goal of TYPO3's application is to not keep any state within global variables, and
+the :php:`T3_VAR` ("TYPO3 Various") has not been actively used for that anymore since TYPO3 6.0, and
+has been kept only for backwards-compatibility of the existing solutions.
+
+The initialization of the global variable during TYPO3 Bootstrap, any usages of :php:`T3_VAR`,
+especially within "indexed search" has been removed.
+
+
+Impact
+======
+
+Accessing :php:`$GLOBALS['T3_VAR']` is fully custom and not evaluated by TYPO3 Core anymore.
+
+Using the variable to modify any global state for e.g. Indexed Search's indexer via
+:php:`$GLOBALS['T3_VAR']['ext']['indexed_search']['indexLocalFiles']` is not respected anymore
+and has no effect.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions or code within :file:`AdditionalConfiguration.php`
+that actively set or read values from the global variable.
+
+
+Migration
+=========
+
+Use your own custom global namespace to identify that your specific extension code has nothing
+to do with TYPO3's legacy work.
+
+Use specific hooks for indexing local files used by download extensions in conjunction with
+Indexed Search.
+
+.. index:: PHP-API, FullyScanned, ext:indexed_search

Documentation/Changelog/10.0/Breaking-88667-RemovedAdditionalJavaScriptSubmitFromFormEngine.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88667:
+
+=====================================================================
+Breaking: #88667 - Removed additionalJavaScriptSubmit from FormEngine
+=====================================================================
+
+See :issue:`88667`
+
+Description
+===========
+
+FormEngine had the feature to add additional submit handlers via the option :php:`additionalJavaScriptSubmit`, that can
+be set by form element renderables. TYPO3 uses RequireJS and a rewritten FormEngine since version 7, the property
+:php:`additionalJavaScriptSubmit` has been removed.
+
+Additional, functions of :js:`TBE_EDITOR` that are associated with that feature (namely :js:`addActionChecks`) were removed as well.
+
+
+Impact
+======
+
+The option has no effect anymore, the code won't get executed at all.
+
+
+Affected Installations
+======================
+
+All 3rd-party extensions using this option are affected.
+
+
+Migration
+=========
+
+It is possible to create and register an AMD module.
+
+.. code-block:: php
+
+   $resultArray['requireJsModules'][] = 'TYPO3/CMS/MyExtension/SubmitHandler';
+
+
+.. code-block:: javascript
+
+   // typo3conf/ext/my_extension/Resources/Public/JavaScript/SubmitHandler.js
+   define(['TYPO3/CMS/Backend/DocumentSaveActions'], function (DocumentSaveActions) {
+     DocumentSaveActions.getInstance().addPreSubmitCallback(function (e) {
+       // e is the submit event
+       // Do stuff here
+
+       // e.stopPropagation() stops the execution chain
+     });
+   });
+
+
+.. index:: Backend, JavaScript, PHP-API, NotScanned, ext:backend

Documentation/Changelog/10.0/Breaking-88669-FormEngineFormDataProviderParentPageTcaRemoved.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88669:
+
+======================================================================
+Breaking: #88669 - FormEngine FormDataProvider "parentPageTca" removed
+======================================================================
+
+See :issue:`88669`
+
+Description
+===========
+
+FormEngine added :php:`parentPageTca` by default to the result object. It was added in TYPO3 v7 during
+refactoring, but already commented that it wasn't used at all in Core, and might not be necessary.
+
+It contained a copy of :php:`$GLOBALS['TCA']['pages']`, which can be obtained directly as well.
+
+The DataProvider and the value within the result key has been removed.
+
+
+Impact
+======
+
+When accessing the :php:`parentPageTca` key within a FormDataProvider or Node (FormEngine-related only),
+a PHP notice is given due to a non-existing array key.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom FormDataProviders for FormEngine relying on the "parentPageTca"
+DataProvider, which is highly unlikely.
+
+
+Migration
+=========
+
+Instead of accessing :php:`$result['parentPageTca']` within a custom FormDataProvider or FormRenderNode,
+:php:`$GLOBALS['TCA']['pages']` can be accessed directly.
+
+.. index:: TCA, NotScanned

Documentation/Changelog/10.0/Breaking-88681-ImportOfPHPFilesInImportExportFilesRemoved.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88681:
+
+=====================================================================
+Breaking: #88681 - Import of PHP files in Import/Export files removed
+=====================================================================
+
+See :issue:`88681`
+
+Description
+===========
+
+Importing XML data via EXT:impexp previously allowed to import PHP files for Administrators
+in TYPO3 Backend. This by-pass functionality is removed, and the configured File Deny Pattern
+now applies for all imports in order to streamline import functionality with other file
+operations within TYPO3 Core.
+
+
+Impact
+======
+
+Importing XML files with embedded PHP files via EXT:impexp will trigger an import error and disallow
+the import of the file.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations using the data importer that use import files with included PHP files.
+
+
+Migration
+=========
+
+Ensure to include PHP files into a custom local extension, as importing PHP code is highly
+discouraged - even for administrators.
+
+.. index:: PHP-API, NotScanned, ext:impexp

Documentation/Changelog/10.0/Breaking-88687-ConfigureExtbaseRequestHandlersViaPHP.rst

@@ -0,0 +1,69 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88687:
+
+=============================================================
+Breaking: #88687 - Configure extbase request handlers via PHP
+=============================================================
+
+See :issue:`88687`
+
+Description
+===========
+
+The configuration of extbase request handlers is no longer possible via typoscript.
+All typoscript concerning the configuration of request handlers needs to be converted to php, residing
+in :file:`EXT:Configuration/Extbase/RequestHandlers.php`.
+
+
+Impact
+======
+
+Unless converted to php, the configuration in typoscript does no longer have any effect and therefore the registration
+of request handlers will no longer work.
+
+
+Affected Installations
+======================
+
+All installations that configure request handlers via typoscript.
+
+
+Migration
+=========
+
+Every extension that used typoscript for such configuration must provide a php configuration class called:
+:file:`EXT:Configuration/Extbase/RequestHandlers.php`
+
+The migration is best described by an example:
+
+.. code-block:: typoscript
+
+   config.tx_extbase {
+       mvc {
+           requestHandlers {
+               Vendor\Extension\Mvc\Web\FrontendRequestHandler = Vendor\Extension\Mvc\Web\FrontendRequestHandler
+           }
+       }
+   }
+
+This configuration will look like this, defined in php:
+
+.. code-block:: php
+
+   <?php
+   declare(strict_types = 1);
+
+   return [
+       \Vendor\Extension\Mvc\Web\FrontendRequestHandler::class,
+   ];
+
+.. warning::
+
+   With typoscript it was possible to override request handlers, registered by extensions loaded before the current one.
+   This also included core extensions. This approach has been bad practice because suitable request handlers are chosen
+   by their ability to handle a request and their priority. The evaluation of priorities could have been bypassed by
+   overriding keys of the configuration. This is no longer possible as request handler configuration files can only
+   add possible request handlers. Hence the omitted keys in the configuration array.
+
+.. index:: TypoScript, NotScanned, ext:extbase

Documentation/Changelog/10.0/Breaking-88706-StreamlineFeloginLocallangKeys.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88706:
+
+====================================================
+Breaking: #88706 - Streamline felogin locallang keys
+====================================================
+
+See :issue:`88706`
+
+Description
+===========
+
+Remove  `ll_` prefixes from translation keys in :file:`ext:felogin/Resources/private/Language/locallang.xlf` so that they share the same identifiers with the flexform settings.
+
+
+Impact
+======
+
+Breaks installations that override ext:felogin language keys that are prefixed with `ll_`.
+
+
+Affected Installations
+======================
+
+Only installations that override one of the following keys via TypoScript are affected.
+
+Keys:
+
+- `ll_welcome_header`
+- `ll_welcome_message`
+- `ll_logout_header`
+- `ll_logout_message`
+- `ll_error_header`
+- `ll_error_message`
+- `ll_success_header`
+- `ll_success_message`
+- `ll_status_header`
+- `ll_status_message`
+- `ll_change_password_header`
+- `ll_change_password_message`
+- `ll_change_password_nolinkprefix_message`
+- `ll_change_password_notvalid_message`
+- `ll_change_password_notequal_message`
+- `ll_change_password_tooshort_message`
+- `ll_change_password_done_message`
+- `ll_forgot_header`
+- `ll_forgot_email_password`
+- `ll_forgot_email_nopassword`
+- `ll_forgot_validate_reset_password`
+- `ll_forgot_message`
+- `ll_forgot_message_emailSent`
+- `ll_forgot_reset_message`
+- `ll_forgot_reset_message_emailSent`
+- `ll_forgot_reset_message_error`
+- `ll_forgot_header_backToLogin`
+- `ll_enter_your_data`
+
+
+Migration
+=========
+
+Remove the `ll_` prefix from the key.
+
+.. index:: Frontend, NotScanned, ext:felogin

Documentation/Changelog/10.0/Breaking-88724-RemoveSuperfluousMethodsOfLocalizationRedirect.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88724:
+
+=====================================================================
+Breaking: #88724 - Remove superfluous methods of localizationRedirect
+=====================================================================
+
+See :issue:`88724`
+
+Description
+===========
+
+The method :php:`localizationRedirect` in PageLayoutView, DatabaseRecordList and EditDocumentController were almost equal.
+The usage has been streamlined and the methods in PageLayoutView and DatabaseRecordList have been removed.
+
+
+Impact
+======
+
+Calling the routes `web_layout` or `web_list` with parameter `justLocalized` will not redirect to the translated record anymore.
+Calling :php:`TYPO3\CMS\Backend\View\PageLayoutView->localizationRedirect` or :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList->localizationRedirect`
+will result in a fatal :php:`E_ERROR`.
+
+
+Migration
+=========
+
+Use route `record_edit` instead of `web_layout` or `web_list`. Set as additional parameter `returnUrl` to the url to the certain module.
+Use :php:`TYPO3\CMS\Backend\Controller\EditDocumentController->localizationRedirect` instead of
+:php:`TYPO3\CMS\Backend\View\PageLayoutView->localizationRedirect` or :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/10.0/Breaking-88741-CHashCalculationInIndexedSearchRemoved.rst

@@ -0,0 +1,62 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88741:
+
+==============================================================
+Breaking: #88741 - cHash calculation in indexed search removed
+==============================================================
+
+See :issue:`88741`
+
+Description
+===========
+
+When indexing a page, the indexer of `Indexed search` previously kept the used cHash and the
+used "cHashParams" for storing search entries. This is not necessary anymore, as Site Handling now
+contains the relevant arguments already in the search entry as well. This can be removed now.
+
+In addition, when setting up an Indexing configuration, the option to respect cHash is removed,
+as this is done automatically when needed.
+
+The public property :php:`TYPO3\CMS\IndexedSearch\Indexer->cHashParams` has been removed.
+
+The sixth method argument of :php:`TYPO3\CMS\IndexedSearch\Indexer->backend_initIndexer()`
+has been removed.
+
+The following database fields are unused and have been removed:
+
+* :sql:`index_config.chashcalc`
+* :sql:`index_phash.cHashParams`
+
+The database field :sql:`index_debug.debuginfo` now contains data stored in a JSON-formatted string
+instead of a serialized PHP string.
+
+
+Impact
+======
+
+Manual database queries accessing the database fields will result in SQL errors.
+
+In addition, accessing the removed property or using the sixth argument of the changed public method
+will have no effect anymore.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using Indexed Search and custom configuration or extending functionality
+of Indexed Search.
+
+
+Migration
+=========
+
+No migration needed, as everything works as before. The data is now stored in
+the database field as JSON-encoded string `index_phash.static_page_arguments`.
+
+In case of using debug information for Indexed Search (index with enabled debug information),
+where data was previously stored in `index_debug.debuginfo` as serialized PHP string,
+indexing needs to be rebuilt, but only to render the debug information properly in the TYPO3 Backend
+module. If debug information is not enabled, re-indexing is not necessary.
+
+.. index:: Database, PHP-API, PartiallyScanned, ext:indexed_search

Documentation/Changelog/10.0/Breaking-88744-DatabaseFieldsRelatedToCSSStyledContentRemoved.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88744:
+
+========================================================================
+Breaking: #88744 - Database fields related to CSS Styled Content removed
+========================================================================
+
+See :issue:`88744`
+
+Description
+===========
+
+CSS Styled Content was superseded with Fluid Styled Content in TYPO3 v7, and support was dropped
+with TYPO3 v9. TYPO3 Core still shipped with some database fields that were kept to easy
+manual migration for specific values in these fields.
+
+These database fields within the database table :sql:`tt_content` have been removed.
+
+* :sql:`tt_content.spaceBefore` (now used via space_before_class)
+* :sql:`tt_content.spaceAfter` (now used via space_after_class)
+
+
+Impact
+======
+
+Accessing the database fields with a custom SQL query will result in SQL errors or empty values.
+
+
+Affected Installations
+======================
+
+TYPO3 installations from earlier TYPO3 versions (prior to v8) that still have CSS Styled Content
+in use or adopted to migrate the fields to still render via CSS Styled Content.
+
+Additionally, TYPO3 installations that mis-used the database fields for other purposes but
+still rely on the presence of the database fields.
+
+
+Migration
+=========
+
+If the database fields still contain value that hasn't been migrated, it is possible to re-add
+these database fields in a custom extension.
+
+It is recommended to switch to Fluid Styled Content rendering or custom content types with
+custom additional fields.
+
+.. index:: Database, Frontend, NotScanned, ext:frontend

Documentation/Changelog/10.0/Breaking-88755-RemovePOSTOptionFromTypolinkaddQueryStringmethod.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88755:
+
+=========================================================================
+Breaking: #88755 - Remove POST option from typolink.addQueryString.method
+=========================================================================
+
+See :issue:`88755`
+
+Description
+===========
+
+Setting :typoscript:`addQueryString.method` of typolink could be used like shown below in order to transform
+HTTP POST parameters into according GET parameters.
+
+.. code-block:: typoscript
+
+   typolink {
+     parameter = 123
+     addQueryString = 1
+     addQueryString.method = POST
+   }
+
+In terms of correctly using HTTP verbs it's bad practise in general to treat GET and POST equally, besides that
+documentation already mentioned potential side-effects like accidentally exposing sensitive data submitted via
+POST to proxies or log files.
+
+That's why values :typoscript:`POST`, :typoscript:`GET,POST` and :typoscript:`POST,GET` are not allowed anymore
+for :typoscript:`typolink.addQueryString.method`. Maintaining functionality - if required at all - has to be done
+using domain specific logic in according controllers or middleware implementations.
+
+
+Impact
+======
+
+* using :typoscript:`GET,POST`, :typoscript:`POST,GET` or :typoscript:`POST` will trigger an :php:`E_USER_WARNING`
+* using :typoscript:`GET,POST` or :typoscript:`POST,GET` will fall back to :typoscript:`GET`
+* using :typoscript:`POST` will be ignored and an empty result
+
+In a consequence only query parameters submitted via HTTP GET are taken into account, parameters of HTTP POST
+body are ignored.
+
+
+Affected Installations
+======================
+
+* TypoScript defining :typoscript:`typolink.addQueryString.method` with values mentioned in previous section
+* invocations of :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryStringMethod()` with values
+  mentioned in previous section
+* as an effect Fluid view helpers forwarding this information to
+  :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder::setAddQueryStringMethod()` are affected -
+  argument :php:`addQueryStringMethod` is affected in view helper of TYPO3 core like shown below
+  + :html:`<f:form ... addQueryStringMethod="POST">`
+  + :html:`<f:link.action addQueryStringMethod="POST">`
+  + :html:`<f:link.page ... addQueryStringMethod="POST">`
+  + :html:`<f:link.typolink addQueryStringMethod="POST">`
+  + :html:`<f:uri.action ... addQueryStringMethod="POST">`
+  + :html:`<f:uri.page ... addQueryStringMethod="POST">`
+  + :html:`<f:uri.typolink addQueryStringMethod="POST">`
+  + :html:`<f:widget.uri ... addQueryStringMethod="POST">`
+  + :html:`<f:widget.link addQueryStringMethod="POST">`
+  + :html:`<f:widget.paginate ... configuration="{addQueryStringMethod: 'POST'}">`
+
+
+Migration
+=========
+
+* change to mentioned assignments in TypoScript, Fluid templates or PHP code to :typoscript:`GET`
+* analyse and try to understand whether :typoscript:`POST` is still required or could be substituted
+
+
+.. index:: Backend, Fluid, Frontend, PHP-API, TypoScript, NotScanned

Documentation/Changelog/10.0/Breaking-88758-SelectiveConcatenationOfCSSFilesInResourceCompressorRemoved.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88758:
+
+=====================================================================================
+Breaking: #88758 - Selective Concatenation of CSS files in ResourceCompressor removed
+=====================================================================================
+
+See :issue:`88758`
+
+Description
+===========
+
+:php:`TYPO3\CMS\Core\Resource\ResourceCompressor`, used to merge and compress CSS and JS files, has had an option to only
+merge CSS files from selected folders. This was used to limit CSS files of skins for TYPO3
+Backend files.
+
+The functionality has been removed, as all added CSS files are now merged into one file.
+
+As TYPO3 Frontend and TypoScript has a much more flexible system for adding CSS files,
+which should be concatenated, this change does not affect TYPO3 API of Frontend Requests.
+
+
+Impact
+======
+
+Calling :php:`TYPO3\CMS\Core\Resource\ResourceCompressor->concatenateCssFiles()` with a second argument has no effect anymore.
+
+Adding CSS files manually in TYPO3 Backend via custom extensions will now automatically be merged
+with the loaded CSS styles of :php:`$TBE_STYLES` skin.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions adding third-party CSS files in the TYPO3 Backend,
+or extensions using :php:`TYPO3\CMS\Core\Resource\ResourceCompressor` directly.
+
+
+Migration
+=========
+
+None, as it is considered to be useful to have one larger CSS file for TYPO3 Backend.
+
+If necessary, add a CSS file manually via PageRenderer API which should be excluded from Concatenation.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Breaking-88772-JavaScriptScriptTagsOmitTypetextjavascriptInHTML5.rst

@@ -0,0 +1,56 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88772:
+
+============================================================================
+Breaking: #88772 - JavaScript script tags omit type=text/javascript in HTML5
+============================================================================
+
+See :issue:`88772`
+
+Description
+===========
+
+When rendering HTML5 output, :html:`<script>` tags do not the additional attribute :html:`type=text/javascript`
+anymore as it is considered optional, and if none given, modern browsers fall back to this type
+already.
+
+See the official W3C definition here: https://www.w3.org/TR/html52/semantics-scripting.html#element-attrdef-script-type
+
+For this reason, all of TYPO3's Backend (which is rendering HTML5) and Installer do not include
+this optional attribute in :html:`<script>` tags anymore.
+
+For TYPO3 Frontend rendering, the attribute is omitted when having no doctype or HTML5 as doctype
+configured (via TypoScript :typoscript:`config.doctype = html5`). This leads to a minimal smaller
+HTML document submitted to the client.
+
+For any XHTML or HTML4-based website, the attribute is still added.
+
+
+Impact
+======
+
+TYPO3's Frontend rendering does not render :html:`type=text/javascript` anymore in :html:`<script>` tags when
+rendering a HTML5 output, unless explicitly specified.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation running a HTML5-based frontend output.
+
+
+Migration
+=========
+
+As all modern browsers do not need this tag, and the specification says it's optional, there is
+no migration needed at all.
+
+If still requested by a specific project, it can be added via:
+
+.. code-block:: javascript
+
+   page.includeJS.myfile = EXT:site_mysite/Resources/Public/JavaScript/myfile.js
+   page.includeJS.myfile.type = text/javascript
+
+.. index:: Frontend, TypoScript, NotScanned

Documentation/Changelog/10.0/Breaking-88779-RecordListRemoveUnusedCode.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88779:
+
+=================================================
+Breaking: #88779 - RecordList: Remove unused code
+=================================================
+
+See :issue:`88779`
+
+Description
+===========
+
+The following public properties have been removed from :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`:
+
+* :php:`modSharedTSconfig`
+* :php:`no_noWrap`
+* :php:`setLMargin`
+* :php:`JScode`
+* :php:`leftMargin`
+
+The following public methods have been removed from :php:`TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`:
+
+* :php:`getButtons`
+* :php:`thumbCode`
+* :php:`requestUri`
+* :php:`writeTop`
+* :php:`fwd_rwd_nav`
+* :php:`fwd_rwd_HTML`
+
+
+Impact
+======
+
+Calling one of the mentioned methods will trigger a fatal :php:`E_ERROR`.
+
+
+Migration
+=========
+
+Use :php:`BackendUtility::thumbCode` instead of :php:`thumbCode`. Use :php:`listURL` instead of :php:`requestUri`.
+
+.. index:: PHP-API, FullyScanned, ext:recordlist

Documentation/Changelog/10.0/Breaking-88799-IntroducedPSR-3CompatibleLoggingAPI.rst

@@ -0,0 +1,80 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-88799:
+
+==========================================================
+Breaking: #88799 - Introduced PSR-3 compatible Logging API
+==========================================================
+
+See :issue:`88799`
+
+Description
+===========
+
+With the adaption of the PSR-3 standard some PHP code had to be changed in order to reach compliance.
+The key difference is that log levels are now represented by strings rather than numbers. Note that the order
+of log levels is not affected and stays the same.
+
+The breaking changes mostly affect internal functionality and should not apply to third-party extensions.
+
+
+Impact
+======
+
+The class :php:`\TYPO3\CMS\Core\Log\LogLevel` now extends from the PSR-3 base class and therefore inherits the new definition
+of the log levels (`EMERGENCY` to `DEBUG`) based on string values.
+
+The signatures of following methods have been adjusted to accept the new :php:`LogLevel::*` constants:
+
+* :php:`\TYPO3\CMS\Core\Log\Logger::addWriter`
+* :php:`\TYPO3\CMS\Core\Log\Logger::addProcessor`
+
+The internal storage of the log level inside :php:`\TYPO3\CMS\Core\Log\LogRecord` has been adjusted, consequently the methods
+
+* :php:`setLevel()` and
+* :php:`getLevel()`
+
+respectively accept and return :php:`string` values now.
+
+In case you have configured own logger or log targets, you have to adjust the integer level and use strings.
+
+Example:
+
+.. code-block:: php
+
+   # old configuration
+   $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['writerConfiguration'] = [
+      7 => [
+         \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
+            'logFile' => 'typo3temp/var/log/core.log'
+         ]
+      ],
+   ];
+
+   # new configuration
+   $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['writerConfiguration'] = [
+      'debug' => [
+         \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
+            'logFile' => 'typo3temp/var/log/core.log'
+         ]
+      ],
+   ];
+
+In case you have used the constants like :php:`LogLevel::DEBUG` you are fine and your config will work like before.
+
+
+Affected Installations
+======================
+
+Any installation using third-party extensions interacting with the internals of the Logging API.
+
+
+Migration
+=========
+
+There are two easy ways to convert the integer to the string representation and vice versa:
+
+- Convert from integer to string: :php:`$logLevel = LogLevel::getInternalName($logLevelAsNumber)`
+- Convert from string to integer: :php:`$logLevelAsNumber = LogLevel::normalizeLevel($logLevel)`
+
+.. index:: PHP-API, NotScanned, ext:core

Documentation/Changelog/10.0/Deprecation-80420-EmailFinisherSingleAddressOptions.rst

@@ -0,0 +1,157 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-80420:
+
+==========================================================
+Deprecation: #80420 - EmailFinisher single address options
+==========================================================
+
+See :issue:`80420`
+
+Description
+===========
+
+The :php:`EmailFinisher` of EXT:form has options to set multiple recipients for :code:`To`, :code:`CC` and :code:`BCC`.
+For consistency reasons and to limit the number of choices, resulting in easier configuration, the single value configuration options
+have will be removed in favour for their respective multi value variants.
+
+For this reason, the following options have been marked as deprecated and will be removed in TYPO3 11.0:
+
+* :yaml:`recipientAddress`
+* :yaml:`recipientName`
+* :yaml:`replyToAddress`
+* :yaml:`carbonCopyAddress`
+* :yaml:`blindCarbonCopyAddress`
+
+If any of these options are used, their values will be automatically migrated to their replacements.
+
+Opening and saving a form with the form editor once also performs this migration and makes it permanent.
+
+
+Impact
+======
+
+Any of these options will no longer work in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and its :php:`EmailFinisher`.
+
+
+Migration
+=========
+
+All single value options must be migrated to their list value successors.
+
+
+Multiple Recipients
+-------------------
+
+Change :yaml:`recipientAddress` and :yaml:`recipientName` to :yaml:`recipients`.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         recipientAddress: to@example.org
+         recipientName: 'To Example'
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         recipients:
+           to@example.org: 'To Example'
+
+
+Multiple Reply-To Recipients
+----------------------------
+
+Change :yaml:`replyToAddress` to :yaml:`replyToRecipients`. Additionally this allows for setting the name of a Reply-To recipient.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         replyToAddress: rt@example.org
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         replyToRecipients:
+           rt@example.org@example.org: 'Reply-To Example'
+
+
+Multiple Carbon Copy (CC) Recipients
+------------------------------------
+
+Change :yaml:`carbonCopyAddress` to :yaml:`carbonCopyRecipients`. Additionally this allows for setting the name of a CC recipient.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         carbonCopyAddress: cc@example.org
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         carbonCopyRecipients:
+           cc@example.org: 'CC Example'
+
+
+Multiple Blind Carbon Copy (BCC) Recipients
+-------------------------------------------
+
+Change :yaml:`blindCarbonCopyAddress` to :yaml:`blindCarbonCopyRecipients`. Additionally this allows for setting the name of a BCC recipient.
+
+Before:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         blindCarbonCopyAddress: bcc@example.org
+
+After:
+
+.. code-block:: yaml
+
+   finishers:
+     -
+       identifier: EmailToReceiver
+       options:
+         blindCarbonCopyRecipients:
+           bcc@example.org: 'BCC Example'
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/10.0/Deprecation-82669-StreamlineBackendRoutePathInconsistencies.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-82669:
+
+===================================================================
+Deprecation: #82669 - Streamline Backend route path inconsistencies
+===================================================================
+
+See :issue:`82669`
+
+Description
+===========
+
+When registering Backend modules, it is already possible to define a custom route path, via the :php:`path`
+option in the module configuration section within :file:`ext_tables.php`.
+
+Backend Routes to modules without path configurations are now named using the pattern
+"/module/<main-module-name>/<submodule-name>" e.g. `/module/web/ts`.
+
+Old route paths for modules are called "/web/ts/" will still work but are discouraged to use.
+
+
+Impact
+======
+
+Creating modules without a defined "path" option will now have two path routes available to be
+resolved, whereas the old path will be removed in TYPO3 v10.0.
+
+
+Affected Installations
+======================
+
+Any installation using TYPO3 Backend Links via :php:`TYPO3\CMS\Backend\Routing\UriBuilder->buildUriFromRoutePath()` in custom extensions.
+
+
+Migration
+=========
+
+TYPO3 Backend Links via :php:`TYPO3\CMS\Backend\Routing\UriBuilder->buildUriFromRoutePath()` should be used with the new module name as
+described above.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-85895-DeprecateFile_getMetaData.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85895:
+
+====================================================
+Deprecation: #85895 - Deprecate File::_getMetaData()
+====================================================
+
+See :issue:`85895`
+
+Description
+===========
+
+The internal method :php:`TYPO3\CMS\Core\Resource\File::_getMetaData()` which is used to fetch meta data of a file
+has been marked as deprecated. This method has been superseded by the :php:`TYPO3\CMS\Core\Resource\MetaDataAspect`.
+
+
+Impact
+======
+
+Using this method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any 3rd party extension calling :php:`:php:`TYPO3\CMS\Core\Resource\File::_getMetaData()` is affected.
+
+
+Migration
+=========
+
+To fetch the meta data, call :php:`$fileObject->getMetaData()->get()` instead.
+
+.. index:: FAL, PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-87200-EmailFinisherFormatContants.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87200-1668719172:
+
+======================================================
+Deprecation: #87200 - EmailFinisher FORMAT_* constants
+======================================================
+
+See :issue:`87200`
+
+Description
+===========
+
+The constants
+
+* :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::FORMAT_PLAINTEXT` and
+* :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher::FORMAT_HTML`
+
+have been marked as deprecated and will be removed in TYPO3 11.0.
+
+
+Impact
+======
+
+Accessing these constants will lead to a fatal :php:`E_ERROR` in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and directly access these constants.
+
+
+Migration
+=========
+
+Do not use these constants anymore.
+
+.. index:: PHP-API, FullyScanned, ext:form

Documentation/Changelog/10.0/Deprecation-87200-EmailFinisherFormatOption.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87200:
+
+===================================================
+Deprecation: #87200 - EmailFinisher "format" option
+===================================================
+
+See :issue:`87200`
+
+Description
+===========
+
+The :yaml:`format` option of the :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher` has been marked as deprecated and
+will be removed in TYPO3 11.0. It is replaced by the new :yaml:`addHtmlPart` option which can be used to disable HTML
+and enforce plaintext-only mails. If set, mails will contain a plaintext and HTML part, otherwise only a plaintext part.
+
+If the :yaml:`format` option is used, its value will be automatically migrated to :yaml:`addHtmlPart`:
+
+* :yaml:`format: html` becomes :yaml:`addHtmlPart: true`
+* :yaml:`format: plaintext` becomes :yaml:`addHtmlPart: false`
+* a missing :yaml:`format` becomes :yaml:`addHtmlPart: true`
+
+Opening and saving a form with the form editor once also performs this migration and makes it permanent.
+
+
+Impact
+======
+
+The :yaml:`format` option will no longer work in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+All installations which use EXT:form and its :php:`TYPO3\CMS\Form\Domain\Finishers\EmailFinisher`.
+
+
+Migration
+=========
+
+Replace :yaml:`format: html` with :yaml:`addHtmlPart: true`.
+
+Replace :yaml:`format: plaintext` with :yaml:`addHtmlPart: false`.
+
+.. index:: YAML, NotScanned, ext:form

Documentation/Changelog/10.0/Deprecation-87305-UseConstructorInjectionInDataMapper.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87305:
+
+=============================================================
+Deprecation: #87305 - Use constructor injection in DataMapper
+=============================================================
+
+See :issue:`87305`
+
+Description
+===========
+
+The 8th argument (:php:`\TYPO3\CMS\Extbase\Persistence\QueryInterface`) of method
+:php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper->__construct` has been marked as deprecated.
+
+
+Impact
+======
+
+Instantiating objects along with that argument will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that create instances of the class :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper` while providing the 8th argument.
+
+
+Migration
+=========
+
+Instantiate the object without the 8th argument and use :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper->setQuery` if needed.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87332-AvoidRuntimeReflectionCallsInObjectAccess.rst

@@ -0,0 +1,50 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87332:
+
+====================================================================
+Deprecation: #87332 - Avoid runtime reflection calls in ObjectAccess
+====================================================================
+
+See :issue:`87332`
+
+Description
+===========
+
+Class :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess` uses reflection to make non public properties gettable and settable.
+This behaviour is triggered by setting the argument :php:`$forceDirectAccess` of methods
+
+* :php:`getProperty`
+* :php:`getPropertyInternal`
+* :php:`setProperty`
+
+to :php:`true`. Triggering this behaviour has been marked as deprecated and will be removed in TYPO3 11.0.
+
+Method :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName` has been marked as deprecated and will be removed in TYPO3 11.0.
+
+
+Impact
+======
+
+1) Accessing non public properties via the mentioned methods will no longer work in TYPO3 11.0.
+
+2) Calling :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName` will no longer work in TYPO3 11.0.
+
+
+Affected Installations
+======================
+
+1) All installations that use the mentioned methods with argument :php:`$forceDirectAccess` set to :php:`true`.
+
+2) All installations that call :php:`\TYPO3\CMS\Extbase\Reflection\ObjectAccess::buildSetterMethodName`.
+
+
+Migration
+=========
+
+1) Make sure the affected property is accessible by either making it public or providing getters/hassers/issers or setters
+(:php:`getProperty()`, :php:`hasProperty()`, :php:`isProperty()`, :php:`setProperty()`).
+
+2) Build setter names manually: :php:`$setterMethodName = 'set' . ucfirst($propertyName);`
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87550-UseControllerClassesWhenRegisteringPluginsmodules.rst

@@ -0,0 +1,92 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87550:
+
+=============================================================================
+Deprecation: #87550 - Use controller classes when registering plugins/modules
+=============================================================================
+
+See :issue:`87550`
+
+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 you to provide the argument :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.
+
+.. 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 is now 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.
+
+.. 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
+   );
+
+Conclusion
+==========
+
+The following things have been marked as deprecated:
+
+* Prepend the :php:`$extensionName` argument with a vendor name.
+* Using controller aliases as array keys in both arguments :php:`$controllerActions` and :php:`$nonCacheableControllerActions`.
+
+
+Impact
+======
+
+Using the deprecated syntax will trigger PHP :php:`E_USER_DEPRECATED` errors and will stop working in TYPO3 11.0.
+
+
+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/10.0/Deprecation-87613-DeprecateTYPO3CMSExtbaseUtilityTypeHandlingUtilityhex2bin.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87613:
+
+============================================================================================
+Deprecation: #87613 - Deprecate \\TYPO3\\CMS\\Extbase\\Utility\\TypeHandlingUtility::hex2bin
+============================================================================================
+
+See :issue:`87613`
+
+Description
+===========
+
+:php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin` has been marked as deprecated and will be removed in TYPO3 11.0.
+
+
+Impact
+======
+
+Calling :php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin` will trigger PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that call :php:`\TYPO3\CMS\Extbase\Utility\TypeHandlingUtility::hex2bin`.
+
+
+Migration
+=========
+
+Use the native php function :php:`hex2bin` instead.
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/10.0/Deprecation-87882-FileRelatedControllersMovedToEXTfilelist.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87882:
+
+====================================================================
+Deprecation: #87882 - File related controllers moved to EXT:filelist
+====================================================================
+
+See :issue:`87882`
+
+Description
+===========
+
+The following controllers have been moved to extension `filelist` as they are part of
+the filelist feature set:
+
+* :php:`CreateFolderController`
+* :php:`EditFileController`
+* :php:`FileUploadController`
+* :php:`RenameFileController`
+* :php:`ReplaceFileController`
+
+
+Impact
+======
+
+The namespace changed from :php:`TYPO3\CMS\Backend\Controller\File` to :php:`TYPO3\CMS\Filelist\Controller\File`. Using
+the old controllers will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Installations accessing any of the above controllers.
+
+
+Migration
+=========
+
+When wanting to use any of the functionality in these controllers, you should build your own controllers as they are
+internal and might change at any time. Use the TYPO3 file abstraction layer as API and add your own functionality on top
+of it with an own controller instead of reusing these.
+
+.. index:: Backend, PHP-API, PartiallyScanned, ext:filelist

Documentation/Changelog/10.0/Deprecation-87894-GeneralUtilityidnaEncode.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-87894:
+
+================================================
+Deprecation: #87894 - GeneralUtility::idnaEncode
+================================================
+
+See :issue:`87894`
+
+Description
+===========
+
+PHP has the native function :php:`idn_to_ascii($domain, IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46)` for converting UTF-8 based domains to ascii-based ("punicode")
+which is available in all supported PHP versions using :php:`"symfony/polyfill-intl-idn"`.
+
+For this reason the method :php:`GeneralUtility::idnaEncode()` has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`GeneralUtility::idnaEncode()` directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extensions calling this method.
+
+
+Migration
+=========
+
+Use :php:`idn_to_ascii($domain, IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46);` instead.
+
+Please be aware that contrary to :php:`GeneralUtility::idnaEncode()` the native PHP function only works on domain names, not email addresses or
+similar. In order to encode email addresses split the address at the last :php:`'@'` and use :php:`idn_to_ascii()` on that last part.
+Also, if there is an error in converting a string, a bool :php:`false` is returned.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88366-DefaultCachingFrameworkCacheNamesChanged.rst

@@ -0,0 +1,57 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88366:
+
+===================================================================
+Deprecation: #88366 - Default caching framework cache names changed
+===================================================================
+
+See :issue:`88366`
+
+Description
+===========
+
+TYPO3's internal Caching Framework has several caches already shipped with TYPO3 Core.
+
+The caches have been renamed for convenience and for newcomers to overcome another "speciality"
+of TYPO3 which was due to legacy and integration reasons back in TYPO3 4.3 when the Caching
+Framework was introduced.
+
+The following caches have been renamed:
+
+* `cache_core` => `core`
+* `cache_hash` => `hash`
+* `cache_pages` => `pages`
+* `cache_pagesection` => `pagesection`
+* `cache_runtime` => `runtime`
+* `cache_rootline` => `rootline`
+* `cache_imagesizes` => `imagesizes`
+
+The caches should now be accessed via :php:`$cacheManager->getCache('core')` instead of
+:php:`$cacheManager->getCache('cache_core')` - without the ``cache_`` prefix.
+
+In addition, when the DatabaseBackend cache is used, the database tables do not have the :sql:`cf_`
+prefix anymore, making it clearer for integrators and developers what the caches mean.
+
+
+Impact
+======
+
+When accessing the cache with a "cache" prefix, a PHP :php:`E_USER_DEPRECATED` error is triggered.
+
+
+Affected Installations
+======================
+
+Any TYPO3 extension using the caching framework with the ``cache_`` prefix.
+
+
+Migration
+=========
+
+Remove the ``cache_`` prefix from the callers code.
+
+In addition, run through the Database Table Analyzer of the Configuration module to
+re-create any database tables of the Caching Framework.
+
+.. index:: Database, LocalConfiguration, NotScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88406-SetCacheHashnoCacheHashOptionsInViewHelpersAndUriBuilder.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88406:
+
+====================================================================================
+Deprecation: #88406 - setCacheHash/noCacheHash options in ViewHelpers and UriBuilder
+====================================================================================
+
+See :issue:`88406`
+
+Description
+===========
+
+Various Fluid ViewHelpers regarding linking have arguments similar to:
+
+* :php:`useCacheHash`
+* :php:`noCacheHash`
+
+which are not evaluated anymore.
+
+Extbase's UriBuilder has the following options that have no effect anymore since the Site
+Handling concept automatically detects when to a cHash argument is necessary:
+
+* :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->setUseCacheHash()`
+* :php:`TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->getUseCacheHash()`
+
+Impact
+======
+
+Calling the UriBuilder methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Using the arguments :php:`noCacheHash`/:php:`useCacheHash` in the following ViewHelpers will
+trigger a PHP :php:`E_USER_DEPRECATED` error:
+
+* :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`
+* :html:`f:widget.link`
+* :html:`f:widget.uri`
+
+If the underlying TypoLink logic is accessed directly, it will trigger a PHP :php:`E_USER_DEPRECATED` error
+if :typoscript:`.useCacheHash` is set - without any effect either.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with custom templates setting this argument in Fluid or extensions
+using Extbase's UriBuilder in a custom fashion.
+
+
+Migration
+=========
+
+Remove any usages within the Fluid templates or Extension code.
+
+.. index:: Fluid, PHP-API, TypoScript, PartiallyScanned

Documentation/Changelog/10.0/Deprecation-88428-ToprawurlencodeAndTopstr_replace.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88428:
+
+==========================================================
+Deprecation: #88428 - top.rawurlencode and top.str_replace
+==========================================================
+
+See :issue:`88428`
+
+Description
+===========
+
+The global JavaScript functions :js:`top.rawurlencode()` and :js:`top.str_replace()` have been marked as deprecated.
+
+
+Impact
+======
+
+Calling any of these two functions will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All installations using third party extensions with these functions are affected.
+
+
+Migration
+=========
+
+For :js:`top.rawurlencode()` it's safe to use native JavaScript function :js:`encodeURIComponent()` instead. The only
+difference is that this function does not escape asterisk characters, which may be additionally achieved via
+:js:`encodeURIComponent('*my_string*').replace(/\*/g, '%2A')`.
+
+For :js:`top.str_replace()` consider using JavaScript's string function `.replace()` instead.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88432-ReplacedMd5jsWithAnAMDModule.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88432:
+
+========================================================
+Deprecation: #88432 - Replaced md5.js with an AMD module
+========================================================
+
+See :issue:`88432`
+
+Description
+===========
+
+The file :file:`md5.js` used to generate a MD5 hash in JavaScript has been marked as deprecated and replaced by an AMD module
+:js:`TYPO3/CMS/Backend/Hashing/Md5`.
+
+
+Impact
+======
+
+Using the global function `MD5()` will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All installations using third party extensions that use :js:`MD5()` of :file:`md5.js` are affected.
+
+
+Migration
+=========
+
+Load the AMD module :js:`TYPO3/CMS/Backend/Hashing/Md5` via RequireJS as `Md5` and call :js:`Md5.hash()` instead.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88433-DeprecateTopopenUrlInWindow.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88433:
+
+===================================================
+Deprecation: #88433 - Deprecate top.openUrlInWindow
+===================================================
+
+See :issue:`88433`
+
+Description
+===========
+
+The global JavaScript function :js:`top.openUrlInWindow()` has been marked as deprecated. This method was used to open
+links in a full size popup.
+
+
+Impact
+======
+
+Calling this function will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All installations using third party extensions that use :js:`top.openUrlInWindow()` are affected.
+
+
+Migration
+=========
+
+Instead of using this method, consider using plain HTML and open the link in a new tab:
+:html:`<a href="/path/to/my/document", target="_blank">Linked content</a>`
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88473-TypoScriptFrontendController-settingLocale.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88473:
+
+=================================================================
+Deprecation: #88473 - TypoScriptFrontendController->settingLocale
+=================================================================
+
+See :issue:`88473`
+
+Description
+===========
+
+Due to Site Handling, setting the locale information (:php:`setlocale`) can be handled
+much earlier without any dependencies on the global :php:`TSFE` object.
+
+The functionality of the method :php:`TypoScriptFrontendController->settingLocale()` has
+been moved into :php:`Locales::setSystemLocaleFromSiteLanguage()`. The former method
+has been marked as deprecated.
+
+
+Impact
+======
+
+Calling :php:`TypoScriptFrontendController->settingLocale()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third party extension booting up a custom Frontend system and
+explicitly calling the method.
+
+
+Migration
+=========
+
+Migrate the existing PHP code to :php:`Locales::setSystemLocaleFromSiteLanguage()` or ensure
+that the SiteResolver middleware for Frontend Requests is executed where the locale is now
+set automatically.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88499-BackendUtilitygetViewDomain.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88499:
+
+===================================================
+Deprecation: #88499 - BackendUtility::getViewDomain
+===================================================
+
+See :issue:`88499`
+
+Description
+===========
+
+The static method :php:`TYPO3\CMS\Backend\Utility\BackendUtility::getViewDomain()` has been marked
+as deprecated, as it has been superseded by directly using the PageRouter of Site Handling.
+
+Site Handling allows to generate proper frontend preview URLs the same way as TYPO3 Core does in
+all other places, by calling the PageRouter of a Site object directly, so the workarounds are not
+necessary anymore, making this method obsolete.
+
+
+Impact
+======
+
+Calling :php:`BackendUtility::getViewDomain()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installations with custom extensions that call this method.
+
+
+Migration
+=========
+
+Substitute the method by directly detecting a site based on a given Page ID in the TYPO3 Backend.
+Call the :php:`getRouter()` method on this Site object to create proper links to pages in TYPO3 Frontend.
+
+Example with additional GET parameters:
+
+.. code-block:: php
+
+    $site = GeneralUtility::makeInstance(SiteFinder::class)->getSiteByPageId($pageId);
+    $url = $site->getRouter()->generateUri($pageId, ['type' => 13]);
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88554-DeprecatedMethodsInVersionNumberUtility.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88554:
+
+================================================================
+Deprecation: #88554 - Deprecated methods in VersionNumberUtility
+================================================================
+
+See :issue:`88554`
+
+Description
+===========
+
+The following methods of :php:`\TYPO3\CMS\Core\Utility\VersionNumberUtility` have been marked as deprecated and will be removed in
+TYPO3 11.0:
+
+* :php:`convertIntegerToVersionNumber`
+* :php:`splitVersionRange`
+* :php:`raiseVersionNumber`
+
+
+Impact
+======
+
+Calling the methods :php:`convertIntegerToVersionNumber`, :php:`splitVersionRange` or :php:`raiseVersionNumber` of
+:php:\TYPO3\CMS\Core\Utility\VersionNumberUtility` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations that call the mentioned methods.
+
+
+Migration
+=========
+
+Implement the methods in your custom code.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88559-TSFE-sys_language_isocode.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88559:
+
+=================================================
+Deprecation: #88559 - $TSFE->sys_language_isocode
+=================================================
+
+See :issue:`88559`
+
+Description
+===========
+
+The public property :php:`TypoScriptFrontendController->sys_language_isocode`
+has set the equivalent of :php:`TYPO3\CMS\Core\Site\Entity\SiteLanguage->getTwoLetterIsoCode()` since the introduction
+of Site Handling in TYPO3 v9.
+
+As all code should switch to Site Handling, this property can be accessed via
+the current site language as well, making this property obsolete.
+
+The property has been marked as deprecated.
+
+
+Impact
+======
+
+Setting or fetching this property will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third party extension accessing this property,
+or via TypoScript :typoscript:`TSFE:sys_language_isocode`.
+
+
+Migration
+=========
+
+Access the property via :php:`SiteLanguage->getTwoLetterIsoCode()`
+and :typoscript:`sitelanguage:twoLetterIsoCode` instead.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88567-GLOBALS_LOCAL_LANG.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88567:
+
+============================================
+Deprecation: #88567 - $GLOBALS['LOCAL_LANG']
+============================================
+
+See :issue:`88567`
+
+Description
+===========
+
+The global array :php:`$GLOBALS['LOCAL_LANG']` contains all labels from language
+files that were loaded "globally". However, instead of having this in global
+scope, it is more feasible to have it scoped to the actual :php:`LanguageService`
+that loaded this data, in order to allow various language functionality in the
+same PHP process without having to deal with global variables.
+
+For this reason, it is discouraged to use :php:`$GLOBALS['LOCAL_LANG']`
+but instead rely on :php:`LanguageService->includeLLfile()` which returns
+the actual values as well, but only the ones loaded from this instance.
+
+Since an instance of :php:`TYPO3\CMS\Core\Localization\LanguageService` is usually available via `$GLOBALS['LANG']` the
+labels are accessible within PHP anyways.
+
+Due to this change, the second and third arguments of :php:`LanguageService->includeLLFile()` have been marked as deprecated.
+
+
+Impact
+======
+
+Calling the method above with an explicit second and/or third argument will
+trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extensions using
+:php:`$GLOBALS['LOCAL_LANG']` or the mentioned method with more than one argument,
+which is very unlikely.
+
+
+Migration
+=========
+
+Use the return value of :php:`LanguageService->includeLLFile()` and remove
+the second and third arguments to work with label files.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88569-LocalesinitializeInFavorOfRegularSingletonInstance.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88569:
+
+==================================================================================
+Deprecation: #88569 - Locales::initialize() in favor of regular singleton instance
+==================================================================================
+
+See :issue:`88569`
+
+Description
+===========
+
+The method :php:`TYPO3\CMS\Core\Localization\Locales::initialize()` has been marked as deprecated.
+It was a workaround to re-initialize the Singleton Instance of the PHP class :php:`Locales` for user-defined locales, which were
+loaded by an extensions' :file:`ext_localconf.php`.
+
+:php:`Locales` is now initialized only when needed, and not during the early bootstrap process,
+making this functionality obsolete, as this is taken care of within the regular constructor.
+
+
+Impact
+======
+
+Calling :php:`TYPO3\CMS\Core\Localization\Locales::initialize()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a third-party extension calling :php:`Locales::initialize()` directly.
+
+
+Migration
+=========
+
+Replace the function call by a regular :php:`GeneralUtility::makeInstance(Locales::class);`
+or use Dependency Injection (Constructor Injection or ObjectManager) to fetch an instance of
+the :php:`Locales` class.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/10.0/Deprecation-88651-ReplaceTYPO3CMSBackendSplitButtonsWithTYPO3CMSBackendDocumentSaveActions.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88651:
+
+=======================================================================================================
+Deprecation: #88651 - Replace TYPO3/CMS/Backend/SplitButtons with TYPO3/CMS/Backend/DocumentSaveActions
+=======================================================================================================
+
+See :issue:`88651`
+
+Description
+===========
+
+Since FormEngine doesn't use split buttons anymore with TYPO3 v9, the JavaScript module
+:js:`TYPO3/CMS/Backend/SplitButtons` has been replaced with :js:`TYPO3/CMS/Backend/DocumentSaveActions`.
+
+
+Impact
+======
+
+Loading :js:`TYPO3/CMS/Backend/SplitButtons` will trigger a deprecation log entry in the browser's console.
+
+
+Affected Installations
+======================
+
+All 3rd party extensions using :js:`TYPO3/CMS/Backend/SplitButtons` are affected.
+
+
+Migration
+=========
+
+Use :js:`TYPO3/CMS/Backend/DocumentSaveActions` instead. Since the module is a singleton, the instance can be fetched by
+calling :js:`DocumentSaveActions.getInstance()`.
+
+.. index:: Backend, JavaScript, NotScanned, ext:backend

Documentation/Changelog/10.0/Deprecation-88662-DeprecatedBackendRouteXMOD_tximpexp.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88662:
+
+============================================================
+Deprecation: #88662 - Deprecated backend route xMOD_tximpexp
+============================================================
+
+See :issue:`88662`
+
+Description
+===========
+
+The route identifier :php:`xMOD_tximpexp` (route `record/importexport`) pointing to
+:php:`ImportExportController::mainAction` has been marked as deprecated. The class was previously responsible to handle
+either the export or the import process, controlled by a query parameter.
+
+
+Impact
+======
+
+Calling the route will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All 3rd-party extensions using the route :php:`xMOD_tximpexp` are affected.
+
+
+Migration
+=========
+
+Depending on the task, either use :php:`tx_impexp_export` or :php:`tx_impexp_import`. Additionally, remove any
+`tx_impexp[action]` query parameter.
+
+.. index:: Backend, NotScanned, ext:impexp

Documentation/Changelog/10.0/Deprecation-88746-PageRepositoryPHPClassMovedFromFrontendToCoreExtension.rst

@@ -0,0 +1,52 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88746:
+
+====================================================================================
+Deprecation: #88746 - PageRepository PHP class moved from Frontend to Core Extension
+====================================================================================
+
+See :issue:`88746`
+
+Description
+===========
+
+In previous TYPO3 versions, accessing records was mixed between Frontend (handled by PageRepository)
+and Backend (handled by static methods in BackendUtility). In TYPO3 v9, the Context API was introduced
+and PageRepository now acts as a strong database accessor which is not bound to Frontend anymore,
+at all.
+
+In addition, various places of the backend also used PageRepository already, which violated the
+separation of packages, as TYPO3 Core aims to strictly separate Frontend and Backend application
+code.
+
+In the case of PageRepository, the code is used by both applications, and is therefore moved
+to Core system extension (EXT:core), and renamed to :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository`.
+
+Until TYPO3 v9, it was placed in :php:`TYPO3\CMS\Frontend\Page\PageRepository`.
+
+In addition, all interface'd hooks are moved to EXT:core as well with the same PHP namespace.
+
+
+Impact
+======
+
+A class alias was introduced which does not trigger any deprecations, so both variants
+still work as before, however it is recommended to rename any calls to the PHP class.
+
+No other functionality was changed.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with custom PHP extensions accessing PageRepository directly.
+
+
+Migration
+=========
+
+Replace any PHP references of :php:`TYPO3\CMS\Frontend\Page\PageRepository`
+to :php:`TYPO3\CMS\Core\Domain\Repository\PageRepository` in any custom PHP code.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/10.0/Deprecation-88792-ForceTemplateParsingInTSFEAndTemplateService.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88792:
+
+======================================================================
+Deprecation: #88792 - forceTemplateParsing in TSFE and TemplateService
+======================================================================
+
+See :issue:`88792`
+
+Description
+===========
+
+* :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::forceTemplateParsing` and
+* :php:`TYPO3\CMS\Core\TypoScript\TemplateService::forceTemplateParsing`
+
+have been marked as deprecated and replaced by Context API.
+
+
+Impact
+======
+
+Setting either :php:`forceTemplateParsing` of :php:`TypoScriptFrontendController` or :php:`TemplateService`
+will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All installations setting or reading :php:`$TSFE->forceTemplateParsing` or :php:`TemplateService->forceTemplateParsing`.
+
+
+Migration
+=========
+
+Use the Context API ::
+
+   GeneralUtility::makeInstance(Context::class)->getPropertyFromAspect('typoscript', 'forcedTemplateParsing');
+   $context->setAspect('typoscript', GeneralUtility::makeInstance(TypoScriptAspect::class, true));
+
+.. index:: Frontend, PHP-API, PartiallyScanned, ext:core

Documentation/Changelog/10.0/Deprecation-88807-AdminPanelInitializableInterfaceHasBeenDeprecated.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-88807:
+
+===========================================================================
+Deprecation: #88807 - AdminPanel InitializableInterface has been deprecated
+===========================================================================
+
+See :issue:`88807`
+
+Description
+===========
+
+`\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface` has been deprecated in favor of the newly
+introduced `\TYPO3\CMS\Adminpanel\ModuleApi\RequestEnricherInterface`.
+
+
+Impact
+======
+
+Using `\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface` will trigger a deprecation message.
+
+
+Affected Installations
+======================
+
+All instances that use `\TYPO3\CMS\Adminpanel\ModuleApi\InitializableInterface` are affected.
+
+
+Migration
+=========
+
+Switch to `\TYPO3\CMS\Adminpanel\ModuleApi\RequestEnricherInterface` instead:
+
+- change method name `initializeModule` to `enrich`
+- change return value to return an instance of
+  :php:`\Psr\Http\Message\ServerRequestInterface`
+
+.. index:: Frontend, PHP-API, PartiallyScanned, ext:adminpanel