[TASK] Move Changelog files into 11.3 for upcoming release

With the release of TYPO3 v11.3, Changelog documentation is no
longer expected in master, but in 11.3 folder.

Resolves: #94532
Releases: master
Change-Id: I04808715808e6ac66e8a032e2809fc1d4d44109c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69807
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>

typo3/sysext/core/Documentation/Changelog-11.rst

@@ -11,6 +11,7 @@ Every change to the TYPO3 Core which might affect your site is documented here.
 .. toctree::
    :titlesonly:
 
+   Changelog/11.3/Index
    Changelog/11.2/Index
    Changelog/11.1/Index
    Changelog/11.0/Index

typo3/sysext/core/Documentation/Changelog/master/Deprecation-91806-BackendUtilityViewOnClick.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-91806-BackendUtilityViewOnClick.rst

@@ -32,8 +32,7 @@ Migration
 =========
 
 The :php:`\TYPO3\CMS\Backend\Routing\PreviewUriBuilder` should be used
-instead as described in this `Changelog`_ file.
-
-.. _`Changelog`: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.4.x/Important-91132-AvoidJavaScriptInUserSettingsConfigurationOptions.html
+instead as described in
+:doc:`../10.4.x/Important-91132-AvoidJavaScriptInUserSettingsConfigurationOptions`.
 
 .. index:: Backend, JavaScript, PHP-API, FullyScanned, ext:backend

typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94058-JavaScriptGoToModule.rst

@@ -0,0 +1,45 @@
+.. include:: ../../Includes.txt
+
+=============================================
+Deprecation: #94058 - JavaScript goToModule()
+=============================================
+
+See :issue:`94058`
+
+Description
+===========
+
+One of the most prominent inline JavaScript functions
+:javascript:`goToModule()` has been deprecated in favor of a streamlined
+ActionHandler API for JavaScript.
+
+
+Impact
+======
+
+When using the internal backend module entry objects via `setOnClick` and
+`getOnClick` methods, PHP deprecation warnings are now triggered.
+
+
+Affected Installations
+======================
+
+TYPO3 installations with custom extensions referencing these methods.
+
+
+Migration
+=========
+
+Use the following HTML code to replace the inline :javascript:`goToModule()`
+call to for example link to the page module:
+
+.. code-block:: html
+
+   <a href="#"
+      data-dispatch-action="TYPO3.ModuleMenu.showModule"
+      data-dispatch-args-list="web_layout"
+   >
+      Go to page module
+   </a>
+
+.. index:: JavaScript, FullyScanned, ext:backend

typo3/sysext/core/Documentation/Changelog/master/Deprecation-94115-ParameterTypeEvaluationViaDocBlockComments.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94115-ParameterTypeEvaluationViaDocBlockComments.rst

@@ -1,7 +1,7 @@
 .. include:: ../../Includes.txt
 
 =====================================================================
-Deprecation: #94115 - Parameter Type Evaluation via DocBlock comments
+Deprecation: #94115 - Parameter type evaluation via DocBlock comments
 =====================================================================
 
 See :issue:`94115`

typo3/sysext/core/Documentation/Changelog/master/Deprecation-94137-SwitchBehaviorOfArrayUtilityarrayDiffAssocRecursive.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94137-SwitchBehaviorOfArrayUtilityarrayDiffAssocRecursive.rst

@@ -9,25 +9,28 @@ See :issue:`94137`
 Description
 ===========
 
-Despite its name, the method :php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()`
-mimics the behavior of :php:`array_diff_key()` and not of :php:`array_diff_assoc()`.
+Despite its name, the method
+:php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()`
+mimics the behavior of :php:`array_diff_key()` and not of
+:php:`array_diff_assoc()`.
 
 
 Impact
 ======
 
 The method has been adjusted to act like :php:`array_diff_assoc()`. As this is
 considered being a breaking change, the behavior must be enabled explicitly by
-passing a 3rd parameter :php:`$useArrayDiffAssocBehavior` being true. If the
+passing a third parameter :php:`$useArrayDiffAssocBehavior` being true. If the
 argument is either omitted or :php:`false`, the old behavior is kept but a
 deprecation warning will be thrown.
 
 
 Affected Installations
 ======================
 
-Every 3rd party extension using :php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()`
-without its 3rd argument being true is affected.
+Every 3rd party extension using
+:php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffAssocRecursive()`
+without its third argument being :php:`true` is affected.
 
 
 Migration
@@ -36,6 +39,6 @@ Migration
 To keep the previous :php:`array_diff_key()` based behavior, use the introduced
 method :php:`\TYPO3\CMS\Core\Utility\ArrayUtility::arrayDiffKeyRecursive()`.
 To make use of the :php:`array_diff_assoc()` based behavior, which will become
-the default behavior in TYPO3 v12, pass :php:`true` as the 3rd argument.
+the default behavior in TYPO3 v12, pass :php:`true` as the third argument.
 
 .. index:: PHP-API, FullyScanned, ext:core

typo3/sysext/core/Documentation/Changelog/master/Deprecation-94165-SysLanguageDatabaseTable.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94165-SysLanguageDatabaseTable.rst

@@ -10,7 +10,7 @@ Description
 ===========
 
 Since the introduction of site handling back in TYPO3 v9, available
-languages and their associated information, e.g. locale, ISO code or the
+languages and their associated information, for example locale, ISO code or the
 navigation title are configured in the site configurations. As a consequence,
 the :sql:`sys_language` table just duplicated this information and is therefore
 now deprecated.
@@ -26,7 +26,7 @@ independent of any :sql:`sys_language` record. Previously, when using the
 site module to create or edit a site configuration, site languages could
 only be added when a corresponding :sql:`sys_language` record existed.
 This has now changed. The site configurations' `languages` field now
-features a "Create new language" button, which allows to create a new
+features a :guilabel:`Create new language` button, which allows to create a new
 site language for this site configuration. Such newly created site
 language will then also be available in the selector box of all other
 site configurations. The ID for a new site language is always created
@@ -37,8 +37,8 @@ another site configuration, most of the fields will now be prefilled.
 
    When creating the first site configuration of a new installation, the
    languages selector box is empty, as new languages must be created via
-   the "Create new language" button first. However, a default language
-   (ID=0) record will always be added automatically.
+   the :guilabel:`Create new language` button first. However, a default
+   language (ID=0) record will always be added automatically.
 
 Impact
 ======

typo3/sysext/core/Documentation/Changelog/master/Deprecation-94193-PublicUrlWithRelativePathsInFALAPI.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94193-PublicUrlWithRelativePathsInFALAPI.rst

@@ -1,28 +1,28 @@
 .. include:: ../../Includes.txt
 
-===============================================================
-Deprecation: #94193 - Public url with relative paths in FAL API
-===============================================================
+================================================================
+Deprecation: #94193 - Public URLs with relative paths in FAL API
+================================================================
 
 See :issue:`94193`
 
 Description
 ===========
 
 The public FAL API for accessing the public url of a FAL object,
-e.g. :php:`FileReference` or :php:`Folder`, previously allowed to
+for example :php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`, previously allowed to
 retrieve the relative path instead of the absolute path. This could
 be achieved by setting :php:`$relativeToCurrentScript` to :php:`true`
 while calling :php:`getPublicUrl()`.
 
-However, only under some circumstances FAL is actually able to build such
-relative links. If at all, this only worked for local drivers. Other drivers
+FAL is only able to build relative links for local drivers. Other drivers
 would still return the absolute URL, which has often led to unexpected
-side-effects.
+side effects.
 
 Since both, frontend (site handling) and backend (url routing) are meanwhile
 fully capable of supporting absolute URLs, :php:`$relativeToCurrentScript`
-is now deprecated and will finally be removed in TYPO3 v12.0.
+is now deprecated and will be removed in TYPO3 v12.
 
 This also affects the :php:`isRelativeToCurrentScript()` method in the
 :php:`GeneratePublicUrlForResourceEvent` event, as well as the
@@ -31,8 +31,10 @@ This also affects the :php:`isRelativeToCurrentScript()` method in the
 Impact
 ======
 
-Calling :php:`getPublicUrl()` on a FAL object, e.g. :php:`FileReference`
-or :php:`Folder`, with :php:`$relativeToCurrentScript` set to :php:`true`
+Calling :php:`getPublicUrl()` on a FAL object, for example
+:php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`, with :php:`$relativeToCurrentScript`
+set to :php:`true`
 will trigger a PHP :php:`E_USER_DEPRECATED` error. The extension scanner
 will detect such calls.
 
@@ -42,31 +44,38 @@ Accessing :php:`isRelativeToCurrentScript()` on
 such calls.
 
 Manually calling :php:`getPublicUrl()` on an :php:`OnlineMediaHelper`,
-e.g. :php:`YoutubeHelper`, will not trigger a PHP :php:`E_USER_DEPRECATED`
+for example :php:`YoutubeHelper`, will not trigger a PHP :php:`E_USER_DEPRECATED`
 error, but the extension scanner will detect such calls.
 
 Affected Installations
 ======================
 
 All installations which set :php:`$relativeToCurrentScript` to :php:`true`
-when calling :php:`getPublicUrl()` on a FAL object, e.g. :php:`FileReference`
-or :php:`Folder`.
+when calling :php:`getPublicUrl()` on a FAL object, for example
+:php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`.
 
 All installations which manually call :php:`getPublicUrl()` on an
-:php:`OnlineMediaHelper`, e.g. :php:`YoutubeRenderer`.
+:php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelper`,
+for example :php:`\TYPO3\CMS\Core\Resource\Rendering\YoutubeRenderer`.
 
 All installation which access :php:`isRelativeToCurrentScript()` on the
-:php:`GeneratePublicUrlForResourceEvent` event.
+:php:`\TYPO3\CMS\Core\Resource\Event\GeneratePublicUrlForResourceEvent` event.
 
 Migration
 =========
 
 Remove the :php:`$relativeToCurrentScript` parameter from all calls to
-:php:`getPublicUrl()` on FAL objects, e.g. :php:`FileReference` or :php:`Folder`.
+:php:`getPublicUrl()` on FAL objects, for example
+:php:`\TYPO3\CMS\Core\Resource\FileReference` or
+:php:`\TYPO3\CMS\Core\Resource\Folder`.
 
 Remove the :php:`$relativeToCurrentScript` parameter from all manual calls
-to :php:`getPublicUrl()` on an :php:`OnlineMediaHelper`, e.g. :php:`YoutubeHelper`.
+to :php:`getPublicUrl()` on a
+:php:`\TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelper`,
+for example :php:`\TYPO3\CMS\Core\Resource\Rendering\YoutubeRenderer`.
 
-Remove all calls to :php:`GeneratePublicUrlForResourceEvent->isRelativeToCurrentScript()`.
+Remove all calls to
+:php:`\TYPO3\CMS\Core\Resource\Event\GeneratePublicUrlForResourceEvent->isRelativeToCurrentScript()`.
 
 .. index:: FAL, PHP-API, FullyScanned, ext:core

typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94209-BackendModuleLayoutViewHelpers.rst

@@ -0,0 +1,69 @@
+.. include:: ../../Includes.txt
+
+======================================================
+Deprecation: #94209 - Backend ModuleLayout ViewHelpers
+======================================================
+
+See :issue:`94209`
+
+Description
+===========
+
+The following Fluid ViewHelpers have been deprecated:
+
+*  :html:`be:moduleLayout`
+*  :html:`be:moduleLayout.menu`
+*  :html:`be:moduleLayout.menuItem`
+*  :html:`be:moduleLayout.button.linkButton`
+*  :html:`be:moduleLayout.button.shortcutButton`
+
+These ViewHelpers partially mimic their counterparts of the PHP based
+:php:`ModuleTemplate` API. They were previously used in backend modules
+when the 'doc header' handling was done in Fluid.
+
+The ViewHelpers however relied on knowledge that shouldn't be the scope
+of a view component, especially variables like the current action
+and controller had to be assigned to the view in many cases.
+
+Additionally, those ViewHelpers were only a sub set of the ModuleTemplate
+functionality and created a second API for the same problem domain and
+various scenarios like good shortcut implementation and main drop down
+state were hard to solve when using these ViewHelpers.
+
+
+Impact
+======
+
+Using these ViewHelpers will trigger a PHP :php:`E_USER_DEPRECATED` error.
+
+
+Affected Installations
+======================
+
+Some extensions with backend modules may use these ViewHelpers. Searching
+templates for string :php:`be:moduleLayout` should reveal usages. Extensions
+extending the PHP classes are found by the extension scanner as a weak match.
+
+
+Migration
+=========
+
+In general, extensions using these ViewHelpers should switch to using the
+PHP API based on class :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate`,
+usually initialized by class
+:php:`\TYPO3\CMS\Backend\Template\ModuleTemplateFactory` instead.
+All Core extensions that render backend
+modules provide usage examples and the fluent API is quite straight
+forward.
+
+For Extbase base backend modules, the 'doc header' should be handled within
+controller actions, while the module body is rendered
+by the Fluid view component.
+
+In case an extension heavily relies on the deprecated ViewHelpers and the
+functionality should be kept with as little work as possible, the easiest
+way is of course to simply copy the according ViewHelpers to the extension
+directly and to just adapt the namespace in templates accordingly.
+
+
+.. index:: Backend, Fluid, PartiallyScanned, ext:backend

typo3/sysext/core/Documentation/Changelog/master/Deprecation-94223-ExtbaseRequest-getBaseUri.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94223-ExtbaseRequest-getBaseUri.rst

@@ -9,8 +9,8 @@ See :issue:`94223`
 Description
 ===========
 
-To further prepare extbase towards PSR-7 compatible requests, the
-extbase :php:`TYPO3\CMS\Extbase\Mvc\Request` has to be streamlined.
+To further prepare Extbase towards PSR-7 compatible requests, the
+Extbase :php:`TYPO3\CMS\Extbase\Mvc\Request` has to be streamlined.
 
 Method :php:`getBaseUri()` has been deprecated and shouldn't be
 used any longer.
@@ -19,8 +19,7 @@ used any longer.
 Impact
 ======
 
-Using the method will log a deprecation message, it will be
-removed with v12.
+Using the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
 
 
 Affected Installations
@@ -35,13 +34,13 @@ Migration
 =========
 
 When :php:`getBaseUri()` is called in extensions, it is most likely
-in a view related component. Since fluid view helpers currently still
+in a view related component. Since Fluid ViewHelpers currently still
 don't receive an instance of the native PSR-7 request (which will change),
 a typical substitution of this getter looks like this for now:
 
 .. code-block:: php
 
-    // @todo Adapt this example as soon as view helpers receive a ServerRequestInterface
+    // @todo Adapt this example as soon as ViewHelpers receive a ServerRequestInterface
     $request = $GLOBALS['TYPO3_REQUEST'];
     /** @var NormalizedParams $normalizedParams */
     $normalizedParams = $request->getAttribute('normalizedParams');

typo3/sysext/core/Documentation/Changelog/master/Deprecation-94225-FbecontainerViewHelper.rst → typo3/sysext/core/Documentation/Changelog/11.3/Deprecation-94225-FbecontainerViewHelper.rst

@@ -9,24 +9,24 @@ See :issue:`94225`
 Description
 ===========
 
-The :html:`<f:be.container>` view helper has been deprecated.
+The :html:`<f:be.container>` ViewHelper has been deprecated.
 
-This backend module related view helper was pretty useless since
+This backend-module-related ViewHelper was pretty useless since
 it mostly provides the same functionality as :html:`<f:be.pageRenderer>`,
 with the additional opportunity to render an empty doc header.
 
 
 Impact
 ======
 
-Using the view helper in fluid templates will log a deprecation warning
-and the view helper will be dropped with v12.
+Using the ViewHelper in Fluid templates will trigger a PHP
+:php:`E_USER_DEPRECATED` error.
 
 
 Affected Installations
 ======================
 
-The limited functionality of the view helper likely leads to little
+The limited functionality of the ViewHelper likely leads to little
 usage numbers.
 Searching extensions for the string html:`<f:be.container>` should
 reveal any usages.
@@ -35,11 +35,11 @@ reveal any usages.
 Migration
 =========
 
-When this view helper is used to register additional backend module
+When this ViewHelper is used to register additional backend module
 resources like CSS or JavaScript, :html:`<f:be.pageRenderer>` can be
 used as drop-in replacement.
 
-If the view helper is used to additionally render an empty ModuleTemplate,
+If the ViewHelper is used to additionally render an empty ModuleTemplate,
 this part should be moved to a controller instead. Simple example:
 
 .. code-block:: php