TYPO3 v15 dev-main snapshot ()
This commit is contained in:
+78
@@ -0,0 +1,78 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100173-1680696124:
|
||||
|
||||
================================================================================================
|
||||
Deprecation: #100173 - Various methods and properties in UserAuthentication classes now internal
|
||||
================================================================================================
|
||||
|
||||
See :issue:`100173`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Various methods and properties within the main classes regarding frontend
|
||||
user and backend user (:php:`$GLOBALS[BE_USER]`) authentication handling
|
||||
have been either marked as internal or have been deprecated for usage
|
||||
outside of the classes.
|
||||
|
||||
This is due to the further refactorings and decoupling work, as subclasses of
|
||||
:php:`AbstractUserAuthentication` deal with many more functionality nowadays,
|
||||
and therefore have been moved to service classes. The tight coupling of these
|
||||
classes, for example, the database fields, or login form field names are now marked as
|
||||
internal, as these properties should not be modified from the outside scope.
|
||||
|
||||
Instead, functionality like :ref:`PSR-14 events <t3coreapi:EventDispatcher>` or
|
||||
:ref:`Authentication Services <t3coreapi:authentication>` should influence the
|
||||
authentication and authorization workflow.
|
||||
|
||||
The following properties and methods are now marked as internal in all
|
||||
user authentication related classes (extending
|
||||
:php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication`):
|
||||
|
||||
* :php:`lastLogin_column`
|
||||
* :php:`formfield_uname`
|
||||
* :php:`formfield_uident`
|
||||
* :php:`formfield_status`
|
||||
* :php:`loginSessionStarted`
|
||||
* :php:`dontSetCookie`
|
||||
* :php:`isSetSessionCookie()`
|
||||
* :php:`isRefreshTimeBasedCookie()`
|
||||
* :php:`removeCookie()`
|
||||
* :php:`isCookieSet()`
|
||||
* :php:`unpack_uc()`
|
||||
* :php:`appendCookieToResponse()`
|
||||
|
||||
Additionally, the following properties of the
|
||||
:php:`\TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication`
|
||||
implementation are marked as internal:
|
||||
|
||||
* :php:`formfield_permanent`
|
||||
* :php:`is_permanent`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The affected properties and methods have been marked as `@internal` and set to
|
||||
:php:`protected`. With an additional trait, it is still possible to access them
|
||||
in TYPO3 v12. In case third-party extensions call them, a PHP deprecation
|
||||
warning is thrown.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions accessing the properties or methods.
|
||||
The extension scanner reports corresponding places.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Depending on the specific requirements, it is recommended to use
|
||||
:ref:`PSR-14 events <t3coreapi:EventDispatcher>` or
|
||||
:ref:`authentication services <t3coreapi:authentication>` to modify behaviour
|
||||
of the authentication classes.
|
||||
|
||||
.. index:: Backend, Frontend, PHP-API, FullyScanned, ext:core
|
||||
@@ -0,0 +1,77 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100335-1679998903:
|
||||
|
||||
==================================================
|
||||
Deprecation: #100335 - TCA config MM_insert_fields
|
||||
==================================================
|
||||
|
||||
See :issue:`100335`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TCA option :php:`MM_insert_fields` has been marked
|
||||
as deprecated and should not be used anymore.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using :php:`MM_insert_fields` raises a deprecation level log message
|
||||
during TCA cache warmup. Its functionality is kept in TYPO3 v12 but will
|
||||
be removed in v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
There may be extensions that use this option when configuring database
|
||||
MM relations. In most cases, the option can be removed. The migration
|
||||
section gives more details.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
General scope: :php:`MM_insert_fields` is used in combination with "true"
|
||||
database MM intermediate tables to allow many-to-many relations between
|
||||
two tables for :php:`group`, :php:`select` and sometimes even :php:`inline`
|
||||
type fields.
|
||||
|
||||
A core example is the :sql:`sys_category` to :sql:`tt_content`
|
||||
relation, with :sql:`sys_category_record_mm` as intermediate table: The
|
||||
intermediate table has field :sql:`uid_local` (pointing to a uid of
|
||||
the "left" :sql:`sys_category` table), and :sql:`uid_foreign` (pointing to a
|
||||
uid of the "right" :sql:`tt_content` table). Note this specific relation also
|
||||
allows multiple different "right-side" table-field combinations, using the two
|
||||
additional fields :sql:`tablenames` and :sql:`fieldname`. All this is configured
|
||||
with TCA on the "left" and the "right" side table field, while table
|
||||
:sql:`sys_category_record_mm` has no TCA itself. Rows within the intermediate
|
||||
table are transparently handled by TYPO3 by the :php:`RelationHandler` and
|
||||
extbase TCA-aware domain logic.
|
||||
|
||||
The :php:`MM_insert_fields` now allows to configure a hard coded value for
|
||||
an additional column within the intermediate table. This is obsolete: There is
|
||||
no API to retrieve this value again, having a "stable" value in an additional
|
||||
column is useless. This config option should be removed from TCA
|
||||
definition.
|
||||
|
||||
Note on the related option :php:`MM_match_fields`: This is important when an
|
||||
MM relation allows multiple "right" sides. In the example above, when a category
|
||||
is added to a :sql:`tt_content` record using the :sql:`categories` field, and when editing
|
||||
this relation from the "right" side (editing a :sql:`tt_content` record), then this option
|
||||
is used to select only relations for this :sql:`tt_content.categories` combination. The
|
||||
TCA column :sql:`categories` thus uses :sql:`MM_match_fields` to restrict the
|
||||
query. Note :sql:`MM_match_fields` is *not* set for the "left-side" :sql:`sys_category`
|
||||
:sql:`items` fields, this would indicate a TCA misconfiguration.
|
||||
|
||||
Various extensions in the wild did not get these details right, and often simply
|
||||
set *both* :php:`MM_insert_fields` and :php:`MM_match_fields` to the same values.
|
||||
Removing :php:`MM_insert_fields` helps reducing confusion and simplifies this
|
||||
construct a bit. Affected extensions can simply remove the :php:`MM_insert_fields`
|
||||
configuration and keep the :php:`MM_match_fields`. Note the Core strives to further
|
||||
simplify these options and :php:`MM_match_fields` may become fully obsolete in the
|
||||
future as well.
|
||||
|
||||
.. index:: TCA, NotScanned, ext:core
|
||||
+131
@@ -0,0 +1,131 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100349-1680097287:
|
||||
|
||||
========================================================================
|
||||
Deprecation: #100349 - TypoScript loginUser() and usergroup() conditions
|
||||
========================================================================
|
||||
|
||||
See :issue:`100349`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The two TypoScript / TSconfig related condition functions
|
||||
:typoscript:`[loginUser()]` and :typoscript:`[usergroup()]` have
|
||||
been marked as deprecated with TYPO3 v12, should not be used anymore
|
||||
and will be removed in TYPO3 v13. They can be substituted using
|
||||
conditions based on the variables :typoscript:`frontend.user` and
|
||||
:typoscript:`backend.user`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using the old conditions in frontend TypoScript or TSconfig triggers a
|
||||
deprecation level log entry in TYPO3 v12 and will stop working with
|
||||
TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with TypoScript or TSconfig using one of the above functions
|
||||
may be affected. This is a relatively common use case, but affected
|
||||
instances can be adapted quite easily.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
There is a rather straightforward migration path. In general, switch to
|
||||
either :typoscript:`frontend.user` to test for frontend user state
|
||||
(available in frontend TypoScript), or to :typoscript:`backend.user` (available
|
||||
in frontend TypoScript and TSconfig).
|
||||
|
||||
Note the transition can be done in existing TYPO3 v11 projects already.
|
||||
|
||||
Some examples:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
[loginUser('*')]
|
||||
page = PAGE
|
||||
page.20 = TEXT
|
||||
page.20.value = User is logged in<br />
|
||||
[end]
|
||||
[frontend.user.isLoggedIn]
|
||||
page = PAGE
|
||||
page.21 = TEXT
|
||||
page.21.value = User is logged in<br />
|
||||
[end]
|
||||
|
||||
[loginUser('*') === false]
|
||||
page = PAGE
|
||||
page.30 = TEXT
|
||||
page.30.value = User is not logged in<br />
|
||||
[end]
|
||||
[!frontend.user.isLoggedIn]
|
||||
page = PAGE
|
||||
page.31 = TEXT
|
||||
page.31.value = User is not not logged in<br />
|
||||
[end]
|
||||
|
||||
[loginUser(13)]
|
||||
page = PAGE
|
||||
page.40 = TEXT
|
||||
page.40.value = Frontend user has the uid 13<br />
|
||||
[end]
|
||||
[frontend.user.userId == 13]
|
||||
page = PAGE
|
||||
page.41 = TEXT
|
||||
page.41.value = Frontend user has the uid 13<br />
|
||||
[end]
|
||||
|
||||
[loginUser('1,13')]
|
||||
page = PAGE
|
||||
page.50 = TEXT
|
||||
page.50.value = Frontend user uid is 1 or 13<br />
|
||||
[end]
|
||||
[frontend.user.userId in [1,13]]
|
||||
page = PAGE
|
||||
page.51 = TEXT
|
||||
page.51.value = Frontend user uid is 1 or 13<br />
|
||||
[end]
|
||||
|
||||
[usergroup('*')]
|
||||
page = PAGE
|
||||
page.60 = TEXT
|
||||
page.60.value = A Frontend user is logged in and belongs to some usergroup.<br />
|
||||
[end]
|
||||
# Prefer [frontend.user.isLoggedIn] to not rely on magic array values.
|
||||
[frontend.user.userGroupIds !== [0, -1]]
|
||||
page = PAGE
|
||||
page.61 = TEXT
|
||||
page.61.value = A Frontend user is logged in and belongs to some usergroup.<br />
|
||||
[end]
|
||||
|
||||
[usergroup(11)]
|
||||
page = PAGE
|
||||
page.70 = TEXT
|
||||
page.70.value = Frontend user is member of group with uid 11<br />
|
||||
[end]
|
||||
[11 in frontend.user.userGroupIds]
|
||||
page = PAGE
|
||||
page.71 = TEXT
|
||||
page.71.value = Frontend user is member of group with uid 11<br />
|
||||
[end]
|
||||
|
||||
[usergroup('1,11')]
|
||||
page = PAGE
|
||||
page.80 = TEXT
|
||||
page.80.value = Frontend user is member of group 1 or 11<br />
|
||||
[end]
|
||||
[1 in frontend.user.userGroupIds || 11 in frontend.user.userGroupIds]
|
||||
page = PAGE
|
||||
page.81 = TEXT
|
||||
page.81.value = Frontend user is member of group 1 or 11<br />
|
||||
[end]
|
||||
|
||||
|
||||
.. index:: TSConfig, TypoScript, NotScanned, ext:core
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100355-1680608322:
|
||||
|
||||
==============================================================================
|
||||
Deprecation: #100355 - Deprecate methods in PasswordChangeEvent in ext:felogin
|
||||
==============================================================================
|
||||
|
||||
See :issue:`100355`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following methods in the PSR-14 event :php:`PasswordChangeEvent` of
|
||||
ext:felogin have been marked as deprecated and should not be used any more:
|
||||
|
||||
* :php:`setAsInvalid()`
|
||||
* :php:`getErrorMessage()`
|
||||
* :php:`isPropagationStopped()`
|
||||
* :php:`setHashedPassword()`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Event listeners, who use one of the deprecated methods of the
|
||||
:php:`PasswordChangeEvent` PSR-14 event, will raise a deprecation level log
|
||||
message. The functionality is kept in TYPO3 v12 but will be removed in v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances who use the PSR-14 event :php:`PasswordChangeEvent` for password
|
||||
validation and who use one of the deprecated methods.
|
||||
|
||||
The extension scanner reports usages as a weak match.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Password validation for the password recovery functionality in ext:felogin
|
||||
must be implemented using a custom password policy validator.
|
||||
|
||||
See :issue:`97388` for details.
|
||||
|
||||
.. index:: Backend, FullyScanned, ext:felogin
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100405-1680520177:
|
||||
|
||||
==================================================================
|
||||
Deprecation: #100405 - Property TypoScriptFrontendController->type
|
||||
==================================================================
|
||||
|
||||
See :issue:`100405`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The public property :php:`type` of the main class in TYPO3 frontend
|
||||
:php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController` has been
|
||||
marked as internal, as it should not be used outside of this PHP class anymore
|
||||
in the future.
|
||||
|
||||
This is part of the overall part to reduce dependencies on this PHP class, as
|
||||
it is not always available in TYPO3 frontend.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Accessing this property will trigger a PHP deprecation notice. Accessing this
|
||||
property might also happen via TypoScript and TypoScript conditions.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations using this property on checking various typeNum settings
|
||||
from TypoScript.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
When using this property in PHP code via :php:`$GLOBALS['TSFE']->type`, it is
|
||||
recommended to move to the PSR-7 request via
|
||||
:php:`$request->getAttribute('routing')->getPageType()`, which is the property
|
||||
of the :php:`PageArguments` object, as a result of the :php:`GET` parameter
|
||||
:php:`type`, or `$GLOBALS['TSFE']->getPageArguments()->getPageType()` if
|
||||
the request object is not available.
|
||||
|
||||
Within TypoScript, conditions and getData properties need to be adapted:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
# Before
|
||||
[getTSFE() && getTSFE().type == 13]
|
||||
|
||||
# After
|
||||
[request.getPageArguments()?.getPageType() == 13]
|
||||
|
||||
In TypoScript getData attributes:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
# Before
|
||||
page.10.data = TSFE:type
|
||||
|
||||
# After
|
||||
page.10.data = request:routing|pageType
|
||||
|
||||
|
||||
.. index:: Frontend, TypoScript, FullyScanned, ext:frontend
|
||||
@@ -0,0 +1,77 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100454-1680685413:
|
||||
|
||||
==================================================
|
||||
Deprecation: #100454 - Legacy tree implementations
|
||||
==================================================
|
||||
|
||||
See :issue:`100454`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Due to many refactorings in TYPO3's tree implementations in the past versions,
|
||||
many implementations and functionality of the legacy rendering :php:`\TYPO3\CMS\Backend\Tree\AbstractTreeView`
|
||||
is not needed anymore.
|
||||
|
||||
The following PHP classes are not in use anymore and have been marked as deprecated:
|
||||
|
||||
* :php:`\TYPO3\CMS\Backend\Tree\View\BrowseTreeView`
|
||||
* :php:`\TYPO3\CMS\Backend\Tree\View\ElementBrowserPageTreeView`
|
||||
|
||||
The base class is still available, but discouraged to be used or extended,
|
||||
even though TYPO3 still uses this in a few places.
|
||||
|
||||
The following properties and methods within the base class
|
||||
:php:`AbstractTreeView` have either been marked as deprecated or
|
||||
declared as internal:
|
||||
|
||||
* :php:`AbstractTreeView->thisScript`
|
||||
* :php:`AbstractTreeView->BE_USER`
|
||||
* :php:`AbstractTreeView->clause`
|
||||
* :php:`AbstractTreeView->title`
|
||||
* :php:`AbstractTreeView->table`
|
||||
* :php:`AbstractTreeView->parentField`
|
||||
* :php:`AbstractTreeView->orderByFields`
|
||||
* :php:`AbstractTreeView->fieldArray`
|
||||
* :php:`AbstractTreeView->defaultList`
|
||||
* :php:`AbstractTreeView->determineScriptUrl()`
|
||||
* :php:`AbstractTreeView->getThisScript()`
|
||||
* :php:`AbstractTreeView->PM_ATagWrap()`
|
||||
* :php:`AbstractTreeView->addTagAttributes()`
|
||||
* :php:`AbstractTreeView->getRootIcon()`
|
||||
* :php:`AbstractTreeView->getIcon()`
|
||||
* :php:`AbstractTreeView->getRootRecord()`
|
||||
* :php:`AbstractTreeView->getTitleStr()`
|
||||
* :php:`AbstractTreeView->getTitleAttrib()`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Instantiating the deprecated classes or calling the deprecated methods will
|
||||
trigger a PHP deprecation warning, except for
|
||||
:php:`AbstractTreeView->getThisScript()`, which is still used internally by
|
||||
deprecated code.
|
||||
|
||||
The Extension Scanner will find those usages and additionally also reports
|
||||
usages of the corresponding public properties of the :php:`AbstractTreeView`
|
||||
class.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions using this functionality. This is
|
||||
usually the case for old installations from TYPO3 v6 or TYPO3 v4 times.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
It is recommended to avoid generating the markup directly in PHP. Instead use
|
||||
one of various other tree functionalities (for example, see PageTree implementations)
|
||||
in PHP and render trees via web components or Fluid.
|
||||
|
||||
.. index:: Backend, PHP-API, FullyScanned, ext:backend
|
||||
@@ -0,0 +1,50 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100459-1680683235:
|
||||
|
||||
=========================================================
|
||||
Deprecation: #100459 - BackendUtility::getRecordToolTip()
|
||||
=========================================================
|
||||
|
||||
See :issue:`100459`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The method :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getRecordToolTip()`
|
||||
has been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling this method will trigger a PHP deprecation warning.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions using this method. This is usually
|
||||
the case for old installations where Fluid templates or Extbase backend modules
|
||||
were not common.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
As this method is just a wrapper around :php:`BackendUtility::getRecordIconAltText()`
|
||||
with a "title" attribute for the markup, the replacement is straightforward:
|
||||
|
||||
Before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$link = '<a href="..." ' . BackendUtility::getRecordToolTip(...) . '>my link</a>';
|
||||
|
||||
After:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$link = '<a href="..." title="' . BackendUtility::getRecordIconAltText(...) . '">my link</a>';
|
||||
|
||||
.. index:: Backend, PHP-API, FullyScanned, ext:backend
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100461-1680690006:
|
||||
|
||||
============================================================
|
||||
Deprecation: #100461 - TypoScript option config.xhtmlDoctype
|
||||
============================================================
|
||||
|
||||
See :issue:`100461`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TypoScript option :typoscript:`config.xhtmlDoctype` has been marked as
|
||||
deprecated. This is done in order to consolidate TypoScript options, as the
|
||||
option :typoscript:`config.doctype` is now the default.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Having :typoscript:`config.xhtmlDoctype` set, but not :typoscript:`config.doctype`
|
||||
will trigger a TypoScript deprecation warning.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations having this TypoScript instruction set.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
If the property :typoscript:`config.xhtmlDoctype` is set, replace it with
|
||||
:typoscript:`config.doctype`.
|
||||
|
||||
.. index:: TypoScript, NotScanned, ext:frontend
|
||||
@@ -0,0 +1,53 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100577-1681384407:
|
||||
|
||||
======================================================
|
||||
Deprecation: #100577 - FormEngine needs request object
|
||||
======================================================
|
||||
|
||||
See :issue:`100577`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The backend FormEngine construct (editing records in the backend)
|
||||
now expects the current :php:`ServerRequestInterface` object to
|
||||
be hand over as initial data.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Backend modules that use the FormEngine data provider construct to
|
||||
render records should provide the current request object. Failing
|
||||
to do so will trigger a deprecation level log message and the system
|
||||
will fall back to :php:`$GLOBALS['TYPO3_REQUEST']`. This will stop
|
||||
working with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with extensions that provide custom modules using the FormEngine
|
||||
construct are affected. This is a relatively seldom case.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Provide the request object as "initial data" when using the
|
||||
:php:`FormDataCompiler`:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$formDataCompiler = GeneralUtility::makeInstance(FormDataCompiler::class, $myFormDataGroup);
|
||||
$formDataCompilerInput = [
|
||||
'request' => $request,
|
||||
// further data, for example:
|
||||
'tableName' => $table,
|
||||
'vanillaUid' => $uid,
|
||||
];
|
||||
$formData = $formDataCompiler->compile($formDataCompilerInput);
|
||||
|
||||
.. index:: Backend, PHP-API, NotScanned, ext:backend
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100581-1681396349:
|
||||
|
||||
=====================================================================
|
||||
Deprecation: #100581 - Avoid constructor argument in FormDataCompiler
|
||||
=====================================================================
|
||||
|
||||
See :issue:`100581`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When instantiating the backend FormEngine related :php:`FormDataCompiler`,
|
||||
the constructor argument :php:`FormDataGroupInterface` should be omitted,
|
||||
the form data group should be provided as second argument to :php:`compile()`
|
||||
instead.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Handing over the form data group as second argument to :php:`compile()`
|
||||
allows injecting :php:`FormDataCompiler` into controllers with TYPO3 v13
|
||||
since the manual constructor argument will be removed.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with own backend modules that use FormEngine to render records
|
||||
may be affected. Handing over the form data group as constructor argument
|
||||
to :php:`FormDataCompiler` will trigger a deprecation level log warning
|
||||
with TYPO3 v12. With TYPO3 v13, the form data group must be provided as
|
||||
second argument to :php:`compile()` and will not be optional anymore.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
// before
|
||||
$formDataCompiler = GeneralUtility::makeInstance(
|
||||
FormDataCompiler::class, GeneralUtility::makeInstance(MyDataGroup::class)
|
||||
);
|
||||
$formData = $formDataCompiler->compile($myFormDataCompilerInput);
|
||||
|
||||
// after
|
||||
$formDataCompiler = GeneralUtility::makeInstance(FormDataCompiler::class);
|
||||
$formData = $formDataCompiler->compile(
|
||||
$myFormDataCompilerInput,
|
||||
GeneralUtility::makeInstance(MyDataGroup::class)
|
||||
);
|
||||
|
||||
.. index:: Backend, PHP-API, NotScanned, ext:backend
|
||||
@@ -0,0 +1,62 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100584-1681452843:
|
||||
|
||||
=======================================================
|
||||
Deprecation: #100584 - GeneralUtility::linkThisScript()
|
||||
=======================================================
|
||||
|
||||
See :issue:`100584`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The method :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::linkThisScript()`
|
||||
has been marked as deprecated and should not be used any longer.
|
||||
|
||||
The method uses the super global :php:`$_GET` which should be avoided. Instead,
|
||||
data should be retrieved via the PSR-7 :php:`ServerRequestInterface`.
|
||||
|
||||
Controllers should typically create URLs using the :php:`\TYPO3\CMS\Backend\Routing\UriBuilder`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using the method triggers a deprecation level log entry in TYPO3 v12, the
|
||||
method will be removed with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
The method was typically used in backend context: Extensions with own
|
||||
backend modules may be affected. The extension scanner finds usages
|
||||
with a strong match.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
:php:`linkThisScript()` was typically used when a link to some view is
|
||||
created that should return back to the current view later.
|
||||
|
||||
Controllers usually "know" the route a view should return to and the relevant
|
||||
GET parameters.
|
||||
|
||||
A transition could look like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$uriBuilder = GeneralUtility::makeInstance(UriBuilder::class);
|
||||
$queryParams = $request->getQueryParams();
|
||||
$url = $uriBuilder->buildUriFromRoute(
|
||||
'my_route',
|
||||
[
|
||||
'table' => $queryParams['table'] ?? '',
|
||||
'uid' => (int)($queryParams['uid'] ?? 0),
|
||||
]
|
||||
);
|
||||
|
||||
|
||||
.. index:: Backend, PHP-API, FullyScanned, ext:core
|
||||
+87
@@ -0,0 +1,87 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100587-1681477405:
|
||||
|
||||
=======================================================================================================
|
||||
Deprecation: #100587 - Deprecate form engine additionalJavaScriptPost and custom eval inline JavaScript
|
||||
=======================================================================================================
|
||||
|
||||
See :issue:`100587`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The result property `additionalJavaScriptPost` of the form engine result array
|
||||
is deprecated. It was used, for instance, in custom eval definitions, that provided
|
||||
inline JavaScript (configured via :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tce']['formevals']`).
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Custom form engine components that assign the result property `additionalJavaScriptPost`,
|
||||
or custom eval class implementations for method :php:`returnFieldJS()` that return a plain
|
||||
string (which is used as inline JavaScript), will raise a deprecation level log message.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Installations that use custom form engine components modifying the result array,
|
||||
or custom eval class implementations for method :php:`returnFieldJS()` returning
|
||||
a plain string.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Instead of using inline JavaScript, functionality has to be bundled in a static
|
||||
JavaScript module. Custom eval class implementations for method :php:`returnFieldJS()`
|
||||
have to return an instance of :php:`\TYPO3\CMS\Core\Page\JavaScriptModuleInstruction`
|
||||
instead of a plain string.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Deprecated custom eval implementation:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
namespace TYPO3\CMS\Redirects\Evaluation;
|
||||
|
||||
class SourceHost
|
||||
{
|
||||
public function returnFieldJS(): string
|
||||
{
|
||||
$jsCode = [];
|
||||
$jsCode[] = 'if (value === \'*\') {return value;}';
|
||||
$jsCode[] = 'var parser = document.createElement(\'a\');';
|
||||
$jsCode[] = 'parser.href = value.indexOf(\'://\') != -1 ? value : \'http://\' + value;';
|
||||
$jsCode[] = 'return parser.host;';
|
||||
return implode(' ', $jsCode);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Migrated custom eval implementation (JavaScript is now bundled in module
|
||||
:js:`@typo3/redirects/form-engine-evaluation.js`):
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
namespace TYPO3\CMS\Redirects\Evaluation;
|
||||
|
||||
class SourceHost
|
||||
{
|
||||
public function returnFieldJS(): JavaScriptModuleInstruction
|
||||
{
|
||||
return JavaScriptModuleInstruction::create(
|
||||
'@typo3/redirects/form-engine-evaluation.js',
|
||||
'FormEngineEvaluation'
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
.. index:: Backend, NotScanned, ext:backend
|
||||
@@ -0,0 +1,68 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100596-1681478199:
|
||||
|
||||
=============================================
|
||||
Deprecation: #100596 - GeneralUtility::_GET()
|
||||
=============================================
|
||||
|
||||
See :issue:`100596`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The method :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::_GET()` has
|
||||
been marked as deprecated and should not be used any longer.
|
||||
|
||||
Modern code should access GET and POST data from the PSR-7 :php:`ServerRequestInterface`,
|
||||
and should avoid accessing superglobals :php:`$_GET` directly. This also avoids
|
||||
future side-effects when using sub-requests. Some :php:`GeneralUtility` related
|
||||
helper methods like :php:`_GET()` violate this, using them is considered a technical
|
||||
debt. They are being phased out.
|
||||
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling the method from PHP code will log a PHP deprecation level entry,
|
||||
the method will be removed with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with third-party extensions using :php:`GeneralUtility::_GET()`
|
||||
are affected, typically in TYPO3 installations which
|
||||
have been migrated to the latest TYPO3 Core versions and
|
||||
haven't been adapted properly yet.
|
||||
|
||||
The extension scanner will find usages with a strong match.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
:php:`GeneralUtility::_GET()` is a helper method that retrieves
|
||||
incoming HTTP `GET` query arguments and returns the value.
|
||||
|
||||
The same result can be achieved by retrieving arguments from the request object.
|
||||
An instance of the PSR-7 :php:`ServerRequestInterface` is handed over to
|
||||
controllers by TYPO3 Core's PSR-15 :php:`\TYPO3\CMS\Core\Http\RequestHandlerInterface`
|
||||
and middleware implementations, and is available in various related scopes
|
||||
like the frontend :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer`.
|
||||
|
||||
Typical code:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
use TYPO3\CMS\Core\Utility\GeneralUtility;
|
||||
|
||||
// Before
|
||||
$value = GeneralUtility::_GET('tx_scheduler');
|
||||
|
||||
// After
|
||||
$value = $request->getQueryParams()['tx_scheduler'] ?? null;
|
||||
|
||||
|
||||
.. index:: PHP-API, FullyScanned, ext:core
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100597-1681480956:
|
||||
|
||||
================================================================================================
|
||||
Deprecation: #100597 - BackendUtility methods getThumbnailUrl() and getLinkToDataHandlerAction()
|
||||
================================================================================================
|
||||
|
||||
See :issue:`100597`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The methods :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getThumbnailUrl()`
|
||||
and :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getLinkToDataHandlerAction()`
|
||||
have been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling those methods will trigger a PHP deprecation level log warning.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions using those methods. The extension
|
||||
scanner will report usages as strong match.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Instead of calling :php:`BackendUtility::getThumbnailUrl()`, inject and use
|
||||
the :php:`\TYPO3\CMS\Core\Resource\ResourceFactory` directly:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
// before
|
||||
$url = BackendUtility::getThumbnailUrl(2004, [
|
||||
'width' => 20,
|
||||
'height' => 13,
|
||||
'_context' => ProcessedFile::CONTEXT_IMAGEPREVIEW
|
||||
]);
|
||||
|
||||
// after
|
||||
$url = $this->resourceFactory
|
||||
->getFileObject(2004)
|
||||
->process(ProcessedFile::CONTEXT_IMAGEPREVIEW, ['width' => 20, 'height' => 13])
|
||||
->getPublicUrl();
|
||||
|
||||
Instead of calling :php:`BackendUtility::getLinkToDataHandlerAction()`, inject
|
||||
and use the :php:`\TYPO3\CMS\Backend\Routing\UriBuilder` directly:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
// before
|
||||
$url = BackendUtility::getLinkToDataHandlerAction(
|
||||
'&cmd[pages][123][localize]=10',
|
||||
(string)$uriBuilder->buildUriFromRoute('some_route')
|
||||
);
|
||||
|
||||
// after
|
||||
$url = (string)$this->uriBuilder->buildUriFromRoute(
|
||||
'tce_db',
|
||||
[
|
||||
'cmd' => [
|
||||
'pages' => [
|
||||
123 => [
|
||||
'localize' => 10,
|
||||
],
|
||||
],
|
||||
],
|
||||
'redirect' => (string)$uriBuilder->buildUriFromRoute('some_route'),
|
||||
]
|
||||
);
|
||||
|
||||
In case the second parameter `$redirectUrl` was omitted,
|
||||
:php:`getLinkToDataHandlerAction` automatically used the current request URI
|
||||
as the return URL. In case you relied on this, make sure the `redirect`
|
||||
parameter is set to :php:`$request->getAttribute('normalizedParams')->getRequestUri()`.
|
||||
|
||||
.. index:: Backend, PHP-API, FullyScanned, ext:backend
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100614-1681589901:
|
||||
|
||||
=======================================================================================
|
||||
Deprecation: #100614 - Deprecate PageRenderer::$inlineJavascriptWrap and $inlineCssWrap
|
||||
=======================================================================================
|
||||
|
||||
See :issue:`100614`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The protected properties :php:`$inlineJavascriptWrap` and :php:`$inlineCssWrap`
|
||||
of the class :php:`\TYPO3\CMS\Core\Page\PageRenderer` have been deprecated and
|
||||
shall not be used any longer.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
:php:`PageRenderer` specifics concerning rendering XHTML or non-HTML5 content are
|
||||
not working any longer in affected installations having custom code extending
|
||||
:php:`\TYPO3\CMS\Core\Page\PageRenderer`.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Installations with custom code extending :php:`\TYPO3\CMS\Core\Page\PageRenderer`
|
||||
that are reading from or writing to the mentioned protected properties
|
||||
:php:`$inlineJavascriptWrap` or :php:`$inlineCssWrap`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Avoid using the protected properties :php:`$inlineJavascriptWrap` and
|
||||
:php:`$inlineCssWrap`. In case any custom code needs to wrap with inline
|
||||
:html:`<script>` or :html:`<style>` tags, use the new protected methods
|
||||
:php:`wrapInlineScript($content)` and :php:`wrapInlineStyle($content)`
|
||||
within :php:`\TYPO3\CMS\Core\Page\PageRenderer`.
|
||||
|
||||
|
||||
.. index:: Frontend, Backend, NotScanned, ext:core
|
||||
@@ -0,0 +1,102 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100622-1681664078:
|
||||
|
||||
==============================================
|
||||
Deprecation: #100622 - Extbase feature toggles
|
||||
==============================================
|
||||
|
||||
See :issue:`100622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Extbase has an own system for feature toggles next to the Core feature
|
||||
toggle API. It has always been marked as internal, but is used for
|
||||
a couple of toggles within the Extbase framework.
|
||||
|
||||
All toggles and the internal PHP API have been marked as deprecated
|
||||
in TYPO3 v12 and should be avoided.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The PHP API for Extbase toggles has always been marked as internal. It will
|
||||
be removed with TYPO3 v13.
|
||||
|
||||
The single toggles can still be used in TYPO3 v12, but their triggered
|
||||
functionality will be removed with TYPO3 v13, if set to `1`.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Extensions should not rely on
|
||||
:php:`\TYPO3\CMS\Extbase\ConfigurationConfigurationManagerInterface->isFeatureEnabled()`.
|
||||
The method is marked as internal and should never have been used by extensions. The
|
||||
extension scanner still finds usages of this method in extensions as weak match.
|
||||
|
||||
All feature toggles have been marked as deprecated. Setting one of them to `1` in
|
||||
TypoScript will trigger a deprecation level log message, they will stop working with
|
||||
TYPO3 v13.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Extbase has three feature toggles in TYPO3 v12. All of them will be removed
|
||||
with TYPO3 v13. Instances with extensions setting those to `1` in TypoScript
|
||||
may need adaptions. Instances setting the toggles to `0` can simply remove them
|
||||
from TypoScript.
|
||||
|
||||
skipDefaultArguments = 1
|
||||
------------------------
|
||||
|
||||
This is an ancient toggle that was used before routing has been added with
|
||||
TYPO3 v9. It allowed to skip the `controller` and `action` argument in frontend
|
||||
plugin links, when linking to the default Extbase controller / action combination.
|
||||
This toggle has been documented as being broken in combination with
|
||||
:ref:`Extbase plugin enhancer <t3coreapi:routing-extbase-plugin-enhancer>` already.
|
||||
Consuming instances should switch to proper routing configuration instead.
|
||||
|
||||
ignoreAllEnableFieldsInBe = 1
|
||||
-----------------------------
|
||||
|
||||
This is another ancient toggle that triggers
|
||||
:php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->setIgnoreEnableFields(true)`
|
||||
for Extbase repositories when used in backend scope. It allows ignoring default :php:`TCA`
|
||||
flags like suppressing of deleted records in queries.
|
||||
|
||||
Extbase-based backend modules that rely on this toggle being set to `1` can easily
|
||||
migrate this: When the repository in question is only used in backend context, the
|
||||
code below should trigger the same behavior. Note as with other query settings,
|
||||
this toggle needs to be used with care, otherwise backend users may see records
|
||||
they are not supposed to see.
|
||||
|
||||
.. code-block::php
|
||||
|
||||
/**
|
||||
* Overwrite createQuery to not respect enable fields.
|
||||
*/
|
||||
public function createQuery(): QueryInterface
|
||||
{
|
||||
$query = parent::createQuery();
|
||||
$query->getQuerySettings()->setIgnoreEnableFields(true);
|
||||
return $query;
|
||||
}
|
||||
|
||||
When the repository is used in both backend and frontend context, the code
|
||||
should be refactored a bit towards a public method that can be set by the
|
||||
Extbase backend controller only.
|
||||
|
||||
enableNamespacedArgumentsForBackend = 1
|
||||
---------------------------------------
|
||||
|
||||
This toggle has been introduced in TYPO3 v12. See :ref:`feature-97096`
|
||||
for more details. Extbase backend modules should no longer expect the
|
||||
namespace to be set. It may be necessary to adapt some Ajax calls and
|
||||
request-related argument checks in custom modules.
|
||||
|
||||
|
||||
.. index:: PHP-API, TypoScript, PartiallyScanned, ext:extbase
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100637-1681737971:
|
||||
|
||||
====================================================================
|
||||
Deprecation: #100637 - Third argument ContentObjectRenderer->start()
|
||||
====================================================================
|
||||
|
||||
See :issue:`100637`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When creating instances of the
|
||||
:php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer`, the
|
||||
third argument :php:`$request` when calling :php:`start()` should not be
|
||||
handed over anymore. Instead, :php:`setRequest()` should be used
|
||||
after creating the object.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Handing over the third argument to :php:`start()` has been marked as deprecated
|
||||
in TYPO3 v12, it will be ignored with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with casual extensions are probably not affected by this: Instances
|
||||
of :php:`ContentObjectRenderer` are usually set-up framework internally.
|
||||
|
||||
Using the third argument on :php:`start()` triggers a deprecation level log
|
||||
message. The extension scanner will *not* find usages, since the method
|
||||
name :php:`start()` is used in different context as well and would lead to
|
||||
too many false positives.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Ensure the request is an instance of :php:`Psr\Http\Message\ServerRequestInterface`,
|
||||
and call :php:`setRequest()` after instantiation instead of calling
|
||||
:php:`start()` with three arguments.
|
||||
|
||||
|
||||
.. index:: Frontend, PHP-API, NotScanned, ext:frontend
|
||||
@@ -0,0 +1,47 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100639-1681740974:
|
||||
|
||||
===============================================
|
||||
Deprecation: #100639 - Deprecate AbstractPlugin
|
||||
===============================================
|
||||
|
||||
See :issue:`100639`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Abstract "pibase" class :php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin`
|
||||
has been marked @internal with
|
||||
:ref:`changelog-Breaking-98281-MakeAbstractPluginInternal <breaking-98281-1662549900>` in TYPO3 v12.0
|
||||
already and should not be used anymore.
|
||||
|
||||
It has now been fully deprecated with TYPO3 v12.4 and will be removed with TYPO3 v13.0.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Extending :php:`AbstractPlugin` will trigger a deprecation level log warning
|
||||
since TYPO3 v12.4. The class will be removed with TYPO3 v13.0.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with frontend plugin extensions that extend
|
||||
:php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin` are affected.
|
||||
|
||||
The extension scanner will find usages with a strong match.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Stop extending the class. A simple way to migrate is by copying needed methods
|
||||
over to an own controller class. See
|
||||
:ref:`changelog-Breaking-98281-MakeAbstractPluginInternal <breaking-98281-1662549900>`
|
||||
for more details on this.
|
||||
|
||||
|
||||
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100653-1681805677:
|
||||
|
||||
==============================================================
|
||||
Deprecation: #100653 - Deprecated some methods in DebugUtility
|
||||
==============================================================
|
||||
|
||||
See :issue:`100653`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following methods in :php:`\TYPO3\CMS\Core\Utility\DebugUtility` have been
|
||||
marked as deprecated:
|
||||
|
||||
* :php:`debugInPopUpWindow()`
|
||||
* :php:`debugRows()`
|
||||
* :php:`printArray()`
|
||||
|
||||
While :php:`debugRows()` and :php:`printArray()` duplicate already existing
|
||||
methods, :php:`debugInPopUpWindow()` is discouraged to use as either external
|
||||
debuggers, e.g. Xdebug or :php:`\TYPO3\CMS\Extbase\Utility\DebuggerUtility` may
|
||||
be used instead.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling any of the aforementioned methods will trigger deprecation log entries.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances using any of the aforementioned methods are affected.
|
||||
|
||||
The extension scanner will find and report usages.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
In case of :php:`debugRows()`, the identical method :php:`debug()` can be used.
|
||||
The method :php:`printArray()` can be replaced with :php:`viewArray()`. However,
|
||||
the former method directly outputs the contents, which is not the case with
|
||||
:php:`viewArray()`.
|
||||
|
||||
The method :php:`debugInPopUpWindow()` is deprecated without a direct
|
||||
replacement, consider using an external debugger or
|
||||
:php:`\TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump()` instead.
|
||||
|
||||
.. index:: PHP-API, FullyScanned, ext:core
|
||||
@@ -0,0 +1,58 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100657-1681816063:
|
||||
|
||||
=============================================================
|
||||
Deprecation: #100657 - TYPO3_CONF_VARS['BE']['languageDebug']
|
||||
=============================================================
|
||||
|
||||
See :issue:`100657`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['languageDebug']`
|
||||
has been marked as deprecated in TYPO3 v12, it will be removed with TYPO3 v13
|
||||
along with the property :php:`\TYPO3\CMS\Core\Localization->debugKey`.
|
||||
|
||||
Setting the configuration option `languageDebug` to true adds the label name
|
||||
including the path to the :file:`.xlf` file to the output in the backend.
|
||||
|
||||
The intention was to allow translators to see where a specific localized
|
||||
string comes from in the backend to allow locating missing localization
|
||||
sources.
|
||||
|
||||
Judging from translators feedback, the option isn't used in practice, though:
|
||||
Setting the toggle to true leads to a massively convoluted backend experience
|
||||
that breaks tons of CSS and renders the backend so unusable that it's hardly
|
||||
a benefit at all.
|
||||
|
||||
TYPO3 v12 cleaned up lots of label usages and makes them more unique.
|
||||
Translators should find single label usages much more easily by searching
|
||||
the code base for label names and label files. Also, many Fluid templates are
|
||||
located more transparently and are easier to find, localizing labels within
|
||||
PHP classes is also improving a lot. Translators should in general have
|
||||
less headaches to see where labels are used, and this will improve further.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The option has been marked as deprecated in TYPO3 v12 and does not have any
|
||||
effect anymore with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
The target of this toggle were translators, production sites are not affected
|
||||
by this. Extensions using the property :php:`\TYPO3\CMS\Core\Localization->debugKey`
|
||||
are found by the extension scanner as weak match.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove access to :php:`\TYPO3\CMS\Core\Localization->debugKey`.
|
||||
|
||||
.. index:: Backend, LocalConfiguration, PartiallyScanned, ext:core
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100662-1681906563:
|
||||
|
||||
===============================================================
|
||||
Deprecation: #100662 - ConfigurationManager->getContentObject()
|
||||
===============================================================
|
||||
|
||||
See :issue:`100662`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The Extbase-related method
|
||||
:php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface->getContentObject()`
|
||||
has been marked as deprecated in TYPO3 v12 and should not be used anymore.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling :php:`ConfigurationManagerInterface->getContentObject()` will trigger
|
||||
a deprecation level log message in TYPO3 v12, the method will be removed
|
||||
from the interface together with their implementations with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with Extbase extensions that use :php:`getContentObject()` on
|
||||
injected :php:`ConfigurationManager` instances are affected. The extension
|
||||
scanner has not been configured to find these calls, since the method
|
||||
name is used in different scope as well and would trigger too many
|
||||
false positives.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
There may be instances with Extbase controllers that need to retrieve
|
||||
data from the current content object that initiated the frontend Extbase
|
||||
plugin call.
|
||||
|
||||
In this case, controllers can access the current content object from the
|
||||
Extbase request object using :php:`$request->getAttribute('currentContentObject')`
|
||||
instead.
|
||||
|
||||
|
||||
.. index:: PHP-API, NotScanned, ext:extbase
|
||||
@@ -0,0 +1,138 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100670-1681916011:
|
||||
|
||||
================================================
|
||||
Deprecation: #100670 - DI-aware FormEngine nodes
|
||||
================================================
|
||||
|
||||
See :issue:`100670`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When the FormEngine construct (used when editing records in the backend) has
|
||||
been rewritten back in TYPO3 v7, dependency injection for non-Extbase
|
||||
constructs has not been a thing, yet.
|
||||
|
||||
With dependency injection being part of the TYPO3 Core extension since TYPO3 v10,
|
||||
and the Extbase solution being out-phased, it is time to make FormEngine
|
||||
dependency injection aware as well.
|
||||
|
||||
This has some impact on classes implementing
|
||||
:php:`\TYPO3\CMS\Backend\Form\NodeInterface` directly, or indirectly by
|
||||
extending :php:`\TYPO3\CMS\Backend\Form\AbstractNode` and
|
||||
:php:`\TYPO3\CMS\Backend\Form\Element\AbstractFormElement`. Custom
|
||||
implementations *can* use this already, but the full power will
|
||||
only be leveraged with TYPO3 v13.
|
||||
|
||||
Similar changes as described below can be done for classes implementing
|
||||
:php:`\TYPO3\CMS\Backend\Form\NodeResolverInterface` as well, but the
|
||||
impact is much smaller since this construct is used less often in the wild.
|
||||
|
||||
Additionally, classes should either implement one of the interfaces
|
||||
directly, or extend an appropriate abstract. They must not extend any
|
||||
of the existing "leaf" classes the core provides, since those will be
|
||||
declared :php:`final` with TYPO3 v13.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using dependency injection within FormEngine related classes
|
||||
becomes possible in TYPO3 v12.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
Instances with extensions that come with own FormEngine additions
|
||||
may be affected. The extensions scanner is not configured to find
|
||||
affected classes.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Compatibility with TYPO3 v11 and v12
|
||||
------------------------------------
|
||||
|
||||
Extensions that strive for both TYPO3 v11 and v12 compatibility should
|
||||
just keep their implementation as is.
|
||||
|
||||
Compatibility with TYPO3 v12 and v13
|
||||
------------------------------------
|
||||
|
||||
Extensions that strive for TYPO3 v12 compatibility, skipping v11, that
|
||||
want to support v13 as well, must adapt their implementations.
|
||||
|
||||
As main change, :php:`NodeInterface` no longer declares :php:`__construct()`,
|
||||
the class constructor is now "free" for injection. The :php:`NodeFactory` uses
|
||||
the existence of method :php:`setData()` as indicator if :php:`NodeFactory` and
|
||||
:php:`$data` array should be hand over as manual constructor argument (old way),
|
||||
or if :php:`setData()` should be called after object instantiation. Note
|
||||
:php:`setData()` will be activated as interface method with TYPO3 v13.
|
||||
|
||||
A class with both TYPO3 v12 and v13 compatibility should look like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
public function __construct(
|
||||
// If the class creates sub elements
|
||||
NodeFactory $nodeFactory,
|
||||
// If the class needs IconFactory
|
||||
IconFactory $iconFactory,
|
||||
// Further dependencies
|
||||
private readonly MyService $myService,
|
||||
) {
|
||||
$this->nodeFactory = $nodeFactory;
|
||||
$this->iconFactory = $iconFactory;
|
||||
}
|
||||
|
||||
public function setData(array $data): void
|
||||
{
|
||||
$this->data = $data;
|
||||
}
|
||||
|
||||
public function render(): array
|
||||
{
|
||||
// Implement render(), note the "array" return type hint,
|
||||
// which will be mandatory in TYPO3 v13.
|
||||
}
|
||||
|
||||
The class has to be registered for public DI in :file:`Services.yaml` as well, since
|
||||
it is instantiated by :php:`NodeFactory` using :php:`GeneralUtility::makeInstance()`:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
MyVendor\MyExtension\Form\Element\MyElementClass:
|
||||
public: true
|
||||
|
||||
|
||||
Compatibility with v13
|
||||
----------------------
|
||||
|
||||
Extensions dropping TYPO3 v12 compatibility and going with v13 and up, can
|
||||
simplify the construct: In v13, :php:`setData()` will be added to :php:`AbstractNode`,
|
||||
extending classes don't need to implement it anymore. The class
|
||||
property :php:`$iconFactory` (:php:`AbstractFormElement`
|
||||
only) will be removed from the abstracts, constructor property promotion
|
||||
can be used. :php:`NodeFactory` will be injected in the abstracts, without
|
||||
polluting :php:`__construct()`. Also, a dependency injection service provider pass will
|
||||
be added, to automatically set classes public that implement implement :php:`NodeInterface`,
|
||||
so a :yaml:`public: true` entry in :file:`Services.yaml` can be skipped.
|
||||
|
||||
A typical class extending :php:`AbstractNode` looks like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
public function __construct(
|
||||
private readonly IconFactory $iconFactory,
|
||||
private readonly MyService $myService,
|
||||
) {
|
||||
}
|
||||
|
||||
// Implement render().
|
||||
|
||||
|
||||
.. index:: PHP-API, NotScanned, ext:backend
|
||||
@@ -0,0 +1,74 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-100721-1682333511:
|
||||
|
||||
==========================================================
|
||||
Deprecation: #100721 - Label-related methods and arguments
|
||||
==========================================================
|
||||
|
||||
See :issue:`100721`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The method :php:`\TYPO3\CMS\Core\Localization\LanguageService->getLL()` has been
|
||||
marked as deprecated.
|
||||
|
||||
Along with the deprecation the method
|
||||
:php:`\TYPO3\CMS\Core\Localization\LanguageService->includeLLFile()` has been
|
||||
marked as internal, as it is still used in TYPO3 Core for backwards-compatibility
|
||||
internally, but not part of TYPO3's Core API anymore.
|
||||
|
||||
With the introduction of :ref:`Locales <feature-99694-1674552209>`, it is also now not recommended anymore to use
|
||||
custom alternative language keys.
|
||||
|
||||
For this reason the argument "alternativeLanguageKeys" of the
|
||||
:html:`<f:translate>` ViewHelper has been deprecated as well, along with the
|
||||
method argument of the same name in
|
||||
:php:`\TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate()`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling the method :php:`\TYPO3\CMS\Core\Localization\LanguageService->getLL()`
|
||||
will trigger a PHP deprecation warning.
|
||||
|
||||
Calling :php:`\TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate()` with
|
||||
the argument "alternativeLanguageKeys" will also trigger a PHP deprecation warning,
|
||||
which is the underlying deprecation warning when using the argument
|
||||
"alternativeLanguageKeys" of the :html:`<f:translate>` ViewHelper.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations within backend modules using the method :php:`getLL()` or
|
||||
extensions or templates using the translate methods.
|
||||
|
||||
The former usually happens in extensions which have been migrated from older
|
||||
TYPO3 versions with legacy functionality in backend modules along
|
||||
with :php:`$GLOBALS['LANG']` as :php:`LanguageService` object.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
It is highly recommended to use the full path to a label file along
|
||||
with the :php:`sL()` method of :php:`\TYPO3\CMS\Core\Localization\LanguageService`:
|
||||
|
||||
Before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['LANG']->includeLLfile('EXT:my_extension/Resources/Private/Language/db.xlf');
|
||||
$label = htmlspecialchars($GLOBALS['LANG']->getLL('my_label'));
|
||||
|
||||
After:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$label = $GLOBALS['LANG']->sL('LLL:EXT:my_extension/Resources/Private/Language/db.xlf:my_label');
|
||||
$label = htmlspecialchars($label);
|
||||
|
||||
.. index:: PHP-API, PartiallyScanned, ext:core
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-98093-1681741493:
|
||||
|
||||
================================================================
|
||||
Deprecation: #98093 - ext_icon.* as extension icon file location
|
||||
================================================================
|
||||
|
||||
See :issue:`98093`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Since :issue:`77349` it is possible to place the extension icon, which is
|
||||
displayed at various places in the backend, e.g. in the extension manager, in
|
||||
an extension's :file:`Resources/Public/Icons/` directory. The :file:`Resources/` directory
|
||||
is :ref:`by convention <t3coreapi:extension-files-locations>` the place to
|
||||
store such files. To simplify the extension registration and to fully follow the
|
||||
convention the following file locations have been deprecated:
|
||||
|
||||
* :file:`ext_icon.png`
|
||||
* :file:`ext_icon.svg`
|
||||
* :file:`ext_icon.gif`
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Adding an extension icon using one of the mentioned file locations will raise
|
||||
a deprecation level log message and will stop working with TYPO3 v13.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions using the deprecated file locations.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Place your extension icon as :file:`Extension.*` into :file:`Resources/Public/Icons/`,
|
||||
as described in :ref:`Feature: #77349 - Additional locations for extension icons <feature-77349>`.
|
||||
|
||||
.. index:: Backend, NotScanned, ext:core
|
||||
@@ -0,0 +1,37 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-99237-1681640732:
|
||||
|
||||
=======================================
|
||||
Deprecation: #99237 - MagicImageService
|
||||
=======================================
|
||||
|
||||
See :issue:`99237`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The class :php:`\TYPO3\CMS\Core\Resource\Service\MagicImageService`, which was
|
||||
previously used for inline images by EXT:rtehtmlarea has been marked as
|
||||
deprecated, since its functionality is no longer needed for `CKEditor`.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using :php:`\TYPO3\CMS\Core\Resource\Service\MagicImageService` or one of its
|
||||
public methods will raise a deprecation level log message.
|
||||
|
||||
|
||||
Affected installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions using the class or its public
|
||||
methods. The extension scanner will report usages as strong match.
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
There is no direct migration. In case you rely on any of the provided
|
||||
functionality, just copy the corresponding code into your custom extension.
|
||||
|
||||
.. index:: PHP-API, NotScanned, ext:core
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-100207-1679414752:
|
||||
|
||||
==================================================================================
|
||||
Important: #100207 - Let DataMapper::createEmptyObject() use doctrine/instantiator
|
||||
==================================================================================
|
||||
|
||||
See :issue:`100207`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This document explains the intended way in which the Extbase ORM thaws/hydrates objects.
|
||||
|
||||
Hydrating objects
|
||||
-----------------
|
||||
|
||||
Hydrating (the term originates from `doctrine/orm`), or in Extbase terms thawing, is
|
||||
the act of creating an object from a given database row. The responsible class involved
|
||||
is the :php:`DataMapper`. During the process of hydrating, the :php:`DataMapper` creates
|
||||
objects to map the raw database data onto.
|
||||
|
||||
Before diving into the framework internals, let's take a look at models from the
|
||||
user's perspective.
|
||||
|
||||
Creating objects with constructor arguments
|
||||
-------------------------------------------
|
||||
|
||||
Imagine you have a table :sql:`tx_extension_domain_model_blog` and a corresponding model
|
||||
or entity (entity is used as a synonym here) :php:`Vendor\Extension\Domain\Model\Blog`.
|
||||
|
||||
Now, also imagine there is a domain rule which states, that all blogs must have a
|
||||
title. This rule can easily be followed by letting the blog class have a constructor
|
||||
with a required argument :php:`string $title`.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
class Blog extends AbstractEntity
|
||||
{
|
||||
protected ObjectStorage $posts;
|
||||
|
||||
public function __construct(protected string $title)
|
||||
{
|
||||
$this->posts = new ObjectStorage();
|
||||
}
|
||||
}
|
||||
|
||||
This example also shows how the :php:`posts` property is initialized. It is done in
|
||||
the constructor because PHP does not allow setting a default value that is of
|
||||
type object.
|
||||
|
||||
Hydrating objects with constructor arguments
|
||||
--------------------------------------------
|
||||
|
||||
Whenever the user creates new blog objects in extension code, the aforementioned
|
||||
domain rule is followed. It is also possible to work on the :php:`posts` :php:`ObjectStorage`
|
||||
without further initialization. :php:`new Blog('title')` is all I need to create
|
||||
a blog object with a valid state.
|
||||
|
||||
What happens in the :php:`DataMapper` however, is a totally different thing. When
|
||||
hydrating an object, the :php:`DataMapper` cannot follow any domain rules. Its only
|
||||
job is to map the raw database values onto a `Blog` instance. The :php:`DataMapper`
|
||||
could of course detect constructor arguments and try to guess which argument
|
||||
corresponds to what property but only if there is an easy mapping, i.e. if the
|
||||
constructor takes argument :php:`string $title` and updates property `title` with it.
|
||||
|
||||
To avoid possible errors due to guessing, the :php:`DataMapper` simply
|
||||
ignores the constructor at all. It does so with the help of the library `doctrine/instantiator`_.
|
||||
|
||||
.. _doctrine/instantiator: https://github.com/doctrine/instantiator
|
||||
|
||||
This pretty much explains the title of this document in detail. But there is more
|
||||
to all this.
|
||||
|
||||
Initializing objects
|
||||
--------------------
|
||||
|
||||
Have a look at the :php:`$posts` property in the example above. If the :php:`DataMapper`
|
||||
ignores the constructor, that property is in an invalid state, i.e. uninitialized.
|
||||
|
||||
To address this problem and possible others, the :php:`DataMapper` will call the method
|
||||
`initializeObject(): void` on models, if it exists.
|
||||
|
||||
Here is an updated version of the model:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
class Blog extends AbstractEntity
|
||||
{
|
||||
protected ObjectStorage $posts;
|
||||
|
||||
public function __construct(protected string $title)
|
||||
{
|
||||
$this->initializeObject();
|
||||
}
|
||||
|
||||
public function initializeObject(): void
|
||||
{
|
||||
$this->posts = new ObjectStorage();
|
||||
}
|
||||
}
|
||||
|
||||
This example demonstrates how Extbase expects the user to set up their model(s). If
|
||||
method :php:`initializeObject()` is used for initialization logic that needs to be
|
||||
triggered on initial creation AND on hydration. Please mind that :php:`__construct()`
|
||||
**SHOULD** call :php:`initializeObject()`.
|
||||
|
||||
If there are no domain rules to follow, the recommended way to set up a model
|
||||
would then still be to define a :php:`__construct()` and :php:`initializeObject()`
|
||||
method like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
class Blog extends AbstractEntity
|
||||
{
|
||||
protected ObjectStorage $posts;
|
||||
|
||||
public function __construct()
|
||||
{
|
||||
$this->initializeObject();
|
||||
}
|
||||
|
||||
public function initializeObject(): void
|
||||
{
|
||||
$this->posts = new ObjectStorage();
|
||||
}
|
||||
}
|
||||
|
||||
Mutating objects
|
||||
----------------
|
||||
|
||||
I'd like to add a few more words on mutators (setter, adder, etc.). One might think that
|
||||
:php:`DataMapper` uses mutators during object hydration but it DOES NOT. `mutators`
|
||||
are the only way for the user (developer) to implement business rules besides
|
||||
using the constructor.
|
||||
|
||||
The :php:`DataMapper` uses the `@internal` method :php:`AbstractDomainObject::_setProperty()`
|
||||
to update object properties. This looks a bit dirty and is a way around all business
|
||||
rules but that's what the :php:`DataMapper` needs in order to leave the `mutators` to
|
||||
the users.
|
||||
|
||||
.. warning::
|
||||
|
||||
While :php:`DataMapper` does not use any mutators, other parts of Extbase do.
|
||||
Both, validation and property mapping, either use existing mutators or gather
|
||||
type information from them. This will change in the future but as of TYPO3 v12 LTS
|
||||
this information is correct.
|
||||
|
||||
Property visibility
|
||||
-------------------
|
||||
|
||||
One important thing to know is that Extbase needs entity properties to be protected
|
||||
or public. As written in the former paragraph, :php:`AbstractDomainObject::_setProperty()`
|
||||
is used to bypass setters. :php:`AbstractDomainObject` however, is not able to access
|
||||
private properties of child classes, hence the need to have protected or public
|
||||
properties.
|
||||
|
||||
|
||||
Dependency injection
|
||||
--------------------
|
||||
|
||||
Without digging too deep into this topic the following statements have to be made.
|
||||
Extbase expects entities to be so called prototypes, i.e. classes that do have a
|
||||
different state per instance. DataMapper DOES NOT use dependency injection for the
|
||||
creation of entities, i.e. it does not query the object container. This also means,
|
||||
that dependency injection is not possible in entities.
|
||||
|
||||
If you think that your entities need to use/access services, you need to find other
|
||||
ways to implement it.
|
||||
|
||||
.. index:: PHP-API, ext:extbase
|
||||
@@ -0,0 +1,69 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-100525-1681029540:
|
||||
|
||||
================================================================================
|
||||
Important: #100525 - Dropped usage of .text(-*)-right and .text(-*)-left classes
|
||||
================================================================================
|
||||
|
||||
See :issue:`100525`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The Core has dropped support for directional class names to
|
||||
better support RTL languages. We are now preferring the logical
|
||||
class names over the directional ones. This change also affects
|
||||
the default RTE configuration.
|
||||
|
||||
In summary, that means we are dropping the classes :css:`.text-right`
|
||||
and :css:`.text-left` and replacing them with their logical counterparts
|
||||
:css:`.text-end` and :css:`.text-start`.
|
||||
|
||||
We are still shipping the :css:`.text-right` and :css:`.text-left` classes
|
||||
with the default RTE content styling. Your content is
|
||||
persisted as is and we have no intention of changing this.
|
||||
|
||||
You will see the following:
|
||||
|
||||
- Your content is still aligned as you set it once
|
||||
- The alignment button will not be active anymore for :css:`.text-left`
|
||||
and :css:`.text-right`
|
||||
- New alignments will now use :css:`.text-end` and :css:`.text-start`
|
||||
|
||||
While there is never a good time to introduce such a change,
|
||||
we still think this will benefit us all over time.
|
||||
|
||||
If you want to follow us on that route, we suggest that you
|
||||
add the following CSS to your frontend and or the custom
|
||||
CSS for your RTE.
|
||||
|
||||
.. code-block:: css
|
||||
|
||||
.text-end {
|
||||
text-align: end;
|
||||
}
|
||||
.text-start {
|
||||
text-align: start;
|
||||
}
|
||||
|
||||
See caniuse for compatibility, which is 96.23% at the time of writing.
|
||||
For example: https://caniuse.com/?search=text-align%3A%20start
|
||||
|
||||
You need to adjust your RTE config, if you want to use
|
||||
the old classes.
|
||||
|
||||
.. code-block:: yaml
|
||||
:caption: EXT:my_extension/Configuration/RTE/MyPreset.yaml
|
||||
|
||||
editor:
|
||||
config:
|
||||
alignment:
|
||||
options:
|
||||
- { name: 'left', className: 'text-left' }
|
||||
- { name: 'center', className: 'text-center' }
|
||||
- { name: 'right', className: 'text-right' }
|
||||
- { name: 'justify', className: 'text-justify' }
|
||||
|
||||
|
||||
.. index:: RTE, ext:rte_ckeditor
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-100634-1681822129:
|
||||
|
||||
=============================================================
|
||||
Important: #100634 - Rich Text Editor always enabled per user
|
||||
=============================================================
|
||||
|
||||
See :issue:`100634`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Back in TYPO3 v3.x there was an RTE integrated into TYPO3 which only worked
|
||||
in Internet Explorer 4+, but not in Mozilla / Firefox browsers. This was a
|
||||
huge mess, as not every user / client was able to use an RTE and instead to had
|
||||
to write pure HTML in a :html:`<textarea>` input field with special tags ("typolink" etc).
|
||||
|
||||
Since TYPO3 v4 a huge effort were made to integrate HTMLarea as Rich Text Editor,
|
||||
which was forked and developed by the TYPO3 community. It was then possible for
|
||||
most users working with a real RTE.
|
||||
|
||||
In v8, TYPO3 migrated towards CKEditor 4 as a dependency, and :ref:`CKEditor 5 <feature-96874-1664488673>` with
|
||||
TYPO3 v12, the Rich Text Editor is working very browser-native for modern browsers
|
||||
without an iframe around the RTE.
|
||||
|
||||
A lot of legacy code was moved and migrated, however, one option - the option
|
||||
to deactivate the Rich Text Editor on a per-user basis - which was necessary in
|
||||
TYPO3 v3, has now been removed, as it is not needed in 99.99%
|
||||
of TYPO3 installations and users anymore nowadays.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The previous user TSconfig setting :typoscript:`setup.edit_RTE` has no effect anymore.
|
||||
|
||||
.. index:: TSConfig, ext:setup
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-100658-1681819486:
|
||||
|
||||
====================================================================================================
|
||||
Important: #100658 - Drop use TSconfig options `createFoldersInEB` and `folderTree.hideCreateFolder`
|
||||
====================================================================================================
|
||||
|
||||
See :issue:`100658`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The user TSconfig options :typoscript:`createFoldersInEB` and :typoscript:`folderTree.hideCreateFolder` were
|
||||
used in the past to control the existence of the "Create folder" form in Element
|
||||
Browser instances. With the migration of the "Create folder" view into a separate
|
||||
modal used in EXT:filelist, which is based on Element Browser as well, those
|
||||
options became useless and are therefore dropped.
|
||||
|
||||
.. index:: Backend, TSConfig, ext:backend
|
||||
@@ -0,0 +1,106 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-94246-1681366863:
|
||||
|
||||
===================================================
|
||||
Important: #94246 - Generic sudo mode configuration
|
||||
===================================================
|
||||
|
||||
See :issue:`94246`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
:doc:`Sudo mode <../9.5.x/Important-92836-IntroduceSudoModeForInstallToolAccessedViaBackend>`
|
||||
has been integrated since TYPO3 v9.5.x to protect only Install Tool components. With TYPO3 v12
|
||||
it has been changed to a generic configuration for backend routes (and implicitly modules).
|
||||
|
||||
Besides that, access to the Extension Manager now needs to pass the sudo mode verification as well.
|
||||
|
||||
|
||||
Process in a nutshell
|
||||
---------------------
|
||||
|
||||
All simplified classnames below are located in the namespace :php:`\TYPO3\CMS\Backend\Security\SudoMode\Access`).
|
||||
The low-level request orchestration happens in the middleware :php:`\TYPO3\CMS\Backend\Middleware\SudoModeInterceptor`,
|
||||
markup rendering and payload processing in controller :php:`\TYPO3\CMS\Backend\Controller\Security\SudoModeController`.
|
||||
|
||||
#. A backend route is processed, that requires sudo mode for route URI `/my/route`
|
||||
in :php:`\TYPO3\CMS\Backend\Http\RouteDispatcher`.
|
||||
#. Using :php:`AccessFactory` and :php:`AccessStorage`, the :php:`RouteDispatcher`
|
||||
tries to find a valid and not expired :php:`AccessGrant` item for the specific
|
||||
:php:`RouteAccessSubject('/my/route')` aspect in the current backend user session data.
|
||||
#. In case no :php:`AccessGrant` can be determined, a new :php:`AccessClaim` is created
|
||||
for the specific :php:`RouteAccessSubject` instance and temporarily persisted in the
|
||||
current user session data - the claim also contains the originally requested route
|
||||
as :php:`ServerRequestInstruction` (a simplified representation of a :php:`ServerRequestInterface`).
|
||||
#. Next, the user is redirected to the user interface for providing either their own password, or
|
||||
the global install tool password as alternative.
|
||||
#. Given, the password was correct, the :php:`AccessClaim` is "converted" to an
|
||||
:php:`AccessGrant`, which is only valid for the specific subject (URI `/my/route`)
|
||||
and for a limited lifetime.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
In general, the configuration for a particular route or module looks like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
// ...
|
||||
'sudoMode' => [
|
||||
'group' => 'individual-group-name',
|
||||
'lifetime' => AccessLifetime::veryShort,
|
||||
],
|
||||
|
||||
* `group` (optional): if given, grants access to other objects of the same `group`
|
||||
without having to verify sudo mode again for a the given lifetime. Example:
|
||||
Admin Tool modules :guilabel:`Maintainance` and :guilabel:`Settings` are configured with the same
|
||||
`systemMaintainer` group - having access to one (after sudo mode verification)
|
||||
grants access to the other automatically.
|
||||
* `lifetime`: enum value of :php:`\TYPO3\CMS\Backend\Security\SudoMode\Access\AccessLifetime`,
|
||||
defining the lifetime of a sudo mode verification, afterwards users have to go through
|
||||
the process again - cases are `veryShort` (5 minutes), `short` (10 minutes),
|
||||
`medium` (15 minutes), `long` (30 minutes), `veryLong` (60 minutes)
|
||||
|
||||
|
||||
For backend routes declared via :file:`Configuration/Backend/Routes.php`, the
|
||||
relevant configuration would look like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
return [
|
||||
'my-route' => [
|
||||
'path' => '/my/route',
|
||||
'target' => MyHandler::class . '::process',
|
||||
'sudoMode' => [
|
||||
'group' => 'mySudoModeGroup',
|
||||
'lifetime' => AccessLifetime::short,
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
|
||||
For backend modules declared via :file:`Configuration/Backend/Modules.php`, the
|
||||
relevant configuration would look like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
<?php
|
||||
return [
|
||||
'tools_ExtensionmanagerExtensionmanager' => [
|
||||
// ...
|
||||
'routeOptions' => [
|
||||
'sudoMode' => [
|
||||
'group' => 'systemMaintainer',
|
||||
'lifetime' => AccessLifetime::medium,
|
||||
],
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
@@ -0,0 +1,50 @@
|
||||
:template: changelogOverview.html
|
||||
.. include:: /Includes.rst.txt
|
||||
.. _changelog-12-4:
|
||||
|
||||
============
|
||||
12.4 Changes
|
||||
============
|
||||
|
||||
**Table of contents**
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
|
||||
Breaking Changes
|
||||
================
|
||||
|
||||
None since TYPO3 v12.0 release.
|
||||
|
||||
.. attention::
|
||||
|
||||
After TYPO3 v12.0, only new functionality with a solid migration path
|
||||
can be added on top, with aiming for as little as possible breaking changes
|
||||
after the initial v12.0 release on the way to LTS.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
None since TYPO3 v12.3 release.
|
||||
|
||||
Deprecation
|
||||
===========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Deprecation-*
|
||||
|
||||
Important
|
||||
=========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Important-*
|
||||
Reference in New Issue
Block a user