All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh


From TYPO3Wiki
Jump to: navigation, search


Feature: #47919 - Possibility to configure an exception handler when rendering TypoScript content objects


Exceptions which occur during rendering of content objects (typically plugins) will now be caught by default in production context and an error message is shown as rendered output. If this is done, the page will remain available while the section of the page that produces an error (throws an exception) will show a configurable error message. By default this error message contains a random code which references the exception which is also logged by the logging framework for developer reference.


# Use 1 for the default exception handler (enabled by default in production context)
config.contentObjectExceptionHandler = 1

# Use a class name for individual exception handlers
config.contentObjectExceptionHandler = TYPO3\CMS\Frontend\ContentObject\Exception\ProductionExceptionHandler

# Customize the error message. A randomly generated code is replaced within the message if needed.
config.contentObjectExceptionHandler.errorMessage = Oops an error occurred. Code: %s

# Configure exception codes which will not be handled, but bubble up again (useful for temporary fatal errors)
tt_content.login.20.exceptionHandler.ignoreCodes.10 = 1414512813

# Disable the exception handling for an individual plugin/ content object
tt_content.login.20.exceptionHandler = 0

# ignoreCodes and errorMessage can be both configured globally …
config.contentObjectExceptionHandler.errorMessage = Oops an error occurred. Code: %s
config.contentObjectExceptionHandler.ignoreCodes.10 = 1414512813

# … or locally for individual content objects
tt_content.login.20.exceptionHandler.errorMessage = Oops an error occurred. Code: %s
tt_content.login.20.exceptionHandler.ignoreCodes.10 = 1414512813


Instead of breaking the whole page when an exception occurs, an error message is shown for the part of the page that is broken. Be aware that unlike before, it is now possible that a page with error message gets cached. To get rid of the error message not only the actual error needs to be fixed, but the cache must be cleared for this page.

Feature: #50039 - Multiple CSS Files in Rich Text Editor


It is now possible to import more than one CSS file for the Rich Text Editor.

New syntax is:

RTE.default.contentCSS {
    file1 = fileadmin/myStylesheet1.css
    file2 = fileadmin/myStylesheet2.css


The old syntax may still be used. If no CSS files are set, the RTE default CSS file is used as before.

Feature: #51905 - Add dependencies between classes in the Rich Text Editor


It is now possible to configure a class as requiring other classes.

The syntax of this new property is

RTE.classes.[ *classname* ] {
    .requires = list of class names; list of classes that are required by the class;
                if this property, in combination with others, produces a circular relationship, it is ignored;
                when a class is added on an element, the classes it requires are also added, possibly recursively;
                when a class is removed from an element, any non-selectable class that is not required by any of the classes remaining on the element is also removed.


There is no impact on previous configurations.

Feature: #54518 - Provide TSconfig to link checkers


The active TSconfig of the linkvalidator is stored in the LinkAnalyser and made publicly available to the link checkers.

The TSconfig is read either from the currently active TSconfig in the Backend when the linkvalidator is used in the info module or from the configuration provided in the linkvalidator scheduler task.

This allows passing configuration to the different link checkers.


# The configuration in mod.linkvalidator can be read by the link checkers.
mod.linkvalidator.mychecker.myvar = 1


The method signature of `TYPO3CMSLinkvalidator::LinkAnalyser::init()` is changed. A new parameter has been added for submitting the current TSconfig. This can break third party code that extends this method.

Feature: #54519 - Report links to disabled linkhandler records


A new configuration option has been introduced for the linkhandler link checker in the linkvalidator extension:

mod.linkvalidator.linkhandler.reportHiddenRecords = 1

When enabled links will be considered invalid when they point to disabled records. By default only links to deleted records are reported.


The `TYPO3CMSLinkvalidatorLinktype::checkLink()` method has been restructured and will now determine if the linked record is deleted or hidden and report a error depending on the `reportHiddenRecords` configuration.

Feature: #58122 - Configure class as non-selectable in Rich Text Editor


It is now possible to configure a class as non-selectable in the style selectors of the Rich Text Editor.

The syntax of this new property is

RTE.classes.[ *classname* ] {
    .selectable = boolean; if set to 0, the class is not selectable in the style selectors; if the property is omitted or set to 1, the class is selectable in the style selectors


There is no impact on previous configurations.

Feature: #59396 - TypolinkViewHelper


Adding Link and Uri ViewHelper that cope with the contents of any field that was filled with a link wizard in TYPO3 CMS Backend. Those fields contain various parts split by a space and being escaped to provide input for the typoLink function. In order to use those fields natively in Fluid without the need of TypoScript in between, this ViewHelper was introduced. It takes the field content as a whole and can additionally take some parameters directly from Fluid.

The full parameter usage in Fluid might look like this, where {link} is the field content:

<f:link.typolink parameter="{link}" target="_blank" class="ico-class" title="some title" additionalParams="b=u" additionalAttributes="{type:'button'}">

<f:uri.typolink parameter="{link}" additionalParameters="b=u">

Only parameter is required, all other parameters are optional. While passing additional parameters to the ViewHelper, following rules apply:

  • target is overridden, the value from Fluid applies
  • class is merged from the values passed from the database and those of class
  • title is overridden, the value from Fluid applies
  • additionalParams is merged from the values passed from the database and those of additionalParams
  • additionalAttributes is (as usual) added to the resulting tag as type="button"

{link} contains 19 _blank - "testtitle with whitespace" &X=y. In case of the Uri.Typolink Viewhelper, only the first and the fourth parameter of the field content are taken into account, the tag related properties are discarded. For the given examples, the output is:

<a href="index.php?id=19&X=y&b=u" title="some title" target="_blank" class="ico-class" type="button">



The new ViewHelper can be used in all new projects. There is no interference with any part of existing code.

Feature: #59830 - Introduce read-only column for file mounts


File mount records now have a new flag "read only". This flag replaces the virtual flag introduced earlier, so it can be defined natively in the record.


The impact is low as the old behavior still exists. A storage was never marked as read-only before. There is an option to set this through UserTs, but now it is also possible to set it on the storage record directly.

Feature: #60064 - Logging Framework Introspection Processor


The introspection processor of the logging framework has been extended to log the full PHP backtrace and not only the last element of a backtrace.

Two options were added to enable this feature:

  •  :code:`appendFullBackTrace`, boolean, not mandatory` Add full backtrace to the log
  •  :code:`shiftBackTraceLevel`, integer, default 0, not mandatory` Removes the given number of entries from the top of the backtrace stack.


The introspection processor behaves as before as long as the feature is not explicitly configured.

Feature: #60123 - Unit base test case removes test files


Some unit tests need to create test files or directories to check the system under test. Those files should be removed again. A test can now register absolute file paths in :code:`$this->testFilesToDelete`, and the generic :code:`tearDown()` method will then remove them. Only files, links and directories within typo3temp/ are allowed.


This allows tests to clean up the environment without leaving obsolete test files behind.

Feature: #60567 - Show Styles Segment in TS Object Browser


The TypoScript Object Browser now shows the setup segment :code:`styles.`


The segment is cached in the Frontend and not unset anymore, page cache entries increase slightly in size.

Feature: #60822 - Class annotations in extbase reflection service


The extbase reflection service can now return tags/annotations added to a class.

Suppose the given class:

 * @SomeClassAnnotation A value
 class Foo {

Those annotation can be fetched with the reflection service:

$service = new \TYPO3\CMS\Extbase\Reflection\ReflectionService();
$classValues = $service->getClassTagsValues('Foo');
$classValue = $service->getClassTagValue('Foo', 'SomeClassAnnotation');


Getting class tags by ReflectionService is now possible.

Feature: #66185 - Allow Svg Files as Extension icon


Extension authors can ship Extensions with an ext_icon file with the suffixes .png, .svg and .gif.


Extension icons might be rendered better when provided as vector graphics and not as bitmaps.

Feature: #61289 - Signal for IconUtility html tag manipulation


This signal allows to manipulate the rendered html code for a sprite icon by an extension.

Currently all sprite icons are rendered as :code: <span class="">&nbsp;</span>`.

Extensions can now adjust the html tag, add or remove attributes and define own content in between the html tags.


The rendered html code is no longer a span with fixed classes, but can be modified by an extension.

Feature: #61351 - Add data attribute to Fluid ViewHelpers


Since HTML5 Elements can contain a generic data attribute, Fluid provides for those elements the possibility to add key-value pairs as array, which will be rendered as `data-$key="$value"`.

<f:form.textfield data="{foo: 'bar', baz: 'foos'}" />


Generic data attributes do not need to be passed by the `additionalAttributes` array anymore making the viewhelper more straightforward to use.

Feature: #61361 - Template Path Fallback for Fluid StandaloneView and FLUIDTEMPLATE



Earlier in the development of Fluid, a template fallback was introduced in the TemplateView, providing the possibility to pass a set of possible file locations to the View Configuration, where Templates, Layouts and Partials can be found.

The same functionality is now available in the StandaloneView. It is possible to let the system look up the fitting paths for Partials and Layouts. It is in the nature of the StandaloneView to get a specific template file set, so for Templates there is no lookup requirement.

As a developer or integrator, you can configure your View as follows:

$view = $this->objectManager->get(\TYPO3\CMS\Fluid\View\StandaloneView::class);
$view->setTemplatePathAndFileName(ExtensionManagementUtility::extPath('myExt') . 'Resources/Private/Templates/Email.html');
  'default' => ExtensionManagementUtility::extPath('myExt') . 'Resources/Private/Layouts',
  'specific' => ExtensionManagementUtility::extPath('myTemplateExt') . 'Resources/Private/Layouts/MyExt',
  'default' => ExtensionManagementUtility::extPath('myExt') . 'Resources/Private/Partials',
  'specific' => ExtensionManagementUtility::extPath('myTemplateExt') . 'Resources/Private/Layouts/MyExt',
  'evenMoreSpecific' => 'fileAdmin/templates/myExt/Partials',

With this, the View will first look up the requested layout file in the path with the key :code:`specific`, and in case there is no such file, it will fall back to :code:`default`. For the partials the sequence would be :code:`evenMoreSpecific`, then :code:`specific`, then fall back to :code:`default`.

You are free in the naming of the keys. The paths are searched from bottom to top. In case you choose for numeric array keys, the array is ordered first, then reversed for the lookup, so the highest index is accessed first.


Additionally the TypoScript Content Object FLUIDTEMPLATE, which is based on StandaloneView, also supports this kind of fallback mechanism. Two new TypoScript options are added for this purpose:

  • partialRootPaths
  • layoutRootPaths

Example usage:

page.10.file = EXT:sitedesign/Resources/Private/Templates/Main.html
page.10.partialRootPaths {
  10 = EXT:sitedesign/Resources/Private/Partials
  20 = EXT:sitemodification/Resources/Private/Partials

In case you're using the old options (partialRootPath, layoutRootPath) together with the new options, the content of the old options will be placed at the first position (index zero) in the fallback list.


In order to change the skin of an extension output, provided by the Fluid StandaloneView, you are no longer required to copy the whole Resources folder into fileadmin or to some specific location, but you can pick only the files you want to change. Those need to be organized in folders, which are then configured for the view. The system will fall through all the provided locations, taking the first fitting file it finds.

Feature: #61489 - Allow own TypoScript Condition implementations


It is now possible to add own TypoScript conditions via a separate API.

An extension / package can now ship an implementation of a new abstract class AbstractCondition. Via the existing TypoScript Condition Syntax the class is called by the simple full namespaced class name. The class's main function "matchCondition" can flexibly evaluate any parameters given after the class name.



[BigCompanyName\TypoScriptLovePackage\BennisTypoScriptCondition = 7]

[BigCompanyName\TypoScriptLovePackage\BennisTypoScriptCondition = 7, != 6]

[BigCompanyName\TypoScriptLovePackage\BennisTypoScriptCondition = {$mysite.myconstant}]

where the TypoScript Condition class deals with =/!= etc itself.


If you've previously used the "userFunc" condition, you are encouraged to use this new API for your own TypoScript conditions.

Feature: #61529 - Add multiple parameter to f:form.checkbox


Introduce parameter "multiple" for f:form.checkbox ViewHelper.

<f:form action="create" method="POST" name="pizza" object="{pizza}">
    <f:form.checkbox property="covering" multiple="1" value="salami" /><br />
    <f:form.checkbox property="covering" multiple="1" value="ham" /><br />
    <f:form.checkbox property="covering" multiple="1" value="cheese" /><br />
    <f:form.submit value="Send" />


If you add the parameter "multiple" to your checkboxes, it automatically appends [] to the name of your checkbox.

Feature: #61577 - Backend markup for checkboxes with labels


A typical checkbox with label form element should now be rendered as:

<div class="checkbox">
    <label for="someId">
        <input type="checkbox" id="someId" />
        Label text


If this HTML markup is applied, CSS styles by the TYPO3 core will take care of optimized view and custom CSS has become obsolete.

Feature: #61668 - Video and audio playback in backend record information


The record information popup ("i" symbol) can play certain html5 video and audio types. This is especially useful in the "file list" module.


Better usability of media files.

Feature: #61800 - Registry for adding file rendering classes


To be able to render all kinds of media files a file rendering registry is needed where you can register a "renderer" class that can generate the needed HTML output.

Every renderer has a priority between 1 and 100, 100 is more important than 1. When the rendererRegistry is asked for a renderer that fits a given file all registered renderer classes are "asked", in order of priority, if they are able to render the file. The first renderer class that can render the file an instance is returned by the rendererRegistry.

Every registered renderer class needs to implement the FileRendererInterface. This makes sure the class has a getPriority(), canRender() and render() method.

  • getPriority() returns integer between 1 and 100
  • canRender() gets a file(Reference) object as parameter and returns TRUE if the class is able to render the file It checks on mime-type but also storage type etc. can be performed to determine if creating the correct output is possible
  • render() also gets the file(Reference) object as parameter together with width, height and an optional options array the return value is the HTML output

A AudioTagRenderer and VideoTagRenderer have already been added.

It is possible to register your own renderer classes in the ext_localconf.php of an extension.


$rendererRegistry = \TYPO3\CMS\Core\Resource\Rendering\RendererRegistry::getInstance();


The registry on its own doesn't do anything. Some followup patches are needed to use this registry to find the correct renderer class for rendering videos and other media files in BE preview and FE.

Feature: #62147 - New eval option in TCA: email


A new option has been added to the eval field: email. This will check if the entered value is a valid e-mail address server-side. If not, a flash error message will be shown.


'email' => array(
    'exclude' => 1,
    'label' => 'LLL:EXT:wd_products/Resources/Private/Language/',
    'config' => array(
        'type' => 'input',
        'size' => 30,
        'eval' => 'email,trim'


Users don't have to write their own validation classes for e-mail validation.