TYPO3 v15 dev-main snapshot ()

Documentation/Changelog/9.3/Breaking-84680-RemovedUnusedLocallangFilesFromEXTlang.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84680:
+
+===============================================================
+Breaking: #84680 - Removed unused locallang files from EXT:lang
+===============================================================
+
+See :issue:`84680`
+
+Description
+===========
+
+Removed the last unused locallang files from EXT:lang.
+
+
+Impact
+======
+
+Extensions or configuration that use one of the following locallang files will not show a translation anymore.
+
+
+* :file:`lang/Resources/Private/Language/locallang_alt_intro.xlf`
+* :file:`lang/Resources/Private/Language/locallang_alt_doc.xlf`
+* :file:`lang/Resources/Private/Language/locallang_login.xlf`
+* :file:`lang/Resources/Private/Language/locallang_common.xlf`
+* :file:`lang/Resources/Private/Language/locallang_core.xlf`
+* :file:`lang/Resources/Private/Language/locallang_general.xlf`
+* :file:`lang/Resources/Private/Language/locallang_misc.xlf`
+* :file:`lang/Resources/Private/Language/locallang_mod_web_list.xlf`
+* :file:`lang/Resources/Private/Language/locallang_tca.xlf`
+* :file:`lang/Resources/Private/Language/locallang_tsfe.xlf`
+* :file:`lang/Resources/Private/Language/locallang_wizards.xlf`
+* :file:`lang/Resources/Private/Language/locallang_browse_links.xlf`
+* :file:`lang/Resources/Private/Language/locallang_tcemain.xlf`
+
+
+Affected Installations
+======================
+
+All extensions or configuration that still use any of the mentioned locallang files.
+
+
+Migration
+=========
+
+Use your own language files.
+
+.. index:: Backend, TCA, NotScanned

Documentation/Changelog/9.3/Breaking-84744-RaiseDoctrinedbal-version.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84744:
+
+==============================================
+Breaking: #84744 - Raise doctrine/dbal-version
+==============================================
+
+See :issue:`84744`
+
+Description
+===========
+
+The upgrade doctrine/dbal to 2.7.1 came with a potentially breaking change that makes
+it necessary to adjust the format of DateInterval fields.
+
+Those fields can now be negative as well and thus are expected to begin with either
+`+` or `-`.
+
+
+Impact
+======
+
+Users not having prefixes in DateInterval fields will be greeted by a :php:`ConversionException`.
+
+We do not expect many (if any) TYPO3 users to be affected by this change.
+
+You can read up on the topic at https://github.com/doctrine/dbal/pull/2579 and https://github.com/doctrine/dbal/releases/tag/v2.7.0.
+
+
+Affected Installations
+======================
+
+Users with existing DateInterval fields that don't yet use the proper field prefix.
+
+
+Migration
+=========
+
+Manually provide the proper prefixes in your DateInterval fields.
+
+If you didn't use negative DateIntervals yet, you can safely prefix your data with `+`.
+
+.. index:: Database, PHP-API, NotScanned

Documentation/Changelog/9.3/Breaking-84810-RemoveExplicitConfirmationOfTranslation.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84810:
+
+===========================================================
+Breaking: #84810 - Remove explicitConfirmationOfTranslation
+===========================================================
+
+See :issue:`84810`
+
+Description
+===========
+
+Removes the explicitConfirmationOfTranslation feature which seems to be completely unused. Besides that it does no
+longer fit in the new button bar introduced with the "unsplit the split button concept".
+It has been detected before that there were missing icons for those buttons in earlier releases for which not even a bugreport was created.
+
+
+Impact
+======
+
+The buttons will disappear if the setting was actually used.
+
+
+Affected Installations
+======================
+
+Installations using the "Translation finished, save and close" and "Translation NOT finished, Save" buttons in their translation workflow.
+Or possibly where the translation labels might be re-used in extensions.
+
+
+Migration
+=========
+
+There's no migration needed as the setting is automatically removed. Possible calls to the previously public methods
+will appear in the deprecation log but it seems to be highly unlikely those are used.
+
+.. index:: Backend, LocalConfiguration, NotScanned, ext:core

Documentation/Changelog/9.3/Breaking-84843-UseNo-cookieDomainForYoutubeByDefault.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84843-1668719171:
+
+==============================================================
+Breaking: #84843 - Use no-cookie domain for youtube by default
+==============================================================
+
+See :issue:`84843`
+
+Description
+===========
+
+To improve the privacy of users the renderer for YouTube videos has been changed to use
+the no-cookie domain `www.youtube-nocookie.com` by default. The regular domain `www.youtube.com`
+is used if explicitly set by the following TypoScript configuration:
+
+.. code-block:: typoscript
+
+    lib.contentElement {
+        settings {
+            media {
+                additionalConfig {
+                    no-cookie = 0
+                }
+            }
+        }
+    }
+
+
+Impact
+======
+
+The TypoScript configuration :typoscript:`lib.contentElement.settings.media.additionalConfig` is used
+as attribute :php:`additionalConfig` of the ViewHelper :php:`\TYPO3\CMS\Fluid\ViewHelpers\MediaViewHelper`.
+
+If no configuration is provided, the domain `www.youtube-nocookie.com` is used.
+
+
+Affected Installations
+======================
+
+Installations which require the usage of the domain `www.youtube.com` or setting cookies by YouTube.
+
+
+Migration
+=========
+
+Use the TypoScript configuration :typoscript:`lib.contentElement.settings.media.additionalConfig.no-cookie = 0`
+
+.. index:: TypoScript, ext:fluid_styled_content, NotScanned

Documentation/Changelog/9.3/Breaking-84877-LocalizationOfPageOnColumnBasisRemoved.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84877-1668719183:
+
+===============================================================
+Breaking: #84877 - Localization of page on column basis removed
+===============================================================
+
+See :issue:`84877`
+
+Description
+===========
+
+The "Translate" buttons located in each column (colPos) in the page module have been replaced by one global action
+button per language.
+
+
+Impact
+======
+
+The possibility to translate each column of a page from a different source language has been removed. Instead, the whole
+page gets translated with the locale action.
+
+
+Affected Installations
+======================
+
+Every installation relying on having different sources per localization is affected.
+
+
+Migration
+=========
+
+Manually migrate any content element by changing its parent by editing the element, in case mixed sources are used.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/9.3/Breaking-84877-LocalizationRepositoryMarkedAsInternal.rst

@@ -0,0 +1,30 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84877-1668719195:
+
+============================================================
+Breaking: #84877 - LocalizationRepository marked as internal
+============================================================
+
+See :issue:`84877`
+
+Description
+===========
+
+The class :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository` has been marked as internal, as
+it's supposed to be used within the TYPO3 Core only.
+
+
+Impact
+======
+
+The class :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository` may change its behavior at any
+point.
+
+
+Affected Installations
+======================
+
+Every 3rd party extension using :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository` is affected.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/9.3/Breaking-84877-MethodsOfLocalizationRepositoryChanged.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84877:
+
+=============================================================
+Breaking: #84877 - Methods of localization repository changed
+=============================================================
+
+See :issue:`84877`
+
+Description
+===========
+
+The method :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository::getUsedLanguagesInPageAndColumn()`
+has been renamed to :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository::getUsedLanguagesInPage()`.
+
+The signatures of the following methods in :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository` have changed:
+
+- :php:`fetchOriginLanguage`
+- :php:`getLocalizedRecordCount`
+- :php:`fetchAvailableLanguages`
+- :php:`getRecordsToCopyDatabaseResult`
+
+In every method, the second argument :php:`$colPos` has been removed.
+
+
+Impact
+======
+
+Calling the method :php:`getUsedLanguagesInPageAndColumn()` will trigger a fatal error.
+
+Calling the methods with the former argument for :php:`$colPos` in place will result in broken query results or fatal
+errors.
+
+
+Affected Installations
+======================
+
+Every 3rd party extension using :php:`\TYPO3\CMS\Backend\Domain\Repository\Localization\LocalizationRepository` is affected.
+
+
+Migration
+=========
+
+Change the method call from :php:`getUsedLanguagesInPageAndColumn()` to :php:`getUsedLanguagesInPage()`.
+
+Remove the :php:`$colPos` arguments in the calls, as they are not required anymore.
+
+.. index:: Backend, FullyScanned, ext:backend

Documentation/Changelog/9.3/Breaking-84877-RouteOfLanguageRetrievalChanged.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-84877-1668719171:
+
+======================================================
+Breaking: #84877 - Route of language retrieval changed
+======================================================
+
+See :issue:`84877`
+
+Description
+===========
+
+The name of the route that fetches the languages per page has changed.
+
+
+Impact
+======
+
+Calling the old route :php:`languages_page_colpos` will result in a fatal error.
+
+
+Affected Installations
+======================
+
+Every 3rd party extension calling the route is affected.
+
+
+Migration
+=========
+
+Replace the old route name :php:`languages_page_colpos` with :php:`page_languages`.
+
+.. index:: Backend, NotScanned, ext:backend

Documentation/Changelog/9.3/Breaking-85025-EnumerationsAreNowFinal.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-85025:
+
+=============================================
+Breaking: #85025 - Enumerations are now final
+=============================================
+
+See :issue:`85025`
+
+Description
+===========
+
+All enumeration classes in TYPO3 have been marked as :php:`final` which prevents extension by 3rd party code.
+
+By definition an enumeration is a limited and known set of values, any code which uses enumeration relies on this fact.
+If an enumeration was extended by 3rd party code undefined behavior would occur. For this reason no enumerations must be extended.
+
+Developers of 3rd party extensions are also encouraged to mark their enumerations as :php:`final`.
+
+
+Impact
+======
+
+Classes extending TYPO3 enumerations will trigger a fatal PHP error.
+
+
+Affected Installations
+======================
+
+Instances with classes extending TYPO3 enumerations.
+
+
+Migration
+=========
+
+Remove the classes which extend TYPO3 enumerations.
+
+.. index:: PHP-API, NotScanned

Documentation/Changelog/9.3/Breaking-85036-RemoveSupportForNonNamespacedClassesInExtbase.rst

@@ -0,0 +1,41 @@
+.. include:: /Includes.rst.txt
+
+.. _breaking-85036:
+
+========================================================================
+Breaking: #85036 - Removed support for non-namespaced classes in Extbase
+========================================================================
+
+See :issue:`85036`
+
+Description
+===========
+
+Non-namespaced classes like :php:`Tx_Extension_Controller_FooController` are not supported any more
+and all magic based on class names no longer works with classes like these:
+
+* Translating model name to repository name (and vice versa)
+* Translating model name to validator name
+* Guessing the extension name
+* Guessing the controller name by looking at a command name
+* Translating model name to (database) table name
+* Recognizing child property types in object storage annotations
+
+Impact
+======
+
+All this magic no longer works with non-namespaced classes.
+
+
+Affected Installations
+======================
+
+All installations that still use non-namespaced classes in Extbase.
+
+
+Migration
+=========
+
+Use namespaced class names for Extbase.
+
+.. index:: ext:extbase, NotScanned

Documentation/Changelog/9.3/Deprecation-81686-AccessingCoreTypoScriptWithTxtFileExtensionHasBeenDeprecated.rst

@@ -0,0 +1,44 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-81686:
+
+============================================================================================
+Deprecation: #81686 - Accessing core TypoScript with .txt file extension has been deprecated
+============================================================================================
+
+See :issue:`81686`
+
+Description
+===========
+
+TYPO3 Core TypoScript files were renamed from :file:`.txt` extension to :file:`.typoscript` and :file:`.tsconfig`.
+The backward compatibility layer has been introduced for :typoscript:`<INCLUDE_TYPOSCRIPT` inclusion.
+If including file with :file:`.txt` does not exist, then TYPO3 will try to load a file with :file:`.typoscript` extension.
+
+
+Impact
+======
+
+Installations including Core TypoScript using old file extension will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Migration
+=========
+
+Rename file name from :file:`.txt` to :file:`.typoscript` extension.
+For example code like:
+
+.. code-block:: typoscript
+
+   <INCLUDE_TYPOSCRIPT: source="FILE:EXT:form/Configuration/TypoScript/setup.txt">
+   <INCLUDE_TYPOSCRIPT: source="FILE:EXT:fluid_styled_content/Configuration/TypoScript/constants.txt">
+
+should be changed to:
+
+.. code-block:: typoscript
+
+   <INCLUDE_TYPOSCRIPT: source="FILE:EXT:form/Configuration/TypoScript/setup.typoscript">
+   <INCLUDE_TYPOSCRIPT: source="FILE:EXT:fluid_styled_content/Configuration/TypoScript/constants.typoscript">
+
+
+.. index:: TSConfig, TypoScript, NotScanned

Documentation/Changelog/9.3/Deprecation-83167-ReplaceValidateWithTYPO3CMSExtbaseAnnotationValidate.rst

@@ -0,0 +1,141 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-83167:
+
+=======================================================================================
+Deprecation: #83167 - Replace @validate with @TYPO3\\CMS\\Extbase\\Annotation\\Validate
+=======================================================================================
+
+See :issue:`83167`
+
+Description
+===========
+
+The :php:`@validate` annotation has been marked as deprecated and should be replaced with the doctrine annotation
+:php:`@TYPO3\CMS\Extbase\Annotation\Validate`.
+
+
+Impact
+======
+
+Classes using :php:`@validate` will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All extensions that use :php:`@validate`
+
+
+Migration
+=========
+
+Use :php:`@TYPO3\CMS\Extbase\Annotation\Validate` instead.
+
+
+Examples:
+---------
+
+The following examples show both the old and the new way of using validation annotations. Both versions can still be used
+in the same doc block, but you should start using the new way today.
+
+.. code-block:: php
+
+	use TYPO3\CMS\Extbase\Annotation as Extbase;
+
+
+.. note::
+
+   Doctrine annotations are actual classes, so they can be either used via FQCN, imported via the use statement or even
+   be aliased which is the preferred way. As doctrine annotations can only be used in the Extbase context (for now), the
+   aliased version makes that perfectly clear even for people that are new to TYPO3.
+
+.. tip::
+
+   When using PhpStorm, you can install the `PHP Annotation` plugin that recognizes the annotation classes and makes you
+   jump directly into them. Also, it enables autocompletion for annotation options.
+
+Validators for class properties
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is how annotations look like, that register validators without options
+
+.. code-block:: php
+
+	/**
+	 * @validate NotEmpty
+	 * @Extbase\Validate("NotEmpty")
+	 * @var Foo
+	 */
+	public $property;
+
+.. code-block:: php
+
+	/**
+	 * @validate NotEmpty
+	 * @Extbase\Validate(validator="NotEmpty")
+	 * @var Foo
+	 */
+	public $property;
+
+This is how annotations look like, that register validators with options
+
+.. code-block:: php
+
+	/**
+	 * @validate StringLength(minimum=3, maximum=50)
+	 * @Extbase\Validate("StringLength", options={"minimum": 3, "maximum": 50})
+	 * @var Foo
+	 */
+	public $property;
+
+.. important::
+
+   Registering multiple validators, separated by comma, is not possible any more. Instead, use one validator per line.
+
+.. code-block:: php
+
+	/**
+	 * @validate StringLength(minimum=3), StringLength(maximum=50)
+	 * @Extbase\Validate("StringLength", options={"minimum": 3})
+	 * @Extbase\Validate("StringLength", options={"maximum": 50})
+	 * @var Foo
+	 */
+	public $property;
+
+Validators for method params
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. important::
+
+   When using validators for method params, you need to define what param the validator is registered for. Also, please
+   note that the param name does no longer include the dollar sign.
+
+.. code-block:: php
+
+	/**
+	 * @validate $bar NotEmpty
+	 * @Extbase\Validate("NotEmpty", param="bar")
+	 * @var string $foo
+	 * @var string $bar
+	 */
+	public function method(string $foo, string $bar)
+	{
+	}
+
+Full qualified validator class names and aliases
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Of course it's still possible to reference validators by extension key, aliases and FQCN's.
+
+.. code-block:: php
+
+	/**
+	 * @Extbase\Validate("NotEmpty")
+	 * @Extbase\Validate("TYPO3.CMS.Extbase:NotEmpty")
+	 * @Extbase\Validate("TYPO3\CMS\Extbase\Validation\Validator\NotEmptyValidator")
+	 * @Extbase\Validate("\TYPO3\CMS\Extbase\Validation\Validator\NotEmptyValidator")
+	 */
+	protected $property;
+
+.. index:: PHP-API, ext:extbase, FullyScanned

Documentation/Changelog/9.3/Deprecation-83976-MovedFileExtensionDetectionToFALDriver.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-83976:
+
+==================================================================
+Deprecation: #83976 - Moved file extension detection to FAL driver
+==================================================================
+
+See :issue:`83976`
+
+Description
+===========
+
+The only object that is allowed to handle the physical file in the FAL is the driver, as it is the
+only instance that knows how to access the file.
+
+The definition of the FAL driver method :php:`getFileInfoByIdentifier()` is enhanced with the return
+value `extension`.
+
+
+Impact
+======
+
+Installations with a FAL driver :php:`getFileInfoByIdentifier()` method that doesn't return the
+`extension` value will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Installations with 3rd party FAL drivers.
+
+
+Migration
+=========
+
+Adjust the :php:`getFileInfoByIdentifier()` method of your file drivers to return the `extension` value.
+
+.. index:: FAL, NotScanned

Documentation/Changelog/9.3/Deprecation-84680-MoveLastLanguageFilesAwayFromExtlangAndRemoveExtlangCompletely.rst

@@ -0,0 +1,51 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84680:
+
+================================================================================================
+Deprecation: #84680 - Move last language files away from ext:lang and remove ext:lang completely
+================================================================================================
+
+See :issue:`84680`
+
+Description
+===========
+
+Move last language files away from ext:lang and remove ext:lang completely.
+
+
+Impact
+======
+
+Extensions or configuration that use language paths to EXT:lang/Resources/Private/Language/* will trigger a
+PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+All extensions or configuration that still uses EXT:lang for translations.
+
+
+Migration
+=========
+
+Migrate the current location to the new location from the list below.
+
+.. code-block:: php
+
+    'lang/Resources/Private/Language/locallang_alt_intro.xlf' => 'about/Resources/Private/Language/Modules/locallang_alt_intro.xlf'
+    'lang/Resources/Private/Language/locallang_alt_doc.xlf' => 'backend/Resources/Private/Language/locallang_alt_doc.xlf'
+    'lang/Resources/Private/Language/locallang_login.xlf' => 'backend/Resources/Private/Language/locallang_login.xlf'
+    'lang/Resources/Private/Language/locallang_common.xlf' => 'core/Resources/Private/Language/locallang_common.xlf'
+    'lang/Resources/Private/Language/locallang_core.xlf' => 'core/Resources/Private/Language/locallang_core.xlf'
+    'lang/Resources/Private/Language/locallang_general.xlf' => 'core/Resources/Private/Language/locallang_general.xlf'
+    'lang/Resources/Private/Language/locallang_misc.xlf' => 'core/Resources/Private/Language/locallang_misc.xlf'
+    'lang/Resources/Private/Language/locallang_mod_web_list.xlf' => 'core/Resources/Private/Language/locallang_mod_web_list.xlf'
+    'lang/Resources/Private/Language/locallang_tca.xlf' => 'core/Resources/Private/Language/locallang_tca.xlf'
+    'lang/Resources/Private/Language/locallang_tsfe.xlf' => 'core/Resources/Private/Language/locallang_tsfe.xlf'
+    'lang/Resources/Private/Language/locallang_wizards.xlf' => 'core/Resources/Private/Language/locallang_wizards.xlf'
+    'lang/Resources/Private/Language/locallang_browse_links.xlf' => 'recordlist/Resources/Private/Language/locallang_browse_links.xlf'
+    'lang/Resources/Private/Language/locallang_tcemain.xlf' => 'workspaces/Resources/Private/Language/locallang_tcemain.xlf'
+
+.. index:: Backend, TCA, NotScanned

Documentation/Changelog/9.3/Deprecation-84725-SysDomainResolvingMovedIntoMiddleware.rst

@@ -0,0 +1,48 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84725:
+
+================================================================
+Deprecation: #84725 - sys_domain resolving moved into middleware
+================================================================
+
+See :issue:`84725`
+
+Description
+===========
+
+The method :php:`PageRepository->getDomainStartPage()` has been marked as deprecated.
+
+The method :php:`TypoScriptFrontendController->findDomainRecord()` which was marked
+as internal, has been removed.
+
+As both methods have been used to resolve the root page ID of the current request,
+they were solely there to fill :php:`$GLOBALS['TSFE']->domainStartPage` which is now filled
+at an earlier stage through the :php:`SiteResolver` middleware.
+
+
+Impact
+======
+
+Calling the PageRepository method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+Calling the TypoScriptFrontendController method will result in a fatal PHP error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with third-party extensions calling the methods directly, usually
+related to resolve a page ID or to mimic a frontend call.
+
+
+Migration
+=========
+
+If the return value is needed, access :php:`$GLOBALS['TSFE']->domainStartPage` directly.
+
+If the functionality is used in a third-party functionality and still needed,
+ensure to extend from :php:`SiteResolver` middleware to call the now-protected method equivalents
+instead.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/9.3/Deprecation-84965-VariousTypoScriptFrontendControllerMethods.rst

@@ -0,0 +1,67 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84965:
+
+==================================================================
+Deprecation: #84965 - Various TypoScriptFrontendController methods
+==================================================================
+
+See :issue:`84965`
+
+Description
+===========
+
+A lot of functionality from :php:`TypoScriptFrontendController` (a.k.a. `TSFE`) has been migrated
+into new PSR-15 middlewares, which are flexible modules to modify a HTTP request workflow.
+
+Most of the functionality which is now in a PSR-15-based middleware is related to setting up various
+permission and GET/POST variable resolving.
+
+The following methods within :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` have been marked
+as deprecated:
+
+- :php:`connectToDB()`
+- :php:`checkAlternativeIdMethods()`
+- :php:`initializeBackendUser()`
+- :php:`handleDataSubmission()`
+- :php:`setCSS()`
+- :php:`convPOSTCharset()`
+
+All hooks previously located within these methods still work as expected, as they are now called within
+a PSR-15 middleware.
+
+Additionally, there are some methods within :php:`TSFE` which have been marked as "internal" for a long time,
+but had the PHP visibility "public" from a legacy code base. These methods, which are internal for TYPO3 Core
+purposes, now have the visibility "protected".
+
+- :php:`getPageAndRootline()`
+- :php:`checkRootlineForIncludeSection()`
+- :php:`setSysPageWhereClause()`
+- :php:`checkAndSetAlias()`
+- :php:`getHash()`
+- :php:`getLockHash()`
+- :php:`setUrlIdToken()`
+
+
+Impact
+======
+
+Calling any of the deprecated methods above will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a custom extension setting up or mimicking a custom frontend request by
+calling :php:`TypoScriptFrontendController` methods directly.
+
+
+Migration
+=========
+
+Extensions that bootstrap their own frontend should ensure that the respective Middlewares are run,
+e.g. via custom stacks or just by setting up the "frontend" middleware stack.
+
+Additionally, extensions can create custom middlewares to modify a HTTP request or response as well.
+
+.. index:: Frontend, PHP-API, FullyScanned, ext:frontend

Documentation/Changelog/9.3/Deprecation-84980-BackendUserAuthentication-addTScommentDeprecated.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84980:
+
+===============================================================
+Deprecation: #84980 - BackendUserAuthentication->addTScomment()
+===============================================================
+
+See :issue:`84980`
+
+Description
+===========
+
+Method :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication->addTScomment()` has been marked as deprecated.
+
+
+Impact
+======
+
+The method has been used to add comments to :typoscript:`TSconfig` at runtime, those
+comments however are never shown in the TYPO3 backend.
+Calling the method directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Instances with extensions calling :php:`BackendUserAuthentication->addTScomment()`
+will trigger a deprecation error.
+It is however rather unlikely that extensions
+rely on this widely unknown API method and method calls were mostly core internal.
+The extension scanner should find possible usages within extensions.
+
+
+Migration
+=========
+
+Drop the method call.
+
+.. index:: Backend, PHP-API, TSConfig, FullyScanned

Documentation/Changelog/9.3/Deprecation-84981-BackendUserAuthentication-simplelogDeprecated.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84981:
+
+============================================================
+Deprecation: #84981 - BackendUserAuthentication->simplelog()
+============================================================
+
+See :issue:`84981`
+
+Description
+===========
+
+Method :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication->simplelog()` has been marked as deprecated.
+
+
+Impact
+======
+
+The method has been a shortcut to :php:`writelog()` which can be used instead.
+
+
+Affected Installations
+======================
+
+Instances with extensions that call this method. Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+The extension scanner should find possible usages.
+
+
+Migration
+=========
+
+Use :php:`writelog()` instead or - even better - use the logging framework to log messages.
+
+.. index:: Backend, PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-84984-ProtectedUserTSconfigPropertiesInBackendUserAuthentication.rst

@@ -0,0 +1,47 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84984:
+
+=====================================================================================
+Deprecation: #84984 - Protected user TSconfig properties in BackendUserAuthentication
+=====================================================================================
+
+See :issue:`84984`
+
+Description
+===========
+
+The following properties of class :php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication` have been set to protected:
+
+* :php:`->userTS`: use method :php:`->getTSConfig()` instead
+* :php:`->userTSUpdated`: Class internal property
+* :php:`->userTS_text`: Class internal property
+* :php:`->TSdataArray`: Class internal property
+* :php:`->userTS_dontGetCached`: Will be removed in v10 without substitution
+
+From the above list, property :php:`->userTS` is the most likely one to be used by extensions.
+As a substitution, the full parsed user TSconfig data array can be retrieved calling method :php:`getTSConfig()`.
+
+
+Impact
+======
+
+The properties are still accessible in v9 from outside of the class but will trigger a PHP :php:`E_USER_DEPRECATED` error if used.
+
+
+Affected Installations
+======================
+
+Instances with extensions that add backend modules which can be configured via user TSconfig may be
+affected by this change. The extension scanner should find possible usages in extensions.
+
+
+Migration
+=========
+
+Use :php:`->getTSConfig()` instead of :php:`->userTS`.
+Do not use the properties marked as internal above.
+Remove usage of :php:`userTS_dontGetCached` and configure the UserTSconfig cache via the caching
+framework's configuration instead.
+
+.. index:: Backend, PHP-API, TSConfig, FullyScanned

Documentation/Changelog/9.3/Deprecation-84993-DeprecateSomeTSconfigRelatedMethods.rst

@@ -0,0 +1,107 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84993:
+
+=============================================================
+Deprecation: #84993 - Deprecate some TSconfig related methods
+=============================================================
+
+See :issue:`84993`
+
+Description
+===========
+
+Some user TSconfig related methods have been deprecated:
+
+* :php:`TYPO3\CMS\core\Authentication\BackendUserAuthentication->getTSConfigVal()`
+* :php:`TYPO3\CMS\core\Authentication\BackendUserAuthentication->getTSConfigProp()`
+
+Changed method signatures:
+
+* :php:`TYPO3\CMS\core\Authentication\BackendUserAuthentication->getTSConfig()`, no argument allowed any longer
+
+Some page TSconfig related methods have been marked as deprecated:
+
+* :php:`TYPO3\CMS\backend\Utility\BackendUtility::getModTSconfig()`
+* :php:`TYPO3\CMS\backend\Utility\BackendUtility::unsetMenuItems()`
+* :php:`TYPO3\CMS\backend\Tree\View\PagePositionMap->getModConfig()`
+* :php:`TYPO3\CMS\core\DataHandling\DataHandler->getTCEMAIN_TSconfig()`
+
+These properties have been set to protected, should not be used any longer and trigger a deprecation error on access:
+
+* :php:`TYPO3\CMS\backend\Tree\View\PagePositionMap->getModConfigCache`
+* :php:`TYPO3\CMS\backend\Tree\View\PagePositionMap->modConfigStr`
+
+
+Impact
+======
+
+Calling the above methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extensions with backend modules may call these methods. The extension scanner
+will find affected code occurrences in extensions.
+
+
+Migration
+=========
+
+Change user TSconfig related calls to use :php:`BackendUserAuthentication->getTSConfig()`
+instead, it comes with a slightly changed return syntax.
+
+:php:`getTSConfig()` without arguments simply returns the entire user TSconfig as array, similar to other
+methods that return parsed TypoScript arrays. The examples below show some imaginary user TSConfig,
+the full parsed array returned by :php:`getTSConfig()` and some typical access patterns with fallback. Note
+it's almost always useful to use the null coalescence :php:`??` operator for a fallback value to suppress
+PHP notice level warnings::
+
+    // Incoming user TSconfig:
+    // options.someToggle = 1
+    // options.somePartWithSubToggles = foo
+    // options.somePartWithSubToggles.aValue = bar
+
+    // Parsed array returned by getTSConfig(), note the dot if a property has sub keys:
+    // [
+    //     'options.' => [
+    //         'someToggle' => '1',
+    //         'somePartWithSubToggles' => 'foo',
+    //         'somePartWithSubToggles.' => [
+    //             'aValue' => 'bar',
+    //         ],
+    //     ],
+    // ],
+    $userTsConfig = $backendUserAuthentication->getTSConfig():
+
+    // Typical call to retrieve a sanitized value:
+    $isToggleEnabled = (bool)($userTsConfig['options.']['someToggle'] ?? false);
+
+    // And to retrieve a sub set, note the dot at the end:
+    $subArray = $userTsConfig['options.']['somePartWithSubToggles.'] ?? [];
+
+    // Switch an old getTSConfigVal() to getTSConfig(), note the parenthesis:
+    $value = (bool)$backendUser->getTSConfigVal('options.someToggle');
+    $value = (bool)($backendUser->getTSConfig()['options.']['someToggle'] ?? false);
+
+    // Switch an old getTSConfigProp() to getTSConfig(), note the parenthesis and the trailing dot:
+    $value = (array)$backendUser->getTSConfigProp('options.somePartWithSubToggles');
+    $value = (array)($backendUser->getTSConfig()['options.']['somePartWithSubToggles.'] ?? []);
+
+
+Change :php:`BackendUtility->getModTSconfig()` related calls to use :php:`BackendUtility::getPagesTSconfig($pid)` instead.
+Note this method does not return the 'properties' and 'value' sub array as :php:`->getModTSconfig()` did::
+
+    // Switch an old getModTSconfig() to getPagesTSConfig() for array of properties:
+    $configArray = BackendUtility::getModTSconfig($pid, 'mod.web_list');
+    $configArray['properties'] = BackendUtility::getPagesTSconfig($pid)['mod.']['web_list.'] ?? [];
+
+    // Switch an old getModTSconfig() to getPagesTSConfig() for single value:
+    $configArray = BackendUtility::getModTSconfig($pid, 'TCEFORM.sys_dmail_group.select_categories.PAGE_TSCONFIG_IDLIST');
+    $configArray['value'] = BackendUtility::getPagesTSconfig($pid)['TCEFORM.']['sys_dmail_group.']['select_categories.']['PAGE_TSCONFIG_IDLIST'] ?? null;
+
+Methods :php:`BackendUtility::unsetMenuItems()` and :php:`DataHandler->getTCEMAIN_TSconfig()` have been rarely used
+and are dropped without substitution. Copy the code into consuming methods if you really need them.
+
+.. index:: Backend, PHP-API, TSConfig, FullyScanned

Documentation/Changelog/9.3/Deprecation-84994-BackendUtilitygetPidForModTSconfigDeprecated.rst

@@ -0,0 +1,35 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84994:
+
+============================================================
+Deprecation: #84994 - BackendUtility::getPidForModTSconfig()
+============================================================
+
+See :issue:`84994`
+
+Description
+===========
+
+Method :php:`TYPO3\CMS\backend\Utility\BackendUtility::getPidForModTSconfig()` has
+been marked as deprecated and should not be used any longer.
+
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extensions that call that method, even if is marked as internal. The extension scanner will find usages.
+
+
+Migration
+=========
+
+Drop the method call and copy the one-liner implementation into consuming code.
+
+.. index:: Backend, PHP-API, TSConfig, FullyScanned

Documentation/Changelog/9.3/Deprecation-85005-DeprecateMethodsAndConstantsInValidatorResolver.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85005:
+
+==========================================================================
+Deprecation: #85005 - Deprecate methods and constants in ValidatorResolver
+==========================================================================
+
+See :issue:`85005`
+
+Description
+===========
+
+The following methods within :php:`TYPO3\CMS\Extbase\Validation\ValidatorResolver` have been marked
+as deprecated:
+
+- :php:`buildSubObjectValidator`
+- :php:`parseValidatorAnnotation`
+- :php:`parseValidatorOptions`
+- :php:`unquoteString`
+
+The following constants within :php:`TYPO3\CMS\Extbase\Validation\ValidatorResolver` have been marked
+as deprecated:
+
+- :php:`PATTERN_MATCH_VALIDATORS`
+- :php:`PATTERN_MATCH_VALIDATOROPTIONS`
+
+Impact
+======
+
+Calling any of the deprecated methods above will trigger a PHP :php:`E_USER_DEPRECATED` error.
+Using any of the deprecated constants above will not ttrigger a PHP :php:`E_USER_DEPRECATED` error but will stop working in TYPO3 v10.0.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a custom extension making use of these methods and constants. As these constants and methods
+are to be considered internal api it's very unlikely that anyone is affected by this change at all.
+
+Migration
+=========
+
+There is none.
+
+.. index:: PHP-API, ext:extbase, PartiallyScanned

Documentation/Changelog/9.3/Deprecation-85012-OnlyValidateMethodParamsIfNeeded.rst

@@ -0,0 +1,40 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85012:
+
+=================================================================================
+Deprecation: #85012 - GetValidationResults of Argument:class and Arguments::class
+=================================================================================
+
+See :issue:`85012`
+
+Description
+===========
+
+The following public methods have been marked as deprecated:
+
+* :php:`TYPO3\CMS\Extbase\Mvc\Controller\Argument::getValidationResults()`
+* :php:`TYPO3\CMS\Extbase\Mvc\Controller\Arguments::getValidationResults()`
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Extensions that call any of the methods. The extension scanner will find usages.
+
+
+Migration
+=========
+
+Use the following methods instead:
+
+* :php:`TYPO3\CMS\Extbase\Mvc\Controller\Argument::validate()`
+* :php:`TYPO3\CMS\Extbase\Mvc\Controller\Arguments::validate()`
+
+
+.. index:: PHP-API, FullyScanned, ext:extbase

Documentation/Changelog/9.3/Deprecation-85016-OverridingPageTSconfigModWithUserTSconfigModDeprecated.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-84982:
+
+===========================================================================
+Deprecation: #84982 - Overriding page TSconfig mod. with user TSconfig mod.
+===========================================================================
+
+See :issue:`84982`
+
+Description
+===========
+
+Overriding page TSconfig properties on a backend user or group basis is usually
+done by prefixing the page TSconfig path with :typoscript:`page.` in user TSconfig.
+
+As an exception, properties within the page TSconfig top level object :typoscript:`mod.` could
+sometimes also be overridden in user TSconfig using :typoscript:`mod.` and omitting :typoscript:`page.`. This
+has been deprecated: :typoscript:`mod.` now needs to be overridden in user TSconfig by prefixing
+the path with :typoscript:`page.`, too.
+
+
+Impact
+======
+
+User TSconfig paths that start with :typoscript:`mod.` will trigger a PHP :php:`E_USER_DEPRECATED` error and will
+stop working with core v10.
+
+
+Affected Installations
+======================
+
+Instances that set TSconfig on backend user or group basis starting with :typoscript:`mod.`.
+
+
+Migration
+=========
+
+Simply prefix the user TSconfig path with :typoscript:`page.` as usual if overriding page TSconfig
+on user TSconfig level. Example:
+
+.. code-block:: typoscript
+
+   // Before
+   mod.web_list.disableSingleTableView = 1
+   // After
+   page.mod.web_list.disableSingleTableView = 1
+
+.. index:: Backend, TSConfig, NotScanned

Documentation/Changelog/9.3/Deprecation-85027-SaltedPasswordsRelatedMethodsAndClasses.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85027:
+
+==============================================================
+Deprecation: #85027 - SaltedPasswordsUtility::isUsageEnabled()
+==============================================================
+
+See :issue:`85027`
+
+Description
+===========
+
+The following method of the saltedpasswords extension has been marked as deprecated:
+
+* :php:`TYPO3\CMS\saltedpasswords\Utility\SaltedPasswordsUtility::isUsageEnabled()`, it always returns TRUE.
+
+
+Impact
+======
+
+Relying on clear-text password storage has been dropped, passwords are always stored as salted password hashes.
+
+
+Affected Installations
+======================
+
+Instances that use third party authentication mechanisms may be affected by the change.
+The extension scanner will find usages.
+
+
+Migration
+=========
+
+Use the authentication services documented in the core API to not rely on clear-text password storage and the method mentioned above.
+
+.. index:: Database, Frontend, LocalConfiguration, PHP-API, FullyScanned, ext:saltedpasswords

Documentation/Changelog/9.3/Deprecation-85078-PageRepositoryVersioningPreview.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85078:
+
+=======================================================
+Deprecation: #85078 - PageRepository->versioningPreview
+=======================================================
+
+See :issue:`85078`
+
+Description
+===========
+
+The public property :php:`$versioningPreview` in :php:`TYPO3\CMS\Frontend\Page\PageRepository` has been marked
+as deprecated. The property was used in conjunction with :php:`$versioningWorkspaceId` which is set to a workspace
+ID, in order to preview records of a workspace.
+
+In order to ease the functionality for developers, only :php:`$versioningWorkspaceId` is taken into account now,
+without needing to set :php:`$versioningPreview` anymore.
+
+
+Impact
+======
+
+Setting or reading this option will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions using this property.
+
+
+Migration
+=========
+
+Just set :php:`$versioningWorkspaceId` and remove any calls to the property.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85086-GeneralUtilityArrayToLogString.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85086:
+
+========================================================
+Deprecation: #85086 - GeneralUtility::arrayToLogString()
+========================================================
+
+See :issue:`85086`
+
+Description
+===========
+
+The method :php:`GeneralUtility::arrayToLogString()`, responsible for formatting an array to a string
+ready for logging or output, has been marked as deprecated.
+
+
+Impact
+======
+
+Calling the method directly will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with third-party extensions using this method.
+
+
+Migration
+=========
+
+For logging purposes, switch to PSR-3 compatible logging where a log-writer is taking care of outputting / storing
+this information properly.
+
+For other purposes, like CLI-command output, it is recommended to implement this functionality directly in the
+corresponding CLI command.
+
+.. index:: CLI, PHP-API, FullyScanned, ext:core

Documentation/Changelog/9.3/Deprecation-85102-PhpOptionsUtility.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85102:
+
+=======================================
+Deprecation: #85102 - PhpOptionsUtility
+=======================================
+
+See :issue:`85102`
+
+Description
+===========
+
+The PHP class :php:`\TYPO3\CMS\Core\Utility\PhpOptionsUtility` has been marked as deprecated.
+
+The only purpose for this class was to check for available session handling in the installer.
+
+
+Impact
+======
+
+Calling any method in this class will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Installations checking for session handling in custom extensions.
+
+
+Migration
+=========
+
+Implement the :php:`filter_var()` and :php:`ini_get()` used in the PhpOptionsUtility wrapper yourself.
+
+.. index:: PHP-API, FullyScanned, ext:core

Documentation/Changelog/9.3/Deprecation-85113-LegacyBackendModuleRoutingMethods.rst

@@ -0,0 +1,49 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85113:
+
+===========================================================
+Deprecation: #85113 - Legacy Backend Module Routing methods
+===========================================================
+
+See :issue:`85113`
+
+Description
+===========
+
+In TYPO3 v9, Backend routing was unified to be handled via the "route" query string parameter. Backend modules
+are now automatically registered to be a backend route.
+
+The following methods are thus deprecated in favor of using the method above.
+
+* :php:`BackendUtility::getModuleUrl()`
+* :php:`UriBuilder->buildUriFromModule()`
+
+
+Impact
+======
+
+Calling one of the deprecated methods above will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Any TYPO3 installation with a custom backend-related extension using one of the methods directly in a PHP context.
+
+
+Migration
+=========
+
+Use :php:`UriBuilder->buildUriFromRoute($moduleIdentifier)` instead.
+
+For example ::
+
+   BackendUtility::getModuleUrl('record_edit', $uriParameters);
+
+becomes ::
+
+   $uriBuilder = GeneralUtility::makeInstance(UriBuilder::class);
+   $uriBuilder->buildUriFromRoute('record_edit', $uriParameters);
+
+.. index:: Backend, PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85120-JavaScriptEncoder.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85120:
+
+=======================================
+Deprecation: #85120 - JavaScriptEncoder
+=======================================
+
+See :issue:`85120`
+
+Description
+===========
+
+The standalone utility class :php:`TYPO3\CMS\Core\Encoder\JavaScriptEncoder` has been superseded in TYPO3 6.2
+by PHP's native :php:`json_encode()` and :php:`GeneralUtility::quoteJSvalue()` which provide significant
+performance improvements. The utility class is thus marked for removal in TYPO3 v10.0.
+
+
+Impact
+======
+
+Instantiating the class will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions using this PHP class.
+
+
+Migration
+=========
+
+Use :php:`GeneralUtility::quoteJSvalue()` or :php:`json_encode()` with proper options as second parameter to
+escape a string for JavaScript output.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85122-FunctionalityInCharsetConverter.rst

@@ -0,0 +1,54 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85122:
+
+=======================================================
+Deprecation: #85122 - Functionality in CharsetConverter
+=======================================================
+
+See :issue:`85122`
+
+Description
+===========
+
+The following methods have been marked as deprecated due to better functionality mostly provided by native
+PHP functionality, like :php:`mbstring` functions.
+
+- :php:`CharsetConverter->synonyms`
+- :php:`CharsetConverter->parse_charset()`
+- Fourth parameter of :php:`CharsetConverter->conv()`
+- :php:`CharsetConverter->convArray()`
+- :php:`CharsetConverter->utf8_to_entities()`
+- :php:`CharsetConverter->entities_to_utf8()`
+- :php:`CharsetConverter->crop()`
+- :php:`CharsetConverter->convCaseFirst()`
+- :php:`CharsetConverter->utf8_char2byte_pos()`
+
+Additionally the following public properties have been changed to have a "protected" visibility,
+as these only reflect internal state:
+
+- :php:`CharsetConverter->noCharByteVal`
+- :php:`CharsetConverter->parsedCharsets`
+- :php:`CharsetConverter->toASCII`
+- :php:`CharsetConverter->twoByteSets`
+- :php:`CharsetConverter->eucBasedSets`
+
+
+Impact
+======
+
+Calling any of the methods or accessing any of the properties will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with extensions making use of the CharsetConverter methods or properties directly.
+
+
+Migration
+=========
+
+Use native PHP equivalents instead, see the methods directly for substitutes.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85123-ConstantsRelatedToServices.rst

@@ -0,0 +1,46 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85123:
+
+===================================================
+Deprecation: #85123 - Constants related to Services
+===================================================
+
+See :issue:`85123`
+
+Description
+===========
+
+The following constants have been marked as deprecated, and will be removed in TYPO3 v10.0.
+
+- :php:`T3_ERR_SV_GENERAL`
+- :php:`T3_ERR_SV_NOT_AVAIL`
+- :php:`T3_ERR_SV_WRONG_SUBTYPE`
+- :php:`T3_ERR_SV_NO_INPUT`
+- :php:`T3_ERR_SV_FILE_NOT_FOUND`
+- :php:`T3_ERR_SV_FILE_READ`
+- :php:`T3_ERR_SV_FILE_WRITE`
+- :php:`T3_ERR_SV_PROG_NOT_FOUND`
+- :php:`T3_ERR_SV_PROG_FAILED`
+
+The according constants have been moved to class constants of :php:`TYPO3\CMS\Core\Service\AbstractService`.
+
+
+Impact
+======
+
+These constants will not trigger a deprecation warning, however they will result in a fatal error in TYPO3 v10.0.
+
+
+Affected Installations
+======================
+
+TYPO3 Installations with extensions using these constants or having custom services using these constants.
+
+
+Migration
+=========
+
+Use the class constants provided within :php:`TYPO3\CMS\Core\Service\AbstractService`.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85124-RedirectingUrlHandlerHookConcept.rst

@@ -0,0 +1,42 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85124:
+
+=========================================================
+Deprecation: #85124 - Redirecting urlHandler Hook Concept
+=========================================================
+
+See :issue:`85124`
+
+Description
+===========
+
+The URL handler concept introduced in TYPO3 v7 to allow pages to do redirects has been deprecated in favor
+of using PSR-7 / PSR-15 middlewares.
+
+The Redirect URL handlers were used for e.g. jumpURLs, pages that should redirect to an external URL
+or special handlings registered via the :php:`\TYPO3\CMS\Frontend\Http\UrlHandlerInterface`.
+
+All functionality and methods have been marked as deprecated and will be removed in TYPO3 v10.0.
+
+
+Impact
+======
+
+Calling :php:`$TSFE->initializeRedirectUrlHandlers()` and :php:`$TSFE->redirectToExternalUrl()` will
+trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 Installations with extensions registering a urlHandler via
+:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['urlProcessing']['urlHandlers']`.
+
+
+Migration
+=========
+
+Check the extension scanner if the site is affected and migrate to a PSR-15 middleware.
+
+.. index:: Frontend, PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85125-UsagesOfCharsetConverterInCore.rst

@@ -0,0 +1,43 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85125:
+
+==================================================================
+Deprecation: #85125 - Deprecate usages of CharsetConverter in core
+==================================================================
+
+See :issue:`85125`
+
+Description
+===========
+
+The following method has been marked as deprecated:
+
+- :php:`TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver->getCharsetConversion()`
+
+The following public properties have been deprecated:
+
+- :php:`TYPO3\CMS\IndexedSearch\Lexer->csObj`
+- :php:`TYPO3\CMS\IndexedSearch\Indexer->csObj`
+
+
+Impact
+======
+
+Calling the method or accessing any of the properties will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 Installations with custom FAL drivers or special handling for indexed search extending the
+Lexer functionality.
+
+
+Migration
+=========
+
+Check the extension scanner if the site is affected and instantiate CharsetConverter directly in the
+callers' code.
+
+.. index:: PHP-API, FullyScanned

Documentation/Changelog/9.3/Deprecation-85130-TSFE-getPageShortcutMovedToPageRepository.rst

@@ -0,0 +1,37 @@
+.. include:: /Includes.rst.txt
+
+.. _deprecation-85130:
+
+======================================================================
+Deprecation: #85130 - $TSFE->getPageShortcut() moved to PageRepository
+======================================================================
+
+See :issue:`85130`
+
+Description
+===========
+
+The method :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::getPageShortcut()` has been
+moved to :php:`TYPO3\CMS\Frontend\Page\PageRepository::getPageShortcut()`, as it conceptually belongs in
+this class.
+
+
+Impact
+======
+
+Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+TYPO3 installations using the method directly in an extension.
+
+
+Migration
+=========
+
+Switch the call :php:`$GLOBALS['TSFE']->getPageShortcut()` to :php:`$GLOBALS['TSFE']->sys_page->getPageShortcut()` to receive the exact
+same result without a deprecation message.
+
+.. index:: Frontend, PHP-API, PartiallyScanned

Documentation/Changelog/9.3/Feature-69274-PreserveImageRotationIfOrientIsSavedInExif.rst

@@ -0,0 +1,27 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-69274:
+
+====================================================================
+Feature: #69274 - Preserve image rotation if orient is saved in exif
+====================================================================
+
+See :issue:`69274`
+
+Description
+===========
+
+Many photo cameras nowadays store pictures in the native sensor orientation.
+The real orientation is stored as meta information in the EXIF data.
+
+TYPO3 now recognizes this image orientation and uses it when reading the image dimensions and
+uses this info when scaling/cropping (processing) the image.
+
+
+Impact
+======
+
+Images with an orientation other than 0 degrees are now properly scaled/cropped (processed).
+Thumbnails in the Backend and processed images in the Frontend are presented in the correct orientation.
+
+.. index:: FAL, ext:core

Documentation/Changelog/9.3/Feature-71644-AddMetadataToFilebrowserSearch.rst

@@ -0,0 +1,16 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-71644:
+
+====================================================
+Feature: #71644 - Add metadata to filebrowser search
+====================================================
+
+See :issue:`71644`
+
+Description
+===========
+
+This change is now superseded by a more solid solution with `#87610`, which also respects folders in file search.
+
+.. index:: Backend, ext:filelist

Documentation/Changelog/9.3/Feature-79889-SaltedpasswordsSupportPHPPasswordAPI.rst

@@ -0,0 +1,26 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-79889:
+
+===========================================================
+Feature: #79889 - Saltedpasswords supports PHP password API
+===========================================================
+
+See :issue:`79889`
+
+Description
+===========
+
+Salted passwords now supports the PHP Password Hashing API: https://secure.php.net/manual/en/ref.password.php
+
+The two hash algorithms `bcrypt` and `argon2i` are available and can be selected in the
+settings of the salted passwords extension if the PHP instance supports them.
+
+Impact
+======
+
+None. You can start to use the new password hashing methods by selecting "Standard PHP password hashing (bcrypt)"
+or "Standard PHP password hashing (argon2i)" in Extension Manager Configuration of saltedpasswords. Password
+hashes of existing users will be updated as soon as users log in.
+
+.. index:: Backend, Frontend, PHP-API, ext:saltedpasswords

Documentation/Changelog/9.3/Feature-81464-AddAPIForMetaTagManagement.rst

@@ -0,0 +1,117 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-81464:
+
+=================================================
+Feature: #81464 - Add API for meta tag management
+=================================================
+
+See :issue:`81464`
+
+Description
+===========
+
+In order to have the possibility to set metatags in a flexible (but regulated way), a new Meta Tag API is introduced.
+
+The API uses :php:`MetaTagManagers` to manage the tags for a "family" of meta tags. The core e.g. ships an
+OpenGraph MetaTagManager that is responsible for all OpenGraph tags.
+In addition to the MetaTagManagers included in the core, you can also register your own
+:php:`MetaTagManager` in the :php:`MetaTagManagerRegistry`.
+
+Using the Meta Tag API
+======================
+
+To use the API, first get the right :php:`MetaTagManager` for your tag from the :php:`MetaTagManagerRegistry`.
+You can use that manager to add your meta tag; see the example below for the :html:`og:title` meta tag.
+
+.. code-block:: php
+
+    $metaTagManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\MetaTag\MetaTagManagerRegistry::class)->getManagerForProperty('og:title');
+    $metaTagManager->addProperty('og:title', 'This is the OG title from a controller');
+
+This code will result in a :html:`<meta property="og:title" content="This is the OG title from a controller" />` tag in frontend.
+
+If you need to specify sub-properties, e.g. :html:`og:image:width`, you can use the following code:
+
+.. code-block:: php
+
+    $metaTagManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\MetaTag\MetaTagManagerRegistry::class)->getManagerForProperty('og:image');
+    $metaTagManager->addProperty('og:image', '/path/to/image.jpg', ['width' => 400, 'height' => 400]);
+
+You can also remove a specific property:
+
+.. code-block:: php
+
+    $metaTagManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\MetaTag\MetaTagManagerRegistry::class)->getManagerForProperty('og:title');
+    $metaTagManager->removeProperty('og:title');
+
+Or remove all previously set meta tags of a specific manager:
+
+.. code-block:: php
+
+    $metaTagManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\MetaTag\MetaTagManagerRegistry::class)->getManagerForProperty('og:title');
+    $metaTagManager->removeAllProperties();
+
+
+Creating your own MetaTagManager
+================================
+
+If you need to specify the settings and rendering of a specific meta tag (for example when you want to make it possible
+to have multiple occurrences of a specific tag), you can create your own :php:`MetaTagManager`.
+This MetaTagManager should implement :php:`\TYPO3\CMS\Core\MetaTag\MetaTagManagerInterface`.
+
+To use the manager, you must register it in :php:`ext_localconf.php`:
+
+.. code-block:: php
+
+    $metaTagManagerRegistry = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\MetaTag\MetaTagManagerRegistry::class);
+    $metaTagManagerRegistry->registerManager(
+        'custom',
+        \Some\CustomExtension\MetaTag\CustomMetaTagManager::class
+    );
+
+Registering a :php:`MetaTagManager` works with the :php:`DependencyOrderingService`. So you can also specify the
+priority of the manager by setting the third (before) and fourth (after) parameter of the method. If you for example
+want to implement your own :php:`OpenGraphMetaTagManager`, you can use the following code:
+
+.. code-block:: php
+
+    $metaTagManagerRegistry = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\MetaTag\MetaTagManagerRegistry::class);
+    $metaTagManagerRegistry->registerManager(
+        'myOwnOpenGraphManager',
+        \Some\CustomExtension\MetaTag\MyOpenGraphMetaTagManager::class,
+        ['opengraph']
+    );
+
+This will result in :php:`MyOpenGraphMetaTagManager` having a higher priority and it will first check if your own
+manager can handle the tag before it checks the default manager provided by the core.
+
+TypoScript and PHP
+==================
+
+You can set your meta tags by TypoScript and PHP (for example from plugins). First the meta tags from content (plugins)
+will be handled. After that the meta tags defined in TypoScript will be handled.
+
+It is possible to override earlier set meta tags by TypoScript if you explicitly say this should happen. Therefore the
+:typoscript:`meta.*.replace` option was introduced. It is a boolean flag with these values:
+
+* :typoscript:`1`: The meta tag set by TypoScript will replace earlier set meta tags
+* :typoscript:`0`: (default) If the meta tag is not set before, the meta tag will be created. If it is already set, it will ignore the meta tag set by TypoScript.
+
+.. code-block:: typoscript
+
+    page.meta {
+        og:site_name = TYPO3
+        og:site_name.attribute = property
+        og:site_name.replace = 1
+    }
+
+When you set the property replace to :typoscript:`1` at the specific tag, the tag will replace tags that are set from plugins.
+
+Impact
+======
+
+By using the new API it is not possible to have duplicate metatags, unless this is explicitly allowed. If you use custom
+meta tags and want to have multiple occurrences of the same meta tag, you have to create your own :php:`MetaTagManager`.
+
+.. index:: ext:core

Documentation/Changelog/9.3/Feature-81794-PasswordFieldsInTheInstallTool.rst

@@ -0,0 +1,22 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-81794:
+
+=====================================================
+Feature: #81794 - Password fields in the Install tool
+=====================================================
+
+See :issue:`81794`
+
+Description
+===========
+
+Now it is possible to define password fields in the Install tool configuration with "type : password".
+
+
+Impact
+======
+
+Field Mail/transport_smtp_password uses a password field.
+
+.. index:: LocalConfiguration

Documentation/Changelog/9.3/Feature-82511-ExtFormAddHtml5DateElement.rst

@@ -0,0 +1,107 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-82511:
+
+======================================================
+Feature: #82511 - EXT:form add HTML5 date form element
+======================================================
+
+See :issue:`82511`
+
+Description
+===========
+
+
+Date form element
+-----------------
+
+The form framework contains a new form element called :yaml:`Date` which is technically an HTML5 'date'
+form element.
+
+The following snippet shows a comprehensive example on how to use the new element within the form
+definition including the new :yaml:`DateRange` validator:
+
+.. code-block:: yaml
+
+    type: Date
+    identifier: date-1
+    label: Date
+    defaultValue: '2018-03-02'
+    properties:
+      # default if not defined: 'd.m.Y' (https://php.net/manual/de/datetime.createfromformat.php#refsect1-datetime.createfromformat-parameters)
+      displayFormat: 'd.m.Y'
+      fluidAdditionalAttributes:
+        min: '2018-03-01'
+        max: '2018-03-30'
+        step: '1'
+    validators:
+      -
+        identifier: DateRange
+        options:
+          minimum: '2018-03-01'
+          maximum: '2018-03-30'
+
+The properties :yaml:`defaultValue`, :yaml:`properties.fluidAdditionalAttributes.min`,
+:yaml:`properties.fluidAdditionalAttributes.max` and the :yaml:`DateRange` validator options :yaml:`minimum` and
+:yaml:`maximum` must have the format 'Y-m-d' which represents the RFC 3339 'full-date' format.
+
+Read more: https://www.w3.org/TR/2011/WD-html-markup-20110405/input.date.html
+
+The :yaml:`DateRange` validator is the server side validation equivalent to the client side validation
+through the :yaml:`min` and :yaml:`max` HTML attribute and should always be used in combination.
+If the :yaml:`DateRange` validator is added to the form element within the form editor, the :html:`min` and
+:html:`max` HTML attributes are added automatically.
+
+The property :yaml:`properties.displayFormat` defines the display format of the submitted value within the
+summary step, email finishers etc. but **not** for the form element value itself.
+The display format of the form element value depends on the browser settings and can not be defined!
+
+Read more: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#Value
+
+Browsers which do not support the HTML5 date element gracefully degrade to a text input.
+The HTML5 date element always normalizes the value to the format Y-m-d (RFC 3339 'full-date').
+With a text input, by default the browser has no recognition of which format the date should be in.
+A workaround could be to put a pattern attribute on the date input. Even though the date input does
+not use it, the text input fallback will. By default, the HTML attribute
+'pattern="([0-9]{4})-(0[1-9]|1[012])-(0[1-9]|1[0-9]|2[0-9]|3[01])"' is rendered on the date form
+element. Note that this basic regular expression does not support leap years and does not check for
+the correct number of days in a month. But as a start, this should be sufficient.
+The same pattern is used by the form editor to validate the properties :yaml:`defaultValue` and the
+:yaml:`DateRange` validator options :yaml:`minimum` and :yaml:`maximum`.
+
+Read more: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#Handling_browser_support
+
+
+DateRange server side validation
+--------------------------------
+
+A new validator called DateRange is available.
+The input must be a DateTime object.
+This input can be tested against a minimum date and a maximum date.
+The minimum date and the maximum date are strings.
+The minimum date and the maximum date can be configured through the validator options.
+
+.. code-block:: yaml
+
+    validators:
+      -
+        identifier: DateRange
+        options:
+          # The PHP \DateTime object format of the `minimum` and `maximum` option
+          # @see https://php.net/manual/de/datetime.createfromformat.php#refsect1-datetime.createfromformat-parameters
+          # 'Y-m-d' is the default value of this validator and must have this value
+          # if you use this validator in combination with the `Date` form element.
+          # This is because the HTML5 date value is always a RFC 3339 'full-date' format (Y-m-d)
+          # @see https://www.w3.org/TR/2011/WD-html-markup-20110405/input.date.html#input.date.attrs.value
+          format : 'Y-m-d'
+          minimum: '2018-03-01'
+          maximum: '2018-03-30'
+
+
+Impact
+======
+
+It is now possible to add an HTML5 date form element including corresponding HTML attributes and
+validators.
+
+.. index:: Frontend, Backend, ext:form

Documentation/Changelog/9.3/Feature-83167-ReplaceValidateWithTYPO3CMSExtbaseAnnotationValidate.rst

@@ -0,0 +1,73 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-83167:
+
+===================================================================================
+Feature: #83167 - Replace @validate with @TYPO3\\CMS\\Extbase\\Annotation\\Validate
+===================================================================================
+
+See :issue:`83167`
+
+Description
+===========
+
+As a successor to the :php:`@validate` annotation, the doctrine annotation
+:php:`@TYPO3\CMS\Extbase\Annotation\Validate` has been introduced.
+
+
+Example:
+--------
+
+.. code-block:: php
+
+	/**
+	 * @TYPO3\CMS\Extbase\Annotation\Validate
+	 * @var Foo
+	 */
+	public $property;
+
+Doctrine annotations are actual defined classes, therefore you can also use the annotation with a use statement.
+
+
+Example:
+--------
+
+.. code-block:: php
+
+	use TYPO3\CMS\Extbase\Annotation\Validate;
+
+.. code-block:: php
+
+	/**
+	 * @Validate
+	 * @var Foo
+	 */
+	public $property;
+
+Used annotations can also be aliased which the core will most likely be using a lot in the future.
+
+
+Example:
+--------
+
+.. code-block:: php
+
+	use TYPO3\CMS\Extbase\Annotation as Extbase;
+
+.. code-block:: php
+
+	/**
+	 * @Extbase\Validate
+	 * @var Foo
+	 */
+	public $property;
+
+
+Impact
+======
+
+In v9 there is no actual impact. Both the simple :php:`@validate` and
+:php:`@TYPO3\CMS\Extbase\Annotation\Validate` can be used side by side.
+However, :php:`@validate` is deprecated in v9 and will be removed in v10.
+
+.. index:: PHP-API, ext:extbase, FullyScanned

Documentation/Changelog/9.3/Feature-83983-ImprovedModuleLinkViewHelper.rst

@@ -0,0 +1,34 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-83983:
+
+===============================================
+Feature: #83983 - Improved ModuleLinkViewHelper
+===============================================
+
+See :issue:`83983`
+
+Description
+===========
+
+The class :php:`\TYPO3\CMS\Backend\ViewHelpers\ModuleLinkViewHelper` has been improved by
+providing two additional arguments:
+
+- `query`: Allow defining query parameters also as string
+- `currentUrlParameterName`: The given argument is filled with the current URL
+
+With this change it is easily possible to migrate existing custom backend route viewhelpers to this one viewhelper.
+
+For example:
+
+Before::
+
+   {bu:editRecord(parameters: 'edit[be_users][{backendUser.uid}]=edit&returnUrl={returnUrl}')}
+
+After ::
+
+   {be:moduleLink(route: 'record_edit', query: 'edit[be_users][{backendUser.uid}]=edit&returnUrl={returnUrl}')}
+
+... and the editRecord ViewHelper of be_user could be deprecated.
+
+.. index:: Backend, ext:backend

Documentation/Changelog/9.3/Feature-84650-IntroduceLanguageMenuProcessor.rst

@@ -0,0 +1,61 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84650:
+
+===================================================================
+Feature: #84650 - Introduce fluid data processor for language menus
+===================================================================
+
+See :issue:`84650`
+
+Description
+===========
+
+This feature introduces a new :typoscript:`LanguageMenuProcessor` for Fluid based
+language menus based on the languages defined for the current site.
+
+Options
+-------
+
+:`if`:         TypoScript if condition
+:`languages`:  A list of comma separated language IDs (e.g. 0,1,2) to use for
+               the menu creation or `auto` to load from site languages
+:`as`:         The variable to be used within the result
+
+Example TypoScript configuration
+--------------------------------
+
+.. code-block:: typoscript
+
+   10 = TYPO3\CMS\Frontend\DataProcessing\LanguageMenuProcessor
+   10 {
+      languages = auto
+      as = languageNavigation
+   }
+
+
+Example Fluid-Template
+----------------------
+
+.. code-block:: html
+
+   <f:if condition="{languageNavigation}">
+      <ul id="language" class="language-menu">
+         <f:for each="{languageNavigation}" as="item">
+            <li class="{f:if(condition: item.active, then: 'active')}{f:if(condition: item.available, else: ' text-muted')}">
+               <f:if condition="{item.available}">
+                  <f:then>
+                     <a href="{item.link}" hreflang="{item.hreflang}" title="{item.navigationTitle}">
+                        <span>{item.navigationTitle}</span>
+                     </a>
+                  </f:then>
+                  <f:else>
+                     <span>{item.navigationTitle}</span>
+                  </f:else>
+               </f:if>
+            </li>
+         </f:for>
+      </ul>
+   </f:if>
+
+.. index:: Fluid, TypoScript, Frontend

Documentation/Changelog/9.3/Feature-84749-HideDuplicateButtonByDefault.rst

@@ -0,0 +1,25 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84749:
+
+====================================================
+Feature: #84749 - Hide "duplicate" button by default
+====================================================
+
+See :issue:`84749`
+
+Description
+===========
+
+The "duplicate" button visibility can now be managed with userTsConfig using:
+
+-  :typoscript:`options.showDuplicate = 1`
+-  :typoscript:`options.showDuplicate.[table] = 1`
+
+
+Impact
+======
+
+The button was only introduced in 9.0, but would with this change be hidden again.
+
+.. index:: Backend, TSConfig, ext:backend

Documentation/Changelog/9.3/Feature-84760-TypoScriptConditionsForSiteAndSiteLanguage.rst

@@ -0,0 +1,36 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84760:
+
+=================================================================
+Feature: #84760 - TypoScript conditions for site and siteLanguage
+=================================================================
+
+See :issue:`84760`
+
+Description
+===========
+
+Two new TypoScript conditions have been added which makes it possible to interact on the new site configuration.
+
+**Condition for the properties of a site object**
+
+The identifier of the site name is evaluated:
+
+.. code-block:: typoscript
+
+	[site("identifier") == "someIdentifier"]
+		page.30.value = foo
+	[global]
+
+**Condition for the site language**
+
+Any property of the current site language is evaluated:
+
+.. code-block:: typoscript
+
+	[siteLanguage("locale") == "de_CH.UTF-8"]
+		page.40.value = bar
+	[global]
+
+.. index:: TypoScript

Documentation/Changelog/9.3/Feature-84775-ExtendHMENUForLanguageMenus.rst

@@ -0,0 +1,39 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84775:
+
+============================================================================================
+Feature: #84775 - Extend HMENU to support auto filling of special.value for special=language
+============================================================================================
+
+See :issue:`84775`
+
+Description
+===========
+
+This feature extends the :typoscript:`HMENU` content object to support the auto filling of
+:typoscript:`special.value` for language menus with the site languages available for the
+current site. Setting :typoscript:`special.value` to :typoscript:`auto` will include all available
+languages from the current site.
+
+In case of :typoscript:`special.value = auto` the register :typoscript:`languages_HMENU` will be set
+with the determined IDs for the further usage in TypoScript.
+
+Changed options
+---------------
+
+:`special.value`:  A list of comma separated language IDs (e.g. 0,1,2) or
+                   :typoscript:`auto` to load the list from site languages
+
+Example TypoScript configuration
+--------------------------------
+
+.. code-block:: typoscript
+
+   10 = HMENU
+   10 {
+      special = language
+      special.value = auto
+   }
+
+.. index:: Frontend, TypoScript

Documentation/Changelog/9.3/Feature-84780-RemoveEntriesInLocalStorageByKeyPrefix.rst

@@ -0,0 +1,33 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84780:
+
+==============================================================
+Feature: #84780 - Remove entries in localStorage by key prefix
+==============================================================
+
+See :issue:`84780`
+
+Description
+===========
+
+The localStorage wrapper :js:`TYPO3/CMS/Backend/Storage/Client` is now capable of removing entries in the localStorage
+by a specific key prefix.
+
+
+Impact
+======
+
+The method :js:`Client.unsetByPrefix()` takes the prefix as argument. As all keys are internally namespaced with a :js:`t3-`
+prefix, this must be omitted in the requested prefix.
+
+Example:
+
+.. code-block:: javascript
+
+	function foo() {
+	    // Removes any localStorage entry whose key starts with "t3-bar-"
+	    Client.unsetByPrefix('bar-');
+	}
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/9.3/Feature-84780-StoreIconsFetchedByTheIconAPIInLocalStorage.rst

@@ -0,0 +1,18 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84780-1668719171:
+
+=====================================================================
+Feature: #84780 - Store icons fetched by the Icon API in localStorage
+=====================================================================
+
+See :issue:`84780`
+
+Description
+===========
+
+Icons that get fetched by the JavaScript-based Icon API are now stored in the localStorage of the client.
+A hash is calculated based on the state of the IconRegistry and stored in the localStorage as well to determine whether
+the icon markup needs to get refetched from the server.
+
+.. index:: Backend, JavaScript, ext:backend

Documentation/Changelog/9.3/Feature-84798-AddSEOFieldsToPagesTCA.rst

@@ -0,0 +1,38 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84798:
+
+=============================================
+Feature: #84798 - Add SEO fields to Pages TCA
+=============================================
+
+See :issue:`84798`
+
+Description
+===========
+
+A new system extension called SEO is introduced.
+
+This extension adds SEO fields to Pages TCA. When this extension is
+installed, a new tab `SEO` appears in the `Page module` which contains SEO related metadata.
+Other non-SEO metadata is still on the `Metadata` tab.
+
+
+Impact
+======
+
+Integrators can add both Open Graph and Twitter Card metadata for each page.
+
+New fields added to Pages table:
+
+- `seo_title`
+- `no_index`
+- `no_follow`
+- `og_title`
+- `og_description`
+- `og_image`
+- `twitter_title`
+- `twitter_description`
+- `twitter_image`
+
+.. index:: Backend, Database, TCA, ext:seo

Documentation/Changelog/9.3/Feature-84894-AddRuntimeCacheWriterToLoggingFramework.rst

@@ -0,0 +1,31 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84894:
+
+=============================================================
+Feature: #84894 - Add RuntimeCacheWriter to Logging Framework
+=============================================================
+
+See :issue:`84894`
+
+Description
+===========
+
+A new log writer has been added with the ability to write log entries to the TYPO3 runtime cache.
+The writer can be configured via the normal logging framework writer configuration.
+It logs the full log record in the database and uses the given component as cache tag.
+
+Usage
+======
+
+Example usage ::
+
+   $GLOBALS['TYPO3_CONF_VARS']['LOG']['mycomponent'] = [
+       'writerConfiguration' => [
+           \TYPO3\CMS\Core\Log\LogLevel::DEBUG => [
+               \TYPO3\CMS\Core\Log\Writer\RuntimeCacheWriter::class => [],
+           ],
+       ],
+   ];
+
+.. index:: Backend, Frontend, PHP-API, ext:core

Documentation/Changelog/9.3/Feature-84932-SortSubpagesByNavTitle.rst

@@ -0,0 +1,17 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84932:
+
+============================================
+Feature: #84932 - Sort subpages by nav_title
+============================================
+
+See :issue:`84932`
+
+Description
+===========
+
+Sorting subpages of a page - available via the Context Menu of a page - allows to sort by the `nav_title` database
+field called "Alternative Navigation Title".
+
+.. index:: Backend

Documentation/Changelog/9.3/Feature-84983-BEViewHelperForEditDocumentController.rst

@@ -0,0 +1,92 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-84983:
+
+==========================================================
+Feature: #84983 - BE ViewHelper for EditDocumentController
+==========================================================
+
+See :issue:`84983`
+
+Description
+===========
+
+Linking to FormEngine / EditDocumentController in fluid templates of backend modules
+to edit database records and to create new records, has been simplified by introducing
+a series of new view helpers.
+
+Usage:
+======
+
+New record URI and Link view helper
+-----------------------------------
+
+Outputs the uri / the link to bring up FormEngine with the create new record form.
+
+Available view helper arguments:
+
+table
+    Mandatory. The database table the record belongs to.
+
+uid
+    Optional. Negative value of the uid of the record the new record should be placed after. Must be negative!
+
+pid
+    Optional. The pid of the page the record should be placed to. Must be zero or positive. If not given, defaults to zero (root page).
+
+returnUrl
+    Optional. If given, the form redirects to that URL after save / close.
+
+.. note::
+
+    The ViewHelper accepts either pid or uid to be set, not both. If none is set, the record will be put to pid 0,
+    if the TCA configuration of the table allows this.
+
+
+.. code-block:: html
+
+    <!-- URI to add a new news record on page 11 -->
+    <be:uri.newRecord pid="11" table="tx_news_domain_model_news" />
+
+    <!-- URI to add a new news record on root page -->
+    <be:uri.newRecord table="tx_news_domain_model_news" />
+
+    <!-- URI to add a new news record sorted after news record 17 and on the same pid as record 17 -->
+    <be:uri.newRecord uid=-17 table="tx_news_domain_model_news" />
+
+    <!-- Full link to add a new news record on page 25 -->
+    <be:link.newRecord pid="25" table="tx_news_domain_model_news">create news article</be:link.newRecord>
+
+
+Edit record URI and Link view helper
+------------------------------------
+
+Outputs the uri / the link to bring up FormEngine with the records edit form.
+
+Available view helper arguments:
+
+table
+    Mandatory. The database table the record belongs to.
+
+uid
+    Mandatory. The uid of the record to be edited.
+
+returnUrl
+    Optional. If given, the form redirects to that URL after save / close.
+
+
+.. code-block:: html
+
+    <!-- URI to edit the news record with uid 43 -->
+    <be:uri.editRecord uid="43" table="tx_news_domain_model_news" />
+
+    <!-- Link to edit the news record with uid 43 -->
+    <be:link.editRecord uid="43" table="tx_news_domain_model_news" />
+
+
+Impact
+======
+
+Extensions must no longer provide their own ViewHelpers for editing and creating records. The ones provided from ext:backend are public API.
+
+.. index:: Backend, Fluid, ext:backend

Documentation/Changelog/9.3/Feature-85017-UserTSconfigShowInConfigurationModule.rst

@@ -0,0 +1,23 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85017:
+
+=============================================================
+Feature: #85017 - User TSconfig shown in Configuration module
+=============================================================
+
+See :issue:`85017`
+
+Description
+===========
+
+The user TSconfig array of the currently logged in user can be surfed in
+the System -> Configuration module.
+
+
+Impact
+======
+
+Backend administrators can check their user TSconfig in the configuration module.
+
+.. index:: Backend, TSConfig

Documentation/Changelog/9.3/Feature-85147-RenderSEOMetaTagsInFrontend.rst

@@ -0,0 +1,27 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85147:
+
+==================================================
+Feature: #85147 - Render SEO meta tags in frontend
+==================================================
+
+See :issue:`85147`
+
+Description
+===========
+
+The SEO meta tags that can be set in the page properties, are now rendered in frontend by default if the system extension
+SEO is installed.
+
+The og:image and twitter:image will be rendered in the 1.91:1 aspect ratio by default. This ratio is used by most of the
+social networks when showing an image of the shared link. You can also choose a free ratio or add ratio's yourself.
+
+Impact
+======
+
+No additional configuration is needed to render these meta tags. If you want to override the meta tags set by
+the page properties, you can use the replace parameter in TypoScript or in the addProperty method of the specific
+MetaTagManager.
+
+.. index:: Frontend, ext:seo

Documentation/Changelog/9.3/Feature-85160-AutoCreateManagementDBFieldsFromTCACtrl.rst

@@ -0,0 +1,110 @@
+.. include:: /Includes.rst.txt
+
+.. _feature-85160:
+
+================================================================
+Feature: #85160 - Auto create management DB fields from TCA ctrl
+================================================================
+
+See :issue:`85160`
+
+Description
+===========
+
+The database schema analyzer automatically creates TYPO3 "management" related
+database columns by reading a tables :php:`TCA` and checking the :php:`ctrl`
+section for table capabilities.
+
+Note this affects only basic columns like :php:`uid`, :php:`deleted` and language
+handling related fields like :php:`sys_language_uid`, but **not** a tables main
+business fields like a "title" field for a news extension. Those still have to
+be defined by extension authors. No column definitions are created from the
+:php:`columns` section of a tables :php:`TCA`.
+
+However, :file:`ext_tables.sql` file can be stripped down to business fields.
+For example, if a :php:`TCA` definition of a table specifies
+:php:`$GLOBALS['TCA']['myTable']['ctrl']['sortby'] = 'sorting'`,
+the core will automatically add the column :php:`sorting` with an appropriate
+definition.
+
+Field definitions in :file:`ext_tables.sql` take precedence over automatically
+generated fields, so the core never overrides a manually specified column definition
+from an :file:`ext_tables.sql` file.
+
+These columns below are automatically added if not defined in :file:`ext_tables.sql`
+for database tables that provide a :php:`$GLOBALS['TCA']` definition:
+
+:php:`uid` and :php:`PRIMARY KEY`
+  If removing the uid field from ext_tables.sql, the :php:`PRIMARY KEY` **must** be removed, too.
+
+:php:`pid` and :php:`KEY parent`
+  Column pid is :php:`unsigned` if the table is not workspace aware, the default
+  index :php:`parent` includes :php:`pid` and :php:`hidden` as well as :php:`deleted`
+  if the latter two are specified in :php:`TCA` :php:`ctrl`. The parent index creation
+  is only applied if column :php:`pid` is auto generated, too.
+
+:php:`['ctrl']['tstamp'] = 'fieldName'`
+  Often set to :php:`tstamp` or :php:`updatedon`
+
+:php:`['ctrl']['crdate'] = 'fieldName'`
+  Often set to :php:`crdate` or :php:`createdon`
+
+:php:`['ctrl']['cruser_id'] = 'fieldName'`
+  Often set to :php:`cruser` or :php:`createdby`
+
+:php:`['ctrl']['delete'] = 'fieldName'`
+  Often set to :php:`deleted`
+
+:php:`['ctrl']['enablecolumns']['disabled'] = 'fieldName'`
+  Often set to :php:`hidden` or :php:`disabled`
+
+:php:`['ctrl']['enablecolumns']['starttime'] = 'fieldName'`
+  Often set to :php:`starttime`
+
+:php:`['ctrl']['enablecolumns']['endtime'] = 'fieldName'`
+  Often set to :php:`endtime`
+
+:php:`['ctrl']['enablecolumns']['fe_group'] = 'fieldName'`
+  Often set to :php:`fe_group`
+
+:php:`['ctrl']['sortby'] = 'fieldName'`
+  Often set to :php:`sorting`
+
+:php:`['ctrl']['descriptionColumn'] = 'fieldName'`
+  Often set to :php:`description`
+
+:php:`['ctrl']['editlock'] = 'fieldName'`
+  Often set to :php:`editlock`
+
+:php:`['ctrl']['languageField'] = 'fieldName'`
+  Often set to :php:`sys_language_uid`
+
+:php:`['ctrl']['transOrigPointerField'] = 'fieldName'`
+  Often set to :php:`l10n_parent`
+
+:php:`['ctrl']['translationSource'] = 'fieldName'`
+  Often set to :php:`l10n_source`
+
+:php:`l10n_state`
+  Column added if :php:`languageField` and :php:`transOrigPointerField` are set
+
+:php:`['ctrl']['origUid'] = 'fieldName'`
+  Often set to :php:`t3_origuid`
+
+:php:`['ctrl']['transOrigDiffSourceField'] = 'fieldName'`
+  Often set to :php:`l10n_diffsource`
+
+:php:`['ctrl']['versioningWS'] = true` - :php:`t3ver_*` columns
+  Columns that make a table workspace aware. All those fields are prefixed with
+  :php:`t3ver_`, for example :php:`t3ver_oid` and :php:`t3ver_id`. A default
+  index named :php:`t3ver_oid` to fields :php:`t3ver_oid` and :php:`t3ver_wsid` is
+  added, too.
+
+
+Impact
+======
+
+Extension developers can skip tons of "general" fields from extensions
+:file:`ext_tables.sql` files.
+
+.. index:: Database, TCA

Documentation/Changelog/9.3/Important-84715-SetExcludePropertyForTt_contentFields.rst

@@ -0,0 +1,24 @@
+.. include:: /Includes.rst.txt
+
+.. _important-84715:
+
+==============================================================
+Important: #84715 - Set exclude property for tt_content fields
+==============================================================
+
+See :issue:`84715`
+
+Description
+===========
+
+The exclude property is set for the following fields in the
+table tt_content:
+
+- `file_collections`
+- `filelink_size`
+- `filelink_sorting`
+- `filelink_sorting_direction`
+
+Access permissions must be adopted if editors need to edit those fields.
+
+.. index:: Backend

Documentation/Changelog/9.3/Important-85026-SaltedpasswordsChanges.rst

@@ -0,0 +1,87 @@
+.. include:: /Includes.rst.txt
+
+.. _important-85026:
+
+============================================
+Important: #85026 - salted passwords changes
+============================================
+
+See :issue:`85026`
+
+Description
+===========
+
+Several changes to the processing of user passwords and storage have been applied to
+the system. Default settings of the system have been adapted over time, these changes
+only apply for instances that actively disabled features during upgrading.
+
+All changes are justified by looking at the time line of salted password milestones
+in the TYPO3 core and should automatically work if no manual changes have been applied
+to the salted passwords evaluation and configuration settings:
+
+* 4.3.0 (05/2008) Introduction of salted passwords extension
+* 4.5.0 (01/2011) Introduction of salted passwords bulk update scheduler task
+* 4.5.0 (01/2011) Default hash algorithm is phpass
+* 4.5.0 (01/2011) The reports module shows a warning if saltedpasswords extension is not loaded
+* 6.2.0 (03/2014) Salted passwords extension is mandatory
+* 6.2.0 (03/2014) Salted password storage can not be disabled for backend users anymore
+* 8.0.0 (03/2016) Default hash algorithm of new instances is pbkdf2
+
+
+Data thriftness
+^^^^^^^^^^^^^^^
+
+As a best practice on the principle of data minimisation, inactive frontend and backend users should be removed from
+the database after a while! The main idea is that not existing data can't be compromised in case of a security breach.
+The `lastlogin` field of the two user tables `fe_users` and `be_users` store the last login timestamp of a user, and
+soft deleted user records have the `deleted` field set to `1`. The "Table garbage collection task" scheduler task can
+be configured to fully remove those inactive or deleted users from the system. See the
+`scheduler documentation <https://docs.typo3.org/typo3cms/extensions/scheduler/Installation/BaseTasks/Index.html>`__
+for details on this task.
+
+
+Salted passwords bulk update task removed
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The "Convert user passwords to salted hashes" scheduler bulk update task of the `saltedpasswords`
+extension has been removed from the system.
+
+The salted passwords extension is by default configured to upgrade single password hashes to the
+currently configured hash algorithm if a user logs in.
+
+The scheduler task itself allowed to convert clear-text and simple md5 hashed passwords of frontend
+and backend users to salted md5 passwords. This hash method however is in itself outdated and not
+considered secure enough anymore. The task needed to be run only once and disabled itself as soon
+as it walked through all frontend and backend users.
+
+TYPO3 v9 assumes all admins took care of basic salted password security within the last ten years if upgrading from
+instances older than version 4.3 by running this task once, the upgrade task has now been removed with core version 9.
+
+If there are still clear-text or simple md5 stored passwords, they can be found by searching the database
+field `password` of tables `fe_users` and `be_users` for entries not starting with `$`. If there are still entries
+like that, an administrator should convert them to simple md5 salted hashes by using the convert bulk update
+scheduler task in a core version prior to v9, before upgrading the system to v9.
+
+
+Disabled clear-text storage of frontend user passwords
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Storing frontend user passwords as non clear-text but as salted password hashes has been optional since
+core version 4.3 and enabled by default since core version 4.5. An option to store passwords in clear-text
+had to be manually configured. This has been removed for backend users in 6.2 already and is now dropped
+for frontend users as well.
+
+There has been little reason to store passwords in clear-text in the database in the past, most of them only
+justified by third party systems being directly connected to the TYPO3 database. Those cases should be solved
+using the :ref:`Authentication service API <t3coreapi:authentication>` instead, which can hand over the
+clear-text user password upon successful user login, but never persists the native clear-text password. If a third party
+layer such as LDAP is used for authentication to TYPO3, the user password should not be stored in the TYPO3 internal
+tables at all. The authentication service chain supports all of these scenarios, it is a common business use case to
+connect third party applications without the need to store passwords in clear-text anywhere.
+
+In case a TYPO3 instance messed around with configuration options of the salted passwords extension in the past, the
+toggle `FE.enabled` is now ignored and users still having clear-text passwords in the database will get their password
+storage strategy automatically upgraded to the configured salted password hash algorithm upon successful login.
+
+
+.. index:: Backend, Database, Frontend, ext:saltedpasswords

Documentation/Changelog/9.3/Important-85116-ChangedVisibilityOfCharsetConverterInitializationMethods.rst

@@ -0,0 +1,26 @@
+.. include:: /Includes.rst.txt
+
+.. _important-85116:
+
+=================================================================================
+Important: #85116 - Changed visibility of CharsetConverter initialization methods
+=================================================================================
+
+See :issue:`85116`
+
+Description
+===========
+
+Initialization methods within TYPO3's :php:`CharsetConverter` class have changed visibility.
+
+The methods's purpose is to initialize conversion done with public API methods, and have previously
+been marked as private already.
+
+The following methods visibility have been changed from :php:`public` to :php:`protected`:
+
+- :php:`CharsetConverter::initCharset()`
+- :php:`CharsetConverter::initUnicodeData()`
+- :php:`CharsetConverter::initCaseFolding()`
+- :php:`CharsetConverter::initToASCII()`
+
+.. index:: PHP-API

Documentation/Changelog/9.3/Index.rst

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