TYPO3 v15 dev-main snapshot ()

This commit is contained in:
2026-08-10 22:31:09 +02:00
commit af8cc155b5
6818 changed files with 642608 additions and 0 deletions
@@ -0,0 +1,154 @@
.. include:: /Includes.rst.txt
.. _deprecation-91787:
==========================================================
Deprecation: #91787 - Inline JavaScript in fieldChangeFunc
==========================================================
See :issue:`91787`
Description
===========
Custom :php:`FormEngine` nodes allow to use internal property :php:`fieldChangeFunc`
to add or modify client-side JavaScript behavior when field values are changed.
In the past these declarations basically were inline JavaScript, provided in
PHP and forwarded to the browser via HTML :html:`onchange` or :html:`onclick`
event attributes. In favor of introducing content security policy headers and
to reduce inline JavaScript, those functionality shall be defined in a
structured way & custom client-side behavior shall be provided by corresponding
JavaScript modules instead.
As a result, :php:`fieldChangeFunc` declarations are not using plain inline
JavaScript (as scalar :php:`string`) anymore, but make use of corresponding objects
implementing new :php:`\TYPO3\CMS\Backend\Form\Behavior\OnFieldChangeInterface`.
This interface provides both a new structured and declarative approach via
`JSON` - but also allows to fallback to legacy inline JavaScript in case it
is required in combination with legacy 3rd party extensions.
Using :php:`fieldChangeFunc` with scalar :php:`string` values has been marked as deprecated and has to
be substituted with specific implementations of :php:`OnFieldChangeInterface`.
Impact
======
Using :php:`fieldChangeFunc` with scalar :php:`string` values will trigger a
PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
Installations implementing custom :php:`FormEngine` components (wizards, nodes,
render-types, ...) that provide inline JavaScript using :php:`fieldChangeFunc`.
.. code-block:: php
// examples
$this->data['parameterArray']['fieldChangeFunc']['example'] = "alert('demo');";
$parameterArray['fieldChangeFunc']['example'] = "alert('demo');";
Migration
=========
The following steps provide a brief overview of the new components in order to
avoid inline JavaScript. A complete and installable example is available with
`ext:demo_91787 <https://github.com/ohader/demo_91787>`__.
PHP :php:`OnFieldChangeInterface` instance
------------------------------------------
.. code-block:: php
<?php
namespace TYPO3\Example;
use TYPO3\CMS\Backend\Form\Behavior\OnFieldChangeInterface;
use TYPO3\CMS\Core\Utility\GeneralUtility;
class AlertOnFieldChange implements OnFieldChangeInterface
{
protected string $value = 'demo';
public function __toString(): string
{
// provides `alert('demo')` as plain inline JavaScript
return sprintf(
'alert(%s)',
// always make sure to encode data, mitigating XSS
GeneralUtility::quoteJSvalue($this->value)
);
}
public function toArray(): array
{
// provides structured representation
return [
// handler `name` as registered with `FormEngine.js`
'name' => 'example-alert',
// fixed `data` segment
'data' => [
// ... can contain any arbitrary & custom payload
'value' => $this->value,
]
];
}
}
PHP :php:`FormEngine` consumer
------------------------------
.. code-block:: php
<?php
namespace TYPO3\Example;
use TYPO3\CMS\Backend\Form\Element\InputTextElement;
use TYPO3\CMS\Core\Page\PageRenderer;
use TYPO3\CMS\Core\Utility\GeneralUtility;
// just extending `input` TCA render-type, to keep it simple
class ConsumingElement extends InputTextElement
{
public function render()
{
// uses custom `OnFieldChangeInterface` implementation from above
// (whenever the value of this field is changed, an alert message shall be shown)
$this->data['parameterArray']['fieldChangeFunc']['example'] = new AlertOnFieldChange();
// side-note: before having `OnFieldChangeInterface`, it looked like this using inline code
// $this->data['parameterArray']['fieldChangeFunc']['example'] = "alert('demo');";
$pageRenderer = GeneralUtility::makeInstance(PageRenderer::class);
// registers RequireJS module to register & handle that `fieldChangeFunc` instruction
// (JavaScript module is loaded from `ext:example/Resources/Public/JavaScript/Demo.js`)
$pageRenderer->loadRequireJsModule('TYPO3/CMS/Example/Demo');
// just use parent method to render that `<input type="text">` field
return parent::render();
}
}
JavaScript :js:`FormEngine` registration
----------------------------------------
JavaScript module :js:`TYPO3/CMS/Example/Demo` is fetched via RequireJS from
resource path :file:`ext:example/Resources/Public/JavaScript/Demo.js`.
.. code-block:: javascript
define(['TYPO3/CMS/Backend/FormEngine'], (FormEngine) => {
FormEngine.registerOnFieldChangeHandler(
// `example-alert` as defined in `name` segment from PHP `AlertOnFieldChange::toArray()`
'example-alert',
// `data` segment from PHP `AlertOnFieldChange::toArray()`
(data) => { alert(data.title); }
);
})
.. index:: Backend, JavaScript, TCA, NotScanned, ext:backend
@@ -0,0 +1,155 @@
.. include:: /Includes.rst.txt
.. _deprecation-91814:
=================================================
Deprecation: #91814 - AbstractControl::setOnClick
=================================================
See :issue:`91814`
Description
===========
In favor of allowing `Content-Security-Policy` HTTP headers, inline JavaScript
invocation via :php:`\TYPO3\CMS\Backend\Template\Components\AbstractControl::setOnClick`
has been marked as deprecated. Existing instructions can be migrated using existing JavaScript
helpers :js:`GlobalEventHandler` or :js:`ActionDispatcher` and their capabilities to provide
similar functionality using :html:`data-` attributes.
There might be scenarios that require a custom JavaScript module handling
specific use cases that are not covered by mentioned JavaScript helpers.
Impact
======
Using affected PHP methods (see section below) will trigger PHP :php:`E_USER_DEPRECATED` errors.
Affected Installations
======================
All sites using 3rd party extensions that are using following methods directly
or in inherited class implementations:
* :php:`\TYPO3\CMS\Backend\Template\Components\AbstractControl->setOnClick`
* :php:`\TYPO3\CMS\Backend\Template\Components\AbstractControl->getOnClick`
Migration
=========
Mentioned JavaScript helpers cover most common use cases by using :html:`data-`
attributes instead of :html:`onclick` event attributes with corresponding HTML
elements.
* consider replacing simple :html:`<a ... onclick="window.location.href=[URI]"`
with plain HTML links like :html:`<a href="[URI]">`
* replacing :php:`BackendUtility::viewOnClick`,
:doc:`see documentation & examples <../11.0/Important-91123-AvoidUsingBackendUtilityViewOnClick>`
* using :html:`data-` attributes for :js:`GlobalEventHandler` and :js:`ActionDispatcher`,
:doc:`see documentation & examples <../10.4.x/Important-91117-UseGlobalEventHandlerAndActionDispatcherInsteadOfInlineJS>`
Example #1: open a new window/tab
---------------------------------
* taken from extension `dce`
* see `corresponding pull-request <https://bitbucket.org/ArminVieweg/dce/pull-requests/97/task-avoid-using-abstractcontrol>`__
.. code-block:: php
$button->setOnClick(
'window.open(\'' . $this->getDceEditLink($contentUid) . '\', \'editDcePopup\', ' .
'\'height=768,width=1024,status=0,menubar=0,scrollbars=1\')'
);
Code block above being substituted with :js:`ActionDispatcher` capabilities,
using :html:`data-dispatch-action` and :html:`data-dispatch-args` HTML attributes:
.. code-block:: php
$button->setDataAttributes([
'dispatch-action' => 'TYPO3.WindowManager.localOpen',
// JSON encoded representation of JavaScript function arguments
// (HTML attributes are encoded in \TYPO3\CMS\Backend\Template\Components\Buttons\LinkButton)
'dispatch-args' => GeneralUtility::jsonEncodeForHtmlAttribute([
$this->getDceEditLink($contentUid),
'editDcePopup',
'height=768,width=1024,status=0,menubar=0,scrollbars=1',
], false)
]);
Example #2: preview page in frontend
------------------------------------
* taken from extension `wizard_crpagetree`
* see `corresponding pull-request <https://github.com/liayn/t3ext-wizard_crpagetree/pull/8>`__
.. code-block:: php
$viewButton = $buttonBar->makeLinkButton()
// @deprecated setOnClick
->setOnClick(BackendUtility::viewOnClick($pageUid, '', BackendUtility::BEgetRootLine($pageUid)))
->setTitle($this->getLanguageService()->sL('LLL:EXT:core/Resources/Private/Language/locallang_core.xlf:labels.showPage'))
->setIcon($iconFactory->getIcon('actions-view-page', Icon::SIZE_SMALL))
->setHref('#');
Code block above being substituted with :php:`\TYPO3\CMS\Backend\Routing\PreviewUriBuilder`
based on :js:`ActionDispatcher` capabilities, using :html:`data-dispatch-action` and
:html:`data-dispatch-args` HTML attributes:
.. code-block:: php
$previewDataAttributes = PreviewUriBuilder::create($pageUid)
->withRootLine(BackendUtility::BEgetRootLine($pageUid))
->buildDispatcherDataAttributes();
$viewButton = $buttonBar->makeLinkButton()
// substituted with HTML data attributes
->setDataAttributes($previewDataAttributes ?? [])
->setTitle($this->getLanguageService()->sL('LLL:EXT:core/Resources/Private/Language/locallang_core.xlf:labels.showPage'))
->setIcon($iconFactory->getIcon('actions-view-page', Icon::SIZE_SMALL))
->setHref('#');
Example #3: confirmation dialog
-------------------------------
* taken form extension `news`
* see `corresponding pull-request <https://github.com/georgringer/news/pull/1585>`__
* side-note: There was a bug in extension `news`, examples below have been adjusted
to show how the scenario probably would have been before, using :js:`confirm()`
.. code-block:: php
$pasteTitle = 'Paste from Clipboard';
$confirmMessage = GeneralUtility::quoteJSvalue('Shall we paste the record?');
$viewButton = $buttonBar->makeLinkButton()
->setHref($clipBoard->pasteUrl('', $this->pageUid))
// @deprecated inline JavaScript requesting user confirmation
->setOnClick('return confirm(' . $confirmMessage . ')')
->setTitle($pasteTitle)
->setIcon($this->iconFactory->getIcon('actions-document-paste-into', Icon::SIZE_SMALL));
Code block above being substituted with capabilities of modal dialog handling
and functionalities of the Bootstrap framework.
.. code-block:: php
$pasteTitle = 'Paste from Clipboard';
$confirmMessage = 'Shall we paste the record?';
$viewButton = $buttonBar->makeLinkButton()
->setHref($clipBoard->pasteUrl('', $this->pageUid))
// using CSS class to trigger confirmation in modal box
->setClasses('t3js-modal-trigger')
->setDataAttributes([
'title' => $pasteTitle,
'bs-content' => $confirmMessage,
])
->setTitle($pasteTitle)
->setIcon($this->iconFactory->getIcon('actions-document-paste-into', Icon::SIZE_SMALL));
.. index:: Backend, JavaScript, PHP-API, FullyScanned, ext:backend
@@ -0,0 +1,48 @@
.. include:: /Includes.rst.txt
.. _deprecation-94094:
==================================================================
Deprecation: #94094 - navigationFrameModule in Module Registration
==================================================================
See :issue:`94094`
Description
===========
TYPO3 allowed for each module to include an iFrame for the navigation area with
the option :php:`navigationFrameModule` and :php:`navigationFrameModuleParameters`.
Since TYPO3 4.5 it was possible to also use a JavaScript component instead
via :php:`navigationComponentId`.
TYPO3 v11 allows to use Web Components for the :php:`navigationComponentId` option,
and all Core-based navigation components have been migrated to Lit-based
Web Components.
With this technology, TYPO3 does not need to handle iFrames for
the navigation area anymore, which is why the feature, together
with the option :php:`navigationFrameModule` has been marked as deprecated.
Impact
======
TYPO3 installations with third-party extensions registering
custom navigation iFrames will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations with third-party extensions shipping modules
with a custom navigation iFrame.
Migration
=========
Migration should be done by using Web Components, as this is much
faster and allows for better interoperability due to less usages of iFrames.
.. index:: Backend, NotScanned, ext:backend
@@ -0,0 +1,53 @@
.. include:: /Includes.rst.txt
.. _deprecation-94791:
========================================================
Deprecation: #94791 - GeneralUtility::minifyJavaScript()
========================================================
See :issue:`94791`
Description
===========
The static method :php:`TYPO3\CMS\Core\Utility\GeneralUtility::minifyJavaScript()`
has been marked as deprecated.
Back in TYPO3 4.x times, the "jsmin" library was used to minify
JavaScript, however as this became more flexible, a hook was
introduced, and then "jsmin" was removed again. Since then,
the hook to minify inline JavaScript is used in PageRenderer,
and should rather be moved into the :php:`ResourceCompressor` functionality,
where it resides now.
The hook itself works exactly as before.
Impact
======
Calling the method will trigger a PHP :php:`E_USER_DEPRECATED` error. Extension
scanner will detect calls as strong match.
Affected Installations
======================
TYPO3 installations with custom extensions calling this method,
which is highly unlikely.
Custom extensions using this hook will still work as before without any changes.
Migration
=========
As this method was used to only trigger a hook, it is recommended
to use the :php:`PageRenderer` and :php:`ResourceCompressor` API instead, removing
any direct calls to this method.
If still needed, extension authors can also copy the hook call
execution to use the hook logic, which is not recommended though.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,54 @@
.. include:: /Includes.rst.txt
.. _deprecation-95041:
===============================================
Deprecation: #95041 - <f:uri.email> view-helper
===============================================
See :issue:`95041`
Description
===========
Fluid view-helper :html:`<f:uri.email email="{email}">` was used in combination
with :typoscript:`config.spamProtectEmailAddresses` settings during frontend rendering
and returned corresponding :js:`javascript:linkTo_UnCryptMailto(...)` inline
JavaScript URI. In case spam-protections is not configured, this view-helper
just passed through the given email address.
In favor of allowing more content security policy scenarios, :js:`URI`
is not used anymore per default. As a result, :html:`<f:uri.email>`
view-helper became obsolete. The view-helper will be removed with TYPO3 v12.0.
Impact
======
Using :html:`<f:uri.email>` view-helper will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
All projects using :html:`<f:uri.email email="{email}">` or
:html:`{email -> f:uri.email(email:email)}` view-helper invocations in their Fluid templates.
Migration
=========
In case :typoscript:`config.spamProtectEmailAddresses` is used, make use of
:html:`<f.link.email email="{email}">` view-helper which returns the
complete :html:`<a>` tag like this:
.. code-block:: html
<a href="#" data-mailto-token="ocknvq,hqqBdct0vnf"
data-mailto-vector="1">user(at)my.example(dot)com</a>
In case spam-protected is not used or not useful (for example in backend user
interface), view-helper invocation can be omitted completely.
.. index:: Fluid, Frontend, FullyScanned, ext:fluid
@@ -0,0 +1,60 @@
.. include:: /Includes.rst.txt
.. _deprecation-95139:
===============================================
Deprecation: #95139 - Extbase ControllerContext
===============================================
See :issue:`95139`
Description
===========
The Extbase related class :php:`TYPO3\CMS\Extbase\Mvc\Controller\ControllerContext`
has been used in the past to transfer data between Extbase controllers and Fluid
views. It has been superseded by class :php:`TYPO3\CMS\Fluid\Core\Rendering\RenderingContext`
with various preparation patches. To further decouple Fluid from Extbase, class
:php:`ControllerContext` has been marked as deprecated.
Impact
======
Accessing :php:`ControllerContext` and consuming information carried in it has
been marked as deprecated. The class will be removed in TYPO3 v12. The object is bound
to various Fluid view related classes and all occurrences have been marked with
an :php:`@deprecated` annotation.
To retain backwards compatibility, accessing :php:`ControllerContext` does not
actively trigger a PHP :php:`E_USER_DEPRECATED` error in most cases, though.
Affected Installations
======================
Instances with extensions that access :php:`ControllerContext` are affected. This
typically affects extensions which provide own view-helpers. The extension scanner
should find possible matches.
Migration
=========
Two getters of the class have already been marked as deprecated with previous patches, namely
:php:`->getUriBuilder()` as documented with :php:`->getFlashMessageQueue()`. Classes
should inject instances of these objects instead, or should :php:`makeInstance()` them.
Method :php:`getRequest()` is available in controllers directly, and view-helpers
receive the current request by calling :php:`RenderingContext->getRequest()`.
Method :php:`getArguments()` returns the Extbase :php:`Arguments` created by the
:php:`ActionController`. The getter has become mostly useless within Fluid context
since argument validation of forms is abstracted differently since various core versions.
If that object construct is still needed, it should be transferred differently to
consuming classes, for instance by assigning it as variable to the view and accessing
it in a view-helper using the variable container. In many cases it should be sufficient
to directly work with the request object instead.
.. index:: Fluid, PHP-API, PartiallyScanned, ext:extbase
@@ -0,0 +1,95 @@
.. include:: /Includes.rst.txt
.. _deprecation-95164:
=====================================================
Deprecation: #95164 - ext:backend BackendTemplateView
=====================================================
See :issue:`95164`
Description
===========
To simplify and align the view part of Extbase-based backend module controller code with
non-Extbase based controllers, class :php:`TYPO3\CMS\Backend\View\BackendTemplateView`
has been marked as deprecated and will be removed in TYPO3 v12.
This follows the general Core strategy to have document header related code
using the :php:`ModuleTemplate` class structure within controllers directly, while
Extbase views render only the main body part.
Impact
======
Extensions should switch away from using :php:`BackendTemplateView`. By hiding an
instance of :php:`ModuleTemplate` class, :php:`BackendTemplateView` basically added
a no longer needed level of indirection to code that should be located directly
within controller actions.
Together with the TYPO3 v11 requirement within Extbase controller actions to return
responses directly, combined with Extbase Request object now implementing the PSR-7
ServerRequestInterface, and with the deprecation of other doc header related Fluid
View helpers, Extbase controller action becomes much more obvious code wise.
Affected installations
======================
Instances with extensions using class :php:`BackendTemplateView` are affected.
Candidates are typically Extbase based extensions that deliver backend modules.
The extension scanner will find usages as strong match.
Migration
=========
A transition away from :php:`BackendTemplateView` should be usually pretty straight:
Instead of retrieving a :php:`ModuleTemplate` instance from the view, the
:php:`ModuleTemplateFactory` should be injected and an instance retrieved using
:php:`create()`.
A typical scenario before:
.. code-block:: php
class MyController extends ActionController
{
protected $defaultViewObjectName = BackendTemplateView::class;
public function myAction(): ResponseInterface
{
$this->view->assign('someVar', 'someContent');
$moduleTemplate = $this->view->getModuleTemplate();
// Adding title, menus, buttons, etc. using $moduleTemplate ...
return $this->htmlResponse();
}
}
Dropping :php:`BackendTemplateView` leads to code similar to this:
.. code-block:: php
class MyController extends ActionController
{
protected ModuleTemplateFactory $moduleTemplateFactory;
public function __construct(
ModuleTemplateFactory $moduleTemplateFactory,
) {
$this->moduleTemplateFactory = $moduleTemplateFactory;
}
public function myAction(): ResponseInterface
{
$this->view->assign('someVar', 'someContent');
$moduleTemplate = $this->moduleTemplateFactory->create($this->request);
// Adding title, menus, buttons, etc. using $moduleTemplate ...
$moduleTemplate->setContent($this->view->render());
return $this->htmlResponse($moduleTemplate->renderContent());
}
}
.. index:: Backend, Fluid, PHP-API, FullyScanned, ext:backend
@@ -0,0 +1,83 @@
.. include:: /Includes.rst.txt
.. _deprecation-95200:
==============================================================
Deprecation: #95200 - RequireJS callbacks as inline JavaScript
==============================================================
See :issue:`95200`
Description
===========
Custom :php:`FormEngine` components allowed to load RequireJS modules
with arbitrary inline JavaScript to initialize those modules. In favor
of introducing content security policy headers, the amount of inline
JavaScript shall be reduced and replaced by corresponding declarations.
Using callback functions has been marked as deprecated and shall be replaced by new
:php:`TYPO3\CMS\Core\Page\JavaScriptModuleInstruction` declarations. In
:php:`FormEngine`, loading RequireJS module via arrays has been marked as deprecated and
has to be migrated as well.
Impact
======
Using :php:`$resultArray['requireJsModules']` with scalar :php:`string` values will
trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
Installations implementing custom :php:`FormEngine` components and loading
RequireJS modules via :php:`$resultArray['requireJsModules']` are affected.
Migration
=========
New :php:`JavaScriptModuleInstruction` allows to declare the following
aspects when loading RequireJS modules:
* :php:`$instruction = JavaScriptModuleInstruction::forRequireJS('TYPO3/CMS/Module')`
creates corresponding loading instruction that can be enriched with
following declarations
* :php:`$instruction->assign(['key' => 'value'])` allows to assign key-value pairs
directly to the loaded RequireJS module object or instance
* :php:`$instruction->invoke('method', 'value-a', 'value-b')` allows to invoke
a particular method of the loaded RequireJS instance with given argument values
* :php:`$instruction->instance('value-a', 'value-b')` allows to invoke the
constructor of the loaded RequireJS class with given argument values
Initializations other than the provided aspects have to be implemented in
custom module implementations, for example triggered by corresponding on-ready handlers.
Example in :php:`FormEngine` component
--------------------------------------
.. code-block:: php
$resultArray['requireJsModules'][] = ['TYPO3/CMS/Backend/FormEngine/Element/InputDateTimeElement' => '
function(InputDateTimeElement) {
new InputDateTimeElement(' . GeneralUtility::quoteJSvalue($fieldId) . ');
}'
];
... has to be migrated to the following ...
.. code-block:: php
// use use TYPO3\CMS\Core\Page\JavaScriptModuleInstruction;
$resultArray['requireJsModules'][] = JavaScriptModuleInstruction::forRequireJS(
'TYPO3/CMS/Backend/FormEngine/Element/InputDateTimeElement'
)->instance($fieldId);
:php:`JavaScriptModuleInstruction` forwards arguments as `JSON` data - and thus
handles proper context-aware encoding implicitly (:php:`GeneralUtility::quoteJSvalue`
and similar custom encoding can be omitted in this case).
.. index:: Backend, JavaScript, NotScanned, ext:backend
@@ -0,0 +1,54 @@
.. include:: /Includes.rst.txt
.. _deprecation-95219:
==============================================================
Deprecation: #95219 - TypoScriptFrontendController->ATagParams
==============================================================
See :issue:`95219`
Description
===========
The public property :php:`TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->ATagParams`
has been marked as deprecated.
It was used in the past as a copy of the value
:php:`TypoScriptFrontendController->config[config][ATagParams]`,
which should be used instead.
There is no need to use such a (less prominent) configuration option in a
separate public property, as it needs to be kept in sync with the
actual configuration option.
The second argument of the related method
:php:`TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->getATagParams()`
called :php:`$addGlobal` is also marked as deprecated, and will have no effect
anymore in TYPO3 v12.
Impact
======
Accessing, setting or writing this property will trigger a PHP :php:`E_USER_DEPRECATED` error.
Calling :php:`ContentObjectRenderer->getATagParams()`
with a second argument set to false will trigger a PHP :php:`E_USER_DEPRECATED` error
as well.
Affected Installations
======================
TYPO3 installations with third-party-extensions accessing, or
writing this property directly within PHP, or calling :php:`getATagParams()`
directly, which is highly unlikely.
Migration
=========
All calls of :php:`$GLOBALS['TSFE']->ATagParams` can be replaced
with :php:`$GLOBALS['TSFE']->config['config']['ATagParams'] ?? ''`.
.. index:: Frontend, PHP-API, TypoScript, FullyScanned, ext:frontend
@@ -0,0 +1,93 @@
.. include:: /Includes.rst.txt
.. _deprecation-95222:
===========================================
Deprecation: #95222 - Extbase ViewInterface
===========================================
See :issue:`95222`
Description
===========
To further streamline Fluid view-related class inheritance and dependencies,
the interface :php:`TYPO3\CMS\Extbase\Mvc\View\ViewInterface` has been marked
as deprecated and will be removed in TYPO3 v12.
Impact
======
This deprecation has minimal impact on TYPO3 v11:
* The interface remains available in the Core without triggering
a E_USER_DEPRECATED warning.
* ViewInterface primarily differs from other view-related classes by
requiring an implementation of :php:`initializeView()`, a method that was
never actively used within TYPO3's Core. This method should not be confused
with :php:`initializeView()` in Extbase controllers, which is frequently
implemented by developers and serves a different purpose. The removal
of :php:`initializeView()` only affects view-related logic and does not
impact controller initialization.
* Another deviation is the method :php:`setControllerContext()`, which is
also deprecated because :php:`ControllerContext` itself is marked
as deprecated.
Affected Installations
======================
The extension scanner will detect usages of Extbase :php:`ViewInterface` as a
strong match.
Migration
=========
Adjusting initializeView() method signature in controllers
----------------------------------------------------------
Some extensions may rely on :php:`ViewInterface` type hints, particularly in
the :php:`initializeView()` method of Extbase action controllers. The default
implementation of :php:`initializeView()` in :php:`ActionController` is empty.
In TYPO3 v12:
* This empty method will be removed from :php:`ActionController`.
* However, if an :php:`initializeView()` method exists in a subclass of
:php:`ActionController`, it will still be called.
* Extension authors should not call :php:`parent::initializeView($view)`, as
this parent method will no longer exist.
* The method signature should be updated to prevent PHP
contravariance violations:
Old:
.. code-block:: php
protected function initializeView(ViewInterface $view)
New:
.. code-block:: php
protected function initializeView($view)
Replacing ViewInterface
-----------------------
Instead of using :php:`\TYPO3\CMS\Extbase\Mvc\View\ViewInterface`, extension
authors should switch to:
* :php:`\TYPO3\CMS\Fluid\View\StandaloneView` — typically in
non-Extbase-related classes.
* :php:`\TYPO3Fluid\Fluid\View\ViewInterface` — for a more
generic replacement.
Handling Custom Views
---------------------
If an extension defines a custom view implementing :php:`ViewInterface`, note
that auto-configuration based on this interface will be removed in TYPO3 v12.
As a result, manual service configuration in :file:`Services.yaml` may
be necessary.
.. index:: Fluid, PHP-API, FullyScanned, ext:fluid
@@ -0,0 +1,87 @@
.. include:: /Includes.rst.txt
.. _deprecation-95235:
=================================================================
Deprecation: #95235 - Public getter of services in ModuleTemplate
=================================================================
See :issue:`95235`
Description
===========
The public methods :php:`getIconFactory` and :php:`getPageRenderer`
in :php:`TYPO3\CMS\Backend\Template\ModuleTemplate` have been marked as deprecated,
since using this getters only hides the dependencies to those services.
Impact
======
Calling either :php:`getIconFactory` or :php:`getPageRenderer` will
trigger a PHP :php:`E_USER_DEPRECATED` error. The extension scanner also detects
such calls as weak match.
Affected Installations
======================
All installations calling the methods in custom extension code.
Migration
=========
Inject the corresponding services :php:`TYPO3\CMS\Core\Imaging\IconFactory`
and :php:`TYPO3\CMS\Core\Page\PageRenderer` directly in your class.
A current Extbase backend controller might look like:
.. code-block:: php
class MyController extends ActionController
{
protected ModuleTemplateFactory $moduleTemplateFactory;
public function __construct(ModuleTemplateFactory $moduleTemplateFactory)
{
$this->moduleTemplateFactory = $moduleTemplateFactory;
}
public function myAction(): ResponseInterface
{
$moduleTemplate = $this->moduleTemplateFactory->create($this->request);
$moduleTemplate->getPageRenderer()->loadRequireJsModule('Vendor/Extension/MyJsModule');
$moduleTemplate->setContent($moduleTemplate->getIconFactory()->getIcon('some-icon', Icon::SIZE_SMALL)->render());
return $this->htmlResponse($moduleTemplate->renderContent());
}
}
This should be migrated to:
.. code-block:: php
class MyController extends ActionController
{
protected ModuleTemplateFactory $moduleTemplateFactory;
protected IconFactory $iconFactory;
protected PageRenderer $pageRenderer;
public function __construct(
ModuleTemplateFactory $moduleTemplateFactory,
IconFactory $iconFactory,
PageRenderer $pageRenderer
) {
$this->moduleTemplateFactory = $moduleTemplateFactory;
$this->iconFactory = $iconFactory;
$this->pageRenderer = $pageRenderer;
}
public function myAction(): ResponseInterface
{
$moduleTemplate = $this->moduleTemplateFactory->create($this->request);
$this->pageRenderer->loadRequireJsModule('Vendor/Extension/MyJsModule');
$moduleTemplate->setContent($this->iconFactory->getIcon('some-icon', Icon::SIZE_SMALL)->render());
return $this->htmlResponse($moduleTemplate->renderContent());
}
}
.. index:: Backend, PHP-API, FullyScanned, ext:backend
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _deprecation-95254:
===============================================
Deprecation: #95254 - Two FlexFormTools methods
===============================================
See :issue:`95254`
Description
===========
Two detail methods of class :php:`TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools`
have been marked as deprecated:
* :php:`FlexFormTools->getArrayValueByPath()`
* :php:`FlexFormTools->setArrayValueByPath()`
Impact
======
Calling the methods will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
Some instances may contain extensions calling above methods. The extension
scanner will find usages as weak match.
Migration
=========
The methods can be substituted with two counterparts from
:php:`TYPO3\CMS\Core\Utility\ArrayUtility`. They exist since TYPO3 v7 already. Their
signature is slightly different, but usages should be simple to adapt:
.. code-block:: php
// use TYPO3\CMS\Core\Utility\ArrayUtility;
// before
$value = $flexFormTools->getArrayValueByPath('search/path', $searchArray);
// after
$value = ArrayUtility::getValueByPath($searchArray, 'search/path');
// before
$flexFormTools->setArrayValueByPath('set/path', $dataArray, $value);
// after
$dataArray = ArrayUtility::setValueByPath($dataArray, 'set/path', $value);
.. index:: FlexForm, PHP-API, FullyScanned, ext:core
@@ -0,0 +1,48 @@
.. include:: /Includes.rst.txt
.. _deprecation-95257:
========================================================
Deprecation: #95257 - GeneralUtility::isFirstPartOfStr()
========================================================
See :issue:`95257`
Description
===========
The helper method
:php:`TYPO3\CMS\Core\Utility\GeneralUtility\GeneralUtility::isFirstPartOfStr()`
has been marked as deprecated, as the newly available PHP built-in
function :php:`str_starts_with()` can be used instead, which
supports proper typing and is faster on PHP 8.0.
For PHP 7.4 installations, the dependency `symfony/polyfill-php80`
adds the PHP function in lower PHP environments, which the TYPO3
Core ships as dependency.
Impact
======
Calling :php:`GeneralUtility::isFirstPartOfStr()` will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations using this TYPO3 API function - either via
extensions or in their own site-specific code. An analysis
via TYPO3's extension scanner will show any matches.
Migration
=========
Replace all calls of :php:`GeneralUtility::isFirstPartOfStr()` with
:php:`str_starts_with()` to avoid deprecation warnings and to keep
your code up-to-date.
See `php.net: str-starts-with <https://www.php.net/manual/en/function.str-starts-with.php>`_ for further syntax.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _deprecation-95261:
=====================================================================
Deprecation: #95261 - Public methods in SectionMarkupGenerated events
=====================================================================
See :issue:`95261`
Description
===========
In TYPO3 v10, a new page module has been introduced. In this version,
administrators could choose between those two approaches by using a feature
toggle. This toggle has been removed in TYPO3 v11, making the
:php:`TYPO3\CMS\Backend\View\PageLayoutView`
unused. Two events, introduced in :issue:`88921`, however exposed this class.
Therefore the public methods :php:`getPageLayoutView()` and
:php:`getLanguageId()` of the :php:`BeforeSectionMarkupGeneratedEvent`
and :php:`AfterSectionMarkupGeneratedEvent` have been marked as deprecated.
Impact
======
Calling those methods in event listeners will trigger a PHP :php:`E_USER_DEPRECATED` error.
The extension scanner also detects those calls as weak match.
Affected installations
======================
All installations using one of the mentioned methods are affected.
Migration
=========
Access necessary information using the new methods :php:`getPageLayoutContext()`
and :php:`getRecords()`.
Examples for retrieving information with the new methods:
.. code-block:: php
// Get the language id of the column
$event->getPageLayoutContext()->getSiteLanguage()->getLanguageId();
// Get records of the column
$event->getRecords();
// Get the page record of the column
$event->getPageLayoutContext()->getPageRecord();
.. index:: Backend, PHP-API, FullyScanned, ext:backend
@@ -0,0 +1,38 @@
.. include:: /Includes.rst.txt
.. _deprecation-95275:
================================================
Deprecation: #95275 - RelationHandler->remapMM()
================================================
See :issue:`95275`
Description
===========
Method :php:`TYPO3\CMS\Core\Database\RelationHandler->remapMM()` has been
marked as deprecated and will be removed with TYPO3 v12.
Impact
======
Calling above method will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected installations
======================
It is highly unlikely instances are affected: The method handles a detail
related to workspaces publishing and is of little use in third party extensions.
The extension scanner will find usages as weak match.
Migration
=========
No direct substitution available, the method has been integrated into
:php:`TYPO3\CMS\Core\DataHandling\DataHandler`.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _deprecation-95293:
===============================================================================
Deprecation: #95293 - StringUtility::beginsWith() and StringUtility::endsWith()
===============================================================================
See :issue:`95293`
Description
===========
The helper methods :php:`StringUtility::beginsWith()` and
:php:`StringUtility::endsWith()` have been marked as deprecated, as the newly
available PHP-built in functions :php:`str_starts_with()` and
:php:`str_ends_with()` can be used instead, which support proper typing and
is faster on PHP 8.0.
For PHP 7.4 installations, the dependency `symfony/polyfill-php80` adds the
PHP functions in lower PHP environments, which TYPO3 Core ships as dependency
since TYPO3 v10 LTS.
Impact
======
Calling :php:`StringUtility::beginsWith()` or :php:`StringUtility::endsWith()`
will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations using these TYPO3 API functions - either via extensions or
in their own site-specific code. An analysis via TYPO3's extension scanner
will show any matches.
Migration
=========
Replace all calls of :php:`StringUtility::beginsWith()` with
:php:`str_starts_with()` and :php:`StringUtility::endsWith()`
with :php:`str_ends_with()` to avoid deprecation warnings and to keep your
code up-to-date.
See `php.net: str-starts-with <https://www.php.net/manual/en/function.str-starts-with.php>`_
and `php.net: str-ends-with <https://www.php.net/manual/en/function.str-ends-with.php>`_
for further syntax.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,48 @@
.. include:: /Includes.rst.txt
.. _deprecation-95317:
========================================================================================
Deprecation: #95317 - Legacy syntax for IRRE localize synchronize command in DataHandler
========================================================================================
See :issue:`95317`
Description
===========
The :php:`\TYPO3\CMS\Core\DataHandling\DataHandler`
command :php:`inlineLocalizeSynchronize` now
triggers a PHP :php:`E_USER_DEPRECATED` error if the incoming command payload is sent
as comma-separated list rather than an array.
The array allows to synchronize/localize multiple values at once,
which is preferred since TYPO3 v7.6, and used in TYPO3 properly
since then.
Impact
======
Calling DataHandler :php:`process_cmdmap` with an incoming
command for :php:`inlineLocalizeSynchronize` with a payload
of comma-separated values will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations with custom code related to DataHandler
and modifying the :php:`inlineLocalizeSynchronize` command,
which is highly unlikely. This only affects special
handling of inline configuration fields.
Migration
=========
See :doc:`changelog <../7.6/Important-71126-AllowToDefineMultipleInlineLocalizeSynchronizeCommands>`
for further information on how to migrate your incoming
DataHandler command.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,64 @@
.. include:: /Includes.rst.txt
.. _deprecation-95318:
================================================
Deprecation: #95318 - TypoScript parseFunc.sword
================================================
See :issue:`95318`
Description
===========
The TypoScript option :typoscript:`parseFunc.sword` allows to wrap
search words (such as defined via GET parameter :html:`sword_list%5B%5D=MySearchText`)
in a special wrap when :html:`no_cache=1` is set. This functionality has been marked as
deprecated as this feature only works in non_cached environments, which
is not a recommended solution by TYPO3.
Since this behavior is enabled by default, it is highly recommended to avoid
this in general, which can be achieved by disabling the :html:`no_cache=1` GET parameter
in :file:`DefaultConfiguration.php`.
Also, such an option within :typoscript:`parseFunc` does not cover all cases to highlight
a search word, such as in headlines or HTML content which is not rendered
via :typoscript:`parseFunc`.
Impact
======
Websites called via `https://example.com/?no_cache=1&sword_list%5B%5D=MySearchText`
and a custom sword wrap will trigger a PHP :php:`E_USER_DEPRECATED` error.
As this feature is seldom used and only configured with indexed
search as desired functionality, deprecations are only triggered
when explicitly configured.
In addition, this feature only works if :typoscript:`disableNoCacheParameter`
is disabled or :typoscript:`config.no_cache = 1` is explicitly set via TypoScript
which is also not recommended in production.
Affected Installations
======================
TYPO3 installations actively using the GET argument :html:`sword_list` and have
:html:`no_cache` as allowed GET argument enabled, usually in cases where indexed
search is in use.
Migration
=========
It is recommended to implement this functionality on the client-side via
JavaScript as a custom solution, when this feature is needed.
Setting :typoscript:`lib.parseFunc.sword` to an empty string will actively
disable the functionality and not trigger a PHP :php:`E_USER_DEPRECATED` error as well.
Setting :typoscript:`lib.parseFunc.sword = <span class="ce-sword">|</span>`
will also not trigger a PHP :php:`E_USER_DEPRECATED` error for TYPO3 v11.
.. index:: Frontend, TypoScript, NotScanned, ext:frontend
@@ -0,0 +1,67 @@
.. include:: /Includes.rst.txt
.. _deprecation-95320:
========================================================================
Deprecation: #95320 - Various method arguments in Authentication objects
========================================================================
See :issue:`95320`
Description
===========
The following methods of the classes
:php:`TYPO3\CMS\Core\Authentication\AbstractUserAuthentication` and
:php:`TYPO3\CMS\Core\Authentication\BackendUserAuthentication` have their
first argument been marked as deprecated:
* :php:`AbstractUserAuthentication->writeUC()`
* :php:`AbstractUserAuthentication->unpack_uc()`
* :php:`BackendUserAuthentication->backendCheckLogin()`
The following method has its third argument marked as deprecated:
* :php:`BackendUserAuthentication->isInWebMount()`
Impact
======
Calling these methods with an explicit argument of the deprecated
arguments given will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected installations
======================
TYPO3 installations with custom extensions calling these methods
with the deprecated arguments which is highly unlikely.
Migration
=========
Call :php:`AbstractUserAuthentication->writeUC()` without a
method argument. If you need to explicitly set a custom UC value
which is not :php:`AbstractUserAuthentication->uc`, you can set this via
:php:`AbstractUserAuthentication->uc = $myValue;` in the
line before.
Call :php:`AbstractUserAuthentication->unpack_uc()` without an
method argument. If you need to explicitly set a custom UC value
which is not :php:`AbstractUserAuthentication->uc`, you can set this via
:php:`AbstractUserAuthentication->uc = $myValue;` in the
line before.
Call :php:`BackendUserAuthentication->backendCheckLogin()` without
an argument but wrap this call in a :php:`try {} catch (\Throwable $e)` if
you need the old behavior and want to avoid a deprecation
message.
Call :php:`BackendUserAuthentication->isInWebMount()` without the
third argument and check for the return value of being :php:`null`
which is the equivalent of the expected :php:`RuntimeException` being
thrown when the third argument was set to :php:`true`.
.. index:: Backend, Frontend, PHP-API, FullyScanned, ext:core
@@ -0,0 +1,51 @@
.. include:: /Includes.rst.txt
.. _deprecation-95322:
==================================================
Deprecation: #95322 - Legacy Element Browser logic
==================================================
See :issue:`95322`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/browse_links.php']['browserRendering']`
has been marked as deprecated as it has been superseded by the :php:`ElementBrowser` API,
introduced in TYPO3 v7.6.
Calling the backend routing endpoint "wizard_element_browser"
called via :html:`?mode=wizard` or :html:`?mode=rte` has been marked as deprecated.
Impact
======
Calling the backend routing endpoint "wizard_element_browser"
called via :html:`?mode=wizard` or :html:`?mode=rte` will trigger a PHP :php:`E_USER_DEPRECATED` error.
Accessing the Element Browser with a registered hook will also
trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations with legacy code (such as an old element
browser hook) or with old links to "wizard_element_browser"
prior to TYPO3 v8 which hasn't been updated yet.
Migration
=========
Use the Element Browser API, introduced in TYPO3 v7.6 instead of the
deprecated hook
`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/browse_links.php']['browserRendering']`.
Instead of referencing "wizard_element_browser" for accessing
the wizard, the link wizard with BE Routing Endpoint "wizard_link"
should be used.
.. index:: Backend, PHP-API, PartiallyScanned, ext:recordlist
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _deprecation-95326:
====================================================================================
Deprecation: #95326 - Various "getInstance()" static methods on singleton interfaces
====================================================================================
See :issue:`95326`
Description
===========
A few classes within TYPO3 Core have a static method :php:`getInstance()`
which acts as a wrapper for the constructor which originally was meant as
a performance improvement as pseudo-singleton concept in TYPO3 v6.
With dependency injection, these classes can be injected or instantiated
directly without any performance penalties.
Therefore the following methods have been marked as deprecated:
* :php:`TYPO3\CMS\Core\Resource\Index\ExtractorRegistry::getInstance()`
* :php:`TYPO3\CMS\Core\Resource\Index\FileIndexRepository::getInstance()`
* :php:`TYPO3\CMS\Core\Resource\Index\MetaDataRepository::getInstance()`
* :php:`TYPO3\CMS\Core\Resource\OnlineMedia\Helpers\OnlineMediaHelperRegistry::getInstance()`
* :php:`TYPO3\CMS\Core\Resource\Rendering\RendererRegistry::getInstance()`
* :php:`TYPO3\CMS\Core\Resource\TextExtraction\TextExtractorRegistry::getInstance()`
* :php:`TYPO3\CMS\Form\Service\TranslationService::getInstance()`
* :php:`TYPO3\CMS\T3editor\Registry\AddonRegistry::getInstance()`
* :php:`TYPO3\CMS\T3editor\Registry\ModeRegistry::getInstance()`
Impact
======
Calling the methods directly in third-party PHP code will trigger a PHP
:php:`E_USER_DEPRECATED` error.
Affected Installations
======================
Any TYPO3 installation with custom PHP code calling the methods are affected.
Migration
=========
Check :guilabel:`Admin Tools > Upgrade > Scan Extension Files` if your
installation is affected and replace calls with constructor injections via
dependency injection if possible, or use
:php:`GeneralUtility::makeInstance()` instead.
.. index:: PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,40 @@
.. include:: /Includes.rst.txt
.. _deprecation-95343:
================================================================
Deprecation: #95343 - Legacy hook for new content element wizard
================================================================
See :issue:`95343`
Description
===========
The hook :php:`$GLOBALS['TBE_MODULES_EXT']['xMOD_db_new_content_el']['addElClasses']`
which has been used primarily back in TYPO3 v4.x times with the extension
kickstarter for pi-based plugins has been marked as deprecated.
Impact
======
When an extension is registering a hook, and the
:guilabel:`Create new content element` wizard is called, a PHP :php:`E_USER_DEPRECATED` error is triggered.
Affected installations
======================
TYPO3 installations with third-party extensions using this hook.
Migration
=========
The alternative hook
:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms']['db_new_content_el']['wizardItemsHook']`
can be used instead, which allows to modify and add wizard items
as well.
.. index:: Backend, PHP-API, FullyScanned, ext:backend
@@ -0,0 +1,64 @@
.. include:: /Includes.rst.txt
.. _deprecation-95349:
=======================================================================
Deprecation: #95349 - TypoScript: page.includeCSS/includeCSSLibs.import
=======================================================================
See :issue:`95349`
Description
===========
The option to use the :css:`@import` syntax for including
external CSS files through TypoScript has been marked as deprecated.
This was possible through:
.. code-block:: typoscript
page = PAGE
page.includeCSSLibs.file1 = fileadmin/benni.css
page.includeCSSLibs.file1.import = 1
Through the "import = 1" option the output was
.. code-block:: html
<style>
@import url('fileadmin/benni.css');
</style>
Impact
======
A PHP :php:`E_USER_DEPRECATED` error is triggered when having the :typoscript:`import = 1`
flag enabled in TypoScript on :typoscript:`includeCSS` or
:typoscript:`includeCSSLibs` properties.
Affected installations
======================
TYPO3 installations with the TypoScript settings
:typoscript:`page.includeCSS.aFile.import = 1`
:typoscript:`page.includeCSSLibs.aFile.import = 1`
enabled are affected.
Migration
=========
Using the :html:`<link>` tag syntax, which is the de-facto standard syntax these days,
allows to load a file directly when interpreting the HTML of the
browser, instead of first interpreting the HTML, then the CSS
and have a blocking call to an external URL to continue interpreting the CSS.
It is recommended to use the :html:`<link>` tag or create an inlineCSS TypoScript
manually to load such a file with the :css:`@import` syntax.
.. index:: TypoScript, NotScanned, ext:frontend
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _deprecation-95351:
===============================================================
Deprecation: #95351 - Custom JSWindow options in HMENU settings
===============================================================
See :issue:`95351`
Description
===========
The common HMENU settings for each HMENU level :typoscript:`JSWindow` (including
sub-properties) and :typoscript:`target` with a value such as
:typoscript:`target = 200x300`, to be set on for example TMENU properties
have been marked as deprecated.
Examples:
.. code-block:: php
page.123 = HMENU
page.123.1 = TMENU
page.123.1.JSWindow = 1
page.123.1.JSWindow.params = width=200,height=300,status=0,menubar=0
page.123 = HMENU
page.123.1 = TMENU
page.123.1.target = 200x300
Impact
======
Calling a frontend page with a HMENU and JSwindow popups will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations with a HMENU and JSwindow settings which are configured
via TypoScript, which is highly unlikely.
Migration
=========
Use an external JavaScript file with an event listener to achieve the same
functionality.
.. index:: Frontend, TypoScript, NotScanned, ext:frontend
@@ -0,0 +1,40 @@
.. include:: /Includes.rst.txt
.. _deprecation-95367:
=================================================
Deprecation: #95367 - GeneralUtility::isAbsPath()
=================================================
See :issue:`95367`
Description
===========
The low-level TYPO3 API method
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::isAbsPath()`
has been marked as deprecated.
Impact
======
Calling the method in your own PHP code will trigger a PHP :php:`E_USER_DEPRECATED` error.
Affected Installations
======================
TYPO3 installations with custom extensions calling this PHP
method are affected. You can check if you are affected via the Extension
Scanner tool provided in the Install Tool.
Migration
=========
Replace any calls to :php:`GeneralUtility::isAbsPath()` with
the exact equivalent :php:`TYPO3\CMS\Core\Utility\PathUtility::isAbsolutePath()`
which checks for the same input.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _deprecation-95395:
====================================================================================================
Deprecation: #95395 - GeneralUtility::isAllowedHostHeaderValue() and TRUSTED_HOSTS_PATTERN constants
====================================================================================================
See :issue:`95395`
Description
===========
The PHP method
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedHostHeaderValue()`
and the PHP constants
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_ALLOW_ALL`
and
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_SERVER_NAME`
have been deprecated.
Impact
======
A deprecation will be logged in TYPO3 v11 if
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedHostHeaderValue()` is
used. It is unlikely for extensions to have used this as the host header
is checked for every frontend and backend request anyway.
Usage of the constants will cause a PHP error "Undefined class constant" in
TYPO3 v12, the method
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedHostHeaderValue()` will be
dropped without replacement.
Affected Installations
======================
Installations using the constants instead of static strings or
that call the method explicitly which is unlikely.
Migration
=========
Use :php:`'.*'` instead of
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_ALLOW_ALL`
and :php:`'SERVER_NAME'` instead of
:php:`TYPO3\CMS\Core\Utility\GeneralUtility::ENV_TRUSTED_HOSTS_PATTERN_SERVER_NAME`.
Don't use :php:`TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedHostHeaderValue()`.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,80 @@
.. include:: /Includes.rst.txt
.. _feature-94868:
===========================================================================
Feature: #94868 - Introduce Bootstrap 5 compatible and accessible templates
===========================================================================
See :issue:`94868`
Description
===========
Until now, CSS classes of the frontend templates and partials of the Form
Framework were not consistently included in the form configuration. So far
some classes were present in the form configuration, others were hardcoded
only in the Fluid templates.
This situation has now been fixed for the Bootstrap 5 compatible template
variants stored in :file:`EXT:form/Resources/Private/Frontend/Version2`.
All CSS classes are consistently defined in the form configuration.
This simplifies the integration of the frontend. The change makes it easier for
integrators to make upgrades of the frontend framework. In most cases, it is
now no longer necessary to override a Fluid template for changes to classes.
Instead, it is only necessary to add the appropriate CSS classes to the
form configuration.
In order not to be breaking, by default the templates are still rendered
as they used to be.
To use the new Bootstrap 5 compatible templates the form rendering option
:yaml:`templateVariant` must be set from :yaml:`version1` to :yaml:`version2` in your form setup:
.. code-block:: yaml
TYPO3:
CMS:
Form:
prototypes:
standard:
formElementsDefinition:
Form:
renderingOptions:
templateVariant: version2
The CSS classes for the Bootstrap 5 compatible templates are defined
in the variant with the name :yaml:`template-variant` for each form element.
This is an example of the text element:
.. code-block:: yaml
TYPO3:
CMS:
Form:
prototypes:
standard:
formElementsDefinition:
Text:
variants:
-
identifier: template-variant
condition: 'getRootFormProperty("renderingOptions.templateVariant") == "version2"'
properties:
containerClassAttribute: 'form-element form-element-text mb-3'
elementClassAttribute: form-control
labelClassAttribute: form-label
To be able to access the configuration of the root element (type "Form")
in conditions, a new function :php:`getRootFormProperty()` has been introduced,
which can be used to access the properties of the "Form" element.
In the context of the "template-variant" variants this is used to determine
the template variant defined on the "Form" element in order to change the
CSS configuration properties or to add new ones.
In the course of Bootstrap 5 compatibility two new breakpoints "xl" and
"xxl" were added to the grid configuration which are also available in the
form editor.
.. index:: Frontend, ext:form
@@ -0,0 +1,69 @@
.. include:: /Includes.rst.txt
.. _feature-95176:
==========================================================
Feature: #95176 - Introduce <f:transform.html> view helper
==========================================================
See :issue:`95176`
Description
===========
Using Fluid view-helper :html:`<f:format.html>` provides capabilities to
resolve `t3://` URIs, which is used in backend contexts as well. Internally
:html:`<f:format.html>` relies on an existing frontend context, with
corresponding TypoScript configuration in :typoscript:`lib.parseFunc` being given.
In order to separate concerns better, a new :html:`<f:transform.html>`
view helper has been introduced
* to be used in frontend and backend context without relying on TypoScript,
* to avoid mixing parsing, sanitization and transformation concerns in
previously used :php:`ContentObjectRenderer::parseFunc` method of the
frontend rendering process.
Impact
======
Individual TYPO3 link handlers (like `t3://` URIs) can be resolved and
substituted without relying on TypoScript configuration and without mixing
concerns in :php:`ContentObjectRenderer::parseFunc` by using Fluid view-helper
:html:`<f:transform.html>`.
Syntax
------
:html:`<f:transform.html selector="[ node.attr, node.attr ]" onFailure="[ behavior ]">`
* `selector`: (optional) comma separated list of node attributes to be considered,
for example `subjects="a.href,a.data-uri,img.src"` (default `a.href`)
* `onFailure` (optional) corresponding behavior, in case transformation failed, for example
URI was invalid or could not be resolved properly (default `removeEnclosure`).
Based on example :html:`<a href="t3://INVALID">value</a>`. corresponding results
of each behavior would be like this:
+ `removeEnclosure`: :html:`value` (removed enclosing tag)
+ `removeTag`: :html:`` (removed tag, incl. child nodes)
+ `removeAttr`: :html:`<a>value</a>` (removed attribute)
+ `null`: :html:`<a href="t3://INVALID">value</a>` (unmodified, as given)
Example
-------
.. code-block:: html
<f:transform.html selector="a.href,div.data-uri">
<a href="t3://page?uid=1" class="page">visit</a>
<div data-uri="t3://page?uid=1" class="page trigger">visit</div>
</f:transform.html>
... will be resolved and transformed to the following markup ...
.. code-block:: html
<a href="https://typo3.localhost/" class="page">visit</a>
<div data-uri="https://typo3.localhost/" class="page trigger">visit</div>
.. index:: Backend, Fluid, Frontend, ext:fluid
@@ -0,0 +1,36 @@
.. include:: /Includes.rst.txt
.. _feature-95364:
=============================================================================
Feature: #95364 - Event to modify frontend user groups without authentication
=============================================================================
See :issue:`95364`
Description
===========
Prior to TYPO3 v11, the "getGroupsFE" authentication service
allowed to add and manipulate frontend user groups to be attached
to a FrontendUserAuthentication request during runtime.
Extensions use this approach to attach certain properties for
customization (for example country or region of a website user)
dynamically for a specific request.
This functionality was removed during the refactoring of the
authentication services (see :issue:`93108`).
A new Event :php:`ModifyResolvedFrontendGroupsEvent` has now been
introduced to modify user groups, even if there is no
authenticated user in place.
Impact
======
Use the new PSR-14 event to attach frontend user groups dynamically
during a frontend request.
.. index:: Frontend, PHP-API, ext:frontend
@@ -0,0 +1,32 @@
.. include:: /Includes.rst.txt
.. _important-95261:
=======================================================================
Important: #95261 - New public methods in SectionMarkupGenerated events
=======================================================================
See :issue:`95261`
Description
===========
With :issue:`88921`, two new events had been introduced. Those can be used to
add additional content to the columns in the page layout module. Due to the
different approach and the different code base of the new Fluid-based page
module, transforming the backend to always use the new approach in TYPO3 v11
also required to extend those events for two new public methods.
The new :php:`getPageLayoutContext()` should be used as a direct replacement
for the deprecated :php:`getPageLayoutView()` method, as it contains nearly
the same information, except for the records of the current column. This
information can from now on be retrieved using the new :php:`getRecords()`
method.
.. note::
Due to the nature of the new Fluid-based page module, the content
added through the events is now always displayed. Previously this
was only possible in the columns mode.
.. index:: Backend, PHP-API, ext:backend
@@ -0,0 +1,38 @@
.. include:: /Includes.rst.txt
.. _important-95298:
===================================================================
Important: #95298 - Fluid ViewHelpers will be declared final in v12
===================================================================
See :issue:`95298`
Description
===========
This is a notice for an upcoming change in TYPO3 v12:
All Fluid ViewHelper classes delivered by Core extensions will be declared
:php:`final` in TYPO3 v12, third party extensions can no longer extend them
with own variants.
The Core takes this step to clarify that single ViewHelpers are not part of the
PHP API, their internal handling may change any time, which is not considered
breaking. Fluid delivers a series of abstract classes to provide base functionality
for common ViewHelper needs. Those can be used by third party ViewHelpers if
not marked :php:`@internal`. TYPO3 v12 will fine-tune these abstracts and may
extract specific ViewHelper code to abstracts if the code is generally useful
for extension developers with own view-helpers.
Using ViewHelpers provided by Core extensions in Fluid templates is of course
fine as long as they are not marked :php:`@internal`. Arguments to casual ViewHelpers
are considered API and are subject of the general Core deprecation strategy. In
general, the base extensions `EXT:fluid`, `EXT:core`, `EXT:frontend` and `EXT:backend`
deliver various general purpose ViewHelpers that can be used, while specific extensions
like `EXT:beuser` add :php:`@internal` ViewHelpers that should not be used in own templates.
Developers are encouraged to adapt own ViewHelpers towards this change with
TYPO3 v11 compatible extensions already, it will simplify compatibility with TYPO3 v12 later.
.. index:: Fluid, PHP-API, ext:fluid
@@ -0,0 +1,21 @@
.. include:: /Includes.rst.txt
.. _important-95384:
================================================================
Important: #95384 - TCA internal_type=db optional for type=group
================================================================
See :issue:`95384`
Description
===========
The TCA option :php:`internal_type` of TCA type :php:`group` defines which type
of record can be referenced. Valid values are :php:`folder` and :php:`db`.
Since :php:`db` is the most common use case, TYPO3 now uses this as default.
Extension authors can therefore remove the :php:`internal_type=db` option
from TCA type :php:`group` fields.
.. index:: Backend, TCA, ext:backend
+54
View File
@@ -0,0 +1,54 @@
:template: changelogOverview.html
.. include:: /Includes.rst.txt
.. _changelog-11-5:
============
11.5 Changes
============
**Table of contents**
.. contents::
:local:
:depth: 1
Breaking Changes
================
None since TYPO3 v11.0 release.
.. attention::
After TYPO3 v11.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 v11.0 release on the way to LTS.
Features
========
.. toctree::
:maxdepth: 1
:titlesonly:
:glob:
Feature-*
Deprecation
===========
.. toctree::
:maxdepth: 1
:titlesonly:
:glob:
Deprecation-*
Important
=========
.. toctree::
:maxdepth: 1
:titlesonly:
:glob:
Important-*