TYPO3 v15 dev-main snapshot ()
This commit is contained in:
+54
@@ -0,0 +1,54 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-70316:
|
||||
|
||||
========================================================================================
|
||||
Breaking: #70316 - AbstractUserAuthentication properties and methods dropped and changed
|
||||
========================================================================================
|
||||
|
||||
See :issue:`70316`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The property :php:`AbstractUserAuthentication::session_table` has been dropped.
|
||||
The property :php:`FrontendUserAuthentication::sessionDataTimestamp` has been dropped.
|
||||
The property :php:`FrontendUserAuthentication::sesData` has been moved to :php:`AbstractUserAuthentication::sessionData`
|
||||
and is protected now.
|
||||
|
||||
The method :php:`FrontendUserAuthentication::fetchSessionData()` has been removed and its
|
||||
logic has been integrated into :php:`AbstractUserAuthentication::fetchUserSession()`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Accessing one of these properties will raise a PHP warning.
|
||||
Calling the method :php:`fetchSessionData()` will cause a PHP fatal error.
|
||||
|
||||
Moreover it is not possible anymore to use the getData function from within TypoScript
|
||||
to access session data. This functionality is replaced by a new API. (see :issue:`80154`)
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All extensions accessing these properties will most likely not work properly anymore.
|
||||
Extensions accessing the removed method will not work at all.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use configuration from :php:`DatabaseSessionBackend` located in
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS]['SYS']['session'][/* Session Identifier */]['table']` or use
|
||||
:php:`AbstractUserAuthentication::loginType` to distinguish between FE or BE login types.
|
||||
|
||||
Session data can be manipulated with the following methods in :php:`AbstractUserAuthentication`
|
||||
|
||||
* :php:`getSessionData()`
|
||||
* :php:`setSessionData()`
|
||||
|
||||
|
||||
Calls to :php:`FrontendUserAuthentication::fetchSessionData()` can safely be removed.
|
||||
|
||||
.. index:: PHP-API
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-77934:
|
||||
|
||||
=========================================================================
|
||||
Breaking: #77934 - Remove field `select_key` from content element preview
|
||||
=========================================================================
|
||||
|
||||
See :issue:`77934`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The value of the field `select_key` has been shown in the preview of a content element in the page module.
|
||||
This field has been removed and therefore also the preview has been removed.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The preview of this field is not available anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Every installation or third party extension which uses the field.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
No migration available.
|
||||
|
||||
.. index:: Backend
|
||||
@@ -0,0 +1,131 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-78192:
|
||||
|
||||
=====================================================
|
||||
Breaking: #78192 - Refactor click menu (context menu)
|
||||
=====================================================
|
||||
|
||||
See :issue:`78192`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Due to the refactoring and unification of the click/context-menu handling in the TYPO3 Backend, a few breaking changes have been introduced.
|
||||
|
||||
Classes removed
|
||||
---------------
|
||||
|
||||
- :php:`\TYPO3\CMS\Backend\ClickMenu\ClickMenu`
|
||||
- :php:`\TYPO3\CMS\Backend\ContextMenu\ContextMenuAction`
|
||||
- :php:`\TYPO3\CMS\Backend\ContextMenu\ContextMenuActionCollection`
|
||||
- :php:`\TYPO3\CMS\Backend\ContextMenu\Pagetree\ContextMenuDataProvider`
|
||||
- :php:`\TYPO3\CMS\Backend\ContextMenu\Pagetree\Extdirect\ContextMenuConfiguration`
|
||||
- :php:`\TYPO3\CMS\Backend\Controller\ClickMenuController`
|
||||
- :php:`\TYPO3\CMS\Impexp\Clickmenu` (replaced by new hook implementation: :php:`TYPO3\CMS\Impexp\Hook\ContextMenuModifyItemsHook`)
|
||||
- :php:`\TYPO3\CMS\Impexp\Hook\ContextMenuDisableItemsHook`
|
||||
- :php:`\TYPO3\CMS\Version\ClickMenu\VersionClickMenu`
|
||||
|
||||
ExtJS component removed
|
||||
-----------------------
|
||||
|
||||
- The :js:`TYPO3.Components.PageTree.ContextMenu` component defined in contextmenu.js has been removed.
|
||||
- The `contextMenuProvider` property as well as `enableContextMenu` and `openContextMenu` methods of the :js:`TYPO3.Components.PageTree.Tree` component have been removed.
|
||||
|
||||
Migration
|
||||
^^^^^^^^^
|
||||
Migrate your code to a requireJS module for custom click-menu actions.
|
||||
|
||||
ClickMenu requireJS component removed
|
||||
-------------------------------------
|
||||
|
||||
The `TYPO3/CMS/Backend/ClickMenu` requireJS component (ClickMenu.js) has been removed.
|
||||
|
||||
Migration
|
||||
^^^^^^^^^
|
||||
|
||||
Use the new requireJS component: `TYPO3/CMS/Backend/ContextMenu`.
|
||||
|
||||
|
||||
Page TSConfig change
|
||||
--------------------
|
||||
|
||||
The pagetree context-menu configuration in Page TSConfig has been removed (except for the `disableItems` part).
|
||||
The list of available menu items is now provided by `ItemProviders` e.g. :php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\PageProvider`.
|
||||
|
||||
The TSConfig options for disabling click-menu items has been streamlined.
|
||||
Also some items names have changed (e.g. `new_wizard` is now called `newWizard`, `db_list` is now `openListModule`). Refer to the provider class for correct naming.
|
||||
|
||||
Migration
|
||||
^^^^^^^^^
|
||||
|
||||
Migrate TSConfig from:
|
||||
|
||||
:typoscript:`options.contextMenu.folderList.disableItems` to :typoscript:`options.contextMenu.table.sys_file.disableItems`
|
||||
|
||||
:typoscript:`options.contextMenu.folderTree.disableItems` to :typoscript:`options.contextMenu.table.sys_file.tree.disableItems`
|
||||
|
||||
:typoscript:`options.contextMenu.pageList.disableItems` to :typoscript:`options.contextMenu.table.pages.disableItems`
|
||||
|
||||
:typoscript:`options.contextMenu.pageTree.disableItems` to :typoscript:`options.contextMenu.table.pages.tree.disableItems`
|
||||
|
||||
|
||||
|
||||
Hooks removed
|
||||
-------------
|
||||
|
||||
The following two hooks have been removed:
|
||||
|
||||
- :php:`$GLOBALS['TBE_MODULES_EXT']['xMOD_alt_clickmenu']['extendCMclasses']`
|
||||
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['backend']['contextMenu']['disableItems']`
|
||||
|
||||
|
||||
Migration
|
||||
^^^^^^^^^
|
||||
|
||||
Use the new ItemsProvider API to add or modify click-menu items.
|
||||
See existing usage of the API in the core :php:`TYPO3\CMS\Filelist\ContextMenu\ItemProviders\FileProvider` or :php:`\TYPO3\CMS\Beuser\ContextMenu\ItemProvider`.
|
||||
|
||||
|
||||
Legacy Tree
|
||||
-----------
|
||||
|
||||
Support for drag & drop menu for LegacyTree.js of pages has been dropped.
|
||||
|
||||
|
||||
Changed markup (data attributes) for click menu
|
||||
-----------------------------------------------
|
||||
|
||||
- `data-listFrame` has been replaced with the optional attribute `data-context` attribute. Context is set to "tree" for click-menus triggered from trees.
|
||||
- for files, `data-table` now contains the real table name "sys_file" while before it contained the combined identifier e.g. `1:/fileadmin/file.jpg`.
|
||||
the `data-uid` attribute now contains the combined identifier of the file (before it was empty).
|
||||
Thus the `data-uid` attribute value is not always an int.
|
||||
- the class which triggers the context-menu has changed from :js:`t3-js-clickmenutrigger` to :js:`t3js-contextmenutrigger`
|
||||
|
||||
|
||||
Migration
|
||||
^^^^^^^^^
|
||||
|
||||
To trigger click-menus for files, use the correct class-attribute as well as the table and uid data attributes. Replace `data-listFrame="0"` with `data-context="tree"`, `data-listFrame="1"` can be removed (it's a default context now).
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Instantiating the PHP class will result in a fatal PHP error.
|
||||
Accessing removed JavaScript properties will result in a JavaScript error.
|
||||
|
||||
Removed hooks will not influence the menu rendering process.
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using the removed PHP classes, JS components or hooks.
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Adapt your code to the new click menu API.
|
||||
|
||||
|
||||
.. index:: Backend, JavaScript, PHP-API, TSConfig
|
||||
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-78477:
|
||||
|
||||
=====================================================================================
|
||||
Breaking: #78477 - FlashMessagesViewHelper no longer inherits from TagBasedViewHelper
|
||||
=====================================================================================
|
||||
|
||||
See :issue:`78477`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :php:`FlashMessagesViewHelper` has been refactored and no longer inherits from the :php:`TagBasedViewHelper`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The :php:`FlashMessagesViewHelper` outputs default context specific markup. Adding own classes or tag attributes is no longer possible.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using the :php:`FlashMessagesViewHelper` with tag specific attributes.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove the tag specific attributes and style the default output. If you need custom output use the possibility to render FlashMessages yourself, for example:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:flashMessages as="flashMessages">
|
||||
<dl class="messages">
|
||||
<f:for each="{flashMessages}" as="flashMessage">
|
||||
<dt>CODE!! {flashMessage.code}</dt>
|
||||
<dd>MESSAGE:: {flashMessage.message}</dd>
|
||||
</f:for>
|
||||
</dl>
|
||||
</f:flashMessages>
|
||||
|
||||
.. index:: Backend, Fluid, Frontend
|
||||
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-78477-1668719172:
|
||||
|
||||
===================================================================
|
||||
Breaking: #78477 - Remove method FlashMessage->getMessageAsMarkup()
|
||||
===================================================================
|
||||
|
||||
See :issue:`78477`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The method :php:`FlashMessage->getMessageAsMarkup()` has been removed.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using this method will stop working immediately.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using the mentioned method above.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use the new :php:`FlashMessageRendererResolver::class`, for example:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
GeneralUtility::makeInstance(FlashMessageRendererResolver::class)->resolve()->render()
|
||||
|
||||
.. index:: Backend, PHP-API
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-78899-1668719172:
|
||||
|
||||
==================================================================
|
||||
Breaking: #78899 - Remove `extJSCODE` from FormEngine result array
|
||||
==================================================================
|
||||
|
||||
See :issue:`78899`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The key :php:`extJSCODE` in the array returned by FormEngine's :php:`Container` and :php:`Element` (initialized
|
||||
in :php:`AbstractNode->initializeResultArray()`) has been removed.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
JavaScript code added to :php:`extJSCODE` by custom elements will not be evaluated anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Search extensions for the string :php:`extJSCODE`. This array is used rather seldom, but if there are matches
|
||||
in combination with Backend Form classes, they should be adapted.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
For a simple solution, add according JavaScript to the return key :php:`additionalJavaScriptPost` for now.
|
||||
Both keys were used nearly identically anyway. Be aware that both keys :php:`additionalJavaScriptPost` and
|
||||
:php:`additionalJavaScriptSubmit` are target of a later removal as soon as a better JavaScript side event handling
|
||||
for those scenarios is in place. See if the current code injected at this point could be done with
|
||||
casual :js:`RequireJsModules` instead already.
|
||||
|
||||
.. index:: Backend, JavaScript, PHP-API
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-78899:
|
||||
|
||||
==================================================================
|
||||
Breaking: #78899 - Remove methods, hook and property in FormEngine
|
||||
==================================================================
|
||||
|
||||
See :issue:`78899`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following methods have been removed:
|
||||
|
||||
* :php:`TYPO3\CMS\Backend\Form\Element\AbstractFormElement->dbFileIcons()`
|
||||
* :php:`TYPO3\CMS\Backend\Form\Element\AbstractFormElement->getClipboardElements()`
|
||||
* :php:`TYPO3\CMS\Backend\Form\Container\SingleFieldContainer->getMergeBehaviourIcon()`
|
||||
* :php:`TYPO3\CMS\Backend\Form\Container\SingleFieldContainer->renderDefaultLanguageDiff()`
|
||||
* :php:`TYPO3\CMS\Backend\Form\Container\SingleFieldContainer->renderDefaultLanguageContent()`
|
||||
* :php:`TYPO3\CMS\Backend\Form\Container\AbstractContainer->previewFieldValue()`
|
||||
|
||||
The following property has been removed:
|
||||
|
||||
* :php:`TYPO3\CMS\Backend\Form\Element\AbstractFormElement->clipboard`
|
||||
|
||||
The following hook interface has been removed and registered hooks in :php:`dbFileIcons` are no longer called:
|
||||
|
||||
* :php:`TYPO3\CMS\Backend\Form\DatabaseFileIconsHookInterface`
|
||||
|
||||
TCA wizards registered as :php:`userFunc` no longer receive the element HTML by reference, so they can no longer change
|
||||
given HTML string of a given element.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using above methods, properties and hooks will result in fatal PHP errors or fail silently.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Check extensions for usages of above methods and especially implementations of the hook interface.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
The methods have been partially moved to the :php:`TcaGroup` data provider and merged to the two
|
||||
FormEngine elements :php:`GroupElement` and :php:`SelectMultipleSideBySideElement`. Those can be
|
||||
changed and extended via FormEngine's internal :php:`NodeFactory` and data provider resolvers.
|
||||
|
||||
.. index:: Backend, PHP-API, TCA
|
||||
@@ -0,0 +1,63 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-78988:
|
||||
|
||||
============================================================
|
||||
Breaking: #78988 - Remove optional Fluid TypoScript template
|
||||
============================================================
|
||||
|
||||
See :issue:`78988`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The static include file "Fluid: (Optional) default ajax configuration (fluid)" was meant as an
|
||||
example/showcase on how to use Fluid Widgets in FE. But the currently used includes are outdated or
|
||||
broken. Furthermore the way of including files with :typoscript:`page.headerData` instead of
|
||||
:typoscript:`page.includeJSLibs` or :typoscript:`page.includeCSSLibs` is not the preferred way anymore. Also in many
|
||||
situations this way of including JavaScript and CSS conflicts with other included JavaScript libs
|
||||
and CSS files.
|
||||
|
||||
Including the files manually has many benefits:
|
||||
|
||||
- more control of what versions of the JavaScript libs are included
|
||||
- prevent multiple jquery.js includes
|
||||
- more control of adjusting styling without resetting/overriding styles delivered by jquery-ui-theme.css
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The jQuery JavaScript and CSS files are not included anymore so the AJAX handling in the frontend
|
||||
will not work anymore when the site relies on these files.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that depend on the jQuery includes added by the static TypoScript template
|
||||
"Fluid: (Optional) default ajax configuration (fluid)".
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Include the needed file manually in your TypoScript template.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
page.includeJSLibs {
|
||||
jquery = https://code.jquery.com/jquery-3.1.1.slim.min.js
|
||||
jquery.external = 1
|
||||
jquery.integrity = sha256-/SIrNqv8h6QGKDuNoLGA4iret+kyesCkHGzVUUV0shc=
|
||||
jqueryUi = https://code.jquery.com/ui/1.12.1/jquery-ui.min.js
|
||||
jqueryUi.external = 1
|
||||
jqueryUi.integrity = sha256-VazP97ZCwtekAsvgPBSUwPFKdrwD3unUfSGVYrahUqU=
|
||||
}
|
||||
|
||||
page.includeCSSLibs {
|
||||
jqueryUI = https://code.jquery.com/ui/1.12.1/themes/smoothness/jquery-ui.css
|
||||
jqueryUi.external = 1
|
||||
}
|
||||
|
||||
.. index:: Fluid, Frontend, JavaScript
|
||||
@@ -0,0 +1,42 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79025:
|
||||
|
||||
======================================================
|
||||
Breaking: #79025 - Extract testing framework for TYPO3
|
||||
======================================================
|
||||
|
||||
See :issue:`79025`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Since the :file:`.gitattributes` export change, a lot of base test classes for writing own tests are missing in distribution builds.
|
||||
To get a sustainable future-proof solution, the TYPO3 core testing framework will be extracted to an own component.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
All test classes that are considered as part of the TYPO3 core testing framework are moved to components/testing_framework and
|
||||
will in the long run be released as an own package that can be required for dev environments.
|
||||
|
||||
Moving the classes results in changed namespaces. To ensure compatibility with earlier TYPO3 versions all classes that
|
||||
were previously available in distribution (non-source) installations are additionally provided by their old namespace names
|
||||
and will be provided for 8 LTS.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using core testing components as base.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Change the namespace from :php:`TYPO3\CMS\Core\Tests` to :php:`TYPO3\TestingFramework\Core` or in case of the xml fixtures the corresponding file path.
|
||||
|
||||
If you need to ensure compatibility with multiple TYPO3 versions, use the base test classes with their old names.
|
||||
|
||||
.. index:: PHP-API
|
||||
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79100:
|
||||
|
||||
==================================================
|
||||
Breaking: #79100 - ext:felogin: Remove default CSS
|
||||
==================================================
|
||||
|
||||
See :issue:`79100`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The applied default CSS styles delivered by EXT:felogin may break the frontend output, for example
|
||||
if CSS frameworks are used. The default styles need to get overridden in such case.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
EXT:felogin doesn't add default CSS styles anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using EXT:felogin with default/non-overwritten :typoscript:`plugin.tx_felogin_pi1._CSS_DEFAULT_STYLE`
|
||||
TypoScript setup are affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
If your frontend relies on the default EXT:felogin CSS styles, make sure to add following CSS on
|
||||
your own:
|
||||
|
||||
.. code-block:: css
|
||||
|
||||
.tx-felogin-pi1 label {
|
||||
display: block;
|
||||
}
|
||||
|
||||
|
||||
|
||||
.. index:: Frontend, ext:felogin
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79109:
|
||||
|
||||
==============================================================
|
||||
Breaking: #79109 - Lowlevel VersionsCommand parameters changed
|
||||
==============================================================
|
||||
|
||||
See :issue:`79109`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The existing CLI command within EXT:lowlevel for showing and cleaning up versions (from EXT:version / EXT:workspaces)
|
||||
has been migrated to a Symfony Console command.
|
||||
|
||||
The command previously available via `./typo3/cli_dispatch.phpsh lowlevel_cleaner versions` is now available
|
||||
via `./typo3/sysext/core/bin/typo3 cleanup:versions` and allows the following CLI options to be set:
|
||||
|
||||
The following options can be set:
|
||||
|
||||
- :bash:`--action={nameofaction}` to clean up versioned records, one of the following actions are possible:
|
||||
|
||||
- "versions_in_live": Delete versioned records in the live workspace
|
||||
|
||||
- "published_versions": Delete versions of published records
|
||||
|
||||
- "invalid_workspace": Move records inside a non-existing workspace ID into the live workspace
|
||||
|
||||
- "unused_placeholders": Remove placeholders which are not used anymore from the database
|
||||
|
||||
- :bash:`-v` and :bash:`-vv` to show more detailed information on the records affected
|
||||
|
||||
- :bash:`--pid=23` or :bash:`-p=23` to only find versions with page ID 23 (otherwise "0" is taken)
|
||||
|
||||
- :bash:`--depth=4` or :bash:`-d=4` to only clean recursively until a certain page tree level.
|
||||
|
||||
- :bash:`--dry-run` to only show the records to be changed / deleted
|
||||
|
||||
The PHP class of the old CLI command :php:`TYPO3\CMS\Lowlevel\VersionsCommand` has been removed.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling the old CLI command :bash:`./typo3/cli_dispatch.phpsh lowlevel_cleaner versions` will result in an error message.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any TYPO3 instances using the lowlevel cleaner for finding and cleaning up versioned records.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Update the CLI call on your servers to the new command line and available options as shown above.
|
||||
|
||||
.. index:: CLI, ext:lowlevel
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79120:
|
||||
|
||||
====================================================================
|
||||
Breaking: #79120 - Remove legacy CLI-related constants and variables
|
||||
====================================================================
|
||||
|
||||
See :issue:`79120`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The deprecated PHP constants :php:`TYPO3_cliKey` and :php:`TYPO3_cliInclude`, and the global variables :php:`$GLOBALS['temp_cliScriptPath']` and
|
||||
:php:`$GLOBALS['temp_cliKey']` which had been filled when running a CLI command have been removed.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling one of the PHP constants above will result in a PHP error. Accessing the global variables will result in a PHP warning.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation with third-party CLI commands which use these constants or global variables.
|
||||
|
||||
.. index:: CLI, PHP-API
|
||||
@@ -0,0 +1,47 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79196:
|
||||
|
||||
======================================================
|
||||
Breaking: #79196 - Toolbar item event handling changed
|
||||
======================================================
|
||||
|
||||
See :issue:`79196`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
With the introduction of the topbar reloading mechanism, the event handling of toolbar items has changed. Reason is
|
||||
that the event information gets lost, as the whole topbar is rendered from scratch after a reload.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
After reloading the topbar, non-migrated events will not get triggered anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations with old-fashioned toolbar item registrations.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
In most cases it's sufficient to replace the register function with :js:`Viewport.Topbar.Toolbar.registerEvent()`.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
define(['jquery', 'TYPO3/CMS/Backend/Viewport'], function($, Viewport) {
|
||||
// old registration
|
||||
MyAwesomeItem.doStuff)
|
||||
|
||||
// new registration
|
||||
Viewport.Topbar.Toolbar.registerEvent(MyAwesomeItem.doStuff);
|
||||
});
|
||||
|
||||
.. index:: Backend, JavaScript
|
||||
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79201:
|
||||
|
||||
======================================================
|
||||
Breaking: #79201 - EXT:form: Split TypoScript Includes
|
||||
======================================================
|
||||
|
||||
See :issue:`79201`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The frontend specific TypoScript setup for EXT:form isn't loaded automatically anymore and must be added manually through
|
||||
static includes. With this change a TYPO3 integrator can easier decide where the extension Typoscript is included.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using the extension without adding static includes of EXT:form will result in an erroneous frontend output.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation with activated EXT:form extension.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Make sure to include the static TypoScript "Form" in your (root) template record. Same procedure as with static includes
|
||||
of fluid_styled_content or css_styled_content.
|
||||
|
||||
.. index:: ext:form, TypoScript, Frontend
|
||||
@@ -0,0 +1,54 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79227:
|
||||
|
||||
===================================================
|
||||
Breaking: #79227 - Removed ExtDirect State Provider
|
||||
===================================================
|
||||
|
||||
See :issue:`79227`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The ExtDirect based State Provider for ExtJS applications (endpoint :js:`TYPO3.ExtDirectStateProvider.ExtDirect`) has been removed.
|
||||
|
||||
The ExtDirect endpoint :js:`TYPO3.ExtDirectStateProvider.ExtDirect` is no longer available.
|
||||
|
||||
The following PHP classes have been removed:
|
||||
|
||||
* :php:`\TYPO3\CMS\Backend\InterfaceState\ExtDirect\DataProvider`
|
||||
* :php:`\TYPO3\CMS\Backend\Tree\AbstractTreeStateProvider`
|
||||
* :php:`\TYPO3\CMS\Backend\Tree\AbstractExtJsTree`
|
||||
|
||||
The relevant JavaScript file :file:`ExtDirect.StateProvider.js` has been removed.
|
||||
|
||||
The PHP method php:`DocumentTemplate->setExtDirectStateProvider()` to load the JavaScript file has been removed.
|
||||
|
||||
Instead the jQuery-based AMD module `TYPO3\CMS\Backend\Storage` is incorporated to load the data the same way via an anonymous
|
||||
State Provider which is handed to ExtJS as long as ExtJS is still available in the TYPO3 Core.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Accessing the ExtDirect endpoint will result in a JavaScript error. Loading the JavaScript file will result in a HTTP 404 error.
|
||||
|
||||
Instantiating the PHP class will result in a fatal PHP error.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using custom implementations with ExtDirect and the State Provider shipped with the TYPO3 Core.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Include the `TYPO3\CMS\Backend\Storage`, and use the UserSettingsController class directly on the PHP side to
|
||||
access the user settings.
|
||||
|
||||
See the implementation of the JavaScript Storage object for a more detailed usage.
|
||||
|
||||
.. index:: JavaScript, Backend
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79228:
|
||||
|
||||
================================================================
|
||||
Breaking: #79228 - Remove ExtJS Pagetree indicator functionality
|
||||
================================================================
|
||||
|
||||
See :issue:`79228`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The functionality to enhance the page tree with custom indicators has been removed.
|
||||
The functionality was never documented and was hidden in the code.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Custom indicators are not shown in the TYPO3 Backend Pagetree anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using indicators of the page tree.
|
||||
|
||||
.. index:: Backend, JavaScript
|
||||
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79242:
|
||||
|
||||
==========================================
|
||||
Breaking: #79242 - Remove l10n_mode noCopy
|
||||
==========================================
|
||||
|
||||
See :issue:`79242`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The setting `noCopy` has been removed without replacement from the list of possible values of the TCA column
|
||||
property `l10n_mode`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Previously `noCopy` prevented that values of the parent language record were copied
|
||||
to a particular localization when that was created. Now, this value is duplicated during the creation of the localized record and has to be cleared manually if required.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All having :php:`$GLOBALS['TCA'][<table-name>]['columns'][<column-name>]['l10n_mode']`
|
||||
set to `noCopy`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove setting :php:`$GLOBALS['TCA'][<table-name>]['columns'][<column-name>]['l10n_mode']`
|
||||
if it is set to `noCopy`.
|
||||
|
||||
.. index:: TCA, Backend
|
||||
@@ -0,0 +1,57 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79243:
|
||||
|
||||
===================================================
|
||||
Breaking: #79243 - Remove l10n_mode mergeIfNotBlank
|
||||
===================================================
|
||||
|
||||
See :issue:`79243`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The setting `mergeIfNotBlank` has been removed without replacement from the list of possible values of
|
||||
the TCA column property `l10n_mode`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Previously values of a localization having a dependent parent record were taken
|
||||
from the parent record if `l10n_mode` for the particular field was set to
|
||||
`mergeIfNotBlank` and the value in the localization was empty. Now, this value
|
||||
is duplicated during the creation of the localized record and has to be
|
||||
modified manually if required.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All instances with extensions setting TCA options and having
|
||||
:php:`$GLOBALS['TCA'][<table-name>]['columns'][<column-name>]['l10n_mode']` set to `mergeIfNotBlank`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
First execute the upgrade wizard
|
||||
**Migrate values in database records having "l10n_mode" set** in the install tool.
|
||||
After that, remove :php:`$GLOBALS['TCA'][<table-name>]['columns'][<column-name>]['l10n_mode']`
|
||||
if it is set to `mergeIfNotBlank`. If `l10n_mode` is removed before the upgrade wizard
|
||||
has been executed, nothing will be migrated - thus, it's important to keep that order
|
||||
of migration.
|
||||
|
||||
The upgrade wizard executes the following field usages:
|
||||
|
||||
* inline children, pointing to `sys_file_reference`:
|
||||
file references are localized for the localization, if missing there
|
||||
* group fields, basically not using MM intermediate tables:
|
||||
value is cloned to the accordant field in the localization, if empty there
|
||||
* any other field type:
|
||||
value is cloned to the accordant field in the localization, is blank there
|
||||
|
||||
The term `blank` refers to an empty string (`''`), `empty` refers to an empty
|
||||
string, null values and zero values (numeric and string).
|
||||
|
||||
.. index:: Database, TCA
|
||||
@@ -0,0 +1,24 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79243-1668719172:
|
||||
|
||||
==========================================================
|
||||
Breaking: #79243 - Remove sys_language_softMergeIfNotBlank
|
||||
==========================================================
|
||||
|
||||
See :issue:`79243`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TypoScript setting :typoscript:`config.sys_language_softMergeIfNotBlank` has been removed
|
||||
without any replacement. This is a result of removing the TCA setting
|
||||
`mergeIfNotBlank` from the list of possible values for `l10n_mode`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove TypoScript setting :typoscript:`config.sys_language_softMergeIfNotBlank`.
|
||||
|
||||
.. index:: Frontend, TypoScript, TCA
|
||||
@@ -0,0 +1,42 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79259:
|
||||
|
||||
=====================================
|
||||
Breaking: #79259 - EXT:t3skin removed
|
||||
=====================================
|
||||
|
||||
See :issue:`79259`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The system extension `t3skin` has been removed, as all functionality has been migrated into
|
||||
other system extensions.
|
||||
|
||||
All ExtJS-related images and css files have been moved to EXT:core.
|
||||
|
||||
All other images have been unused for a while now, and have been deleted from the TYPO3 core.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Any direct references to EXT:t3skin now lead to missing styling or image(s).
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that use CSS files or images from EXT:t3skin.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Do not use ExtJS styling or images anymore, as ExtJS will be removed from the core.
|
||||
|
||||
Other direct references to image(s) in EXT:t3skin should be migrated to have the image(s) in
|
||||
custom extension.
|
||||
|
||||
.. index:: Backend, TCA, ext:t3skin
|
||||
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79263:
|
||||
|
||||
=========================================================
|
||||
Breaking: #79263 - Scheduler CLI Controller class removed
|
||||
=========================================================
|
||||
|
||||
See :issue:`79263`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The PHP class :php:`TYPO3\CMS\Scheduler\Controller\SchedulerCliController` has been removed from the system extension "scheduler"
|
||||
due to the migration to a native Symfony Command.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Instantiating the mentioned PHP class will result in a fatal PHP error.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation with a custom extension using this PHP class directly.
|
||||
|
||||
Please note that this does not affect any calls via CLI to trigger the scheduler via `typo3/cli_dispatch.phpsh scheduler` directly. This
|
||||
still works as before.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove any direct calls to the PHP class and use the provided APIs via CLI instead.
|
||||
|
||||
.. index:: CLI, ext:scheduler
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79270:
|
||||
|
||||
=======================================================================
|
||||
Breaking: #79270 - Removed RTE processing option disableUnifyLineBreaks
|
||||
=======================================================================
|
||||
|
||||
See :issue:`79270`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The RTE option that could be set via PageTSconfig :typoscript:`RTE.default.proc.disableUnifyLineBreaks` has been removed.
|
||||
|
||||
The option was never set by default.
|
||||
|
||||
If activated, it allowed that both line feeds (LFs) and carriage returns (CRs) were left as is. If the option was not set,
|
||||
all line breaks were converted to CRLFs after processing (Windows-syntax) to have a unified style of line breaks
|
||||
in the database.
|
||||
|
||||
The option was only there for historic reasons in TYPO3 v3 and TYPO3 v4 to allow to simulate old behaviour
|
||||
when no RTE was available.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
When editing or saving a rich-text content element, all line breaks are converted to CRLFs at any time. If this option is set, it is not
|
||||
evaluated anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation having the mentioned option explicitly activated in PageTSConfig and counting on the non-unified behaviour.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove the option from TSconfig as it is not necessary anymore.
|
||||
|
||||
.. index:: RTE, TSConfig
|
||||
@@ -0,0 +1,46 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79273:
|
||||
|
||||
=====================================================
|
||||
Breaking: #79273 - Removed RteHtmlParser proc options
|
||||
=====================================================
|
||||
|
||||
See :issue:`79273`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following TSconfig options for processing content of RTE fields have been removed:
|
||||
|
||||
* :typoscript:`RTE.default.proc.dontConvBRtoParagraph`
|
||||
* :typoscript:`RTE.default.proc.dontProtectUnknownTags_rte`
|
||||
* :typoscript:`RTE.default.proc.dontConvAmpInNBSP_rte`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Setting any of these options has no effect anymore.
|
||||
|
||||
Content coming from the database towards the RTE will now always keep unknown tags (but HSC'ed), and never have any
|
||||
double-encoded :html:` ` characters - this was a default since a decade already.
|
||||
|
||||
Content stored in the database will now always treat :html:`<br>` tags as intentional and not treat them like paragraphs, a behaviour which
|
||||
is common in modern Rich Text Editors.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Installations explicitly setting :typoscript:`RTE.default.proc.dontConvBRtoParagraph = 0`, :typoscript:`RTE.default.proc.dontProtectUnknownTags_rte = 1` or
|
||||
:typoscript:`RTE.default.proc.dontConvAmpInNBSP_rte = 1` might experience different results when editing and saving content via an RTE.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove the TSconfig options, as they have no effect anymore. Any custom implementation which is necessary should be handled
|
||||
via separate entryHtmlParser and exitHtmlParsers in both directions.
|
||||
|
||||
.. index:: RTE, TSConfig
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79300:
|
||||
|
||||
=====================================================================
|
||||
Breaking: #79300 - Removed RTE proc.transformBoldAndItalicTags option
|
||||
=====================================================================
|
||||
|
||||
See :issue:`79300`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The RTE processing TSconfig option `RTE.default.proc.transformBoldAndItalicTags` has been removed from the processing
|
||||
functionality.
|
||||
|
||||
It was a shortcut to change all :html:`<b>` and :html:`<i>` tags coming from the database to :html:`<strong>` and :html:`<em>` when loading the RTE. In return
|
||||
when storing the content again from the RTE, the :html:`<strong>` and :html:`<em>` tags were moved to :html:`<b>` and :html:`<i>` again.
|
||||
|
||||
If an integrator wanted to explicitly disable this functionality (basically having :html:`<strong>` and :html:`<em>` in the database), he/she needed
|
||||
to explicitly disable the option (setting it to "0", not just unsetting the option via PageTSconfig).
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Setting this option does not transform the tags anymore when loading the RTE or storing in DB. Instead, :html:`<strong>` and :html:`<em>` are stored
|
||||
in the database when editing a record.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation having custom RTE configuration and explicitly setting this option without having a proper HTMLparser replacement
|
||||
mapping in place.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Any default configuration of RTEHtmlArea that was in place before 8.6.0 has a simple replacement to ensure the same functionality now:
|
||||
|
||||
This code does the same as having :typoscript:`proc.transformBoldAndItalicTags=1`:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
RTE.default.proc {
|
||||
# make <strong> and <em> tags when sending to the RTE
|
||||
HTMLparser_rte {
|
||||
tags {
|
||||
b.remap = strong
|
||||
i.remap = em
|
||||
}
|
||||
}
|
||||
# make <b> and <i> tags when sending to the DB
|
||||
HTMLparser_db {
|
||||
tags {
|
||||
strong.remap = B
|
||||
em.remap = I
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
If having the option explicitly turned off (allowing strong, b, em, and i tags) is what is wanted the configuration should look like this:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
RTE.default.proc {
|
||||
# no remapping should happen, tags should stay as they are
|
||||
HTMLparser_rte {
|
||||
tags {
|
||||
b.remap >
|
||||
i.remap >
|
||||
}
|
||||
}
|
||||
# no remapping should happen, tags should stay as they are
|
||||
HTMLparser_db {
|
||||
tags {
|
||||
strong.remap >
|
||||
em.remap >
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Please note that this migration is only necessary if custom RTE options are in place, as the default RTE HTMLArea configuration does that
|
||||
automatically.
|
||||
|
||||
.. index:: RTE, TSConfig
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79302:
|
||||
|
||||
=====================================================================
|
||||
Breaking: #79302 - Moved pages.url_scheme to compatibility7 extension
|
||||
=====================================================================
|
||||
|
||||
See :issue:`79302`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The database field "pages.url_scheme" functionality has been moved to the compatibility7 extension.
|
||||
|
||||
The field allows to force the HTTP or HTTPS protocol for a specific page to be set by an editor in the page properties on a per-page
|
||||
basis. However, it is common today to ensure (if a SSL certificate is available) to use HTTPS for a whole website or even only for a
|
||||
specific area (inc. subpages) to force the protocol.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
If the functionality was used before, it will not work anymore, thus links will not be forced to be generated with a forced HTTP/HTTPS url
|
||||
scheme and redirects on pages that had the option set will not happen anymore, unless the compatibility7 extension is installed.
|
||||
|
||||
Generating preview links with pages that have an enforced scheme out of the TYPO3 backend will not work anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any TYPO3 instance that depends on the `url_scheme` database field, having any value filled in.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Install the compatibility7 extension to have the same functionality as before, or use HTTPS enforcing via server configuration (.htaccess)
|
||||
or any SSL related extension in the TYPO3 Extension Repository (TER) that provides superior functionality.
|
||||
|
||||
To ensure a certain protocol when previewing a page the TSconfig option :typoscript:`TCEMAIN.previewDomain` can be used to set a preview prefix including
|
||||
the URL scheme.
|
||||
|
||||
.. index:: Database, Frontend
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79327:
|
||||
|
||||
========================================================================
|
||||
Breaking: #79327 - The veriCode - vC parameter is not evaluated any more
|
||||
========================================================================
|
||||
|
||||
See :issue:`79327`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The `veriCode` (`&vC=...`) parameter generated by :php:`AbstractUserAuthentication::veriCode` is not evaluated anymore in:
|
||||
|
||||
- `ImportExportController::checkUpload()`
|
||||
- `FileController::main()`
|
||||
- `EditDocumentController::processData()`
|
||||
- `SimpleDataHandlerController::main()`
|
||||
|
||||
Also the following properties have been removed:
|
||||
|
||||
- `EditDocumentController::vC`
|
||||
- `SimpleDataHandlerController::vC`
|
||||
- `ImportExportController::vC`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Any code reading from the removed `vC` properties will now throw an "Undefined property" notice.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation having code relying on 'vC' property being present in aforementioned classes, or relying on `vC` parameter being checked.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove calls to `veriCode` or any `vC` HTTP parameter evaluation from your code. Ensure your code uses `moduleToken` to protect backend urls.
|
||||
|
||||
.. index:: Backend, PHP-API
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79364:
|
||||
|
||||
==========================================================================
|
||||
Breaking: #79364 - Move page module function `QuickEdit` to compatibility7
|
||||
==========================================================================
|
||||
|
||||
See :issue:`79364`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The function `QuickEdit` in the page module has been moved to EXT:compatibility7 and will not be developed further. EXT:compatibility7 will be moved to TER before the release of 8 LTS.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Installation of EXT:compatibility7 is required to continue using the `QuickEdit` function of the page module.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations depending on the `QuickEdit` function in the page module.
|
||||
|
||||
|
||||
.. index:: Backend
|
||||
@@ -0,0 +1,159 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79464:
|
||||
|
||||
======================================================
|
||||
Breaking: #79464 - EXT:form - Refactor fluid rendering
|
||||
======================================================
|
||||
|
||||
See :issue:`79464`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
EXT:form uses "fluid" as the default rendering strategy.
|
||||
Therefore, EXT:form has to work closely with the concepts of fluid to avoid current and future problems.
|
||||
Until now, EXT:form tried to reuse a fluid view instance by reconfiguring the instance on each nesting level, but fluid is not intended for such a purpose.
|
||||
This change reduces the complexity of the rendering process and works closer with the concepts of fluid.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The configuration options `renderingOptions.templateRootPaths`, `renderingOptions.partialRootPaths` and `renderingOptions.layoutRootPaths` for form elements are
|
||||
from now on only rules for the root form element ('Form') and will be applied for all child form elements.
|
||||
If you configure `renderingOptions.templateRootPaths` etc. for other form elements it will have no effect.
|
||||
|
||||
The configuration option `renderingOptions.templatePathAndFilename` for form elements was removed from the configuration and will have no effect.
|
||||
To define a template file name which should be used instead of a filename which is named like the form element type, there is a new option `renderingOptions.templateName`.
|
||||
|
||||
The internal setting `renderingOptions.renderableNameInTemplate` for form elements has been removed from the configuration and will have no effect.
|
||||
|
||||
The setting `rendererClassName` for form elements are from now on only rules for the root form element ('Form').
|
||||
If you define this option for other form elements, an `invalid configuration` exception will be thrown.
|
||||
|
||||
The configuration for the backend editor inline templates which are used by editor javascript has changed.
|
||||
The configuration path `prototypes.<prototypeName>.formEditor.formEditorTemplates` has been renamed and has no effect anymore.
|
||||
The fluid configuration part moved from `prototypes.<prototypeName>.formEditor.formEditorTemplates` to a new section `prototypes.<prototypeName>.formEditor.formEditorFluidConfiguration`.
|
||||
The backend editor inline template mapping moved to a new section `prototypes.<prototypeName>.formEditor.formEditorPartials`.
|
||||
The inline template mapping for stage templates has been condensed. If you define custom form editor stage templates which use a default stage template it could
|
||||
result in a javascript error within the form editor.
|
||||
|
||||
The template files moved from `Resources/Private/Frontend/Templates/FormElements/` to `Resources/Private/Frontend/Partials`.
|
||||
The template structure has changed. Without adaptation of your overridden templates, no form elements are visible within the frontend.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations since TYPO3 8.5 which use the new EXT:form extension and create or extend custom form elements through configuration and / or
|
||||
override EXT:form template files.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
If you override/ extend
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.mixins.formElementMixins.BaseFormElementMixin.renderingOptions.templateRootPaths
|
||||
TYPO3.CMS.Form.mixins.formElementMixins.BaseFormElementMixin.renderingOptions.partialRootPaths
|
||||
TYPO3.CMS.Form.mixins.formElementMixins.BaseFormElementMixin.renderingOptions.layoutRootPaths
|
||||
|
||||
move it to
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.templateRootPaths
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.partialRootPaths
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.layoutRootPaths
|
||||
|
||||
|
||||
If you override/ extend
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.mixins.formElementMixins.BaseFormElementMixin.renderingOptions.skipUnknownElements
|
||||
|
||||
move it to
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.skipUnknownElements
|
||||
|
||||
|
||||
If you defined
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.<formElementType>.rendererClassName
|
||||
|
||||
for a <formElementType> which is *NOT* 'Form', you have to remove this setting.
|
||||
|
||||
|
||||
If you defined
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.renderableNameInTemplate
|
||||
|
||||
you have to use
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.templateName
|
||||
|
||||
`templateName` is the partial path, relative to `TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.partialRootPaths`
|
||||
|
||||
|
||||
If you defined custom form editor templates within
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formEditor.formEditorTemplates
|
||||
|
||||
you have to move this to
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TYPO3.CMS.Form.prototypes.<prototypeName>.formEditor.formEditorPartials
|
||||
|
||||
|
||||
If you defined a custom form editor stage template which depends on a default form editor stage template you have to redefine it:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Stage/Text => Stage/SimpleTemplate
|
||||
Stage/Password => Stage/SimpleTemplate
|
||||
Stage/AdvancedPassword => Stage/SimpleTemplate
|
||||
Stage/Textarea => Stage/SimpleTemplate
|
||||
Stage/Checkbox => Stage/SimpleTemplate
|
||||
Stage/MultiCheckbox => Stage/SelectTemplate
|
||||
Stage/MultiSelect => Stage/SelectTemplate
|
||||
Stage/RadioButton => Stage/SelectTemplate
|
||||
Stage/SingleSelect => Stage/SelectTemplate
|
||||
Stage/DatePicker => Stage/SimpleTemplate
|
||||
Stage/Hidden => Stage/SimpleTemplate
|
||||
Stage/FileUpload => Stage/FileUploadTemplate
|
||||
Stage/ImageUpload => Stage/FileUploadTemplate
|
||||
|
||||
|
||||
All form element templates except the template for the `Form` element moved from templates to partials.
|
||||
You have to move this too, if you extended the fluid search paths.
|
||||
The 'Form' element is a template and will be found through `TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.templateRootPaths`.
|
||||
All other form elements are partials and will be found through `TYPO3.CMS.Form.prototypes.<prototypeName>.formElementsDefinition.Form.renderingOptions.partialRootPaths`.
|
||||
|
||||
|
||||
The template/partial structure has changed. You have to adapt this to your custom templates.
|
||||
Please look at the files within `EXT:form/Resources/Private/Frontend/Partials`
|
||||
to see what has happened.
|
||||
The main change is that you have to wrap the markup with
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<formvh:renderRenderable renderable="{element}">
|
||||
some form element
|
||||
</formvh:renderRenderable>
|
||||
|
||||
.. index:: Backend, Frontend, ext:form
|
||||
@@ -0,0 +1,59 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79513:
|
||||
|
||||
=============================================================
|
||||
Breaking: #79513 - Removed session locking based on useragent
|
||||
=============================================================
|
||||
|
||||
See :issue:`79513`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When using session data or user-login functionality with TYPO3, the default configuration was to
|
||||
harden the session binding to the User Agent information sent by the HTTP request. If the user agent
|
||||
information does not match, the session gets renewed and the user gets logged out.
|
||||
|
||||
The options :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['lockHashKeyWords']` and :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['lockHashKeyWords']`
|
||||
were set to "useragent" by default to use this additional session locking check.
|
||||
|
||||
This case is especially problematic when having a larger website (e.g. a community platform) with
|
||||
100K frontend users and the session lifetime set to 6 months. After every security update of the
|
||||
browser or possibly a plugin, or if a version update is happening on Evergreen Browsers, then
|
||||
all users would get logged out, which is inconvenient.
|
||||
|
||||
Based on the additional security level on top versus the user experience on the site, the "useragent"
|
||||
functionality has been dropped. Since the "lockHashKeyWords" options did only work on "useragent"
|
||||
and no other functionality was integrated, the option (and related, the database fields "ses_hashlock"
|
||||
as well) has been removed without substitution.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The options :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['lockHashKeyWords']` and :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['lockHashKeyWords']`
|
||||
are removed automatically when hitting the install tool.
|
||||
|
||||
The database fields 'fe_sessions.ses_hashlock' and 'be_sessions.ses_hashlock' have been removed.
|
||||
|
||||
The public property :php:`$lockHashKeyWords` of the PHP class `AbstractUserAuthentication` has been
|
||||
removed and will throw a PHP Notice when trying to access it.
|
||||
|
||||
All other functionality related to sessions still works the same.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using the configuration options for custom checks based on the session handling
|
||||
with third-party extensions, which is very unlikely.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
The TYPO3 Install Tool removes the configuration option for existing installations. Using the
|
||||
"Database Comparison" view, it is possible to remove the fields from the database.
|
||||
|
||||
.. index:: LocalConfiguration, PHP-API
|
||||
@@ -0,0 +1,68 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719202:
|
||||
|
||||
====================================================
|
||||
Breaking: #79622 - CSS Styled Content and TypoScript
|
||||
====================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In order to streamline CSS Styled Content and Fluid Styled Content several options
|
||||
of CSS Styled Content have been dropped without replacement.
|
||||
|
||||
Options Dropped:
|
||||
|
||||
* TCA image_compression
|
||||
* TCA image_effects
|
||||
* TCA image_noRows
|
||||
* TypoScript IMAGE noRows dropped
|
||||
* TypoScript IMAGE noCols dropped
|
||||
* TypoScript IMAGE noRowsStdWrap dropped
|
||||
* TypoScript IMGTEXT captionAlign dropped
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The options mentioned above will have no effect.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All Installations that use the options mentioned above.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Image Compression
|
||||
-----------------
|
||||
|
||||
Use global image compression configuration of TYPO3 instead of deciding
|
||||
compression on content element level.
|
||||
|
||||
|
||||
Image Effects
|
||||
-------------
|
||||
|
||||
Use CSS to apply effects on Images.
|
||||
|
||||
|
||||
No Rows
|
||||
-------
|
||||
|
||||
Use CSS to style the output.
|
||||
|
||||
|
||||
Caption Alignment
|
||||
-----------------
|
||||
|
||||
Use CSS to align the caption text to your preference.
|
||||
|
||||
|
||||
.. index:: Frontend, TypoScript, ext:css_styled_content
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719195:
|
||||
|
||||
========================================================================
|
||||
Breaking: #79622 - CSS Styled Content Bullet Content Element Adjustments
|
||||
========================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In order to streamline the options and enhance compatibility across CSS Styled
|
||||
Content and Fluid Styled Content the bullet content element has been partly
|
||||
refactored.
|
||||
|
||||
The bullet content elements of CSS Styled Content now also uses the field
|
||||
`bullets_type` instead of `layout` to match the behavior of Fluid Styled Content.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Installations that use the CSS Styled Content element bullets.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Run the upgrade wizard in the install tool to migrate the layout field to the
|
||||
dedicated database field `bullets_type`.
|
||||
|
||||
|
||||
.. index:: FlexForm, Frontend, TCA, TypoScript, ext:css_styled_content
|
||||
+124
@@ -0,0 +1,124 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719233:
|
||||
|
||||
=======================================================================
|
||||
Breaking: #79622 - CSS Styled Content table content element adjustments
|
||||
=======================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In order to streamline the options and enhance compatibility across CSS Styled
|
||||
Content and Fluid Styled Content the table content element has been partly
|
||||
refactored. All previous flexform configuration has been migrated to database
|
||||
fields, shared across both content rendering definitions.
|
||||
|
||||
Element options removed:
|
||||
|
||||
* Table Summary
|
||||
* No CSS styles for this table
|
||||
|
||||
Element options changed:
|
||||
|
||||
* Additional CSS Class
|
||||
|
||||
Rendering changes:
|
||||
|
||||
* Additional CSS classes for tr, th, td have been dropped
|
||||
|
||||
TypoScript options removed:
|
||||
|
||||
* color
|
||||
* tableParams_0
|
||||
* tableParams_1
|
||||
* tableParams_2
|
||||
* tableParams_3
|
||||
* border
|
||||
* cellpadding
|
||||
* cellspacing
|
||||
|
||||
|
||||
Table Summary
|
||||
-------------
|
||||
The <table> summary attribute is not supported in HTML5 and has been dropped.
|
||||
No migration path available.
|
||||
|
||||
|
||||
No CSS styles for table
|
||||
-----------------------
|
||||
The default CSS styling for CSS Styled Content is now optional. If no styling
|
||||
is required, simply do not include the optional static template or override
|
||||
the styling with CSS.
|
||||
|
||||
|
||||
Additional CSS Class
|
||||
--------------------
|
||||
The process of adding additional CSS classes for tables has been changed.
|
||||
To ease the work of the editor the CSS class field is no longer a simple input
|
||||
field. Adding CSS classes are now handled by predefined CSS classes that can
|
||||
be adjusted by the integrator. Classes will be prefixed with "contenttable-".
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.tt_content.table_class {
|
||||
removeItems = striped,bordered
|
||||
addItems {
|
||||
hover = LLL:my_extension/Resources/Private/language.xlf:hover
|
||||
}
|
||||
}
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['table_class']['config']['items'][] = [
|
||||
0 = LLL:my_extension/Resources/Private/language.xlf:hover
|
||||
1 = hover
|
||||
];
|
||||
|
||||
|
||||
Rendering changes and removed TypoScript options
|
||||
------------------------------------------------
|
||||
Style specific options have been removed and are no longer available. This
|
||||
includes the following options for table rendering: `color`, `tableParams_0`,
|
||||
`tableParams_1`, `tableParams_2`, `tableParams_3`, `border`, `cellpadding` and
|
||||
`cellspacing`. Also additional CSS classes for `tr`, `th` and `td` are no
|
||||
longer available.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Installations that use the CSS Styled Content element table.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Run the upgrade wizard in the install tool to migrate all fields previously
|
||||
stored in flexforms to dedicated fields in the database.
|
||||
|
||||
|
||||
Table summary
|
||||
-------------
|
||||
The <table> summary attribute is not supported in HTML5 and has been dropped.
|
||||
No migration path available.
|
||||
|
||||
|
||||
No CSS styles for this table
|
||||
----------------------------
|
||||
Remove the optional "CSS Styled Content Styling" static template.
|
||||
|
||||
|
||||
Additional CSS classes
|
||||
----------------------
|
||||
Additional CSS Classes must be registered as items for the field `table_class`.
|
||||
|
||||
|
||||
Rendering changes and removed TypoScript Options
|
||||
------------------------------------------------
|
||||
Use CSS styling to restore the look of your tables.
|
||||
|
||||
|
||||
.. index:: FlexForm, Frontend, TCA, TypoScript, ext:css_styled_content
|
||||
@@ -0,0 +1,49 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719270:
|
||||
|
||||
=======================================================
|
||||
Breaking: #79622 - Dedicated content elements for menus
|
||||
=======================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
For better maintainability the currently existing content element
|
||||
menu has been split into dedicated content elements.
|
||||
|
||||
========================== ========================== ==========================================================
|
||||
Database Key Name Description
|
||||
========================== ========================== ==========================================================
|
||||
menu_abstract Abstracts Menu of subpages of selected pages including abstracts
|
||||
menu_categorized_content Categorized content Content elements for selected categories
|
||||
menu_categorized_pages Categorized pages Pages for selected categories
|
||||
menu_pages Pages Menu of selected pages
|
||||
menu_subpages Subpages Menu of subpages of selected pages
|
||||
menu_recently_updated Recently updated pages Menu of recently updated pages
|
||||
menu_related_pages Related pages Menu of related pages based on keywords
|
||||
menu_section Section index Page content marked for section menus
|
||||
menu_section_pages Section index of subpages Menu of subpages of selected pages including sections
|
||||
menu_sitemap Sitemap Expanded menu of all pages and subpages for selected pages
|
||||
menu_sitemap_pages Sitemaps of selected pages Expanded menu of all subpages for selected pages
|
||||
========================== ========================== ==========================================================
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that use the content element "menu".
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Run the migration wizard in the install tool. All shipped menu types from the
|
||||
TYPO3 core will be migrated to the new dedicated elements.
|
||||
|
||||
The migration is optional, you can also enable the extension `compatibility7`
|
||||
that will make the old menu content element available again.
|
||||
|
||||
.. index:: Frontend, TypoScript, TCA
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719209:
|
||||
|
||||
===========================================================================
|
||||
Breaking: #79622 - Default content element changed for Fluid Styled Content
|
||||
===========================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The default content element has been streamlined with CSS Styled Content
|
||||
and has been changed to "Text".
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The default content element is now "Text".
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All instances that have Fluid Styled Content installed.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
To restore the configuration you need to set the default content element
|
||||
manually to your preferred choice. You can do this by simply overriding
|
||||
the configuration again in your `Configuration/TCA/Overrides/tt_content.php` file.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['CType']['config']['default'] = 'textmedia';
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['CType']['config']['default'] = 'header';
|
||||
|
||||
|
||||
.. index:: TCA, ext:fluid_styled_content
|
||||
+47
@@ -0,0 +1,47 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719247:
|
||||
|
||||
===================================================================
|
||||
Breaking: #79622 - Default layouts for Fluid Styled Content changed
|
||||
===================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The content element layouts for Fluid Styled Content have been changed
|
||||
to provide a better maintainability and to be more flexible.
|
||||
|
||||
Previously available content element layouts `ContentFooter`, `HeaderFooter`
|
||||
and `HeaderContentFooter` have been dropped and replaced with a single
|
||||
`Default` layout that is more flexible.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The content element layouts `ContentFooter`, `HeaderFooter` and
|
||||
`HeaderContentFooter` are no longer available. Referencing these layouts will
|
||||
result in an exception.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All instances that override or implement custom content elements based on
|
||||
Fluid Styled Content that use the layouts `ContentFooter`, `HeaderFooter`
|
||||
or `HeaderContentFooter`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
All content elements and overrides need to be migrated to the new default
|
||||
layout. Have a look at the feature description on how to use the new layout.
|
||||
|
||||
See: :ref:`feature-79622-new-default-layout-for-fluid-styled-content`.
|
||||
|
||||
|
||||
.. index:: Fluid, Frontend, ext:fluid_styled_content
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622:
|
||||
|
||||
==================================================================
|
||||
Breaking: #79622 - Dropping thumbnail configuration for tt_content
|
||||
==================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
It is currently not possible to set the thumbnail field depending on
|
||||
the type of the record. Since tt_content uses different fields to store
|
||||
media we are removing this default configuration that was set to `images`
|
||||
by CSS Styled Content and `assets` by Fluid Styled Content.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Thumbnails in list view are no longer displayed for tt_content records.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All instances.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
To restore the configuration you need to set the thumbnail field manually to
|
||||
your preferred choice.
|
||||
You can do this by simply adding the configuration again in your `Configuration/TCA/Overrides/tt_content.php` file.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['ctrl']['thumbnail'] = 'image';
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['ctrl']['thumbnail'] = 'assets';
|
||||
|
||||
|
||||
.. index:: TCA, Backend, ext:fluid_styled_content, ext:css_styled_content
|
||||
+89
@@ -0,0 +1,89 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719381:
|
||||
|
||||
===================================================================
|
||||
Breaking: #79622 - Removal of Fluid Styled Content Menu ViewHelpers
|
||||
===================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Fetching data directly in the view is not recommended and the temporary
|
||||
solution of menu ViewHelpers has been replaced by its successor, the menu
|
||||
processor that is based on HMENU.
|
||||
|
||||
Menu ViewHelpers have been moved to the `compatibility7` extension, and are
|
||||
replaced in the core menu content elements.
|
||||
|
||||
List of removed ViewHelpers:
|
||||
|
||||
- menu.categories
|
||||
- menu.directory
|
||||
- menu.keywords
|
||||
- menu.list
|
||||
- menu.section
|
||||
- menu.updated
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that use the `fluid_styled_content` menu ViewHelpers.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use `TYPO3\CMS\Frontend\DataProcessing\MenuProcessor` instead of ViewHelpers.
|
||||
|
||||
For CMS 8 the ViewHelpers will be available as soon as `compatibility7` is
|
||||
installed, but it's highly recommended to migrate your configuration.
|
||||
|
||||
Example (Directory)
|
||||
-------------------
|
||||
|
||||
Before:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.menu_subpages.dataProcessing {
|
||||
10 = TYPO3\CMS\Frontend\DataProcessing\SplitProcessor
|
||||
10 {
|
||||
if.isTrue.field = pages
|
||||
fieldName = pages
|
||||
delimiter = ,
|
||||
removeEmptyEntries = 1
|
||||
filterIntegers = 1
|
||||
filterUnique = 1
|
||||
as = pageUids
|
||||
}
|
||||
}
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<ce:menu.directory pageUids="{pageUids}" as="pages" levelAs="level">
|
||||
<f:for each="{pages}" as="page">
|
||||
...
|
||||
</f:for>
|
||||
</ce.menu.directory>
|
||||
|
||||
After:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.menu_subpages.dataProcessing {
|
||||
10 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor
|
||||
10.special = directory
|
||||
10.special.value.field = pages
|
||||
}
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:for each="{menu}" as="page">
|
||||
...
|
||||
</f:for>
|
||||
|
||||
.. index:: Fluid, Frontend, ext:fluid_styled_content
|
||||
+108
@@ -0,0 +1,108 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719172:
|
||||
|
||||
=================================================================================
|
||||
Breaking: #79622 - Section Frame for CSS Styled Content replaced with Frame Class
|
||||
=================================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The functionality provided by `Section Frame` has been streamlined with Fluid Styled
|
||||
Content and is now available as `Frame Class`. Previously, integers have been
|
||||
stored in the Database that required a mapping of non speaking values.
|
||||
|
||||
The new introduced speaking values provide a more valuable use, for example
|
||||
in Fluid Styled Content the values are used directly without mapping.
|
||||
|
||||
For CSS Styled Content the original behaviour has been mapped to the new keys in the
|
||||
database and the option `invisible` has been dropped.
|
||||
|
||||
|
||||
Compatibility Table
|
||||
-------------------
|
||||
|
||||
=============== =============== =============== =================================== =======================
|
||||
Name Previous Key New Key CSS Class Additional Effects
|
||||
=============== =============== =============== =================================== =======================
|
||||
Default 0 default csc-frame csc-frame-default \-
|
||||
Invisible 1 (dropped) \- \-
|
||||
Ruler Before 5 ruler-before csc-frame csc-frame-ruler-before \-
|
||||
Ruler After 6 ruler-after csc-frame csc-frame-ruler-after \-
|
||||
Indent 10 indent csc-frame csc-frame-indent \-
|
||||
Indent, 33/66% 11 indent-left csc-frame csc-frame-indent-left \-
|
||||
Indent, 66/33% 12 indent-right csc-frame csc-frame-indent-right \-
|
||||
No Frame 66 none (none) No Frame is rendered
|
||||
=============== =============== =============== =================================== =======================
|
||||
|
||||
|
||||
TypoScript Before
|
||||
-----------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.stdWrap.innerWrap.cObject.key.field = section_frame
|
||||
tt_content.stdWrap.innerWrap.cObject.5 =< tt_content.stdWrap.innerWrap.cObject.default
|
||||
tt_content.stdWrap.innerWrap.cObject.5.20.10.value = csc-frame csc-frame-ruler-before
|
||||
|
||||
|
||||
TypoScript After
|
||||
----------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.stdWrap.innerWrap.cObject.key.field = frame_class
|
||||
tt_content.stdWrap.innerWrap.cObject.ruler-before =< tt_content.stdWrap.innerWrap.cObject.default
|
||||
tt_content.stdWrap.innerWrap.cObject.ruler-before.20.10.value = csc-frame csc-frame-ruler-before
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Installations that use the CSS Styled Content.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Default fames can be automatically upgraded to the new field and values. Custom
|
||||
values will be prefixed with `custom-<key>` and will also be transferred to the
|
||||
new field.
|
||||
|
||||
Note that custom values must be added again to the field configuration, and the
|
||||
mapping in the TypoScript rendering definition for CSS Styled Content needs also
|
||||
to adapt.
|
||||
|
||||
|
||||
Add custom frame
|
||||
----------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.tt_content.frame_class {
|
||||
addItems {
|
||||
custom-1 = LLL:EXT:extension/Resources/Private/Language/locallang.xlf:customFrame
|
||||
}
|
||||
}
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['frame_class']['config']['items'][] = [
|
||||
0 = LLL:EXT:extension/Resources/Private/Language/locallang.xlf:customFrame
|
||||
1 = custom-1
|
||||
];
|
||||
|
||||
|
||||
Adapt rendering definition
|
||||
--------------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.stdWrap.innerWrap.cObject.custom-1 =< tt_content.stdWrap.innerWrap.cObject.default
|
||||
tt_content.stdWrap.innerWrap.cObject.custom-1.20.10.value = csc-frame csc-frame-custom-1
|
||||
|
||||
|
||||
.. index:: Frontend, TypoScript, ext:css_styled_content
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719355:
|
||||
|
||||
================================================================================
|
||||
Breaking: #79622 - SpaceBefore and SpaceAfter adjustments for CSS Styled Content
|
||||
================================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
CSS Styled Content provided the possibility to the editor to fine-tune distances
|
||||
between content elements. The concept of CSC relied on the editor
|
||||
understanding what `margins` are, how they are calculated and had to maintain
|
||||
an overview of pixels that were used on the site he/she is maintaining.
|
||||
|
||||
This led to different problems not only for the editor but also for the
|
||||
integrator because he had no control about what the editor fills into these
|
||||
fields. Also it was hardly controllable when these distances should be
|
||||
variable and change on certain viewports for mobile usage.
|
||||
|
||||
To regain control over this behaviour we are now introducing a new concept
|
||||
that purely relies on CSS classes, that can be defined by the integrator.
|
||||
|
||||
The original fields `spaceAfter` and `spaceBefore` have been dropped, and also
|
||||
the method :php:`\TYPO3\CMS\CssStyledContent\Controller\CssStyledContentController::renderSpace()`
|
||||
is not called anymore.
|
||||
|
||||
|
||||
Old TypoScript Rendering
|
||||
------------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.stdWrap.innerWrap.cObject.default.20.20 = USER
|
||||
tt_content.stdWrap.innerWrap.cObject.default.20.20 {
|
||||
userFunc = TYPO3\CMS\CssStyledContent\Controller\CssStyledContentController->renderSpace
|
||||
space = before
|
||||
constant = {$content.spaceBefore}
|
||||
classStdWrap {
|
||||
required = 1
|
||||
noTrimWrap = |csc-space-before-| |
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
New TypoScript Rendering
|
||||
------------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.stdWrap.innerWrap.cObject.default.20.20 = TEXT
|
||||
tt_content.stdWrap.innerWrap.cObject.default.20.20 {
|
||||
field = space_before_class
|
||||
required = 1
|
||||
noTrimWrap = |csc-space-before-| |
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
User-defined distances between content elements are missing.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All instances that use CSS Styled Content and have spaceBefore or spaceAfter
|
||||
values set to generate more space between their content elements.
|
||||
|
||||
|
||||
Check if your site is affected
|
||||
------------------------------
|
||||
|
||||
.. code-block:: sql
|
||||
|
||||
SELECT
|
||||
uid,
|
||||
pid,
|
||||
spaceBefore,
|
||||
spaceAfter
|
||||
FROM
|
||||
tt_content
|
||||
WHERE
|
||||
(spaceBefore > 0 OR spaceAfter > 0)
|
||||
AND deleted = 0
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
There is no automatic migration available. If a migration is necessary you need
|
||||
to check the new presets available and migrate the pixels defined before to the
|
||||
a preset of your choice.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
.. code-block:: sql
|
||||
|
||||
UPDATE
|
||||
tt_content
|
||||
SET
|
||||
spaceAfter = 0,
|
||||
space_after_class = 'medium'
|
||||
WHERE
|
||||
spaceAfter >= 42
|
||||
AND spaceAfter < 56
|
||||
|
||||
|
||||
Replacement Documentation
|
||||
-------------------------
|
||||
|
||||
For detailed information about the replacement of spaceBefore and spaceAfter,
|
||||
please head over to the feature documentation of SpaceBefore- and SpaceAfterClass
|
||||
for CSS Styled Content.
|
||||
|
||||
Feature-79622-SpaceBeforeAndSpaceAfterClassForCssStyledContent.rst
|
||||
|
||||
|
||||
.. index:: Frontend, Database, ext:css_styled_content, TypoScript
|
||||
+144
@@ -0,0 +1,144 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719184:
|
||||
|
||||
========================================================================================
|
||||
Breaking: #79622 - Streamlining structure of CSS Styled Content and Fluid Styled Content
|
||||
========================================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The file structures of CSS Styled Content and Fluid Styled Content have been streamlined.
|
||||
|
||||
|
||||
File structure of CSS Styled Content
|
||||
------------------------------------
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
- Configuration/TypoScript
|
||||
| - ContentElement
|
||||
| | - Bullets.txt
|
||||
| | - Div.txt
|
||||
| | - Header.txt
|
||||
| | - Html.txt
|
||||
| | - Image.txt
|
||||
| | - List.txt
|
||||
| | - MenuAbstract.txt
|
||||
| | - MenuCategorizedContent.txt
|
||||
| | - MenuCategorizedPages.txt
|
||||
| | - MenuPages.txt
|
||||
| | - MenuRecentlyUpdated.txt
|
||||
| | - MenuRelatedPages.txt
|
||||
| | - MenuSection.txt
|
||||
| | - MenuSectionPages.txt
|
||||
| | - MenuSitemap.txt
|
||||
| | - MenuSitemapPages.txt
|
||||
| | - MenuSubpages.txt
|
||||
| | - Shortcut.txt
|
||||
| | - Table.txt
|
||||
| | - Text.txt
|
||||
| | - Textmedia.txt
|
||||
| | - Textpic.txt
|
||||
| | - Uploads.txt
|
||||
| - ContentElementPartials
|
||||
| | - Menu.txt
|
||||
| - Helper
|
||||
| | - ParseFunc.txt
|
||||
| | - StandardHeader.txt
|
||||
| | - StylesContent.txt
|
||||
| - Styling
|
||||
| | - setup.txt
|
||||
| - constants.txt
|
||||
| - setup.txt
|
||||
|
||||
|
||||
File structure of Fluid Styled Content
|
||||
--------------------------------------
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
- Configuration/TypoScript
|
||||
| - ContentElement
|
||||
| | - Bullets.txt
|
||||
| | - Div.txt
|
||||
| | - Header.txt
|
||||
| | - Html.txt
|
||||
| | - Image.txt
|
||||
| | - List.txt
|
||||
| | - MenuAbstract.txt
|
||||
| | - MenuCategorizedContent.txt
|
||||
| | - MenuCategorizedPages.txt
|
||||
| | - MenuPages.txt
|
||||
| | - MenuRecentlyUpdated.txt
|
||||
| | - MenuRelatedPages.txt
|
||||
| | - MenuSection.txt
|
||||
| | - MenuSectionPages.txt
|
||||
| | - MenuSitemap.txt
|
||||
| | - MenuSitemapPages.txt
|
||||
| | - MenuSubpages.txt
|
||||
| | - Shortcut.txt
|
||||
| | - Table.txt
|
||||
| | - Text.txt
|
||||
| | - Textmedia.txt
|
||||
| | - Textpic.txt
|
||||
| | - Uploads.txt
|
||||
| - Helper
|
||||
| | - FluidContent.txt
|
||||
| | - ParseFunc.txt
|
||||
| - Styling
|
||||
| | - setup.txt
|
||||
| - constants.txt
|
||||
| - setup.txt
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
TYPO3 will fail to load the rendering definitions correctly if the paths are
|
||||
not included matching the new file locations.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that are referring to the previous location of the rendering
|
||||
definitions. Please check if your using any of these paths for including the
|
||||
rendering definitions.
|
||||
|
||||
|
||||
CSS Styled Content
|
||||
------------------
|
||||
|
||||
- EXT:css_styled_content/static/v4.5
|
||||
- EXT:css_styled_content/static/v4.6
|
||||
- EXT:css_styled_content/static/v4.7
|
||||
- EXT:css_styled_content/static/v6.0
|
||||
- EXT:css_styled_content/static/v6.1
|
||||
- EXT:css_styled_content/static/v6.2
|
||||
- EXT:css_styled_content/static
|
||||
- EXT:css_styled_content/Configuration/TypoScript/v7
|
||||
|
||||
|
||||
Fluid Styled Content
|
||||
--------------------
|
||||
|
||||
- EXT:fluid_styled_content/TypoScript/Static
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Database entries can be automatically upgraded to the new locations. If you have
|
||||
references in your TypoScript files you need to do the migration manually.
|
||||
|
||||
Use the new locations for accessing the TypoScript configuration.
|
||||
|
||||
- `CSS Styled Content` = EXT:css_styled_content/Configuration/TypoScript/
|
||||
- `Fluid Styled Content` = EXT:fluid_styled_content/Configuration/TypoScript/
|
||||
|
||||
|
||||
.. index:: Fluid, Frontend, ext:fluid_styled_content
|
||||
+190
@@ -0,0 +1,190 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _breaking-79622-1668719372:
|
||||
|
||||
========================================================================================
|
||||
Breaking: #79622 - TypoScript Standard Header has been removed from Fluid Styled Content
|
||||
========================================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TypoScript standard header rendering definition `lib.stdHeader` has been
|
||||
introduced in CSS Styled Content to reference it across multiple content
|
||||
elements to simplify maintenance.
|
||||
|
||||
For Fluid Styled Content a workaround for compatibility with CMS 7 has been introduced
|
||||
to simplify migration. However, it only renders the header and misses all frames,
|
||||
and additional are options necessary to generate a streamlined rendering
|
||||
output if the content element layout was not implemented correctly.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
|
||||
TypoScript Configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.simple_content = COA
|
||||
tt_content.simple_content {
|
||||
10 < lib.stdHeader
|
||||
20 = TEXT
|
||||
20.field = bodytext
|
||||
}
|
||||
|
||||
|
||||
Generated Output
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<header>
|
||||
<h1>Nunc vel libero dignissim</h1>
|
||||
</header>
|
||||
<p>
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed cursus
|
||||
vel lectus vel placerat. Suspendisse non metus sed lorem sagittis
|
||||
consequat non vel nulla.
|
||||
</p>
|
||||
|
||||
|
||||
Expected Output
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<div id="c53" class="frame frame-default frame-type-header frame-layout-0">
|
||||
<a id="c62"></a>
|
||||
<header>
|
||||
<h1>Nunc vel libero dignissim</h1>
|
||||
</header>
|
||||
<p>
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed cursus
|
||||
vel lectus vel placerat. Suspendisse non metus sed lorem sagittis
|
||||
consequat non vel nulla.
|
||||
</p>
|
||||
<p>
|
||||
<a href="#top">Top</a>
|
||||
</p>
|
||||
</div>
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Content elements using lib.stdHeader will miss the header in the frontend output.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that have content elements relying on lib.stdHeader and use
|
||||
Fluid Styled Content as content rendering definition.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
To fully embrace support for Fluid Styled Content the setup needs to be changed.
|
||||
This is a very simple example, it is highly recommended to migrate content
|
||||
elements and plugins to only use fluid. The default fluid layout has all
|
||||
information necessary to render the header, frame and everything else
|
||||
correctly. That means that you do not need to care about streamlined rendering.
|
||||
|
||||
|
||||
Example for Content Element with TypoScript Rendering
|
||||
-----------------------------------------------------
|
||||
|
||||
If you need TypoScript to process the rendering of your content element the
|
||||
recommended way is to use a variable to pass the rendering to fluid.
|
||||
|
||||
|
||||
TypoScript Setup
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.simple_content =< lib.fluidContent
|
||||
tt_content.simple_content {
|
||||
templateName = SimpleContent
|
||||
templateRootPaths.12022017 = EXT:my_simple_content/Resources/Private/Templates/
|
||||
variables.content = COA
|
||||
variables.content {
|
||||
10 = TEXT
|
||||
10.field = bodytext
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Fluid Template
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<html xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers" data-namespace-typo3-fluid="true">
|
||||
<f:layout name="Default" />
|
||||
<f:section name="Main">
|
||||
<f:format.raw>{content}</f:format.raw>
|
||||
</f:section>
|
||||
</html>
|
||||
|
||||
|
||||
Recommended Content Element Rendering
|
||||
-------------------------------------
|
||||
|
||||
It's highly recommended to migrate content elements to embrace fluid and
|
||||
streamline the rendering definitions.
|
||||
|
||||
|
||||
TypoScript Setup
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
tt_content.simple_content =< lib.fluidContent
|
||||
tt_content.simple_content {
|
||||
templateName = SimpleContent
|
||||
templateRootPaths.12022017 = EXT:my_simple_content/Resources/Private/Templates/
|
||||
}
|
||||
|
||||
|
||||
Fluid Template
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<html xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers" data-namespace-typo3-fluid="true">
|
||||
<f:layout name="Default" />
|
||||
<f:section name="Main">
|
||||
<f:format.html>{data.bodytext}</f:format.html>
|
||||
</f:section>
|
||||
</html>
|
||||
|
||||
|
||||
Customize header rendering
|
||||
--------------------------
|
||||
|
||||
Section in the default layout are optional and have fallbacks. To change
|
||||
for example the header rendering, place a `Header` section in a template
|
||||
and place your adjustments. For unsetting the header simply place an empty `Header`
|
||||
section.
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<html xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers" data-namespace-typo3-fluid="true">
|
||||
<f:layout name="Default" />
|
||||
<f:section name="Header">
|
||||
<h1>{data.header}</h1>
|
||||
</f:section>
|
||||
<f:section name="Main">
|
||||
<f:format.html>{data.bodytext}</f:format.html>
|
||||
</f:section>
|
||||
</html>
|
||||
|
||||
|
||||
.. index:: Frontend, TypoScript, ext:fluid_styled_content
|
||||
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-70316:
|
||||
|
||||
===============================================
|
||||
Deprecation: #70316 - Frontend basket with recs
|
||||
===============================================
|
||||
|
||||
See :issue:`70316`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TypoScriptFrontendController has a basic mechanism to automatically register session data if the GET/POST
|
||||
variable :code:`recs` is given. This has been deprecated. This additionally obsoletes the configuration
|
||||
variable :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['maxSessionDataSize']` which has been deprecated, too.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Handling baskets or other session data in :code:`recs` throws a deprecation warning.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Extensions with a legacy that rely on this automatic basket (`tt_products` for example) should be adapted. Searching extensions
|
||||
for string :php:`recs` should reveal affected parts.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use the session functions :php:`setKey()` and :php:`getKey()` of :php:`$GLOBALS['TSFE']->fe_user` directly to store session data
|
||||
like basket information from within the extension.
|
||||
|
||||
.. index:: Frontend, PHP-API
|
||||
@@ -0,0 +1,34 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-77934:
|
||||
|
||||
===========================================================
|
||||
Deprecation: #77934 - Deprecate tt_content field select_key
|
||||
===========================================================
|
||||
|
||||
See :issue:`77934`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The field `select_key` of the table `tt_content` is not used in the core and has been removed.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The field `select_key` is not available by default anymore.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations and extensions using the field `select_key` of the table `tt_content`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Install the extension `compatibility7` to enable the field again.
|
||||
|
||||
.. index:: TCA, Database
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-78225:
|
||||
|
||||
==============================================================
|
||||
Deprecation: #78225 - Legacy PreparedStatements within Extbase
|
||||
==============================================================
|
||||
|
||||
See :issue:`78225`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Extbase has a way to set raw statements with PreparedStatements based on the legacy DatabaseConnection a.k.a. :code:`TYPO3_DB`.
|
||||
This functionality has been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling a query within Extbase with :php:`$query->setStatement($preparedStatement)` using a
|
||||
:php:`\TYPO3\CMS\Core\Database\PreparedStatement` object will trigger a deprecation log entry.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any TYPO3 extension with Extbase functionality using custom prepared statements with the legacy database API.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use the same method :php:`setStatement()` and provide a QueryBuilder object or a Statement object based on Doctrine DBAL.
|
||||
|
||||
.. index:: Database, PHP-API, ext:extbase
|
||||
@@ -0,0 +1,43 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-78477:
|
||||
|
||||
===========================================================
|
||||
Deprecation: #78477 - Refactoring of FlashMessage rendering
|
||||
===========================================================
|
||||
|
||||
See :issue:`78477`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following methods and properties within :php:`FlashMessage::class` have been marked as deprecated:
|
||||
|
||||
* :php:`FlashMessage->classes`
|
||||
* :php:`FlashMessage->icons`
|
||||
* :php:`FlashMessage->getClass()`
|
||||
* :php:`FlashMessage->getIconName()`
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using these properties and methods will stop working in TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using the mentioned methods and properties above.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use the new :php:`FlashMessageRendererResolver::class`, for example:
|
||||
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
GeneralUtility::makeInstance(FlashMessageRendererResolver::class)->resolve()->render()
|
||||
|
||||
.. index:: Backend, PHP-API
|
||||
@@ -0,0 +1,51 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-78899-1668719172:
|
||||
|
||||
========================================
|
||||
Deprecation: #78899 - FormEngine Methods
|
||||
========================================
|
||||
|
||||
See :issue:`78899`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following methods have been marked as deprecated:
|
||||
|
||||
* :code:`TYPO3\CMS\Core\Database\RelationHandler->readyForInterface()`
|
||||
* :code:`TYPO3\CMS\Backend\Form\FormDataProvider->sanitizeMaxItems()`
|
||||
* :code:`TYPO3\CMS\Backend\Utility::getSpecConfParts()`
|
||||
* :code:`TYPO3\CMS\Backend\Controller\Wizard\ColorpickerController` and backend route :code:`wizard_colorpicker`
|
||||
* :code:`TYPO3\CMS\Backend\Form\Wizard\SuggestWizard` and template :code:`typo3/sysext/backend/Resources/Private/Templates/Wizards/SuggestWizard.html`
|
||||
* :code:`TYPO3\CMS\Backend\Form\AbstractNode->getValidationDataAsDataAttribute()`
|
||||
* :code:`TYPO3\CMS\Backend\Form\Element->renderWizards()`
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using above methods will throw a deprecation warning.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Extensions using above methods.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
* :code:`sanitizeMaxItems()` has been merged into calling methods using a default value and sanitizing with :code:`MathUtility::forceIntegerInRange()`.
|
||||
* :code:`readyForInterface()` has been substituted with the easier to parse method :code:`getResolvedItemArray()`.
|
||||
* :code:`getSpecConfParts()` is obsolete with the removal of :code:`defaultExtras` TCA
|
||||
* :code:`ColorpickerController` is obsolete with the JavaScript based colorpicker in the backend
|
||||
* :code:`SuggestWizard` has been merged into :code:`GroupElement` directly, the standalone class is obsolete
|
||||
* :code:`getValidationDataAsDataAttribute()` - use :code:`getValidationDataAsJsonString()` and :code:`htmlspecialchars()` the result or use `GeneralUtility::implodeAttributes()` with second argument set to true.
|
||||
* :code:`renderWizards()` has been substituted with the new API :code:`NodeExpansion`. Old :code:`popup, userFunc, script` wizards are still called and rendered, but the method usage should be avoided and extensions should switch to the new API.
|
||||
|
||||
|
||||
Extensions using above methods should consider to switch away from those methods.
|
||||
|
||||
|
||||
.. index:: Backend, PHP-API
|
||||
@@ -0,0 +1,42 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-78899:
|
||||
|
||||
==========================================================
|
||||
Deprecation: #78899 - TCA ctrl field requestUpdate dropped
|
||||
==========================================================
|
||||
|
||||
See :issue:`78899`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :code:`TCA` :code:`ctrl` configuration option :code:`['ctrl']['requestUpdate']` has been dropped.
|
||||
This option was often used together with :code:`displayCond` fields to re-evaluate display conditions
|
||||
if referenced fields changed their value. Typically, a "Refresh required" popup is raised to the editor
|
||||
in those cases, if the editor did not disable that.
|
||||
The field has been moved and is now located within the :code:`['columns']` section of the single field
|
||||
as :code:`'onChange' => 'reload'`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The field is just moved from :code:`ctrl` section to the single field `columns` section. An automatic
|
||||
TCA migration does that and logs deprecation messages.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All :code:`TCA` tables that use :code:`requestUpdate` in :code:`ctrl` section.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Monitor the deprecation log for according messages, remove the :code:`ctrl` field and
|
||||
add :code:`'onChange' => 'reload'` to fields listed in :code:`requestUpdate` parallel to :code:`label`
|
||||
and :code:`config` section of the field in question. The option can be added to multiple fields.
|
||||
|
||||
.. index:: Backend, PHP-API, TCA
|
||||
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79258:
|
||||
|
||||
===================================================================================================================
|
||||
Deprecation: #79258 - Methods getRecordLocalization() and getPreviousLocalizedRecordUid() in LocalizationRepository
|
||||
===================================================================================================================
|
||||
|
||||
See :issue:`79258`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The methods :php:`LocalizationRepository::getRecordLocalization()` and :php:`LocalizationRepository::getPreviousLocalizedRecordUid()`
|
||||
have been marked as deprecated as they are not used in the core anymore, since https://review.typo3.org/#/c/47645/ was merged.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling these methods will trigger a deprecation log entry. Code using them will work until these methods are removed in TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using the mentioned methods :php:`LocalizationRepository::getRecordLocalization()`
|
||||
and :php:`LocalizationRepository::getPreviousLocalizedRecordUid()`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
No migration available.
|
||||
|
||||
.. index:: PHP-API
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79265:
|
||||
|
||||
===============================================================
|
||||
Deprecation: #79265 - CommandLineController and Cleaner Command
|
||||
===============================================================
|
||||
|
||||
See :issue:`79265`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following PHP classes for using CLI commands without Extbase Command Controllers or native Symfony Commands which
|
||||
were introduced in TYPO3 v4 have been marked as deprecated:
|
||||
|
||||
* `TYPO3\CMS\Core\Controller\CommandLineController`
|
||||
* `TYPO3\CMS\Lowlevel\CleanerCommand`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Instantiating any of the PHP classes above will trigger a deprecation log entry.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
TYPO3 instances with extensions that use the old command line controllers or cleaner commands.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use native Symfony Commands or Extbase Command Controller logic instead for creating CLI-based functionality.
|
||||
|
||||
.. index:: CLI, ext:lowlevel, ext:extbase
|
||||
@@ -0,0 +1,35 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79316:
|
||||
|
||||
=======================================================
|
||||
Deprecation: #79316 - Deprecate ArrayUtility::inArray()
|
||||
=======================================================
|
||||
|
||||
See :issue:`79316`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Deprecate ArrayUtility::inArray()
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling :php:`ArrayUtility::inArray()` method will trigger a deprecation log entry. Code using this method will work until it is removed in TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using the mentioned method :php:`ArrayUtility::inArray()`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use the native :php:`in_array()` function of PHP. It is strongly recommended to ensure the same type is used
|
||||
everywhere and the 3rd parameter of :php:`in_array()` is set to :php:`true` to activate the type check.
|
||||
|
||||
.. index:: PHP-API
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79327:
|
||||
|
||||
===========================================================================
|
||||
Deprecation: #79327 - Deprecate AbstractUserAuthentication::veriCode method
|
||||
===========================================================================
|
||||
|
||||
See :issue:`79327`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :php:`AbstractUserAuthentication::veriCode` method has been marked as deprecated.
|
||||
|
||||
Right now all Backend urls require module token, so veriCode is not needed any more.
|
||||
The Veri token was used as an alternative verification when the JavaScript interface executes cmds to tce_db.php from eg. MSIE 5.0 because the proper referrer is not passed with this browser...
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling :php:`AbstractUserAuthentication::veriCode` will trigger a deprecation log entry.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation having extensions calling :php:`AbstractUserAuthentication::veriCode`
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove calls to `veriCode` or any `vC` HTTP parameter evaluation from your code. Ensure your code uses `moduleToken` to protect backend urls.
|
||||
|
||||
.. index:: Backend, JavaScript, PHP-API
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79341-1668719172:
|
||||
|
||||
===============================================================
|
||||
Deprecation: #79341 - Methods related to richtext configuration
|
||||
===============================================================
|
||||
|
||||
See :issue:`79341`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following methods and method arguments have been deprecated:
|
||||
|
||||
* Method :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getSpecConfParametersFromArray()`
|
||||
* Method :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::RTEsetup()`
|
||||
* Second argument :php:`$specConf` of :php:`\TYPO3\CMS\Core\Html\RteHtmlParser->RTE_transform()`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using above methods or arguments trigger deprecation log entries, the according methods will vanish with TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Loaded extensions using one of the above methods.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
If not otherwise possible, class :php:`\TYPO3\CMS\Core\Configuration\Richtext` can be used to fetch richtext configuration.
|
||||
Be aware this class is marked @internal and is likely to change or vanish in TYPO3 v9 again.
|
||||
|
||||
.. index:: Backend, RTE, PHP-API
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79341:
|
||||
|
||||
=========================================================================
|
||||
Deprecation: #79341 - TCA richtext configuration in defaultExtras dropped
|
||||
=========================================================================
|
||||
|
||||
See :issue:`79341`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Enabling richtext rendering for fields in the Backend record editor has been simplified.
|
||||
|
||||
In the past, a typical :php:`TCA` configuration of a richtext field looked like:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'columns' => [
|
||||
'content' => [
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
],
|
||||
'defaultExtras' => 'richtext:rte_transform',
|
||||
],
|
||||
];
|
||||
|
||||
The :php:`defaultExtras` is obsolete and substituted with :php:`enableRichtext` within the :php:`config` section:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'columns' => [
|
||||
'content' => [
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
'enableRichtext' => true,
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
|
||||
If the RTE was enabled for a specific type only, it looked like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'columns' => [
|
||||
'content' => [
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
],
|
||||
],
|
||||
],
|
||||
'types' => [
|
||||
'myType' => [
|
||||
'columnsOverrides' => [
|
||||
'aField' => [
|
||||
'defaultExtras' => 'richtext:rte_transform',
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
This is now:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'columns' => [
|
||||
'content' => [
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
],
|
||||
],
|
||||
],
|
||||
'types' => [
|
||||
'myType' => [
|
||||
'columnsOverrides' => [
|
||||
'aField' => [
|
||||
'config' => [
|
||||
'enableRichtext' => true,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using defaultExtras to enable richtext editor will stop working in TYPO3 v9. An automatic :php:`TCA` migration
|
||||
transfers to the new syntax in TYPO3 v8 and logs deprecations.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations using :php:`defaultExtras` for richtext configuration.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Remove the defaultExtras line and set :php:`'enableRichtext' => true,` within the config section of the field.
|
||||
This is allowed in :php:`columnsOverrides` for specific record types, too.
|
||||
|
||||
.. index:: Backend, FlexForm, RTE, TCA
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79364:
|
||||
|
||||
===============================================================
|
||||
Deprecation: #79364 - Deprecate members in PageLayoutController
|
||||
===============================================================
|
||||
|
||||
See :issue:`79364`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Deprecate the members :php:`\TYPO3\CMS\Backend\Controller\PageLayoutController::edit_record`
|
||||
and :php:`\TYPO3\CMS\Backend\Controller\PageLayoutController::new_unique_uid`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Installation of EXT:compatibility7 is required to continue using this members until they are removed in TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using the mentioned members :php:`\TYPO3\CMS\Backend\Controller\PageLayoutController::edit_record`
|
||||
and :php:`\TYPO3\CMS\Backend\Controller\PageLayoutController::new_unique_uid`.
|
||||
|
||||
.. index:: PHP-API, Backend
|
||||
@@ -0,0 +1,782 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79440:
|
||||
|
||||
=================================
|
||||
Deprecation: #79440 - TCA Changes
|
||||
=================================
|
||||
|
||||
See :issue:`79440`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :code:`TCA` on field level has been changed. Nearly all column types are affected.
|
||||
In general, the sub-section :code:`wizards` is gone and replaced by a combination of new
|
||||
:code:`renderType's` and a new set of configuration options. Wizards are now divided into
|
||||
three different kinds:
|
||||
|
||||
* :code:`fieldInformation` - Informational HTML, typically displayed between the element label
|
||||
and the element itself.
|
||||
* :code:`fieldControl` - Icons, typically displayed right next to the element, used to trigger
|
||||
certain actions, for instance to jump to the link view.
|
||||
* :code:`fieldWizard` - HTML typically shown below the element to enrich the element with further
|
||||
functionality. Example is the rendering of thumbnails below a type=group element.
|
||||
|
||||
Other wizards like the "suggest" functionality have been merged into the affected elements itself.
|
||||
|
||||
Additionally, the config option :code:`defaultExtras`, which was often set within :code:`columnsOverrides` has
|
||||
been removed. The options were transferred to config options of the elements itself and can be set
|
||||
within :code:`columnsOverrides` directly.
|
||||
|
||||
A :code:`TCA` migration transforms old configuration options to new ones and throws descriptive log entries.
|
||||
|
||||
The first list covers all former existing wizards and shows where and how the functionality is now placed.
|
||||
|
||||
The second list below gives examples from before and after based on :code:`type`, together with detail
|
||||
information on certain configuration options.
|
||||
|
||||
|
||||
Wizard list
|
||||
-----------
|
||||
|
||||
|
||||
Add wizard, edit wizard and list wizard
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The three wizards :code:`wizard_add`, :code:`wizard_edit` and :code:`wizard_list` usually used in :code:`type=group`
|
||||
and :code:`type=select` with :code:`renderType=selectMultipleSideBySide` are now default controls of these two elements
|
||||
and just need to be enabled. :code:`options` are optional, the render engine selects a fallback title, a default pid and
|
||||
table name if needed.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'wizards' => [
|
||||
'_VERTICAL' => 1,
|
||||
'edit' => [
|
||||
'type' => 'popup',
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_tca.xlf:be_users.usergroup_edit_title',
|
||||
'module' => [
|
||||
'name' => 'wizard_edit',
|
||||
'popup_onlyOpenIfSelected' => true,
|
||||
'icon' => 'actions-open',
|
||||
'JSopenParams' => 'width=800,height=600,status=0,menubar=0,scrollbars=1'
|
||||
],
|
||||
'add' => [
|
||||
'type' => 'script',
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_tca.xlf:be_users.usergroup_add_title',
|
||||
'icon' => 'actions-add',
|
||||
'params' => [
|
||||
'table' => 'be_groups',
|
||||
'pid' => 0,
|
||||
'setValue' => 'prepend'
|
||||
],
|
||||
'module' => [
|
||||
'name' => 'wizard_add'
|
||||
]
|
||||
],
|
||||
'list' => [
|
||||
'type' => 'script',
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_tca.xlf:be_users.usergroup_list_title',
|
||||
'icon' => 'actions-system-list-open',
|
||||
'params' => [
|
||||
'table' => 'be_groups',
|
||||
'pid' => 0
|
||||
],
|
||||
'module' => [
|
||||
'name' => 'wizard_list'
|
||||
]
|
||||
]
|
||||
]
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'fieldControl' => [
|
||||
'editPopup' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
'addRecord' => [
|
||||
'disabled' => false,
|
||||
'options' => [
|
||||
'setValue' => 'prepend',
|
||||
],
|
||||
'listModule' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Color picker
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The color picker wizard has been changed to :code:`type=input` element with :code:`renderType=colorpicker`
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_34' => [
|
||||
'label' => 'input_34',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'wizards' => [
|
||||
'colorChoice' => [
|
||||
'type' => 'colorbox',
|
||||
'title' => 'LLL:EXT:examples/Resources/Private/Language/locallang_db.xlf:tx_examples_haiku.colorPick',
|
||||
'module' => [
|
||||
'name' => 'wizard_colorpicker',
|
||||
],
|
||||
'JSopenParams' => 'height=600,width=380,status=0,menubar=0,scrollbars=1',
|
||||
'exampleImg' => 'EXT:examples/res/images/japanese_garden.jpg',
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_34' => [
|
||||
'label' => 'input_34',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'renderType' => 'colorpicker',
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Table wizard
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The table wizard has been embedded in :code:`type=text` element with :code:`renderType=textTable`
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'text_17' => [
|
||||
'label' => 'text_17',
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
'cols' => '40',
|
||||
'rows' => '5',
|
||||
'wizards' => [
|
||||
'table' => [
|
||||
'notNewRecords' => 1,
|
||||
'type' => 'script',
|
||||
'title' => 'LLL:EXT:cms/locallang_ttc.xlf:bodytext.W.table',
|
||||
'icon' => 'content-table',
|
||||
'module' => [
|
||||
'name' => 'wizard_table'
|
||||
],
|
||||
'params' => [
|
||||
'xmlOutput' => 0
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'text_17' => [
|
||||
'label' => 'text_17',
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
'renderType' => 'textTable',
|
||||
'cols' => '40',
|
||||
'rows' => '5',
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
RTE wizard
|
||||
^^^^^^^^^^
|
||||
|
||||
The RTE wizard that jumps to a full screen view of a text field has been embedded into `EXT:rtehtmlarea`
|
||||
directly and just needs to be turned on. This additionally obsoletes the :code:`defaultExtras=rte_only` setting.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'rte_1' => [
|
||||
'label' => 'rte_1',
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
'enableRichtext' => true,
|
||||
'RTE' => [
|
||||
'notNewRecords' => 1,
|
||||
'RTEonly' => 1,
|
||||
'type' => 'script',
|
||||
'title' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:bodytext.W.RTE',
|
||||
'icon' => 'actions-wizard-rte',
|
||||
'module' => [
|
||||
'name' => 'wizard_rte'
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'rte_1' => [
|
||||
'label' => 'rte_1',
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
'enableRichtext' => true,
|
||||
'fieldControl' => [
|
||||
'fullScreenRichtext' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Link browser
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The link browser icon wizard has been embedded in new :code:`'renderType' => 'inputLink'` directly. The parameters
|
||||
:code:`blindLinkOptions`, :code:`blindLinkFields` and :code:`allowedExtensions` are now all optional and options of
|
||||
section :code:`fieldControl`.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_29' => [
|
||||
'label' => 'input_29 link',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'wizards' => [
|
||||
'link' => [
|
||||
'type' => 'popup',
|
||||
'title' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:header_link_formlabel',
|
||||
'icon' => 'actions-wizard-link',
|
||||
'module' => [
|
||||
'name' => 'wizard_link',
|
||||
],
|
||||
'JSopenParams' => 'height=800,width=600,status=0,menubar=0,scrollbars=1',
|
||||
'params' => [
|
||||
'blindLinkOptions' => 'folder',
|
||||
'blindLinkFields' => 'class, target',
|
||||
'allowedExtensions' => 'jpg',
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_29' => [
|
||||
'label' => 'input_29',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'renderType' => 'inputLink',
|
||||
'fieldControl' => [
|
||||
'linkPopup' => [
|
||||
'options' => [
|
||||
'blindLinkOptions' => 'folder',
|
||||
'blindLinkFields' => 'class, target',
|
||||
'allowedExtensions' => 'jpg',
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Select wizard
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The select wizard has been directly embedded in :code:`type=input` and :code:`type=text` elements, only works with
|
||||
a static list of items and is called :code:`valuePicker`.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_33' => [
|
||||
'label' => 'input_33',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'wizards' => [
|
||||
'select' => [
|
||||
'items' => [
|
||||
[ 'spring', 'Spring', ],
|
||||
[ 'summer', 'Summer', ],
|
||||
[ 'autumn', 'Autumn', ],
|
||||
[ 'winter', 'Winter', ],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_33' => [
|
||||
'label' => 'input_33',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'valuePicker' => [
|
||||
'items' => [
|
||||
[ 'spring', 'Spring', ],
|
||||
[ 'summer', 'Summer', ],
|
||||
[ 'autumn', 'Autumn', ],
|
||||
[ 'winter', 'Winter', ],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Suggest wizard
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
The suggest wizard has been directly embedded in :code:`type=group` element and is enabled by default. It
|
||||
can be disabled by setting :code:`hideSuggest=true` in config section and suggest options can be added in
|
||||
:code:`suggestOptions`.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'group_db_8' => [
|
||||
'label' => 'group_db_8',
|
||||
'config' => [
|
||||
'type' => 'group',
|
||||
'internal_type' => 'db',
|
||||
'allowed' => 'tx_styleguide_staticdata',
|
||||
'wizards' => [
|
||||
'_POSITION' => 'top',
|
||||
'suggest' => [
|
||||
'type' => 'suggest',
|
||||
'default' => [
|
||||
'pidList' => 42,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'group_db_8' => [
|
||||
'label' => 'group_db_8',
|
||||
'config' => [
|
||||
'type' => 'group',
|
||||
'internal_type' => 'db',
|
||||
'allowed' => 'tx_styleguide_staticdata',
|
||||
'suggestOptions' => [
|
||||
'default' => [
|
||||
'pidList' => 42,
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Slider wizard
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The slider wizard has been embedded in :code:`type=text` as option :code:`slider` within the
|
||||
config section.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_30' => [
|
||||
'label' => 'input_30',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'size' => 5,
|
||||
'eval' => 'trim,int',
|
||||
'range' => [
|
||||
'lower' => -90,
|
||||
'upper' => 90,
|
||||
],
|
||||
'default' => 0,
|
||||
'wizards' => [
|
||||
'angle' => [
|
||||
'type' => 'slider',
|
||||
'step' => 10,
|
||||
'width' => 200,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'input_30' => [
|
||||
'label' => 'input_30',
|
||||
'config' => [
|
||||
'type' => 'input',
|
||||
'size' => 5,
|
||||
'eval' => 'trim,int',
|
||||
'range' => [
|
||||
'lower' => -90,
|
||||
'upper' => 90,
|
||||
],
|
||||
'default' => 0,
|
||||
'slider' => [
|
||||
'step' => 10,
|
||||
'width' => 200,
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
|
||||
Type list
|
||||
---------
|
||||
|
||||
type=input
|
||||
^^^^^^^^^^
|
||||
|
||||
* The wizard :code:`slider` has been directly embedded in this element. The new config option :code:`slider`
|
||||
can be used to configure the slider. The slider appears if the option :code:`slider` exists and is an array.
|
||||
* The wizard :code:`select` has been directly embedded in this element. The new config option :code:`valuePicker`
|
||||
has been introduced to configure items of the drop down.
|
||||
* The four date related :code:`eval` options :code:`date`, :code:`datetime`, :code:`time` and :code:`timesec` have
|
||||
been moved to :code:`renderType=inputDateTime`.
|
||||
* The wizard :code:`wizard_link` has been removed a field now displays the link wizard by setting :code:`renderType=inputLink`
|
||||
for a :code:`type=input` element.
|
||||
|
||||
|
||||
type=text
|
||||
^^^^^^^^^
|
||||
|
||||
* The wizard :code:`select` has been directly embedded in this element. The new config option :code:`valuePicker`
|
||||
has been introduced to configure items of the drop down.
|
||||
* The wizard :code:`wizard_table` has been given the own :code:`renderType=textTable`.
|
||||
* The wizard :code:`RTE` has been changed to a `fieldControl` of the richtext element implemented by
|
||||
extension `rtehtmlarea`.
|
||||
* :code:`defaultExtras=enable-tab` has been moved to config option :code:`enableTabulator`
|
||||
* :code:`defaultExtrasfixed-font` has been moved to config option :code:`fixedFont`
|
||||
* :code:`defaultExtras=nowrap` has been moved to config option :code:`wrap=off`
|
||||
|
||||
|
||||
type=select with renderType=selectSingle
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Config option :code:`showIconTable` has been dropped. Showing assigned images below the select field has
|
||||
been migrated to a :code:`fieldWizard` and is disabled by default.
|
||||
* Config option :code:`selicon_cols` has been dropped without substitution, the render engine now shows as
|
||||
many images in a row as fit into the view.
|
||||
|
||||
Example to enable the icon display:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'select_single_5' => [
|
||||
'label' => 'select_single_5',
|
||||
'config' => [
|
||||
'type' => 'select',
|
||||
'renderType' => 'selectSingle',
|
||||
'items' => [
|
||||
['foo 1', 'foo1', 'EXT:styleguide/Resources/Public/Icons/tx_styleguide.svg'],
|
||||
['foo 2', 'foo2', 'EXT:styleguide/Resources/Public/Icons/tx_styleguide.svg'],
|
||||
],
|
||||
'fieldWizard' => [
|
||||
'selectIcons' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
type=select with renderType=multipleSideBySide
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Configuration option changes of the :code:`renderType=multipleSideBySide` element are similar to
|
||||
the :code:`type=group` changes. In detail, the following changes have been applied:
|
||||
|
||||
* Config option :code:`selectedListStyle` has been dropped without substitution.
|
||||
* Wizards :code:`wizard_add`, :code:`wizard_edit` and :code:`wizard_list` have been changed to :code:`fieldControl`
|
||||
and must be enabled per element. All options are still valid, but the system tries to determine sane fallback
|
||||
values if no options are given. For example, the `table` option of :code:`wizard_add` and :code:`wizard_list`
|
||||
fall back to the value of :code:`foreign_table` if not explicitly given.
|
||||
|
||||
Example configuration of a multipleSideBySide field before change:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'select_multiplesidebyside_6' => [
|
||||
'exclude' => 1,
|
||||
'label' => 'select_multiplesidebyside_6',
|
||||
'config' => [
|
||||
'type' => 'select',
|
||||
'renderType' => 'selectMultipleSideBySide',
|
||||
'foreign_table' => 'tx_styleguide_staticdata',
|
||||
'rootLevel' => 1,
|
||||
'size' => 5,
|
||||
'autoSizeMax' => 20,
|
||||
'wizards' => [
|
||||
'_VERTICAL' => 1,
|
||||
'edit' => [
|
||||
'type' => 'popup',
|
||||
'title' => 'edit',
|
||||
'module' => [
|
||||
'name' => 'wizard_edit',
|
||||
],
|
||||
'icon' => 'actions-open',
|
||||
'popup_onlyOpenIfSelected' => 1,
|
||||
'JSopenParams' => 'height=350,width=580,status=0,menubar=0,scrollbars=1',
|
||||
],
|
||||
'add' => [
|
||||
'type' => 'script',
|
||||
'title' => 'add',
|
||||
'icon' => 'actions-add',
|
||||
'module' => [
|
||||
'name' => 'wizard_add',
|
||||
],
|
||||
'params' => [
|
||||
'table' => 'tx_styleguide_staticdata',
|
||||
'pid' => '0',
|
||||
'setValue' => 'prepend',
|
||||
],
|
||||
],
|
||||
'list' => [
|
||||
'type' => 'script',
|
||||
'title' => 'list',
|
||||
'icon' => 'actions-system-list-open',
|
||||
'module' => [
|
||||
'name' => 'wizard_list',
|
||||
],
|
||||
'params' => [
|
||||
'table' => 'tx_styleguide_staticdata',
|
||||
'pid' => '0',
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'select_multiplesidebyside_6' => [
|
||||
'exclude' => 1,
|
||||
'label' => 'select_multiplesidebyside_6 wizards',
|
||||
'config' => [
|
||||
'type' => 'select',
|
||||
'renderType' => 'selectMultipleSideBySide',
|
||||
'foreign_table' => 'tx_styleguide_staticdata',
|
||||
'rootLevel' => 1,
|
||||
'size' => 5,
|
||||
'autoSizeMax' => 20,
|
||||
'fieldControl' => [
|
||||
'editPopup' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
'addRecord' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
'listModule' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
type=group
|
||||
^^^^^^^^^^
|
||||
|
||||
This element got most changes in this series. A number of options have been fine-tuned
|
||||
and got better default values:
|
||||
|
||||
* Similar to :code:`type=select` with :code:`type=multipleSideBySide`, the three wizards
|
||||
:code:`wizard_add`, :code:`wizard_edit` and :code:`wizard_list` have been changed to :code:`fieldControl`
|
||||
and are disabled by default.
|
||||
* Config option :code:`selectedListStyle` has been dropped without substitution.
|
||||
* The suggest wizard has been directly embedded in :code:`type=group` and has been enabled by default for
|
||||
:code:`internal_type=db` elements. It can be disabled with :code:`hideSuggest=true` and options of the
|
||||
`suggest` can be hand over in config option :code:`suggestOptions`.
|
||||
* The config option :code:`show_thumbs` showed two different things in the past: With :code:`internal_type=db`, it
|
||||
displayed the list of selected records as a table below the element, with :code:`internal_type=file` it rendered
|
||||
thumbnails of selected files and displayed the below the element. :code:`show_thumbs` has been dropped, the
|
||||
functionality has been transferred to :code:`fieldWizard` as :code:`recordsOverview` and :code:`fileThumbnails`
|
||||
respectively and are enabled by default. They can be disabled by setting `disabled=true`.
|
||||
* The config option :code:`disable_controls` has been obsoleted, single parts of the group element can be disabled
|
||||
by adding :code:`disabled=true` to the according :code:`fieldControl` or :code:`fieldWizard`.
|
||||
|
||||
|
||||
Example of a typical group field before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'group_db_1' => [
|
||||
'label' => 'group_db_1',
|
||||
'config' => [
|
||||
'type' => 'group',
|
||||
'internal_type' => 'db',
|
||||
'allowed' => 'be_users,be_groups',
|
||||
'wizards' => [
|
||||
'edit' => [
|
||||
'type' => 'popup',
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_core.xlf:labels.edit',
|
||||
'module' => [
|
||||
'name' => 'wizard_edit',
|
||||
],
|
||||
'popup_onlyOpenIfSelected' => 1,
|
||||
'icon' => 'actions-open',
|
||||
'JSopenParams' => 'height=350,width=580,status=0,menubar=0,scrollbars=1'
|
||||
],
|
||||
'add' => [
|
||||
'type' => 'script',
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_core.xlf:labels.createNewPage',
|
||||
'icon' => 'actions-add',
|
||||
'params' => [
|
||||
'table' => 'be_users',
|
||||
'pid' => 0,
|
||||
'setValue' => 'append'
|
||||
],
|
||||
'module' => [
|
||||
'name' => 'wizard_add'
|
||||
],
|
||||
],
|
||||
'list' => [
|
||||
'type' => 'script',
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_core.xlf:labels.list',
|
||||
'icon' => 'actions-system-list-open',
|
||||
'params' => [
|
||||
'table' => 'be_groups',
|
||||
'pid' => '0'
|
||||
],
|
||||
'module' => [
|
||||
'name' => 'wizard_list'
|
||||
]
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'group_db_1' => [
|
||||
'label' => 'group_db_1',
|
||||
'config' => [
|
||||
'type' => 'group',
|
||||
'internal_type' => 'db',
|
||||
'allowed' => 'be_users,be_groups',
|
||||
'fieldControl' => [
|
||||
'editPopup' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
'addRecord' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
'listModule' => [
|
||||
'renderType' => 'listModule',
|
||||
'options' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Disable other parts of type=group:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'group_db_1' => [
|
||||
'label' => 'group_db_1',
|
||||
'config' => [
|
||||
'type' => 'group',
|
||||
'internal_type' => 'db',
|
||||
'allowed' => 'be_users,be_groups',
|
||||
'fieldControl' => [
|
||||
// Disable element browser icon
|
||||
'elementBrowser' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
// Disable insert from clipboard icon
|
||||
'insertClipboard' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
],
|
||||
'fieldWizard => [
|
||||
// Disable button list of allowed tables
|
||||
'tableList' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
// Disable list of allowed file types
|
||||
'fileTypeList' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
// Disable thumbnail view of selected files
|
||||
'fileThumbnails' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
// Disable table view of selected records
|
||||
'recordsOverview' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
// Disable direct file upload button
|
||||
'fileUpload' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using old TCA settings as outlined above will throw a deprecation warnings.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Most installations are affected by this change.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
An automatic TCA migration transfers from old TCA settings to new ones and throws deprecation log entries with
|
||||
hints which changes should be incorporated. For flex form data structure definitions, the TCA migration is called
|
||||
when opening an according record and logs, too.
|
||||
|
||||
.. index:: Backend, TCA, RTE
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79441:
|
||||
|
||||
==================================================================
|
||||
Deprecation: #79441 - Deprecate visibility internal caching arrays
|
||||
==================================================================
|
||||
|
||||
See :issue:`79441`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following variables have been marked as deprecated in
|
||||
DataHandler since their visibility will change from public to
|
||||
protected or even be replaced by a run-time cache.
|
||||
The documentation states that these are "internal-cache"
|
||||
variables and hence the visibility public is misleading.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
public $recUpdateAccessCache = [];
|
||||
public $recInsertAccessCache = [];
|
||||
public $isRecordInWebMount_Cache = [];
|
||||
public $isInWebMount_Cache = [];
|
||||
public $cachedTSconfig = [];
|
||||
public $pageCache = [];
|
||||
|
||||
|
||||
The following variable has been marked as deprecated in the
|
||||
DataHandler since it is not referenced in the class.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
public $checkWorkspaceCache = [];
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
These variables should not be accessed in DataHandler from outside
|
||||
the class since their visibility or even implementation will
|
||||
change with TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Extensions using one of the above variables.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
None - since public internal
|
||||
|
||||
.. index:: PHP-API, Backend
|
||||
@@ -0,0 +1,28 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79560:
|
||||
|
||||
============================================================
|
||||
Deprecation: #79560 - Deprecate ClientUtility::getDeviceType
|
||||
============================================================
|
||||
|
||||
See :issue:`79560`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The method :php:`\TYPO3\CMS\Core\Utility\ClientUtility::getDeviceType` is not used and completely outdated and has been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Calling :php:`\TYPO3\CMS\Core\Utility\ClientUtility::getDeviceType` method will trigger a deprecation log entry. Code using this method will work until it is removed in TYPO3 v9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Any installation using the mentioned method :php:`\TYPO3\CMS\Core\Utility\ClientUtility::getDeviceType`.
|
||||
|
||||
.. index:: PHP-API
|
||||
@@ -0,0 +1,40 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79622:
|
||||
|
||||
=======================================================
|
||||
Deprecation: #79622 - Deprecation of CSS Styled Content
|
||||
=======================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
CSS Styled Content has been the preferred way of rendering
|
||||
content in the frontend for a long time. Fluid Styled Content has been introduced as
|
||||
successor of CSC, but the feature set diverged from the beginning. The
|
||||
lack of flexibility and incomplete feature set in comparison to CSC made
|
||||
it hard to migrate existing instances.
|
||||
|
||||
Since TYPO3 CMS 7.6 Fluid-Templates are the defined standard and
|
||||
official recommendation for content rendering. The feature set of FSC is
|
||||
now matching CSC. Both content renderings are now streamlined to be fully
|
||||
compatible with each other. For the period of CMS 8 CSC will share
|
||||
the same capabilities to make a transition as easy as possible. CSC is
|
||||
now deprecated and goes into maintenance mode and will be removed with
|
||||
CMS 9.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All installations that still use or rely on the content rendering of `css_styled_content`.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Create a custom content rendering definition or switch to a maintained one like `fluid_styled_content`.
|
||||
|
||||
.. index:: Frontend, ext:css_styled_content
|
||||
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-79658:
|
||||
|
||||
============================================================
|
||||
Deprecation: #79658 - PageRepository shouldFieldBeOverlaid()
|
||||
============================================================
|
||||
|
||||
See :issue:`79658`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The following method has been deprecated:
|
||||
|
||||
* :code:`TYPO3\CMS\Frontend\Page\PageRepository->shouldFieldBeOverlaid()`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Localized record fields are always "overlaid", the method returns true in all cases.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Instances with extensions calling this method
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
The deprecated method returns TRUE in all cases, the call can be omitted.
|
||||
|
||||
.. index:: Frontend, PHP-API
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-12211:
|
||||
|
||||
================================================================================
|
||||
Feature: #12211 - Usability: Scheduler provide page browser to choose start page
|
||||
================================================================================
|
||||
|
||||
See :issue:`12211`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
To improve the usability of the linkvalidator scheduler task, the page browser is provided to choose the start page.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Scheduler tasks that need a page `uid` can now add a button for the page browser popup.
|
||||
|
||||
In the `ValidatorTaskAdditionalFieldProvider` two additional fields have to be added.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'browser' => 'page',
|
||||
|
||||
If the additional field `browser` is set to `page` then the `SchedulerModuleController` adds a button for calling the page browser popup to the field.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'pageTitle' => $pageTitle,
|
||||
|
||||
The `pageTitle` contains the title of the page that is shown next to the browse button.
|
||||
|
||||
.. index:: ext:scheduler, Backend
|
||||
@@ -0,0 +1,24 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-28171:
|
||||
|
||||
===================================================
|
||||
Feature: #28171 - Improved link field in FormEngine
|
||||
===================================================
|
||||
|
||||
See :issue:`28171`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The handling of link fields when managing records has been improved and now shows a human readable string,
|
||||
an icon and an additional help text instead of the cryptic :code:`t3://` syntax. This is enabled
|
||||
by default for all :code:`renderType="inputLink"` elements.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Better UX of link fields in the Backend
|
||||
|
||||
.. index:: Backend, TCA
|
||||
@@ -0,0 +1,18 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-45537:
|
||||
|
||||
==============================================================
|
||||
Feature: #45537 - Run manually executed tasks on next cron-run
|
||||
==============================================================
|
||||
|
||||
See :issue:`45537`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
There is a new action icon to mark a task to be run by cron.
|
||||
Also a new button "Execute selected tasks on next cron job"
|
||||
has been added to mark all selected actions to be run by next cron job.
|
||||
|
||||
.. index:: Backend, ext:scheduler
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-47006:
|
||||
|
||||
=================================================================
|
||||
Feature: #47006 - Extend the widget identifier with custom string
|
||||
=================================================================
|
||||
|
||||
See :issue:`47006`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The parameter `customWidgetId` has been introduced for fluid widgets. This string is used in the widget identifier
|
||||
in addition to the `nextWidgetNumber`.
|
||||
|
||||
The widget identifier is used to create the GET parameter names.
|
||||
|
||||
A good value for the `customWidgetId` is the {contentObjectData.uid} to ensure no collisions happen.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
<f:widget.paginate customWidgetId="{contentObjectData.uid}" ...></f:widget.paginate>
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Allows to use the same fluid widget more than once on one page in different content elements.
|
||||
|
||||
.. index:: Fluid
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-47135:
|
||||
|
||||
=============================================================================
|
||||
Feature: #47135 - Paste icons available at pasting position and use modal now
|
||||
=============================================================================
|
||||
|
||||
See :issue:`47135`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
As soon as the normal clipboard contains an item, a single paste icon becomes available in the page module.
|
||||
The icon is located at each possible pasting position directly besides the [content +] buttons.
|
||||
When the user clicks on the icon, a modal pops up to have the user confirm the action.
|
||||
Depending on the clipboard mode this will either be "Copy" or "Move" together with the title of the item in the clipboard and a "Cancel" button.
|
||||
|
||||
.. index:: Backend, JavaScript
|
||||
@@ -0,0 +1,17 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-67243:
|
||||
|
||||
============================================================
|
||||
Feature: #67243 - Implement folding of scheduler task groups
|
||||
============================================================
|
||||
|
||||
See :issue:`67243`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When task groups are used, the tasks are displayed grouped in the list of tasks.
|
||||
Clicking on the row with the group title hides or shows the tasks of the group now.
|
||||
|
||||
.. index:: Backend, ext:scheduler
|
||||
@@ -0,0 +1,23 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-69572:
|
||||
|
||||
================================================================
|
||||
Feature: #69572 - Page module Notice "Content is also shown on:"
|
||||
================================================================
|
||||
|
||||
See :issue:`69572`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When page content is inherited from a different page via "Show content from page" there is a notice displayed on the page that is pulling in content from a different page.
|
||||
|
||||
As of now, the page whose content is used on other pages gets an info box that indicates which other pages use these contents.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
On pages that are inherited elsewhere you see a notice which links to the pages where the content is inherited.
|
||||
|
||||
.. index:: Backend
|
||||
@@ -0,0 +1,56 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-70316:
|
||||
|
||||
=====================================================
|
||||
Feature: #70316 - Introduce Session Storage Framework
|
||||
=====================================================
|
||||
|
||||
See :issue:`70316`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new session storage framework has been introduced. The goal of this framework is to create interoperability
|
||||
between different session storages (called "backends") like database, file storage, Redis, etc.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
An integrator may configure session backends based on :php:`TYPO3_MODE`, which is either `BE` or `FE`.
|
||||
|
||||
The following session backends are available by default:
|
||||
|
||||
- :php:`\TYPO3\CMS\Core\Session\Backend\DatabaseSessionBackend`
|
||||
- :php:`\TYPO3\CMS\Core\Session\Backend\RedisSessionBackend`
|
||||
|
||||
The default session backend for `BE` and `FE` is :php:`DatabaseSessionBackend` with `table` set to `fe_sessions` and `be_sessions` respectively.
|
||||
|
||||
The configuration of the backend for each :php:`TYPO3_MODE` is stored within `SYS/session`:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'SYS' => [
|
||||
'session' => [
|
||||
'BE' => [
|
||||
'backend' => \TYPO3\CMS\Core\Session\Backend\RedisSessionBackend::class,
|
||||
'options' => [
|
||||
'hostname' => 'localhost',
|
||||
'database' => 2
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
The :php:`DatabaseSessionBackend` requires a `table` as option. If the backend is used to holds non-authenticated
|
||||
sessions (default for `FE`), the `has_anonymous` option must be set to true.
|
||||
|
||||
The :php:`RedisSessionBackend` requires a running PHP redis module (PHP extension "redis") and a running redis service.
|
||||
By default, a connection will be made to `hostname` 127.0.0.1 and `port` 6379. You may also specify a `database`
|
||||
number which to store the sessions in (default database is 0) and a `password` for the connection.
|
||||
|
||||
A developer may implement a custom session backend. To achieve this, the interface
|
||||
:php:`\TYPO3\CMS\Core\Session\Backend\SessionBackendInterface` has to be implemented.
|
||||
|
||||
.. index:: PHP-API
|
||||
@@ -0,0 +1,40 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-72749:
|
||||
|
||||
============================================
|
||||
Feature: #72749 - CLI support for T3D import
|
||||
============================================
|
||||
|
||||
See :issue:`72749`
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
EXT:impexp now allows to import data files (T3D or XML) via the command line interface through a Symfony
|
||||
Command.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The command line allows the following options:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
Imports a T3D file into a page.
|
||||
|
||||
USAGE:
|
||||
./typo3/sysext/core/bin/typo3 impexp:import [<options>] <file> <pageId>
|
||||
|
||||
ARGUMENTS:
|
||||
--file The path / filename to import (.t3d or .xml), the EXT: syntax can be used as well
|
||||
--pageId The page id where the page should be started from, defaults to "0" if not set
|
||||
|
||||
OPTIONS:
|
||||
--updateRecords Force updating existing records
|
||||
--ignorePid Don't correct page ids of updated records
|
||||
--enableLog log all database action
|
||||
|
||||
.. index:: CLI, ext:impexp
|
||||
+219
@@ -0,0 +1,219 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-75880:
|
||||
|
||||
=================================================================================
|
||||
Feature: #75880 - Implement multiple cropping variants in image manipulation tool
|
||||
=================================================================================
|
||||
|
||||
See :issue:`75880`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The `imageManipulation` TCA type is now capable to handle multiple crop variants if configured.
|
||||
|
||||
The default configuration is to have only one variant with the same possible aspect ratios
|
||||
like in older TYPO3 versions.
|
||||
|
||||
For that the TCA configuration has been extended.
|
||||
The following example configures two crop variants, one with the id "mobile",
|
||||
one with the id "desktop". The array key defines the crop variant id, which will be used
|
||||
when rendering an image with the image view helper.
|
||||
|
||||
The allowed crop areas are now also configured differently.
|
||||
The array key is used as identifier for the ratio and the label is specified with the "title"
|
||||
and the actual (floating point) ratio with the "value" key.
|
||||
The value **should** be of PHP type float, not only a string.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'config' => [
|
||||
'type' => 'imageManipulation',
|
||||
'cropVariants' => [
|
||||
'mobile' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.mobile',
|
||||
'allowedAspectRatios' => [
|
||||
'4:3' => [
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_wizards.xlf:imwizard.ratio.4_3',
|
||||
'value' => 4 / 3
|
||||
],
|
||||
'NaN' => [
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_wizards.xlf:imwizard.ratio.free',
|
||||
'value' => 0.0
|
||||
],
|
||||
],
|
||||
],
|
||||
'desktop' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.desktop',
|
||||
'allowedAspectRatios' => [
|
||||
'4:3' => [
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_wizards.xlf:imwizard.ratio.4_3',
|
||||
'value' => 4 / 3
|
||||
],
|
||||
'NaN' => [
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_wizards.xlf:imwizard.ratio.free',
|
||||
'value' => 0.0
|
||||
],
|
||||
],
|
||||
],
|
||||
]
|
||||
]
|
||||
|
||||
|
||||
It is now also possible to define an initial crop area. If no initial crop area is defined, the default selected crop area will cover the complete image.
|
||||
Crop areas are defined relatively with floating point numbers. The x and y coordinates and width and height must be specified for that.
|
||||
The below example has an initial crop area in the size the previous image cropper provided by default.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'config' => [
|
||||
'type' => 'imageManipulation',
|
||||
'cropVariants' => [
|
||||
'mobile' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.mobile',
|
||||
'cropArea' => [
|
||||
'x' => 0.1,
|
||||
'y' => 0.1,
|
||||
'width' => 0.8,
|
||||
'height' => 0.8,
|
||||
],
|
||||
],
|
||||
],
|
||||
]
|
||||
|
||||
Users can also select a focus area, when configured. The focus area is always **inside**
|
||||
the crop area and mark the area in the image which must be visible for the image to transport
|
||||
its meaning. The selected area is persisted to the database but will have no effect on image processing.
|
||||
The data points are however made available as data attribute when using the `<f:image />` view helper.
|
||||
|
||||
The below example adds a focus area, which is initially one third of the size of the image
|
||||
and centered.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'config' => [
|
||||
'type' => 'imageManipulation',
|
||||
'cropVariants' => [
|
||||
'mobile' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.mobile',
|
||||
'focusArea' => [
|
||||
'x' => 1 / 3,
|
||||
'y' => 1 / 3,
|
||||
'width' => 1 / 3,
|
||||
'height' => 1 / 3,
|
||||
],
|
||||
],
|
||||
],
|
||||
]
|
||||
|
||||
Very often images are used in a context, where there are overlaid with other DOM elements
|
||||
like a headline. To give editors a hint which area of the image is affected, when selecting a crop area,
|
||||
it is possible to define multiple so called cover areas. These areas are shown inside
|
||||
the crop area. The focus area cannot intersect with any of the cover areas.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'config' => [
|
||||
'type' => 'imageManipulation',
|
||||
'cropVariants' => [
|
||||
'mobile' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.mobile',
|
||||
'coverAreas' => [
|
||||
[
|
||||
'x' => 0.05,
|
||||
'y' => 0.85,
|
||||
'width' => 0.9,
|
||||
'height' => 0.1,
|
||||
]
|
||||
],
|
||||
],
|
||||
],
|
||||
]
|
||||
|
||||
The above configuration examples are basically meant to add one single cropping configuration
|
||||
to sys_file_reference, which will then apply in every record, which reference images.
|
||||
|
||||
It is however also possible to provide a configuration per content element. If you for example want a different
|
||||
cropping configuration for tt_content images, then you can add the following to your `image` field configuration of tt_content records:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'config' => [
|
||||
'overrideChildTca' => [
|
||||
'columns' => [
|
||||
'crop' => [
|
||||
'config' => [
|
||||
'cropVariants' => [
|
||||
'mobile' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.mobile',
|
||||
'cropArea' => [
|
||||
'x' => 0.1,
|
||||
'y' => 0.1,
|
||||
'width' => 0.8,
|
||||
'height' => 0.8,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
]
|
||||
|
||||
Please note, that you need to specify the target column name as array key. Most of the time this will be `crop`
|
||||
as this is the default field name for image manipulation in `sys_file_reference`
|
||||
|
||||
It is also possible to set the cropping configuration only for a specific tt_content element type by using the
|
||||
`columnsOverrides` feature:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['types']['textmedia']['columnsOverrides']['assets']['config']['overrideChildTca']['columns']['crop']['config'] = [
|
||||
'cropVariants' => [
|
||||
'default' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
'mobile' => [
|
||||
'title' => 'LLL:EXT:ext_key/Resources/Private/Language/locallang.xlf:imageManipulation.mobile',
|
||||
'cropArea' => [
|
||||
'x' => 0.1,
|
||||
'y' => 0.1,
|
||||
'width' => 0.8,
|
||||
'height' => 0.8,
|
||||
],
|
||||
'allowedAspectRatios' => [
|
||||
'4:3' => [
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_wizards.xlf:imwizard.ratio.4_3',
|
||||
'value' => 4 / 3
|
||||
],
|
||||
'NaN' => [
|
||||
'title' => 'LLL:EXT:lang/Resources/Private/Language/locallang_wizards.xlf:imwizard.ratio.free',
|
||||
'value' => 0.0
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
Please note, that the array for ``overrideChildTca`` is merged with the child TCA, so are the crop variants that are defined
|
||||
in the child TCA (most likely sys_file_reference). Because you cannot remove crop variants easily, it is possible to disable them
|
||||
for certain field types by setting the array key for a crop variant ``disabled`` to the value ``true``
|
||||
|
||||
To render crop variants, the variants can be specified as argument to the image view helper:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:image image="{data.image}" cropVariant="mobile" width="800" />
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
TCA configuration for field type "imageManipulation" has changed. Old configuration options
|
||||
still work but are deprecated and issue a warning when used.
|
||||
|
||||
The TCA configuration option `enableZoom` has been removed for now. It wasn't really usable
|
||||
anyway and will need some proper UX design before re-implementation. Setting the option
|
||||
will have no effect.
|
||||
|
||||
.. index:: Backend, TCA
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-78169:
|
||||
|
||||
=====================================================================
|
||||
Feature: #78169 - Introduce "Translation Source" field for tt_content
|
||||
=====================================================================
|
||||
|
||||
See :issue:`78169`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The new database field `l10n_source` for tt_content table has been introduced together with a new TCA ctrl configuration `translationSource`.
|
||||
The `translationSource` field contains a uid of the record used as a translation source, no matter whether the record was translated in the free or connected mode.
|
||||
The new TCA configuration `translationSource` contains column name, similar to the `transOrigPointerField`.
|
||||
e.g.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['ctrl']['translationSource'] = 'l10n_source';
|
||||
|
||||
The new field solves few issues:
|
||||
|
||||
1. There was no way to detect whether a record was translated using connected mode or free mode.
|
||||
If a record has value > 0 in the `transOrigPointerField` (e.g. `l10n_parent`) field, it means it was translated using "connected mode".
|
||||
If the `transOrigPointerField` is 0 but the `translationSource` field is > 0 it means it was translated using "free mode".
|
||||
If both are 0, it means the record was not translated but created manually.
|
||||
|
||||
2. TYPO3 allows to use a record in non-default language as a translation source. In this case the information about the translation source was lost.
|
||||
Now, the `translationSource` field always contains a uid of the record used as a translation source.
|
||||
|
||||
3. In some places `origUid` (e.g. `t3_origuid`) fields were misused as a translation source. Now these places can be refactored to use the `translationSource` field.
|
||||
|
||||
Difference between `translationSource` and other existing fields
|
||||
----------------------------------------------------------------
|
||||
|
||||
1. `transOrigPointerField` (e.g. `l10n_parent`) - "translation parent" - this field contains uid of the record in the *default language* representing the same content. The `translationSource` field can contain a uid of the record in non-default language.
|
||||
2. `origUid` (e.g. `t3_origuid`) - "copy source" - this field contains uid of the record, current record was *copied from*. It might be equal to `translationSource` as localization is a copy internally, but often it is different.
|
||||
|
||||
|
||||
See following test scenarios to see how data is handled in details.
|
||||
|
||||
- :code:`\TYPO3\CMS\Core\Tests\Functional\DataHandling\Regular\Modify\ActionTest::localizeContent`
|
||||
- :code:`\TYPO3\CMS\Core\Tests\Functional\DataHandling\Regular\Modify\ActionTest::localizeContentFromNonDefaultLanguage`
|
||||
- :code:`\TYPO3\CMS\Core\Tests\Functional\DataHandling\Regular\Modify\ActionTest::copyContentToLanguage`
|
||||
- :code:`\TYPO3\CMS\Core\Tests\Functional\DataHandling\Regular\Modify\ActionTest::copyPage`
|
||||
- :code:`\TYPO3\CMS\Core\Tests\Functional\DataHandling\Regular\Modify\ActionTest::copyPageFreeMode`
|
||||
- :code:`\TYPO3\CMS\Core\Tests\Functional\DataHandling\Regular\Modify\ActionTest::localizePage`
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Introduction of the new field is a base step for further refactorings, e.g.
|
||||
|
||||
- it opens a way to implement features like "reconnecting" free-mode translations back to the "connected mode"
|
||||
- replace usage of the `t3_origuid` with the `l10n_source` where `t3_origuid` is misused for language handling purposes (e.g. in LocalizationRepository)
|
||||
|
||||
.. index:: Database, TCA, PHP-API
|
||||
@@ -0,0 +1,98 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-78192:
|
||||
|
||||
====================================================
|
||||
Feature: #78192 - Refactor click menu (context menu)
|
||||
====================================================
|
||||
|
||||
See :issue:`78192`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Click-menu (context-menu) handling has been refactored and unified.
|
||||
The ExtJS/ExtDirect click-menu used on the page tree has been replaced with a jQuery based implementation.
|
||||
The same context-menu implementation is used in all places in the Backend (page tree, page module, list module, file list, folder tree...).
|
||||
|
||||
Context-menu rendering flow
|
||||
---------------------------
|
||||
|
||||
The context-menu is shown after click on the HTML element which has `class="t3js-contextmenutrigger"` together with `data-table`, `data-uid` and optional `data-context` attributes.
|
||||
|
||||
The JavaScript click event handler is implemented in the `TYPO3/CMS/Backend/ContextMenu` requireJS module. It takes the data attributes mentioned above and executes an ajax call to the :php:`\TYPO3\CMS\Backend\Controller\ContextMenuController->getContextMenuAction()`.
|
||||
|
||||
:php:`ContextMenuController` asks :php:`\TYPO3\CMS\Backend\ContextMenu\ContextMenu` to generate an array of items. ContextMenu builds a list of available item providers by asking each whether it can provide items (:php:`->canHandle()`), and what priority it has (:php:`->getPriority()`).
|
||||
|
||||
Custom item providers can be registered in :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['ContextMenu']['ItemProviders']`. They must implement :php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\ProviderInterface` and can extend :php:`\TYPO3\CMS\Backend\ContextMenu\ItemProviders\AbstractProvider`.
|
||||
|
||||
A list of providers is sorted by priority, and then each provider is asked to add items. The generated array of items is passed from an item provider with higher priority to a provider with lower priority.
|
||||
|
||||
After that, a compiled list of items is returned to the :php:`ContextMenuController` which passes it back to the ContextMenu.js as JSON.
|
||||
|
||||
Example of the JSON response:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
{
|
||||
"view":{
|
||||
"type":"item",
|
||||
"label":"Show",
|
||||
"icon":"<span class=\"t3js-icon icon icon-size-small icon-state-default icon-actions-document-view\" data-identifier=\"actions-document-view\">\n\t<span class=\"icon-markup\">\n<img src=\"\/typo3\/sysext\/core\/Resources\/Public\/Icons\/T3Icons\/actions\/actions-document-view.svg\" width=\"16\" height=\"16\" \/>\n\t<\/span>\n\t\n<\/span>",
|
||||
"additionalAttributes":{
|
||||
"data-preview-url":"http:\/\/typo37.local\/index.php?id=47"
|
||||
},
|
||||
"callbackAction":"viewRecord"
|
||||
},
|
||||
"edit":{
|
||||
"type":"item",
|
||||
"label":"Edit",
|
||||
"icon":"",
|
||||
"additionalAttributes":[
|
||||
],
|
||||
"callbackAction":"editRecord"
|
||||
},
|
||||
"divider1":{
|
||||
"type":"divider",
|
||||
"label":"",
|
||||
"icon":"",
|
||||
"additionalAttributes":[
|
||||
|
||||
],
|
||||
"callbackAction":""
|
||||
},
|
||||
"more":{
|
||||
"type":"submenu",
|
||||
"label":"More options...",
|
||||
"icon":"",
|
||||
"additionalAttributes":[
|
||||
|
||||
],
|
||||
"callbackAction":"openSubmenu",
|
||||
"childItems":{
|
||||
"newWizard":{
|
||||
"type":"item",
|
||||
"label":"'Create New' wizard",
|
||||
"icon":"",
|
||||
"additionalAttributes":{
|
||||
},
|
||||
"callbackAction":"newContentWizard"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Based on the JSON data ContextMenu.js is rendering a context-menu. If one of the items is clicked, the according JS `callbackAction` is executed on the :js:`TYPO3/CMS/Backend/ContextMenuActions` JS module or other modules defined in the `additionalAttributes['data-callback-module']`.
|
||||
|
||||
For example usage of this API see:
|
||||
|
||||
- Beuser item provider :php:`\TYPO3\CMS\Beuser\ContextMenu\ItemProvider` and requireJS module :js:`TYPO3/CMS/Beuser/ContextMenuActions`
|
||||
- Impexp item provider :php:`\TYPO3\CMS\Impexp\ContextMenu\ItemProvider` and requireJS module :js:`TYPO3/CMS/Impexp/ContextMenuActions`
|
||||
- Version item provider :php:`\TYPO3\CMS\Version\ContextMenu\ItemProvider` and requireJS module :js:`TYPO3/CMS/Version/ContextMenuActions`
|
||||
- Version item provider :php:`\TYPO3\CMS\Version\ContextMenu\ItemProvider` and requireJS module :js:`TYPO3/CMS/Version/ContextMenuActions`
|
||||
- Filelist item providers :php:`\TYPO3\CMS\Filelist\ContextMenu\ItemProviders\FileDragProvider`, :php:`\TYPO3\CMS\Filelist\ContextMenu\ItemProviders\FileProvider`,
|
||||
:php:`\TYPO3\CMS\Filelist\ContextMenu\ItemProviders\FileStorageProvider`, :php:`\TYPO3\CMS\Filelist\ContextMenu\ItemProviders\FilemountsProvider`
|
||||
and requireJS module :js:`TYPO3/CMS/Filelist/ContextMenuActions`
|
||||
|
||||
|
||||
.. index:: Backend, JavaScript, PHP-API, TSConfig
|
||||
@@ -0,0 +1,42 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-78477:
|
||||
|
||||
=======================================================
|
||||
Feature: #78477 - Refactoring of FlashMessage rendering
|
||||
=======================================================
|
||||
|
||||
See :issue:`78477`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The implementation of rendering FlashMessages in the core has been optimized.
|
||||
With :issue:`73698` a cleanup has been started to centralize the markup within the FlashMessage class.
|
||||
|
||||
A new class called :php:`FlashMessageRendererResolver` has been introduced.
|
||||
This class detects the context and renders the given FlashMessages in the correct output format.
|
||||
It can handle any kind of output format.
|
||||
The following FlashMessageRendererResolver classes have been introduced:
|
||||
|
||||
* :php:`TYPO3\CMS\Core\Messaging\Renderer\BootstrapRenderer` (is used in backend context by default)
|
||||
* :php:`TYPO3\CMS\Core\Messaging\Renderer\ListRenderer` (is used in frontend context by default)
|
||||
* :php:`TYPO3\CMS\Core\Messaging\Renderer\PlaintextRenderer` (is used in CLI context by default)
|
||||
|
||||
All new rendering classes have to implement the :php:`TYPO3\CMS\Core\Messaging\Renderer\FlashMessageRendererInterface` interface.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The core has been modified to use the new :php:`FlashMessageRendererResolver`.
|
||||
Any third party extension should use the provided :php:`FlashMessageViewHelper` or the new :php:`FlashMessageRendererResolver` class:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$out = GeneralUtility::makeInstance(FlashMessageRendererResolver::class)
|
||||
->resolve()
|
||||
->render($flashMessages);
|
||||
|
||||
|
||||
.. index:: Backend, PHP-API
|
||||
@@ -0,0 +1,47 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-78899:
|
||||
|
||||
=======================================
|
||||
Feature: #78899 - TCA maxitems optional
|
||||
=======================================
|
||||
|
||||
See :issue:`78899`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :code:`TCA` config setting :code:`maxitems` for :code:`type=select` and :code:`type=group` fields is now an optional setting that defaults to a high value (99999) instead of 1 as before.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Fields that typically relate to multiple relations like the group element and some select elements no longer need :code:`maxitems` set to some value to enable multiple values.
|
||||
|
||||
Example before:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
aField => [
|
||||
'config' => [
|
||||
'type' => `select',
|
||||
'renderType' => 'multipleSideBySide',
|
||||
'maxitems' => 99999,
|
||||
],
|
||||
],
|
||||
|
||||
Example after:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
aField => [
|
||||
'config' => [
|
||||
'type' => `select',
|
||||
'renderType' => 'multipleSideBySide',
|
||||
],
|
||||
],
|
||||
|
||||
This simplifies :code:`TCA` of those fields and removes a cross dependency between :code:`renderType` and :code:`maxitems`.
|
||||
|
||||
.. index:: Backend, TCA
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79121:
|
||||
|
||||
============================================================================
|
||||
Feature: #79121 - Implement hook in typolink for modification of page params
|
||||
============================================================================
|
||||
|
||||
See :issue:`79121`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new hook has been implemented in ContentObjectRenderer::typoLink for links to pages. With this
|
||||
hook you can modify the link configuration, for example enriching it with additional parameters or
|
||||
meta data from the page row.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
You can now register a hook via:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typolinkProcessing']['typolinkModifyParameterForPageLinks'][] = \Your\Namespace\Hooks\MyBeautifulHook::class;
|
||||
|
||||
Your hook has to implement `TypolinkModifyLinkConfigForPageLinksHookInterface` with its method
|
||||
:php:`modifyPageLinkConfiguration(array $linkConfiguration, array $linkDetails, array $pageRow)`.
|
||||
In :php:`$linkConfiguration` you get the configuration array for the link - this is what your hook
|
||||
can modify and **has to** return.
|
||||
:php:`$linkDetails` contains additional information for your link and :php:`$pageRow` is the full
|
||||
database row of the page.
|
||||
|
||||
For more information as to which configuration options may be changed, see TSRef_.
|
||||
|
||||
Example implementation:
|
||||
-----------------------
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
public function modifyPageLinkConfiguration(array $linkConfiguration, array $linkDetails, array $pageRow) : array
|
||||
{
|
||||
$linkConfiguration['additionalParams'] .= $pageRow['myAdditionalParamsField'];
|
||||
return $linkConfiguration;
|
||||
}
|
||||
|
||||
.. _TSRef: https://docs.typo3.org/typo3cms/TyposcriptReference/Functions/Typolink/Index.html
|
||||
|
||||
.. index:: PHP-API, Backend
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79124:
|
||||
|
||||
============================================================================
|
||||
Feature: #79124 - Allow overwriting of template paths in BackendTemplateView
|
||||
============================================================================
|
||||
|
||||
See :issue:`79124`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
BackendTemplateView now allows overwriting of template paths to add your own locations for templates, partials and layouts in a BackendTemplateView based backend module.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
You can now do for example
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$frameworkConfiguration = $this->configurationManager->getConfiguration(ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
|
||||
$viewConfiguration = [
|
||||
'view' => [
|
||||
'templateRootPaths' => ['EXT:myext/Resources/Private/Backend/Templates'],
|
||||
'partialRootPaths' => ['EXT:myext/Resources/Private/Backend/Partials'],
|
||||
'layoutRootPaths' => ['EXT:myext/Resources/Private/Backend/Layouts'],
|
||||
],
|
||||
];
|
||||
$this->configurationManager->setConfiguration(array_merge($frameworkConfiguration, $viewConfiguration));
|
||||
|
||||
|
||||
.. index:: Backend, PHP-API
|
||||
@@ -0,0 +1,68 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79140:
|
||||
|
||||
=============================================================
|
||||
Feature: #79140 - Add hook to add custom TypoScript templates
|
||||
=============================================================
|
||||
|
||||
See :issue:`79140`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new hook in TemplateService allows to add or modify existing TypoScript templates.
|
||||
|
||||
Register the hook via :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Core/TypoScript/TemplateService']['runThroughTemplatesPostProcessing']`
|
||||
in the extensions' ext_localconf.php file.
|
||||
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
An example implementation could look like this:
|
||||
|
||||
EXT:my_site/ext_localconf.php
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Core/TypoScript/TemplateService']['runThroughTemplatesPostProcessing'][1313131313] =
|
||||
\MyVendor\MySite\Hooks\TypoScriptHook::class . '->addCustomTypoScriptTemplate';
|
||||
|
||||
|
||||
EXT:my_site/Classes/Hooks/TypoScriptHook.php
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
namespace MyVendor\MySite\Hooks;
|
||||
|
||||
class TypoScriptHook
|
||||
{
|
||||
|
||||
/**
|
||||
* Hooks into TemplateService after
|
||||
* @param array $parameters
|
||||
* @param \TYPO3\CMS\Core\TypoScript\TemplateService $parentObject
|
||||
* @return void
|
||||
*/
|
||||
public function addCustomTypoScriptTemplate($parameters, $parentObject)
|
||||
{
|
||||
// Disable the inclusion of default TypoScript set via TYPO3_CONF_VARS
|
||||
$parameters['isDefaultTypoScriptAdded'] = true;
|
||||
// Disable the inclusion of ext_typoscript_setup.txt of all extensions
|
||||
$parameters['processExtensionStatics'] = false;
|
||||
|
||||
// No template was found in rootline so far, so a custom "fake" sys_template record is added
|
||||
if ($parentObject->outermostRootlineIndexWithTemplate === 0) {
|
||||
$row = [
|
||||
'uid' => 'my_site_template',
|
||||
'config' => '<INCLUDE_TYPOSCRIPT: source="FILE:EXT:my_site/Configuration/TypoScript/site_setup.t3s">',
|
||||
'root' => 1,
|
||||
'pid' => 0
|
||||
];
|
||||
$parentObject->processTemplate($row, 'sys_' . $row['uid'], 0, 'sys_' . $row['uid']);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.. index:: PHP-API, TypoScript, Frontend
|
||||
@@ -0,0 +1,53 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79196:
|
||||
|
||||
========================================
|
||||
Feature: #79196 - Allow reload of topbar
|
||||
========================================
|
||||
|
||||
See :issue:`79196`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new JavaScript API to reload the backend's topbar has been introduced to the TYPO3 Core.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The toolbar reloading may be triggered on JavaScript and PHP code-level. To enforce the reloading on PHP side,
|
||||
call :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::setUpdateSignal('updateTopbar')`.
|
||||
|
||||
Reloading the topbar via JavaScript requires the following code:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
// Either: RequireJS style
|
||||
define(['TYPO3/CMS/Backend/Viewport'], function(Viewport) {
|
||||
Viewport.Topbar.refresh();
|
||||
});
|
||||
|
||||
// Or: old-fashioned JavaScript
|
||||
if (top && top.TYPO3.Backend && top.TYPO3.Backend.Topbar) {
|
||||
top.TYPO3.Backend.Topbar.refresh();
|
||||
};
|
||||
|
||||
|
||||
In case a toolbar item registers to the `load` event of the page, the registration must be changed. Reason is that the
|
||||
event information gets lost, as the whole toolbar is rendered from scratch after a reload.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
define(['jquery', 'TYPO3/CMS/Backend/Viewport'], function($, Viewport) {
|
||||
// old registration
|
||||
$(MyAwesomeItem.doStuff);
|
||||
|
||||
// new registration
|
||||
Viewport.Topbar.Toolbar.registerEvent(MyAwesomeItem.doStuff);
|
||||
});
|
||||
|
||||
.. index:: Backend, JavaScript, PHP-API
|
||||
@@ -0,0 +1,52 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79216:
|
||||
|
||||
=========================================================
|
||||
Feature: #79216 - Add YAML configuration for CKEditor RTE
|
||||
=========================================================
|
||||
|
||||
See :issue:`79216`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The CKEditor-flavored RTE can now be configured via YAML files, defined as *presets*.
|
||||
|
||||
A preset contains both the RTE configuration and the HTML processing when storing the content
|
||||
in the database.
|
||||
|
||||
A YAML file for RTE configurations can be registered by any extension in `ext_localconf.php`:
|
||||
|
||||
:php:`$GLOBALS['TYPO3_CONF_VARS']['RTE']['Presets']['default'] = 'EXT:rte_ckeditor/Configuration/RTE/Default.yaml';`
|
||||
|
||||
The TYPO3 Core ships with three flavors for the RTE configuration which can also be overridden via
|
||||
PageTSconfig on a per-field/type level:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
RTE.default.preset = minimal
|
||||
RTE.config.tt_content.bodytext.types.textmedia.preset = full
|
||||
|
||||
|
||||
The PageTSconfig allows to use the minimal configuration everywhere, but to use the full
|
||||
configuration on the tt_content.bodytext field (but only for textmedia content types).
|
||||
|
||||
With the YAML configuration files, an "imports" functionality allows to import other
|
||||
configuration and just override the necessary values for a custom configuration for a specific site.
|
||||
This way, the processing part of EXT:rte_ckeditor can be used directly (which acts as best practice)
|
||||
but the editor part can be completely customized.
|
||||
|
||||
The YAML format thus states three important parts considered by the RTE configuration preset:
|
||||
|
||||
1. "imports"
|
||||
Allows to import other files via the "resource" sub-property
|
||||
2. "processing"
|
||||
uses the former "proc" options to hand over to RteHtmlParser to sanitize the content - the option
|
||||
are the same as for RTEHtmlArea
|
||||
3. "editor"
|
||||
A configuration for CKEditor, where all CKEditor-related options can be set which are available
|
||||
from the ckeditor configuration specifications (see http://docs.ckeditor.com/#!/api/CKEDITOR.config
|
||||
for all options).
|
||||
|
||||
.. index:: LocalConfiguration, RTE, TSConfig
|
||||
@@ -0,0 +1,30 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79225:
|
||||
|
||||
===========================================
|
||||
Feature: #79225 - Plugin preview with Fluid
|
||||
===========================================
|
||||
|
||||
See :issue:`79225`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The page TSconfig to render a preview of a single content element in the Backend has been improved
|
||||
by allowing the rendering of plugins as well.
|
||||
|
||||
The following option allows to override the default output of a plugin via page TSconfig:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
mod.web_layout.tt_content.preview.list.example = EXT:site_mysite/Resources/Private/Templates/Preview/ExamplePlugin.html
|
||||
|
||||
All properties of the tt_content record are available in the template directly.
|
||||
Any data of the flexform field `pi_flexform` is available with the property `pi_flexform_transformed` as an array.
|
||||
|
||||
.. note::
|
||||
|
||||
If a PHP hook already is set to render the element, it will take precedence over the Fluid-based preview.
|
||||
|
||||
.. index:: Backend, Fluid
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79235:
|
||||
|
||||
==================================================================
|
||||
Feature: #79235 - Add button to delete similar errors from sys_log
|
||||
==================================================================
|
||||
|
||||
See :issue:`79235`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The log module of TYPO3 now shows a button to delete multiple errors at once based on
|
||||
the `details` field of the `sys_log` table.
|
||||
This comes in handy when you fixed an error that spammed the log before.
|
||||
|
||||
.. index:: Backend
|
||||
@@ -0,0 +1,26 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79240:
|
||||
|
||||
==================================================
|
||||
Feature: #79240 - Single cli user for cli commands
|
||||
==================================================
|
||||
|
||||
See :issue:`79240`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Accessing TYPO3 functionality from the command line has been simplified. Single commands no longer require single
|
||||
users in the database, instead all cli command use the username `_cli_`.
|
||||
This user is created on demand by the framework if it does not exist at the first command line call.
|
||||
The `_cli_` user has admin rights and no longer needs specific access rights assigned to perform specific
|
||||
tasks like manipulating database content using the :php:`DataHandler`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Creating and managing command line tasks has been simplified, all existing `_cli_*` users can be deleted.
|
||||
|
||||
.. index:: CLI, PHP-API
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79250:
|
||||
|
||||
======================================================================
|
||||
Feature: #79250 - EXT:form extend the extension location functionality
|
||||
======================================================================
|
||||
|
||||
See :issue:`79250`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
EXT:form has a feature to load custom form definitions from within extension locations.
|
||||
These locations can be configured through the :code:`allowedExtensionPaths` setting.
|
||||
To define whether forms can be changed from within extension locations through the form editor, a setting named :code:`allowSaveToExtensionPaths` exists.
|
||||
But this setting affects only already existing form definitions within extension locations.
|
||||
This feature makes it possible to store new forms within extension locations through the form manager as well.
|
||||
You can also define whether forms can be deleted within extension locations through the form manager with a new setting called :code:`allowDeleteFromExtensionPaths`.
|
||||
By default both settings :code:`allowSaveToExtensionPaths` and :code:`allowDeleteFromExtensionPaths` are disabled.
|
||||
|
||||
|
||||
Summary
|
||||
=======
|
||||
|
||||
With this patch is it possible to:
|
||||
|
||||
* save existing forms within extension locations ("allowedExtensionPaths") if "allowSaveToExtensionPaths" is set to true (like before)
|
||||
* save new created forms within extension locations ("allowedExtensionPaths") if "allowSaveToExtensionPaths" is set to true
|
||||
* delete forms within extension locations ("allowedExtensionPaths") if "allowDeleteFromExtensionPaths" is set to true
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Example to allow edit form definitions within 'EXT:my_ext/Resources/Private/Forms/':
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
TYPO3:
|
||||
CMS:
|
||||
Form:
|
||||
persistenceManager:
|
||||
allowSaveToExtensionPaths: true
|
||||
allowedExtensionPaths:
|
||||
100: EXT:my_ext/Resources/Private/Forms/
|
||||
|
||||
|
||||
Example to allow remove form definitions within 'EXT:my_ext/Resources/Private/Forms/':
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
TYPO3:
|
||||
CMS:
|
||||
Form:
|
||||
persistenceManager:
|
||||
allowDeleteFromExtensionPaths: true
|
||||
allowedExtensionPaths:
|
||||
100: EXT:my_ext/Resources/Private/Forms/
|
||||
|
||||
|
||||
.. index:: Backend, ext:form
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79262:
|
||||
|
||||
==============================================================================
|
||||
Feature: #79262 - Add possibility to create TRIM expression with Doctrine DBAL
|
||||
==============================================================================
|
||||
|
||||
See :issue:`79262`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The possibility to create TRIM expressions using Doctrine DBAL has been integrated.
|
||||
However, when using this in comparisons, ExpressionBuilder::comparison() has to be
|
||||
invoked explicitly - otherwise the created TRIM expression would be quoted if e.g.
|
||||
used with ExpressionBuilder::eq().
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$queryBuilder->expr()->comparison(
|
||||
$queryBuilder->expr()->trim($fieldName),
|
||||
ExpressionBuilder::EQ,
|
||||
$queryBuilder->createNamedParameter('', \PDO::PARAM_STR)
|
||||
);
|
||||
|
||||
The call to :php:`$queryBuilder->expr()-trim()` can be one of the following:
|
||||
|
||||
* :php:`trim('fieldName')`
|
||||
results in :sql:`TRIM("tableName"."fieldName")`
|
||||
|
||||
* :php:`trim('fieldName', AbstractPlatform::TRIM_LEADING, 'x')`
|
||||
results in :sql:`TRIM(LEADING "x" FROM "tableName"."fieldName")`
|
||||
|
||||
* :php:`trim('fieldName', AbstractPlatform::TRIM_TRAILING, 'x')`
|
||||
results in :sql:`TRIM(TRAILING "x" FROM "tableName"."fieldName")`
|
||||
|
||||
* :php:`trim('fieldName', AbstractPlatform::TRIM_BOTH, 'x')`
|
||||
results in :sql:`TRIM(BOTH "x" FROM "tableName"."fieldName")`
|
||||
|
||||
.. index:: Database, PHP-API
|
||||
@@ -0,0 +1,23 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79263:
|
||||
|
||||
============================================================
|
||||
Feature: #79263 - Scheduler CLI available as Symfony Command
|
||||
============================================================
|
||||
|
||||
See :issue:`79263`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Calling the scheduler to process a task is now callable via CLI through `typo3/cli_dispatch.phpsh scheduler` and
|
||||
`typo3/sysext/core/bin/typo3 scheduler:run`.
|
||||
|
||||
The following aliases for the scheduler options are now available:
|
||||
|
||||
* `--task=13` or `--task 13` as synonym to `-i 13` to run a specific task
|
||||
* `--force` as synonym to `-f` to force to run a specific task in combination with `--task` or `-i`
|
||||
* `--stop` as synonym to `-s` to stop a specific task in combination with `--task` or `-i`
|
||||
|
||||
.. index:: CLI, ext:scheduler
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79337:
|
||||
|
||||
==================================================================================
|
||||
Feature: #79337 - Add useCacheHash parameter to f:link.typolink and f:uri.typolink
|
||||
==================================================================================
|
||||
|
||||
See :issue:`79337`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The older implementation of the two typolink ViewHelpers was lacking support of the useCacheHash parameter.
|
||||
|
||||
The boolean argument `useCacheHash` has been added to the typoscript Viewhelpers.
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:link.typolink parameter="{link}" useCacheHash="true">
|
||||
|
||||
.. index:: Fluid, Frontend
|
||||
@@ -0,0 +1,33 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79341:
|
||||
|
||||
==============================================================
|
||||
Feature: #79341 - TCA richtext configuration in config section
|
||||
==============================================================
|
||||
|
||||
See :issue:`79341`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new config setting `enableRichtext` has been introduced. It enables richtext editing on the text field and replaces the old setting `defaultExtras`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Setting `enableRichtext` will result in the text field being rendered with a richtext editor. Config example:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'columns' => [
|
||||
'content' => [
|
||||
'config' => [
|
||||
'type' => 'text',
|
||||
'enableRichtext' => true,
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
.. index:: Backend, FlexForm, RTE, TCA
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79387:
|
||||
|
||||
==================================================================
|
||||
Feature: #79387 - Add signal to exclude tables from ReferenceIndex
|
||||
==================================================================
|
||||
|
||||
See :issue:`79387`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new signal :php:`shouldExcludeTableFromReferenceIndex` is emitted in :php:`TYPO3\CMS\Core\Database\ReferenceIndex` which allows
|
||||
extensions to define tables which should be excluded from ReferenceIndex.
|
||||
|
||||
Register the class which excludes tables in `ext_localconf.php`:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$dispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\SignalSlot\Dispatcher::class);
|
||||
$dispatcher->connect(
|
||||
\TYPO3\CMS\Core\Database\ReferenceIndex::class,
|
||||
'shouldExcludeTableFromReferenceIndex',
|
||||
\MyVendor\MyExtension\Slots\ReferenceIndexSlot::class,
|
||||
'shouldExcludeTableFromReferenceIndex'
|
||||
);
|
||||
|
||||
Your class could look like this:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
namespace MyVendor\MyExtension\Slot;
|
||||
|
||||
class ReferenceIndexSlot {
|
||||
|
||||
/**
|
||||
* Exclude tables from ReferenceIndex which cannot contain a reference
|
||||
*
|
||||
* @param string $tableName Name of the table
|
||||
* @param bool &$excludeTable Reference to a boolean whether to exclude the table from ReferenceIndex or not
|
||||
*/
|
||||
public function shouldExcludeTableFromReferenceIndex($tableName, &$excludeTable) {
|
||||
if ($tableName === 'tx_myextension_mytable') {
|
||||
$excludeTable = true;
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
This signal allows extensions to speed up the process of maintaining the ReferenceIndex. If an extension has tables in which by
|
||||
definition none of its columns can contain any relations to other records these can be excluded from the ReferenceIndex.
|
||||
|
||||
Only exclude tables from ReferenceIndex which do not contain any relations and never did since existing references won't be
|
||||
deleted if it is excluded! There is no need to add tables without a definition in :php:`$GLOBALS['TCA]` since ReferenceIndex
|
||||
only handles those.
|
||||
|
||||
.. index:: Database, PHP-API, Backend
|
||||
@@ -0,0 +1,31 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79402:
|
||||
|
||||
=======================================================
|
||||
Feature: #79402 - New Fluid ViewHelper f:variable added
|
||||
=======================================================
|
||||
|
||||
See :issue:`79402`
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new ViewHelper `f:variable` has been added in Fluid 2.2.0 which is now minimum required dependency for TYPO3.
|
||||
The ViewHelper allows variables to be assigned in the template:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:variable name="myvariable">My variable's content</f:variable>
|
||||
<f:variable name="myvariable" value="My variable's content"/>
|
||||
{f:variable(name: 'myvariable', value: 'My variable\'s content')}
|
||||
{myoriginalvariable -> f:variable.set(name: 'mynewvariable')}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The new ViewHelper is now available in any and all Fluid templates being rendered in TYPO3.
|
||||
|
||||
.. index:: Fluid
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-73409:
|
||||
|
||||
===============================================================================
|
||||
Feature: #73409 - Auto-render Assets sections in Fluid template with controller
|
||||
===============================================================================
|
||||
|
||||
See :issue:`73409`
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
ActionController has received a new method, `renderAssetsForRequest` which receives the `RequestInterface` of the
|
||||
Request currently being processed. The ActionController has a default implementation of this method which attempts
|
||||
to render two sections in the Fluid template that is associated with the controller action being called:
|
||||
|
||||
* `<f:section name="HeaderAssets">` for assets intended for the `<head>` tag
|
||||
* `<f:section name="FooterAssets">` for assets intended for the end of the `<body>` tag
|
||||
|
||||
Both sections are optional.
|
||||
|
||||
When rendering, `{request}` is available as template variable in both sections, as is `{arguments}`, allowing you
|
||||
to make decisions based on various request/controller arguments. As usual, `{settings}` is also available.
|
||||
|
||||
All content you write into these sections will be output in the respective location as is, meaning you must write the entire
|
||||
`<script>` or whichever tag you are writing, including all attributes. You can of course use various Fluid ViewHelpers
|
||||
to resolve extension asset paths.
|
||||
|
||||
The feature only applies to ActionController (thus excluding CommandController) and will only attempt to render the
|
||||
section if the view is an instance of :php:`TYPO3Fluid\\Fluid\\View\\TemplateView` (thus including any View in TYPO3 which
|
||||
extends either TemplateView or AbstractTemplateView from TYPO3's Fluid adapter).
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
* Fluid templates rendered through any ActionController using a TemplateView may now contain two new sections for
|
||||
either `HeaderAssets` or `FooterAssets` depending on desired output. Content of these sections will be rendered
|
||||
and assigned via PageRenderer to either header or footer.
|
||||
* ActionControllers can override the `renderAssetsForRequest` method to perform asset insertion using other means.
|
||||
The method sits at a very opportune point right after the action method itself gets called, when the entire controller
|
||||
is fully initialized with arguments etc. but no forwarding/redirection has happened in the controller action.
|
||||
|
||||
.. index:: Fluid, Frontend
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79413:
|
||||
|
||||
=============================================================================
|
||||
Feature: #79413 - Auto-render Assets sections in FLUIDTEMPLATE content object
|
||||
=============================================================================
|
||||
|
||||
See :issue:`79413`
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
FLUIDTEMPLATE content object will now automatically render two sections and insert the rendered content as assets via
|
||||
PageRenderer. The two sections can be defined in the template file rendered by the FLUIDTEMPLATE object.
|
||||
|
||||
* `<f:section name="HeaderAssets">` for assets intended for the `<head>` tag
|
||||
* `<f:section name="FooterAssets">` for assets intended for the end of the `<body>` tag
|
||||
|
||||
Both sections are optional.
|
||||
|
||||
When rendering, `{contentObject}` is available as template variable in both sections, allowing you to make decisions
|
||||
based on various aspects of the configured content object instance. In addition, all variables you declared for the
|
||||
content object are available when rendering either section.
|
||||
|
||||
All content you write into these sections will be output in the respective location as is, meaning you must write the entire
|
||||
`<script>` or whichever tag you are writing, including all attributes. You can of course use various Fluid ViewHelpers
|
||||
to resolve extension asset paths.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
* Fluid templates rendered through the FLUIDTEMPLATE content object may now contain two new sections for either
|
||||
`HeaderAssets` or `FooterAssets` depending on desired output. Content of these sections will be rendered
|
||||
and assigned via PageRenderer to either header or footer.
|
||||
|
||||
.. index:: Fluid, Frontend
|
||||
@@ -0,0 +1,25 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79420:
|
||||
|
||||
=======================================================
|
||||
Feature: #79420 - Hide files from list of documentation
|
||||
=======================================================
|
||||
|
||||
See :issue:`79420`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The list of displayed documentation files gets pretty long over time. The user might want to hide those already
|
||||
tackled or of no interest from listing. This is possible via checkboxes.
|
||||
|
||||
A new section has been introduced that lists those hidden files to bring them back if necessary.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The list of documentation files can be shortened now.
|
||||
|
||||
.. index:: Backend
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79438:
|
||||
|
||||
==================================================================================
|
||||
Feature: #79438 - Add configuration option to disable validation of stored records
|
||||
==================================================================================
|
||||
|
||||
See :issue:`79438`
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Two configuration options have been added to the Install Tool, which are used when saving records
|
||||
using the DataHandler.
|
||||
|
||||
The first option allows to disable the check if the contents of a record match the data that should
|
||||
have been written after saving it to the database for the whole TYPO3 installation. This allows a
|
||||
speed-up especially when inserting/copying large amounts of data at the cost of possible differences,
|
||||
if values could not be written as requested. This may happen, if e.g. data types do not match or
|
||||
columns are too small to store the data.
|
||||
|
||||
Disable checking the stored records:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['BE']['checkStoredRecords'] = false;
|
||||
|
||||
|
||||
If checking the stored records is enabled, the second option allows to make the comparison of the
|
||||
record contents strict. If a loose comparison is made (which is the default), comparing an empty
|
||||
string '' with the number 0 is not considered as an error ('' == 0), while using strict comparison
|
||||
it is ('' !== 0).
|
||||
|
||||
Make the comparison of record contents strict:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['BE']['checkStoredRecordsLoose'] = false;
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
In TYPO3 installations where the administrator has configured the database to run in strict-mode
|
||||
disabling the validation of stored records can speed-up inserts and updates by a factor of 2. With
|
||||
strict-mode enabled the record will not be saved at all, if there are errors.
|
||||
|
||||
If the validation of stored records is disabled, the entry in the protocol (sys_log) does not
|
||||
contain the record title (it is displayed as "[No title]" instead) - however table and uid are still
|
||||
provided and can be used for finding the record.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
None as default.
|
||||
|
||||
.. index:: Database, Backend, LocalConfiguration
|
||||
@@ -0,0 +1,171 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79440:
|
||||
|
||||
==============================================
|
||||
Feature: #79440 - FormEngine Element Expansion
|
||||
==============================================
|
||||
|
||||
See :issue:`79440`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new API in FormEngine has been introduced that allows fine grained additions to
|
||||
single elements and containers without substituting the whole element.
|
||||
|
||||
For elements within the :code:`TCA` config section, three new options have been introduced:
|
||||
|
||||
* :code:`fieldInformation` An array of single field information. This could be additionally describing text
|
||||
that is rendered between the element label and the element itself. Field information are restricted, only
|
||||
a couple of HTML tags are allowed within the result HTML.
|
||||
* :code:`fieldControl` An array of single field controls. These are icons with JavaScript or
|
||||
links to further functionality of the framework. They are usually displayed next to the element. Each control
|
||||
must return an icon identifier, a title, and an array of a-tag attributes.
|
||||
* :code:`fieldWizard` Additional functionality enriching the element. These are typically shown
|
||||
below the element. Wizards may return any HTML.
|
||||
|
||||
For FormEngine containers, the same API has been introduced, but it is currently only implemented within
|
||||
the :code:`OuterWrapContainer` which renders the record title and delegates the main record rendering to
|
||||
a different container. Adding :code:`fieldInformation` or :code:`fieldWizard` here allows embedding additional
|
||||
functionality between the record title an the main record body.
|
||||
|
||||
Single elements and containers may register default information, control and wizards. The configuration is merged
|
||||
with any possibly given configuration from `TCA`.
|
||||
|
||||
Example from :code:`GroupElement`:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
class GroupElement extends AbstractFormElement
|
||||
{
|
||||
/**
|
||||
* Default field controls for this element.
|
||||
*
|
||||
* @var array
|
||||
*/
|
||||
protected $defaultFieldControl = [
|
||||
'elementBrowser' => [
|
||||
'renderType' => 'elementBrowser',
|
||||
],
|
||||
'insertClipboard' => [
|
||||
'renderType' => 'insertClipboard',
|
||||
'after' => [ 'elementBrowser' ],
|
||||
],
|
||||
'editPopup' => [
|
||||
'renderType' => 'editPopup',
|
||||
'disabled' => true,
|
||||
'after' => [ 'insertClipboard' ],
|
||||
],
|
||||
'addRecord' => [
|
||||
'renderType' => 'addRecord',
|
||||
'disabled' => true,
|
||||
'after' => [ 'editPopup' ],
|
||||
],
|
||||
'listModule' => [
|
||||
'renderType' => 'listModule',
|
||||
'disabled' => true,
|
||||
'after' => [ 'addRecord' ],
|
||||
],
|
||||
];
|
||||
|
||||
public function render()
|
||||
{
|
||||
...
|
||||
$fieldControlResult = $this->renderFieldControl();
|
||||
$fieldControlHtml = $legacyFieldControlHtml . $fieldControlResult['html'];
|
||||
$resultArray = $this->mergeChildReturnIntoExistingResult($resultArray, $fieldControlResult, false);
|
||||
}
|
||||
}
|
||||
|
||||
This element registers five default field controls (icons next to the element), renders them and later
|
||||
adds the HTML at an appropriate place within the HTML of the main element. The :code:`defaultFieldControl` can
|
||||
be overwritten on :code:`TCA` level of single fields:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'columns' => [
|
||||
'aField' => [
|
||||
'label' => 'aField',
|
||||
'config' => [
|
||||
'fieldControl' => [
|
||||
'elementBrowser' => [
|
||||
'disabled' => true,
|
||||
],
|
||||
'editPopup' => [
|
||||
'disabled' => false,
|
||||
],
|
||||
'aNewControl' => [
|
||||
'renderType' => 'myOwnTypeGroupControl',
|
||||
'before' => [ 'elementBrowser' ],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
The above configuration disables the element browser which is enabled by default, it enabled the edit popup
|
||||
control which exists in default configuration but is disabled by default, and it adds a further control called
|
||||
:code:`aNewControl` with :code:`renderType=myOwnTypeGroupControl`. The renderType instructs the FormEngine
|
||||
:code:`NodeFactory` to instantiate the class that in configured for that renderType, identical to other usages
|
||||
of the NodeFactory, this lookup can be manipulated on configuration and code level. In the example above, a new
|
||||
renderType should be registered in :code:`ext_localconf.php`:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeRegistry'][1485351217] = [
|
||||
'nodeName' => 'myOwnTypeGroupControl',
|
||||
'priority' => 30,
|
||||
'class' => \My\ExtensionName\Form\FieldControl\MyFancyControl::class,
|
||||
];
|
||||
|
||||
|
||||
Note the above configuration also uses the :code:`DependencyResolver`: It is possible to resort single
|
||||
elements by adding :code:`before` and :code:`after` to the configuration. In above example, the new
|
||||
control :code:`aNewControl` would be shown as first control, before :code:`elementBrowser`.
|
||||
|
||||
The first level below :code:`fieldControl` contains speaking names of single controls, each control must
|
||||
have a :code:`renderType` defined (either on TCA level or via defaultFieldControl), and they may have
|
||||
a :code:`before` and :code:`after` and a :code:`disabled` setting. Each control also may have a :code:`options`
|
||||
sub array with further settings given to the specific control.
|
||||
|
||||
In :code:`TCA`, the configuration name for field controls is :code:`fieldControl`, for wizards it is :code:`fieldWizard`,
|
||||
and for information it is :code:`fieldInformation`. All three follow the same structure. It is up to a single element
|
||||
if all three of these are actually called and rendered. For instance, it sometimes does not make sense to have
|
||||
field controls in all elements, so some elements skip that.
|
||||
|
||||
For containers, the configuration of :code:`fieldInformation`, :code:`fieldControl` and :code:`fieldWizard` is within
|
||||
the :code:`ctrl` section of :code:`TCA`. This is currently only implemented within the :code:`OuterWrapContainer` for
|
||||
:code:`fieldInformation` and :code:`fieldWizard`.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
'ctrl' => [
|
||||
...
|
||||
'container' => [
|
||||
'outerWrapContainer' => [
|
||||
'fieldInformation' => [
|
||||
'myHelloWorld' => [
|
||||
'renderType' => 'helloWorld',
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
|
||||
The above example would instruct the system to call the class registered for renderType :code:`helloWorld`
|
||||
within the OuterWrapContainer.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The new API brings lots of new options to add functionality to single elements
|
||||
without substituting the full element.
|
||||
|
||||
|
||||
.. index:: Backend, TCA, PHP-API
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79442:
|
||||
|
||||
==================================================================
|
||||
Feature: #79442 - EXT:form - add element selector for text editors
|
||||
==================================================================
|
||||
|
||||
See :issue:`79442`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new button has been added to the text editors of the form editor. Clicking on this button opens an overlay with
|
||||
available form elements of the current form. The user has the possibility to choose one of these form elements.
|
||||
The process adds the dynamic identifier (e.g. "{text-1}") to the current text editor field.
|
||||
|
||||
.. index:: Backend, ext:form
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79467:
|
||||
|
||||
======================================================================
|
||||
Feature: #79467 - EXT:form - add form settings button to module header
|
||||
======================================================================
|
||||
|
||||
See :issue:`79467`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new button has been added to the module header of the form editor. Clicking on this button shows the form settings within the inspector.
|
||||
|
||||
.. index:: Backend, ext:form
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79521:
|
||||
|
||||
==================================================================
|
||||
Feature: #79521 - Show list of failed input elements in FormEngine
|
||||
==================================================================
|
||||
|
||||
See :issue:`79521`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
When validating input fields of the FormEngine fails, a button is now rendered into the button bar in
|
||||
the module document header. Clicking the button renders a list of all input elements whose validation failed.
|
||||
|
||||
Clicking onto a field in that list automatically focuses the field in the form.
|
||||
|
||||
.. index:: Backend
|
||||
@@ -0,0 +1,119 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79530:
|
||||
|
||||
============================================================
|
||||
Feature: #79530 - EXT:form - Extend SaveToDatabase finisher
|
||||
============================================================
|
||||
|
||||
See :issue:`79530`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The SaveToDatabase finisher has been extended by the following functions:
|
||||
|
||||
Perform multiple database operations
|
||||
------------------------------------
|
||||
|
||||
You can set options as an array to perform multiple database operations.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
finishers:
|
||||
-
|
||||
identifier: SaveToDatabase
|
||||
options:
|
||||
-
|
||||
table: 'my_table'
|
||||
mode: insert
|
||||
databaseColumnMappings:
|
||||
some_column:
|
||||
value: 'cool'
|
||||
-
|
||||
table: 'my_other_table'
|
||||
mode: update
|
||||
whereClause:
|
||||
pid: 1
|
||||
databaseColumnMappings:
|
||||
some_other_column:
|
||||
uid_foreign: '{SaveToDatabase.insertedUids.0}'
|
||||
|
||||
Access the inserted uids from previous database inserts
|
||||
-------------------------------------------------------
|
||||
|
||||
You can access the inserted uids via `{SaveToDatabase.insertedUids.<theArrayKeyNumberWithinOptions>}`.
|
||||
If you perform an insert operation, the value of the inserted database row will be stored within the FinisherVariableProvider.
|
||||
`<theArrayKeyNumberWithinOptions>` references to the numeric key from the `options` array within which the insert operation is executed.
|
||||
|
||||
Add a special option value '{__currentTimestamp}'
|
||||
-------------------------------------------------
|
||||
|
||||
You can write `{__currentTimestamp}` as an option value which returns the current timestamp.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
finishers:
|
||||
-
|
||||
identifier: SaveToDatabase
|
||||
options:
|
||||
-
|
||||
table: 'my_table'
|
||||
mode: insert
|
||||
databaseColumnMappings:
|
||||
tstamp:
|
||||
value: '{__currentTimestamp}'
|
||||
|
||||
Add a variable container object which is passed through all finishers
|
||||
---------------------------------------------------------------------
|
||||
|
||||
There is a simple data storage object available within the `\TYPO3\CMS\Form\Domain\Finishers\FinisherContext`.
|
||||
You can access this from within a finisher with
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$this->finisherContext->getFinisherVariableProvider()
|
||||
|
||||
Each finisher can write and/or read data from this object.
|
||||
All data has to be prefixed with the finisher identifier, so you can determine what data from which finisher you want.
|
||||
|
||||
Prototype to add some data:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$this->finisherContext->getFinisherVariableProvider()->add(
|
||||
$this->shortFinisherIdentifier,
|
||||
'some.data',
|
||||
$yourData
|
||||
);
|
||||
|
||||
Prototype to get some data:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$otherFinisherData = $this->finisherContext->getFinisherVariableProvider()->get(
|
||||
'SomeFinisherIdentifier',
|
||||
'some.data'
|
||||
);
|
||||
|
||||
You can access this data within the form definition:
|
||||
|
||||
For example, a finisher with identifier 'SomeFinisherIdentifier' writes data with the key 'some.data'
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
finishers:
|
||||
-
|
||||
identifier: SaveToDatabase
|
||||
options:
|
||||
-
|
||||
table: 'my_table'
|
||||
mode: insert
|
||||
databaseColumnMappings:
|
||||
tstamp:
|
||||
value: '{SomeFinisherIdentifier.some.key}'
|
||||
|
||||
You can read more about the configuration options within the SaveToDatabase inline documentation.
|
||||
Please see `\TYPO3\CMS\Form\Domain\Finishers\SaveToDatabaseFinisher`.
|
||||
|
||||
.. index:: Frontend, ext:form
|
||||
@@ -0,0 +1,24 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79531:
|
||||
|
||||
=============================================================
|
||||
Feature: #79531 - EXT:form - Add multiselect inspector editor
|
||||
=============================================================
|
||||
|
||||
See :issue:`79531`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
A new inspector editor, i.e. a new field type of the form editor, has been added.
|
||||
If applied, multi-select fields can be added to the inspector.
|
||||
A multi-select field allows the selection of multiple meta properties for a field
|
||||
and stores them in the defined property path.
|
||||
|
||||
For example:
|
||||
If you have a file upload element in your form, until now you could only select a single
|
||||
mime type restriction. With the new multi-select option, the mime-type field was converted
|
||||
and you can now select multiple mime-types (for example docx, doc and odt together).
|
||||
|
||||
.. index:: Backend, ext:form
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79622:
|
||||
|
||||
==================================================================
|
||||
Feature: #79622 - Header Position support for Fluid Styled Content
|
||||
==================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Header position as known from CSS Styled Content is now also supported by
|
||||
Fluid Styled Content. This will allow the editor to have more control about
|
||||
the alignment of the header in the frontend.
|
||||
|
||||
By default all CSS classes for header alignment are prefixed with
|
||||
`ce-headline-` to make the css class unique and to allow even more adjustments
|
||||
without breaking your styling somewhere else.
|
||||
|
||||
|
||||
Predefined values for header alignment and resulting CSS classes
|
||||
----------------------------------------------------------------
|
||||
|
||||
========== ========== ====================
|
||||
Name Value CSS Class
|
||||
========== ========== ====================
|
||||
Default (empty) (No CSS Class added)
|
||||
Center center ce-headline-center
|
||||
Right right ce-headline-right
|
||||
Left left ce-headline-left
|
||||
========== ========== ====================
|
||||
|
||||
|
||||
Implementation Example
|
||||
----------------------
|
||||
|
||||
The following examples are taken from the partials of fluid_styled_content that
|
||||
can be found here `EXT:fluid_styled_content/Resources/Private/Partials/Header/All.html`
|
||||
and here `EXT:fluid_styled_content/Resources/Private/Partials/Header/Header.html`.
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<f:render partial="Header/Header" arguments="{
|
||||
header: data.header,
|
||||
layout: data.header_layout,
|
||||
positionClass: '{f:if(condition: data.header_position, then: \'ce-headline-{data.header_position}\')}',
|
||||
link: data.header_link,
|
||||
default: settings.defaultHeaderType}" />
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<h1 class="{positionClass}">
|
||||
<f:link.typolink parameter="{link}">{header}</f:link.typolink>
|
||||
</h1>
|
||||
|
||||
|
||||
Edit Predefined Options
|
||||
-----------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.tt_content.header_position {
|
||||
removeItems = center,left,right
|
||||
addItems {
|
||||
fancyheader = LLL:EXT:extension/Resources/Private/Language/locallang.xlf:fancyHeader
|
||||
}
|
||||
}
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['header_position']['config']['items'][] = [
|
||||
0 = LLL:EXT:extension/Resources/Private/Language/locallang.xlf:fancyHeader
|
||||
1 = fancyheader
|
||||
];
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Header positions are now available to all editors by default.
|
||||
|
||||
|
||||
.. index:: Fluid, Frontend, ext:fluid_styled_content, TypoScript
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-79622-1668719172:
|
||||
|
||||
==================================================================
|
||||
Feature: #79622 - Introducing Frame Class for Fluid Styled Content
|
||||
==================================================================
|
||||
|
||||
See :issue:`79622`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
In CSS Styled Content it is possible to provide additional CSS classes
|
||||
for the wrapping container element. This feature is now available
|
||||
for Fluid Styled Content, too.
|
||||
|
||||
The default layout of Fluid Styled Content is now passing the value of
|
||||
`Frame Class` directly to the template and prefixes the value by default
|
||||
with `frame-<key>`.
|
||||
|
||||
|
||||
Implementation in Fluid Styled Content
|
||||
--------------------------------------
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<div id="c{data.uid}" class="frame frame-{data.frame_class} ...">
|
||||
...
|
||||
</div>
|
||||
|
||||
|
||||
Explanation of Keys and Effects of Frame Classes
|
||||
-------------------------------------------------
|
||||
|
||||
=============== =============== ===================== ==================================================
|
||||
Name Key CSS Class Additional Effects
|
||||
=============== =============== ===================== ==================================================
|
||||
Default default frame-default -
|
||||
Ruler Before ruler-before frame-ruler-before A ruler is added after the output.
|
||||
Ruler After ruler-after frame-ruler-after A ruler is added after the output.
|
||||
Indent indent frame-indent Margin of 15% is added to the left and right side.
|
||||
Indent, 33/66% intent-left frame-indent-left Margin of 33% is added to the left side.
|
||||
Indent, 66/33% indent-right frame-indent-right Margin of 33% is added to the right side.
|
||||
No Frame none (none) No Frame is rendered.
|
||||
=============== =============== ===================== ==================================================
|
||||
|
||||
Please note that you need to include the optional static template "Fluid Styled
|
||||
Content Styling" to have a visual effect on the new added CSS classes.
|
||||
|
||||
|
||||
Edit Predefined Options
|
||||
-----------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
TCEFORM.tt_content.frame_class {
|
||||
removeItems = default,ruler-before,ruler-after,indent,indent-left,indent-right,none
|
||||
addItems {
|
||||
superframe = LLL:EXT:extension/Resources/Private/Language/locallang.xlf:superframe
|
||||
}
|
||||
}
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
$GLOBALS['TCA']['tt_content']['columns']['frame_class']['config']['items'][] = [
|
||||
0 = LLL:EXT:extension/Resources/Private/Language/locallang.xlf:superframe
|
||||
1 = superframe
|
||||
];
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
`Frame Class` is now available to all Fluid Styled Content elements.
|
||||
|
||||
|
||||
.. index:: Fluid, Frontend, ext:fluid_styled_content, TypoScript
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user