Commit 41110e39 authored by Lina Wolf's avatar Lina Wolf Committed by Anja Leichsenring
Browse files

[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's avatarOliver Bartsch <bo@cedev.de>
Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
parent 39392943
......@@ -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
......@@ -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
......@@ -9,14 +9,16 @@ 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.
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.
When using the internal backend module entry objects via `setOnClick` and
`getOnClick` methods, PHP deprecation warnings are now triggered.
Affected Installations
......@@ -28,9 +30,16 @@ TYPO3 installations with custom extensions referencing these methods.
Migration
=========
Use the following HTML code to replace the inline `goToModule()`
call to e.g. link to the page module:
Use the following HTML code to replace the inline :javascript:`goToModule()`
call to for example link to the page module:
:html:`<a href="#" data-dispatch-action="TYPO3.ModuleMenu.showModule" data-dispatch-args-list="web_layout">Go to page module</a>`
.. code-block:: html
.. index:: JavaScript, FullyScanned, ext:backend
\ No newline at end of file
<a href="#"
data-dispatch-action="TYPO3.ModuleMenu.showModule"
data-dispatch-args-list="web_layout"
>
Go to page module
</a>
.. index:: JavaScript, FullyScanned, ext:backend
.. include:: ../../Includes.txt
=====================================================================
Deprecation: #94115 - Parameter Type Evaluation via DocBlock comments
Deprecation: #94115 - Parameter type evaluation via DocBlock comments
=====================================================================
See :issue:`94115`
......
......@@ -9,8 +9,10 @@ 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
......@@ -18,7 +20,7 @@ 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.
......@@ -26,8 +28,9 @@ 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
......@@ -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
======
......
.. 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`
......@@ -10,19 +10,19 @@ 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
......@@ -9,39 +9,38 @@ See :issue:`94209`
Description
===========
The following fluid view helpers have been deprecated:
The following Fluid ViewHelpers have been deprecated:
* :php:`be:moduleLayout`
* :php:`be:moduleLayout.menu`
* :php:`be:moduleLayout.menuItem`
* :php:`be:moduleLayout.button.linkButton`
* :php:`be:moduleLayout.button.shortcutButton`
* :html:`be:moduleLayout`
* :html:`be:moduleLayout.menu`
* :html:`be:moduleLayout.menuItem`
* :html:`be:moduleLayout.button.linkButton`
* :html:`be:moduleLayout.button.shortcutButton`
These view helpers partially mimic their counterparts of the PHP based
:php:`ModuleTemplate` API. They found some usage in backend modules
when the 'doc header' handling was done in fluid.
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 view helpers however relied on knowledge that shouldn't be the scope
of a view component to be useful, especially variables like current action
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 view helpers were only a sub set of the ModuleTemplate
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 view helpers.
state were hard to solve when using these ViewHelpers.
Impact
======
Using these view helpers will log a deprecation message, they will be
removed with v12.
Using these ViewHelpers will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
Some extensions with backend modules may use these view helpers. Searching
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.
......@@ -49,19 +48,21 @@ extending the PHP classes are found by the extension scanner as a weak match.
Migration
=========
In general, extensions using these view helpers should switch to using the
PHP API based on class :php:`ModuleTemplate`, usually initialized by class
:php:`ModuleTemplateFactory` instead. All core extensions that render backend
modules provide lots of usage examples and the fluent API is quite straight
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 basic idea is that the 'doc header'
should be handled within controller actions, while the module body is rendered
by the fluid view component.
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 view helpers and the
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 view helpers to the extension
way is of course to simply copy the according ViewHelpers to the extension
directly and to just adapt the namespace in templates accordingly.
......
......@@ -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');
......
......@@ -9,9 +9,9 @@ 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.
......@@ -19,14 +19,14 @@ 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
......
......@@ -17,14 +17,14 @@ main :html:`<head>` markup, directly, or indirectly via TypoScript :html:`config
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 log a deprecation warning
and the ViewHelper will be dropped with v12.
Affected Installations
======================
The limited use of the view helper likely leads to little usage numbers.
The limited use of the ViewHelper likely leads to little usage numbers.
Searching extensions for the string html:`<f:base>` should
reveal any usages.
......@@ -34,7 +34,7 @@ Migration
The easiest solution is to simply copy PHP class
:php:`TYPO3\CMS\Fluid\ViewHelpers\BaseViewHelper` to the consuming extension,
giving the view helper a happy life in an extension specific namespace.
giving the ViewHelper a happy life in an extension specific namespace.
.. index:: Fluid, NotScanned, ext:fluid
.. include:: ../../Includes.txt
===============================================================
Deprecation: #94228 - Deprecate extbase request getRequestUri()
===============================================================
=====================================================
Deprecation: #94228 - Extbase request getRequestUri()
=====================================================
See :issue:`94228`
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:`getRequestUri()` has been deprecated and shouldn't be
used any longer.
......@@ -19,9 +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
......@@ -37,12 +35,12 @@ Migration
When :php:`getRequestUri()` is called in extensions, the same information
can be retrieved from the native PSR-7 request. At the moment, this is usually
only available using :php:`$GLOBALS['TYPO3_REQUEST']`, but this will change
when the extbase request is compatible with PSR-7 ServerRequestInterface.
when the Extbase request is compatible with PSR-7 ServerRequestInterface.
A substitution looks like this for now:
.. code-block:: php
// @todo Adapt this example as soon as extbase Request implements ServerRequestInterface
// @todo Adapt this example as soon as Extbase Request implements ServerRequestInterface
$request = $GLOBALS['TYPO3_REQUEST'];
/** @var NormalizedParams $normalizedParams */
$normalizedParams = $request->getAttribute('normalizedParams');
......
.. include:: ../../Includes.txt
=====================================================================
Deprecation: #94231 - Deprecate extbase InvalidRequestMethodException
=====================================================================
===========================================================
Deprecation: #94231 - Extbase InvalidRequestMethodException
===========================================================
See :issue:`94231`
Description
===========
To further prepare towards PSR-7 Requests in extbase, the
To further prepare towards PSR-7 Requests in Extbase, the
:php:`TYPO3\CMS\Extbase\Mvc\Request` has to be streamlined.
Therefore, the internal method :php:`setMethod()` has been removed.
......@@ -22,7 +22,7 @@ Impact
Using :php:`TYPO3\CMS\Extbase\Mvc\Exception\InvalidRequestMethodException`
in custom extension code is discouraged since it will be removed with TYPO3
v12.0 and is also not longer thrown by TYPO3.
v12 and is also no longer thrown by TYPO3.
Affected Installations
======================
......
.. include:: ../../Includes.txt
================================================================================
Deprecation: #94252 - Deprecated GeneralUtility::compileSelectedGetVarsFromArray
================================================================================
=====================================================================
Deprecation: #94252 - GeneralUtility::compileSelectedGetVarsFromArray
=====================================================================
See :issue:`94252`
......@@ -13,30 +13,29 @@ In our effort to reduce usages of :php:`GeneralUtility::_GP()`, the
:php:`GeneralUtility` method :php:`compileSelectedGetVarsFromArray` is
deprecated, since it internally calls :php:`GeneralUtility::_GP()` instead
of accessing the PSR-7 Request. The method was furthermore only used once
in the core since it's internal logic can easily be implemented on a case
in the Core since it's internal logic can easily be implemented on a case
by case basis.
Impact
======
Calling the method will log a deprecation warning and the method will
be dropped with TYPO3 v12.
Using the method will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
All TYPO3 installations calling this method in custom code. The extension
scanner will find all usages as strong match.
All TYPO3 installations calling this method in custom code are affected.
The extension scanner will find such usages as strong match.
Migration
=========
All usages of the method in custom extension code have to be replaced
with a custom implementation, preferably using the PSR-7 Request.
Usages of the method in custom extension code have to be replaced
with a custom implementations, preferably using the PSR-7 Request.
See: :php:`EditDocumentController->compileStoreData()` for an example
on how such migration could look like.
See: :php:`\TYPO3\CMS\Backend\Controller\EditDocumentController->compileStoreData()`
for an example on how such migration could look like.
.. index:: PHP-API, FullyScanned, ext:core
.. include:: ../../Includes.txt
==========================================================
Deprecation: #94272 - Deprecated Application->run callback
==========================================================
===============================================
Deprecation: #94272 - Application->run callback
===============================================
See :issue:`94272`
Description
===========
Since the introduction of the :php:`ApplicationInterface` in :issue:`67808`
(TYPO3 v7), which serves as a wrapper for setting up the bootstrap and
Since the introduction of the :php:`\TYPO3\CMS\Core\Core\ApplicationInterface`
in :issue:`67808` (TYPO3 v7), which serves as a wrapper for setting up the bootstrap and
calling the request, it was possible to run either the console, the frontend