TYPO3 v15 dev-main snapshot ()
This commit is contained in:
@@ -0,0 +1,44 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-92494:
|
||||
|
||||
================================================
|
||||
Deprecation: #92494 - Extbase EnvironmentService
|
||||
================================================
|
||||
|
||||
See :issue:`92494`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The extbase class :php:`TYPO3\CMS\Extbase\Service\EnvironmentService` is an API
|
||||
for TYPO3's legacy constant :php:`TYPO3_MODE`. That constant has been marked as
|
||||
deprecated in v11 and superseded by core API class
|
||||
:php:`TYPO3\CMS\Core\Http\ApplicationType`, which relies on a PSR-7 request
|
||||
to determine frontend or backend mode. The :php:`EnvironmentService` has now
|
||||
been marked as deprecated as a logical follow-up to these works.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using the class will trigger a PHP :php:`E_USER_DEPRECATED` error.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Even though :php:`TYPO3\CMS\Extbase\Service\EnvironmentService` is :php:`@internal`, some extensions
|
||||
may still rely on it. The extension scanner will find usages.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Instances with extensions using that class should either make their code agnostic
|
||||
to frontend or backend mode, or use :php:`ApplicationType`. Code examples can
|
||||
be found in the `Changelog`_ file.
|
||||
|
||||
.. _`Changelog`: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.0/Deprecation-92947-DeprecateTYPO3_MODEAndTYPO3_REQUESTTYPEConstants.html
|
||||
|
||||
.. index:: PHP-API, FullyScanned, ext:extbase
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-92992:
|
||||
|
||||
==================================================================
|
||||
Deprecation: #92992 - Hook t3lib_parsehtml_proc.php:transformation
|
||||
==================================================================
|
||||
|
||||
See :issue:`92992`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Since the deprecation of several internal functions in the
|
||||
:php:`TYPO3\CMS\Core\Html\RteHtmlParser` in TYPO3 10.2 (:ref:`Deprecation:
|
||||
#86440 - Internal Methods and properties within RteHtmlParser <changelog:deprecation-86440>`)
|
||||
the hook :php:`t3lib/class.t3lib_parsehtml_proc.php:transformation` became quite useless.
|
||||
|
||||
It is therefore marked as deprecated and will be removed with TYPO3 v12.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling the hook will trigger a PHP :php:`E_USER_DEPRECATED` error.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations with extensions installed that implement the hook.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Migrate to use the public API only and use other options (such as
|
||||
:php:`allowAttributes`) in order to only run certain instructions on the :php:`RteHtmlParser` object.
|
||||
|
||||
.. index:: RTE, NotScanned, ext:core
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93726:
|
||||
|
||||
====================================================================
|
||||
Deprecation: #93726 - Deprecated TypoScriptParser related properties
|
||||
====================================================================
|
||||
|
||||
See :issue:`93726`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A cleanup of the backend 'Template' module leads to a deprecation
|
||||
of some TypoScript parser related class properties:
|
||||
|
||||
* :php:`TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->breakPointLN`
|
||||
* :php:`TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->parentObject`
|
||||
* :php:`TYPO3\CMS\Core\TypoScript\TemplateService->ext_constants_BRP`
|
||||
* :php:`TYPO3\CMS\Core\TypoScript\TemplateService->ext_config_BRP`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The properties are not handled any longer and will be dropped with TYPO3 v12.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
It is very unlikely extensions used these properties since they were specific
|
||||
to the backend 'Template' module and of little use otherwise.
|
||||
|
||||
The extension scanner will still find usages except the :php:`parentObject`
|
||||
since this property name is too generic and would trigger too many false
|
||||
positive matches.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
The functionality of these properties has been dropped.
|
||||
|
||||
.. index:: Backend, PHP-API, PartiallyScanned, ext:core
|
||||
@@ -0,0 +1,58 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93837:
|
||||
|
||||
=========================================================
|
||||
Deprecation: #93837 - special property of TCA type select
|
||||
=========================================================
|
||||
|
||||
See :issue:`93837`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :php:`special` property of TCA type :php:`select` was introduced to enrich the
|
||||
items array with dynamic values, e.g. the available site languages or
|
||||
page types.
|
||||
|
||||
Since this usually is exactly what an :php:`itemsProcFunc` does, all
|
||||
those options are migrated to such functions, removing complexity
|
||||
from the TCA :php:`select` type. As these options are mainly for internal
|
||||
use in the backend user and backend usergroup records, the new
|
||||
:php:`itemsProcFunc` functions are marked as :php:`@internal`. This means, they
|
||||
are not considered public API and therefore not part of TYPO3s backwards
|
||||
compatibility promise.
|
||||
|
||||
The only option which is considered public API is :php:`special=languages`,
|
||||
which was already migrated to the new TCA type :php:`language` in :issue:`57082`.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using the TCA property :php:`special` inside the :php:`[columns][config]`
|
||||
section of columns with TCA type :php:`select` triggers a PHP :php:`E_USER_DEPRECATED` error.
|
||||
|
||||
When extending :php:`AbstractItemProvider` and directly calling
|
||||
:php:`addItemsFromSpecial()`, also a PHP :php:`E_USER_DEPRECATED` error will be raised.
|
||||
The extension scanner will also detect such calls.
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using the :php:`special` property with TCA type :php:`select` or
|
||||
directly calling :php:`AbstractItemProvider->addItemsFromSpecial()`.
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
While it's very unlikely that the :php:`special` property with another option
|
||||
than :php:`languages` is used in custom extension code, you nevertheless have to
|
||||
replace them with a :php:`itemsProcFunc` in such case. Either by creating
|
||||
your own implementation or by copying the one from Core. Have a look at the
|
||||
:php:`index_config` TCA configuration in EXT:indexed_search how this can be
|
||||
achieved. You can also find detailed information about :php:`itemsProcFunc`
|
||||
in the documentation_.
|
||||
|
||||
.. _documentation: https://docs.typo3.org/m/typo3/reference-tca/main/en-us/ColumnsConfig/CommonProperties/ItemsProcFunc.html
|
||||
|
||||
.. index:: Backend, TCA, FullyScanned, ext:backend
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93899:
|
||||
|
||||
===================================================================
|
||||
Deprecation: #93899 - FormEngine's requestConfirmationOnFieldChange
|
||||
===================================================================
|
||||
|
||||
See :issue:`93899`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
FormEngine's JavaScript method :js:`FormEngine.requestConfirmationOnFieldChange()`
|
||||
to register and trigger the update request when a field's value changes, has
|
||||
been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling the method :js:`FormEngine.requestConfirmationOnFieldChange()` will
|
||||
trigger a deprecation warning in the browser's console.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any 3rd party extension using the aforementioned method is affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
There is no migration available. If a field is properly configured to update the
|
||||
FormEngine after updating a field, a LitElement is rendered into DOM which will
|
||||
handle the update request.
|
||||
|
||||
.. index:: Backend, JavaScript, NotScanned, ext:backend
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93944:
|
||||
|
||||
====================================================================
|
||||
Deprecation: #93944 - File Tree as iframe migrated to SVG-based tree
|
||||
====================================================================
|
||||
|
||||
See :issue:`93944`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When registered backend modules have the legacy-tree navigation frame
|
||||
:html:`file_navframe` set via the module configuration
|
||||
:php:`navigationFrameModule`, the modules are now using the new SVG-based Folder
|
||||
tree view as component (non-iFrame).
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Modules still registering the old :html:`file_navframe` option via
|
||||
Module Configuration :php:`navigationFrameModule` will automatically be migrated
|
||||
to the new Component, and a PHP :php:`E_USER_DEPRECATED` error will be triggered.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
TYPO3 installations with custom extensions having backend modules
|
||||
using the filelist navigation frame (folder-based tree).
|
||||
|
||||
Modules that use the implicit main module configuration and are
|
||||
located directly within the "File" module are not affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Change the affected code in your ext_tables.php:
|
||||
|
||||
:php:`'navigationFrameModule' => 'file_navframe'`
|
||||
|
||||
to
|
||||
|
||||
:php:`'navigationComponentId' => 'TYPO3/CMS/Backend/Tree/FileStorageTreeContainer'`
|
||||
|
||||
.. index:: Backend, NotScanned, ext:backend
|
||||
@@ -0,0 +1,53 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93975:
|
||||
|
||||
===============================================
|
||||
Deprecation: #93975 - TBE_EDITOR.fieldChanged()
|
||||
===============================================
|
||||
|
||||
See :issue:`93975`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The JavaScript function :js:`TBE_EDITOR.fieldChanged()` is a precursor of the
|
||||
rewritten FormEngine that started with TYPO3 v7 already.
|
||||
Now, FormEngine has proper change handling which renders the function
|
||||
:js:`TBE_EDITOR.fieldChanged()` obsolete, thus this function became marked as
|
||||
deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using :js:`TBE_EDITOR.fieldChanged()` will trigger a deprecation entry in the
|
||||
browser's console.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Every installation with 3rd-party extensions installed using this function is
|
||||
affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
It is possible to trigger the :js:`change` event on the given field, if
|
||||
FormEngine is unable to detect changes automatically.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
// Previous invocation
|
||||
TBE_EDITOR.fieldChanged('table', 'field_name', 42);
|
||||
|
||||
// Migrate to event-based handling
|
||||
document
|
||||
.querySelector('[name="data[table][field_name][42]"]')
|
||||
.dispatchEvent(new Event('change', {bubbles: true, cancelable: true}));
|
||||
|
||||
.. index:: Backend, JavaScript, NotScanned, ext:backend
|
||||
@@ -0,0 +1,106 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-57082:
|
||||
|
||||
=========================================
|
||||
Feature: #57082 - New TCA type "language"
|
||||
=========================================
|
||||
|
||||
See :issue:`57082`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new TCA field type called :php:`language` has been added to TYPO3 Core. Its main
|
||||
purpose is to simplify the TCA language configuration. It therefore supersedes
|
||||
the :php:`special=languages` option of TCA columns with :php:`type=select` as well as the
|
||||
now mis-use of the :php:`foreign_table` option, being set to :sql:`sys_language`.
|
||||
|
||||
Since the introduction of site configurations and the corresponding site
|
||||
languages back in v9, the :sql:`sys_language` table was not longer the only source
|
||||
of truth regarding available languages. The languages available for a record are
|
||||
defined by the associated site configuration.
|
||||
|
||||
Therefore, the new field allows to finally decouple the available site
|
||||
languages from the :sql:`sys_language` table. This effectively reduces quite an
|
||||
amount of code and complexity, since no relations have to be fetched and
|
||||
processed anymore. This also makes the :sql:`sys_refindex` table a bit smaller,
|
||||
since no entries have to be added for this relation anymore. To clean up your
|
||||
existing reference index, you might use the CLI command
|
||||
:php:`bin/typo3 referenceindex:update`.
|
||||
|
||||
Another pain point was the special :php:`-1` language which always had to be added
|
||||
to each TCA configuration manually. Thus, a lot of different implementations
|
||||
of this special case could be found in one and the same TYPO3 installation.
|
||||
|
||||
The new TCA type now automatically displays all available languages for the
|
||||
current context (the corresponding site configuration) and also automatically
|
||||
adds the special :php:`-1` language for all record types, except :sql:`pages`.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
// Before
|
||||
|
||||
'config' => [
|
||||
'type' => 'select',
|
||||
'renderType' => 'selectSingle',
|
||||
'foreign_table' => 'sys_language',
|
||||
'items' => [
|
||||
['LLL:EXT:core/Resources/Private/Language/locallang_general.xlf:LGL.allLanguages', -1],
|
||||
['LLL:EXT:core/Resources/Private/Language/locallang_general.xlf:LGL.default_value', 0]
|
||||
],
|
||||
'default' => 0
|
||||
]
|
||||
|
||||
// After
|
||||
|
||||
'config' => [
|
||||
'type' => 'language'
|
||||
]
|
||||
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
// Before
|
||||
|
||||
'config' => [
|
||||
'type' => 'select',
|
||||
'renderType' => 'selectSingle',
|
||||
'special' => 'languages',
|
||||
'items' => [
|
||||
[
|
||||
'LLL:EXT:core/Resources/Private/Language/locallang_general.xlf:LGL.allLanguages',
|
||||
-1,
|
||||
'flags-multiple'
|
||||
],
|
||||
],
|
||||
'default' => 0,
|
||||
]
|
||||
|
||||
// After
|
||||
|
||||
'config' => [
|
||||
'type' => 'language'
|
||||
]
|
||||
|
||||
|
||||
Since the new TCA type is mostly based on the :php:`type=select` internally, most
|
||||
of the associated TCA and TSconfig options can still be applied. This includes
|
||||
e.g. the :php:`selectIcons` field wizard, as well as the :typoscript:`keepItems`
|
||||
and :typoscript:`removeItems` page TSconfig options.
|
||||
|
||||
In records on root level (:sql:`pid=0`) or on a page, outside of a site context,
|
||||
all languages from all site configurations are displayed in the new field.
|
||||
|
||||
An automatic TCA migration is performed on the fly, migrating all occurrences
|
||||
to the new TCA type and triggering a PHP :php:`E_USER_DEPRECATED` error
|
||||
where code adaption has to take place. Columns defined as
|
||||
:php:`$TCA['ctrl']['languageField']`, as well as all columns using the
|
||||
:php:`special=languages` option in combination with :php:`type=select` are
|
||||
affected.
|
||||
|
||||
Note that the migration resets the whole :php:`config` array to use the new TCA
|
||||
type. Custom setting such as field wizards are not evaluated until the TCA
|
||||
configuration is adapted.
|
||||
|
||||
.. index:: Backend, PHP-API, TCA, ext:core
|
||||
+61
@@ -0,0 +1,61 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-73176:
|
||||
|
||||
=======================================================================
|
||||
Feature: #73176 - Filterable Trees in Record Selectors and Link Pickers
|
||||
=======================================================================
|
||||
|
||||
See :issue:`73176`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
TYPO3's Page Tree, which was reworked in TYPO3 v9 to be powered by SVG rendering,
|
||||
and the Folder Tree in the File list module, which was also migrated to SVG
|
||||
rendering in TYPO3 v11.1, have been integrated in the so-called Record
|
||||
Selectors / File Selector ("Element Browser") and Link Pickers of TYPO3
|
||||
backend.
|
||||
|
||||
The Record Selectors are used when e.g. choosing a :guilabel:`Target Page` for a
|
||||
:guilabel:`Shortcut Page`, or selecting a :guilabel:`Storage Page` in a plugin.
|
||||
|
||||
The file selectors are used when choosing a file for an IRRE-based FAL-based
|
||||
file reference.
|
||||
|
||||
Link Pickers are used when linking to a specific page, content element, file,
|
||||
folder or custom records, such as news ("related news" in EXT:news).
|
||||
|
||||
All of these components within TYPO3 backend are now powered by SVG-based
|
||||
tree renderings. In addition, this means they ship with the same feature-set
|
||||
as the main navigation components, such as:
|
||||
|
||||
* A filter within the items of a tree (for folder-based trees, this means,
|
||||
searching for file names within a folder is also possible)
|
||||
* A JSON-based AJAX-loading functionality for fetching just parts of the tree,
|
||||
keeping the same expand/collapse state as the main tree
|
||||
* The Page Tree's "Temporary Mount Point" feature has the same functionality
|
||||
and styling as the main navigation component
|
||||
* Resizing and expand/collapse of the tree area in all modals
|
||||
* Keyboard navigation within the tree components
|
||||
|
||||
The newly added tree components have the following addons:
|
||||
|
||||
* When selecting (Record Selector) or linking to a specific page or folder, the
|
||||
item can be selected by a specific "link" action on the right hand of the tree.
|
||||
* Only showing specific mount points configurable via
|
||||
TSconfig :typoscript:`options.pageTree.altElementBrowserMountPoints`
|
||||
* The content area (for selecting a record on a specific page) is dynamically
|
||||
loaded via AJAX and loads much faster than before
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
All page- and folder-based trees are now completely streamlined all over TYPO3's
|
||||
backend, in terms of UX and code / implementation.
|
||||
|
||||
The overall UX feels much faster for every editor of TYPO3, and the consistency
|
||||
makes TYPO3 more intuitive with an improved search/filter and record selector.
|
||||
|
||||
.. index:: Backend, JavaScript, ext:backend
|
||||
@@ -0,0 +1,25 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-89762:
|
||||
|
||||
===================================================
|
||||
Feature: #89762 - Add pagination for FormManagement
|
||||
===================================================
|
||||
|
||||
See :issue:`89762`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
To enhance usability, a pagination is now integrated in the
|
||||
form management module. Thus, the listing is now limited to 20 forms
|
||||
per page.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
You'll notice a pagination above and below the forms listing in the
|
||||
form management module, which can be used to navigate through the
|
||||
forms listing.
|
||||
|
||||
.. index:: Backend, ext:form
|
||||
@@ -0,0 +1,34 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93188:
|
||||
|
||||
==========================================================
|
||||
Feature: #93188 - Possibility to disable hreflang per page
|
||||
==========================================================
|
||||
|
||||
See :issue:`93188`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Although it should not be needed to disable the hreflang generation, people might
|
||||
have a reason to disable it. If for some reason Core does not
|
||||
render the proper hreflang tags and also the :php:`ModifyHrefLangTagsEvent` PSR-14 event
|
||||
is not enough, you are now able to disable the generation of the hreflang tags
|
||||
via TypoScript. This can be done per page or part of your tree depending on where
|
||||
you set the configuration.
|
||||
|
||||
To disable the hreflang generation, you can add the following line to your
|
||||
TypoScript setup.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
config.disableHrefLang = 1
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
If the option is set to :typoscript:`1`, hreflang generation will be skipped.
|
||||
|
||||
.. index:: Frontend, TypoScript, ext:seo
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93209:
|
||||
|
||||
==========================================================================
|
||||
Feature: #93209 - FAL: Add getFile() to TYPO3\\CMS\\Core\\Resource\\Folder
|
||||
==========================================================================
|
||||
|
||||
See :issue:`93209`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The FAL :php:`\TYPO3\CMS\Core\Resource\Folder` object now contains a new
|
||||
convenience method :php:`getFile()`.
|
||||
|
||||
The :php:`\TYPO3\CMS\Core\Resource\FolderInterface` does not contain the
|
||||
definition yet, as this would be a breaking change, thus, a comment is added to
|
||||
make sure the interface gets this addition in TYPO3 v12 as well.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
When dealing as a developer with FAL Folder objects, the method
|
||||
:php:`$folder->getFile("filename.ext")` can now be used instead of
|
||||
:php:`$folder->getStorage()->getFileInFolder("filename.ext", $folder)`.
|
||||
|
||||
.. index:: FAL, ext:core
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93591:
|
||||
|
||||
=========================================================================
|
||||
Feature: #93591 - Allow group id lookup in conditions with array operator
|
||||
=========================================================================
|
||||
|
||||
See :issue:`93591`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In the backend and frontend the array of user group ids of the current backend user
|
||||
is now available as :typoscript:`backend.user.userGroupIds`.
|
||||
|
||||
In the frontend the array of user group ids of the current frontend user is available
|
||||
as :typoscript:`frontend.user.userGroupIds`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
This allows for a native Symfony Expression Syntax in TypoScript conditions, e.g.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
[4 in frontend.user.userGroupIds]
|
||||
|
||||
[2 in backend.user.userGroupIds]
|
||||
|
||||
With this syntax you can match backend user groups in the frontend without
|
||||
a "like" expression on the comma-separated list of user group ids.
|
||||
|
||||
.. index:: Backend, Frontend, TSConfig, TypoScript, ext:backend, ext:frontend
|
||||
@@ -0,0 +1,34 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93606:
|
||||
|
||||
===========================================================
|
||||
Feature: #93606 - Possibility to disable canonical per page
|
||||
===========================================================
|
||||
|
||||
See :issue:`93606`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Although it should not be needed to disable the generation of :html:`canonical`, people might
|
||||
have a reason to disable it. If for some reason Core does not
|
||||
render the proper canonical tag and also the :php:`ModifyUrlForCanonicalTagEvent` PSR-14 event
|
||||
is not enough, you are now able to disable the generation of the canonical tag
|
||||
via TypoScript. This can be done per page or part of your tree depending on where
|
||||
you set the configuration.
|
||||
|
||||
To disable the canonical generation, you can add the following line to your
|
||||
TypoScript setup.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
config.disableCanonical = 1
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
If the option is set to :typoscript:`1`, the canonical generation will be skipped.
|
||||
|
||||
.. index:: Frontend, TypoScript, ext:seo
|
||||
@@ -0,0 +1,29 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93651:
|
||||
|
||||
==========================================================
|
||||
Feature: #93651 - Provide list of available system locales
|
||||
==========================================================
|
||||
|
||||
See :issue:`93651`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Every language of a site requires at least one locale which is used to format times, dates,
|
||||
currencies and other locale-dependent values. Additional locales can be added as fallback
|
||||
locales (comma separated).
|
||||
|
||||
The site configuration form for site languages provides the available locales as a select field,
|
||||
enabling easy selection of a value, rather than typing in the expected one, which might or might not
|
||||
be available.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Providing a list of available locales makes it faster and less error prone to setup a site and its
|
||||
languages.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93663:
|
||||
|
||||
=========================================================================
|
||||
Feature: #93663 - Backend user's preferred UI language stored as DB field
|
||||
=========================================================================
|
||||
|
||||
See :issue:`93663`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In previous TYPO3 versions, administrators could create new backend
|
||||
users and select from the list of all supported TYPO3-internal
|
||||
languages for their backend language (= all labels from
|
||||
XLIFF files). This information was stored in the database field
|
||||
:sql:`be_users.lang` and was only used on the first login of a user
|
||||
into TYPO3 backend.
|
||||
|
||||
The backend users themselves could use the :guilabel:`User settings` module
|
||||
to change the UI language to their preferred language, based on the
|
||||
available language packs in the system.
|
||||
|
||||
This information was then stored in the user's :sql:`uc` (user configuration),
|
||||
an arbitrary settings field.
|
||||
|
||||
This approach - built over 18 years ago without any significant
|
||||
changes ever since - had several downsides:
|
||||
|
||||
* The database field :sql:`be_users.lang` was not really needed
|
||||
* Administrators did not see available language packs when changing the language
|
||||
* Administrators could only change an editor's preferred language by
|
||||
switching to the user (:guilabel:`Switch User Mode`).
|
||||
* Administrators could not filter / sort editors to see what languages the
|
||||
users had chosen
|
||||
* Fetching the user's preferred language always meant to fetch the whole
|
||||
:sql:`uc` information and unpack it.
|
||||
* The preferred language was only selected if the user had logged in for
|
||||
the first time to initialize the :sql:`uc` values.
|
||||
|
||||
Instead, TYPO3 now keeps the current language preference in the
|
||||
database field :sql:`be_users.lang`, allowing both editors and administrators
|
||||
to access the same value for fetching this information.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
When the user changes their language in the user settings module,
|
||||
the database record gets updated, and it is clear where this information is
|
||||
stored. It is now the same logic when an administrator updates the editor's
|
||||
record via FormEngine.
|
||||
|
||||
The value is now always filled, and if English is chosen, the value
|
||||
is set to the string :php:`default` (instead of an empty value).
|
||||
|
||||
An upgrade wizard migrates existing :sql:`uc` values into the database
|
||||
fields. The :sql:`uc` entry :sql:`user->uc['lang']` is kept in sync for
|
||||
backwards-compatibility.
|
||||
|
||||
.. index:: Backend, JavaScript, ext:backend
|
||||
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93794:
|
||||
|
||||
========================================================
|
||||
Feature: #93794 - Override TCA description with TSconfig
|
||||
========================================================
|
||||
|
||||
See :issue:`93794`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TCA description, introduced in :issue:`85410`, allows to define a description
|
||||
for a TCA field, next to its label. Since the purpose of a field may change
|
||||
depending on the current page, it is now possible to override the TCA
|
||||
description property with page TSconfig.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.aTable.aField.description = override description
|
||||
|
||||
As already known from other properties, this can also be configured for a
|
||||
specific language.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.aTable.aField.description.de = override description for DE
|
||||
|
||||
The option can be used on a per record type basis, too.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.aTable.aField.types.aType.description = override description for aType
|
||||
|
||||
Also referencing language labels is supported.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.aTable.aField.description = LLL:EXT:my_ext/Resources/Private/Language/locallang.xlf:override_description
|
||||
|
||||
.. note::
|
||||
|
||||
The new option can not only be used to override an existing property,
|
||||
but also to set a description for a field, that has not yet been
|
||||
configured a description in TCA.
|
||||
|
||||
.. index:: Backend, TCA, TSConfig, ext:backend
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93857:
|
||||
|
||||
===================================================================================
|
||||
Feature: #93857 - Resizable navigation component for all element / record selectors
|
||||
===================================================================================
|
||||
|
||||
See :issue:`93857`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The newly introduced possibility to resize and/or collapse the
|
||||
navigation frame (e.g. Page Tree) in the main backend has been additionally
|
||||
added to all Element Browser / Record Selectors, and Link Picker selections.
|
||||
|
||||
All modal areas with a Page Tree or File-based Folder Tree now
|
||||
contain the same feature-set of collapsing / resizing, except
|
||||
that the width is not installation-wide but is kept for the
|
||||
main navigation area (initially 300 pixels) in a different place (set in the
|
||||
backend user's :sql:`uc` :php:`navigation.width` property) than for the element browsers
|
||||
modal areas (initially 250 pixels, set in the backend user's :sql:`uc`
|
||||
:php:`selector.navigation.width` property).
|
||||
|
||||
A custom Lit-based web component is added, which is now re-used
|
||||
in various places, and uses the same markup in all contexts.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Any backend user is now able to resize / collapse the navigation
|
||||
area in the Record Selectors / Element Browser shipped with TYPO3 Core.
|
||||
|
||||
.. index:: Backend, JavaScript, ext:recordlist
|
||||
@@ -0,0 +1,41 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93908:
|
||||
|
||||
==================================================
|
||||
Feature: #93908 - Add decoding attribute to images
|
||||
==================================================
|
||||
|
||||
See :issue:`93908`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
TYPO3 now supports the :html:`decoding` HTML attribute in :html:`<img>`
|
||||
tags.
|
||||
|
||||
Supported browsers choose to decode these images asynchronously to not
|
||||
prevent presentation of other content. This has an effect of presenting
|
||||
non-image content faster. However, the image content is missing on screen until
|
||||
the decode finishes. Once the decode is finished, the screen is updated with the
|
||||
image.
|
||||
|
||||
The configuration option is available via TypoScript constants and
|
||||
can be easily adjusted via the TypoScript Constant Editor in the Template
|
||||
module. The default value is an empty string.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
TYPO3 frontend decodes images in content elements asynchronously by default
|
||||
when using TYPO3 templates from Fluid Styled Content.
|
||||
|
||||
Using the TypoScript constant :typoscript:`styles.content.image.imageDecoding`,
|
||||
the behavior can be modified generally to be either set to :typoscript:`sync`, :typoscript:`async`
|
||||
:typoscript:`auto` or to an empty value which removes the property.
|
||||
|
||||
The Fluid :php:`ImageViewHelper` and :php:`MediaViewHelper` have the possibility to set this
|
||||
attribute via :html:`<f:image src="{fileObject}" decoding="async">`
|
||||
and :html:`<f:media file="{fileObject}" decoding="async">`.
|
||||
|
||||
.. index:: Frontend, ext:fluid_styled_content
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93988:
|
||||
|
||||
======================================================================
|
||||
Feature: #93988 - Backend module URLs reflect into browser address bar
|
||||
======================================================================
|
||||
|
||||
See :issue:`93988`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Backend module URLs are now reflected into the browser address bar, whenever a
|
||||
backend module or a FormEngine record is opened.
|
||||
|
||||
The given URL can be bookmarked or shared with other editors and allows to
|
||||
re-open the TYPO3 backend with the given context.
|
||||
|
||||
A custom Lit-based web component router is added which reflects module URLs
|
||||
into the browser address bar and at the same time prepares for native web
|
||||
components to be used as future iframe module alternatives.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Editors can share links to certain records or include these in bug reports.
|
||||
|
||||
This feature is enabled for all modules. For non-module routes this feature
|
||||
will only work if configured via `Routes.php` by adding a `redirect` section:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'redirect' => [
|
||||
'enable' => true,
|
||||
// Transferred parameters when redirecting
|
||||
'parameters' => [
|
||||
'my-parameter-name' => true
|
||||
]
|
||||
],
|
||||
|
||||
.. index:: Backend, JavaScript, ext:backend
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _important-93398:
|
||||
|
||||
==============================================================================
|
||||
Important: #93398 - Possibility to ignore submitted values in HiddenViewHelper
|
||||
==============================================================================
|
||||
|
||||
See :issue:`93398`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new argument :php:`respectSubmittedDataValue` is added to Fluid's
|
||||
:php:`HiddenViewHelper` view helper. It allows to enable or disable the usage of
|
||||
previously submitted values for the corresponding field. This is especially
|
||||
useful if dealing with sub requests, e.g. when a :php:`\TYPO3\CMS\Extbase\Http\ForwardResponse` is
|
||||
being dispatched within Extbase.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:form.hidden property="hiddenProperty" value="{form.hiddenProperty}" respectSubmittedDataValue="false"/>
|
||||
|
||||
.. index:: Fluid, ext:fluid
|
||||
@@ -0,0 +1,53 @@
|
||||
:template: changelogOverview.html
|
||||
.. include:: /Includes.rst.txt
|
||||
.. _changelog-11-2:
|
||||
|
||||
============
|
||||
11.2 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-*
|
||||
Reference in New Issue
Block a user