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: #59606 - Integrate Symfony/Console into CommandController


The CommandController now makes use of Symfony/Console internally and provides various methods directly from the CommandController's output member:

  • TableHelper

    • outputTable($rows, $headers = NULL)
  • DialogHelper

    • select($question, $choices, $default = NULL, $multiSelect = false, $attempts = FALSE)
    • ask($question, $default = NULL, array $autocomplete = array())
    • askConfirmation($question, $default = TRUE)
    • askHiddenResponse($question, $fallback = TRUE)
    • askAndValidate($question, $validator, $attempts = FALSE, $default = NULL, array $autocomplete = NULL)
    • askHiddenResponseAndValidate($question, $validator, $attempts = FALSE, $fallback = TRUE)
  • ProgressHelper

    • progressStart($max = NULL)
    • progressSet($current)
    • progressAdvance($step = 1)
    • progressFinish()

Here's an example showing of some of those functions:

namespace Acme\Demo\Command;

use TYPO3\CMS\Extbase\Mvc\Controller\CommandController;

 * My command
class MyCommandController extends CommandController {

     * @return string
    public function myCommand() {
        // render a table
            array('Bob', 34, 'm'),
            array('Sally', 21, 'f'),
            array('Blake', 56, 'm')
        array('Name', 'Age', 'Gender'));

        // select
        $colors = array('red', 'blue', 'yellow');
        $selectedColorIndex = $this->output->select('Please select one color', $colors, 'red');
        $this->outputLine('You choose the color %s.', array($colors[$selectedColorIndex]));

        // ask
        $name = $this->output->ask('What is your name?' . PHP_EOL, 'Bob', array('Bob', 'Sally', 'Blake'));
        $this->outputLine('Hello %s.', array($name));

        // prompt
        $likesDogs = $this->output->askConfirmation('Do you like dogs?');
        if ($likesDogs) {
            $this->outputLine('You do like dogs!');

        // progress
        for ($i = 0; $i < 300; $i ++) {



This change does not alter the public API so it is not breaking in the strict sense. But it introduces a new behavior: Previously all output was collected in the Cli\Response and only rendered to the console at the end of a CLI request. Now all methods producing output (including output() and outputLine()) render the result directly to the console. If you use $this->response directly or let the command method return a string, the rendering is still deferred until the end of the CLI request.

Feature: #62242 - ActionMenuItemGroupViewHelper


Using this ViewHelper, OptGroups can be used in the backend select field, which controls which action is selected.


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


Usage example:

    <f:be.menus.actionMenuItem label="Default: Welcome" controller="Default" action="index" />
    <f:be.menus.actionMenuItem label="Community: get in touch" controller="Community" action="index" />

    <f:be.menus.actionMenuItemGroup label="Information">
        <f:be.menus.actionMenuItem label="PHP Information" controller="Information" action="listPhpInfo" />
        <f:be.menus.actionMenuItem label="Documentation" controller="Information" action="documentation" />
        <f:be.menus.actionMenuItem label="Hooks" controller="Information" action="hooks" />
        <f:be.menus.actionMenuItem label="Signals" controller="Information" action="signals" />
        <f:be.menus.actionMenuItem label="XClasses" controller="Information" action="xclass" />

Feature: #63453 - Template support for FlashMessagesViewHelper


Template support for FlashMessagesViewHelper has been added. This allows to define a custom rendering for flash messages.

The new attribute as for the FlashMessagesViewHelper allows to specify a variable name, which can be used within the view helper's child elements to access the flash messages.

Example usage:

<f:flashMessages as="flashMessages">
    <ul class="myFlashMessages">
        <f:for each="{flashMessages}" as="flashMessage">
            <li class="alert {flashMessage.class}">
                <span class="fancy-icon">{flashMessage.message}</span>

Feature - #63561: Add TypoScript stdWrap strtotime


A new TypoScript property strtotime is now available within stdWrap which allows for conversion of formatted dates to timestamp, e.g. to perform date calculations.

Possible values are 1 or any time string valid as first argument of the PHP strtotime() function.

Basic usage to convert date string to timestamp:

date_as_timestamp = TEXT
date_as_timestamp {
    value = 2015-04-15
    strtotime = 1

Convert incoming date string to timestamp, perform date calculation and output as date string again:

next_weekday = TEXT
next_weekday {
    data = GP:selected_date
    strtotime = + 2 weekdays
    strftime = %Y-%m-%d


The new property is available everywhere in TypoScript where stdWrap is applied.

Feature: #65250 - TypoScript condition add GPmerged


If one uses TypoScript condition with GP then the check is with GeneralUtility::_GP() which means that if I have GET variables beginning with an extbase plugin-namespace and POST variables with the same plugin-namespace, e.g. GET: tx_demo_demo[action]=detail POST: tx_demo_demo[name]=Foo then GeneralUtility::_GP('tx_demo_demo'), as intended, will only return the array of the POST variables for that namespace. However, that results in the issue that if you check for the GET variable the check will fail.

So, instead the check should use GeneralUtility::_GPmerged()

[globalVar = GPmerged:tx_demo|foo = 1]
page.90 = TEXT
page.90.value = DEMO

Feature: #66111 - Add TemplateRootPaths support to cObject FLUIDTEMPLATE


cObject FLUIDTEMPLATE has been extended with templateRootPaths and templateName. Now you can set a template name and when rendering the template this name is used together with the set format to find the template in the given templateRootPaths with the same fallback logic as layoutRootPath and partialRootPath

  • templateName = string/stdWrap
  • templateRootPaths = array of file paths with "EXT:" prefix support

Example 1:

lib.stdContent = FLUIDTEMPLATE
lib.stdContent {
    templateName = Default
    layoutRootPaths {
        10 = EXT:frontend/Resources/Private/Layouts
        20 = EXT:sitemodification/Resources/Private/Layouts
    partialRootPaths {
        10 = EXT:frontend/Resources/Private/Partials
        20 = EXT:sitemodification/Resources/Private/Partials
    templateRootPaths {
        10 = EXT:frontend/Resources/Private/Templates
        20 = EXT:sitemodification/Resources/Private/Templates
    variable {
        foo = bar

Example 2:

lib.stdContent = FLUIDTEMPLATE
lib.stdContent {

    templateName = TEXT
    templateName.stdWrap {
        cObject = TEXT
        cObject {
            data = levelfield:-2,backend_layout_next_level,slide
            override.field = backend_layout
            split {
                token = frontend__
                1.current = 1
                1.wrap = |
        ifEmpty = Default
    layoutRootPaths {
        10 = EXT:frontend/Resources/Private/Layouts
        20 = EXT:sitemodification/Resources/Private/Layouts
    partialRootPaths {
        10 = EXT:frontend/Resources/Private/Partials
        20 = EXT:sitemodification/Resources/Private/Partials
    templateRootPaths {
        10 = EXT:frontend/Resources/Private/Templates
        20 = EXT:sitemodification/Resources/Private/Templates
    variable {
        foo = bar


If templateName and templateRootPaths are set the template and file options are neglected.

Feature - #66173: Allow page title edit by doubleclick


A user can edit the page title in the "Page" and the "List" module by double-clicking the page header.


If a user has sufficient permissions, the page title will become a text field after double-clicking on it. Pressing the "escape" key aborts the edit, pressing "enter" submits the changes.

Feature - #66269: Fluid: Remove ViewHelper xmlns-attributes and specified html tag


With the introduction of using xmlns:* attributes to include ViewHelpers, it is possible to have IDE support for Fluid templates. However, the problem is that the xmlns:* attributes and the corresponding tag will also be rendered, which is not desired most of the time. A workaround to avoid this is to use sections. However, this solution is counter-intuitive, is not available in layouts and causes extra processing overhead.

<html xmlns:f=""

<f:section name="content">


The xmlns:* attributes for valid ViewHelper namespaces will now be removed before rendering. Such ViewHelper namespaces follow this URI pattern:<phpNamespace>


xmlns attributes for non-ViewHelper namespaces will be preserved.

Furthermore an additional data-attribute to HTML-Tags is introduced.


If this attribute is specified on the HTML-Tag, the HTML-tag itself won't be rendered as well. (Also a corresponding closing tag will not be rendered for that template.) This is useful for various IDEs and HTML auto-completion.


Include ViewHelper namespaces on an existing tag (e.g. root xml tag) via xmlns attributes for Fluid and News extension.

&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt;
&lt;root xmlns:f=&quot;;

    &lt;f:if condition=&quot;{newsItem.title}&quot;&gt;

Output is then

&lt;root xmlns:foo=&quot;; &gt;

Include ViewHelper namespaces with HTML-tag and a data-namespace-typo3-fluid="true" attribute via xmlns attributes for Fluid and News extension.

<html data-namespace-typo3-fluid="true"

    <f:if condition="{newsItem.title}">

The output contains everything excluding the HTML-tag.

Feature: #66669 - BE login form API


The backend login has been completely refactored and a new API has been introduced. The OpenID form has been extracted and is now using the new API as well and is completely independent of the central Core classes for the first time.

Registering a login provider

The concept of the new backend login is based on "login providers". A login provider can be registered within your ext_localconf.php file like this:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders'][1433416020] = [
    'provider' => \TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::class,
    'sorting' => 50,
    'icon-class' => 'fa-key',
    'label' => 'LLL:EXT:backend/Resources/Private/Language/'

The settings are defined as:

  • provider: The login provider class name, which must implement TYPO3\CMS\Backend\LoginProvider\LoginProviderInterface.
  • sorting: The sorting is important for the ordering of the links to the possible login providers on the login screen.
  • icon-class: The font-awesome icon name for the link on the login screen.
  • label: The label for the login provider link on the login screen.

For a new login provider you have to register a new key - a unix timestamp - in $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders']. If your login provider extends another one, you may only overwrite necessary settings. An example would be to extend an existing provider and replace its registered 'provider' class with your new class name.

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['backend']['loginProviders'][1433416020]['provider'] = CustomProviderExtendingUsernamePasswordLoginProvider::class


The LoginProviderInterface contains only one method:

public function render(StandaloneView $view, PageRenderer $pageRenderer, LoginController $loginController);

The parameters are defined as:

  • $view: The Fluid StandaloneView which renders the login screen. You have to set the template file and you may add variables to the view according to your needs.
  • $pageRenderer: The PageRenderer instance provides possibility to add necessary JavaScript resources.
  • $loginController: The LoginController instance.

The View

As mentioned above, the render method gets the Fluid StandaloneView as first parameter. You have to set the template path and filename using the methods of this object. The template file must only contain the form fields, not the form-tag. Later on, the view renders the complete login screen.

View requirements:

  • The template must use the Login-layout provided by the Core <f:layout name="Login">.
  • Form fields must be provided within the section <f:section name="loginFormFields">.
<f:layout name="Login" />
<f:section name="loginFormFields">
    <div class="form-group t3js-login-openid-section" id="t3-login-openid_url-section">
        <div class="input-group">
            <input type="text" id="openid_url" name="openid_url" value="{presetOpenId}" autofocus="autofocus" placeholder="{f:translate(key: 'openId', extensionName: 'openid')}" class="form-control input-login t3js-clearable t3js-login-openid-field" />
            <div class="input-group-addon">
                <span class="fa fa-openid"></span>


Within the Core you can find two best practice implementations:

  1. EXT:backend, which implements the UsernamePasswordLoginProvider (the default)
  2. EXT:openid, which implements the OpenIdLoginProvider and adds a second login option


All extensions which add additional fields to the login form must be updated and make use of the new BE login form API.

Feature: #66681 - CategoryRegistry: add options to set l10n_mode and l10n_display


Class CategoryRegistry->addTcaColumn got options to set l10n_mode and l10n_display. The values can be set via:

        'l10n_mode' => 'string (keyword)',
        'l10n_display' => 'list of keywords'

Feature: #66697 - Add uppercamelcase and lowercamelcase to


To make it possible to change a value from underscored to "upperCamelCase" or "lowerCamelCase" the options uppercamelcase and lowercamelcase are added to

tt_content = CASE
tt_content {
    key {
        field = CType

    my_custom_ctype =< lib.userContent
    my_custom_ctype {
        file = EXT:site_base/Resources/Private/Templates/SomeOtherTemplate.html
        settings {
            extraParam = 1

    default =< lib.userContent
    default {
        file = TEXT
        file.field = CType = uppercamelcase
        file.wrap = EXT:site_base/Resources/Private/Templates/|.html

Feature: #66698 - Add integrity property to JavaScript files


Add a property integrity="some-hash" to JavaScript files via TypoScript

page.includeJSLibs.<array>.integrity = some-hash

This patch affects the TypoScript PAGE properties

  • includeJSLibs
  • includeJSFooterLibs
  • includeJS
  • includeJSFooter


page {
    includeJS {
        jQuery = fileadmin/jquery-1.10.2.min.js
        jQuery.disableCompression = 1
        jQuery.excludeFromConcatenation = 1
        jQuery.integrity = sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=

Integrity hashes may be generated using

Feature: #66709 - Add TemplateRootPaths support to Fluid/View/StandaloneView


The StandaloneView is extended with setTemplateRootPaths($templatePaths) and setTemplate($templateName, $throwException = TRUE). Now you can set a template by name.

When setTemplate($templateName) is called the $templateName is used to find the template in the given templateRootPaths with the same fallback logic as layoutRootPath and partialRootPath.

Basic example:

$view = GeneralUtility::makeInstance(StandaloneView::class);

try {
} catch (InvalidTemplateResourceException $e) {
    // no template $templateName found in given $templatePaths

$content = $view->render();

Example of rendering a email template:

$view = GeneralUtility::makeInstance(StandaloneView::class);

$emailBody = $view->render();


The public API of TYPO3\CMS\Fluid\View\StandaloneView is enhanced with the methods
setTemplateRootPaths($templatePaths) and setTemplate($templateName, $throwException = TRUE)

Feature: #66822 - Allow Sprites For Backend Modules


Backend Modules (both Main Modules like "Web" and Submodules like "Filelist") can now use sprites instead of images for displaying the icons in the module menu on the left side of the TYPO3 Backend.

Registering a module can now look like this (as an example the "Page" module):

    \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY) . 'Modules/Layout/',
        'script' => '_DISPATCH',
        'access' => 'user,group',
        'name' => 'web_layout',
        'configuration' => array(
            'icon' => 'module-web',
        'labels' => array(
            'll_ref' => 'LLL:EXT:cms/layout/locallang_mod.xlf',

One can use any available sprite icon known to TYPO3.

Feature: #66907 - Add Data Processing to FLUIDTEMPLATE content object


cObject FLUIDTEMPLATE has been extended with dataProcessing. This setting can be used to add one or multiple processors to manipulate the $data variable of the currently rendered content object, like tt_content or page.

  • dataProcessing = array of class references by full namespace


my_custom_ctype = FLUIDTEMPLATE
my_custom_ctype {
    templateRootPaths {
        10 = EXT:your_extension_key/Resources/Private/Templates
    templateName = CustomName
    settings {
        extraParam = 1
    dataProcessing {
        1 = Vendor\YourExtensionKey\DataProcessing\MyFirstCustomProcessor
        2 = Vendor2\AnotherExtensionKey\DataProcessing\MySecondCustomProcessor
        2 {
            options {
                myOption = SomeValue


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

Feature: #67071 - Processed files cleanup tool added in Install Tool


The Install Tool now provides a new tool to remove processed files (e.g. image thumbnails) from FAL in its "Clean up" section.

The tool is useful if you change graphic-related settings or after updating GraphicsMagick/ImageMagick on the server and you want all files to be regenerated.

Feature: #67229 - FormEngine NodeFactory API


The FormEngine class construct was moved to a tree approach with container classes as inner nodes and element classes (the rendering widgets) as leaves. Finding, instantiation and preparation of those classes is done via TYPO3\CMS\Backend\Form\NodeFactory.

This class was extended with an API to allow flexible overriding and adding of containers and elements:

Registration of new nodes and overwriting existing nodes

This registers the class MyVendor\MyExtension\Form\Element\T3editorElement as render class for the type input. It will be called to render elements of this type and must implement the interface TYPO3\CMS\Backend\Form\NodeInterface. The array key is the unix timestamp of the date when an registry element is added and is just used to have a unique key that is very unlikely to collide with others - this is the same logic that is used for exception codes. If more than one registry element for the same type is registered, the element with highest priority wins. Priority must be set between 0 and 100. Two elements with same priority for the same type will throw an exception.

The core extension t3editor uses this API to substitute a type=text field with renderType=t3editor from the default TextElement to its own T3editorElement.

This registry both allows completely overriding existing implementations of any existing given type as well as registration of a new renderType for own fancy elements. A TCA configuration for a new renderType and its nodeRegistry could look like:

'columns' => array(
    'bodytext' => array(
        'config' => array(
            'type' => 'text',
            'renderType' => '3dCloud',

$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeRegistry'][1433197759] = array(
    'nodeName' => '3dCloud',
    'priority' => 40,
    'class' => \MyVendor\MyExtension\Form\Element\ShowTextAs3dCloudElement::class,

Resolve class resolution to different render classes

In case the above API is not flexible enough, another class can be registered to resolve the final class that renders a certain element or container differently:

// Register FormEngine node type resolver hook to render RTE in FormEngine if enabled
$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeResolver'][1433198160] = array(
    'nodeName' => 'text',
    'priority' => 50,
    'class' => \MyVendor\MyExtension\Form\Resolver\MyTextNodeResolver::class,

This registers a resolver class at priority 50 if the type text should be rendered. This class must implement TYPO3\CMS\Backend\Form\NodeResolverInterface and can return a different class name that is called as render class. The render class in turn must implement TYPO3\CMS\Backend\Form\NodeInterface.

The array key is a unix timestamp of the date when this resolver code is registered. Multiple resolvers are a chain, the resolver with highest priority is asked first, and the chain is called until one resolver returns a new class name. If no resolver returns anything, the default class name will be instantiated and rendered.

Priority is between 0 and 100 and two resolvers for the same type and same priority will throw an exception.

The resolver will receive the full globalOptions array with all settings to make a resolve decision on all incoming values.

This API is used by core extension rtehtmlarea to route the rendering of type=text to its own RichTextElement class in case the editor is enabled for this field and for the user.

This API allows fine grained resolution of render-nodes based on any need, for instance it would be easily possible to call another different richtext implementation (eg. TinyMCE) for specific fields of own extensions based on moon phases or your fathers birthday, by adding a resolver class with a higher priority.


The internal data given to the resolver class still may change. Both the globalOptions and the current renderType values are subject to change without further notice until TYPO3 CMS 7 LTS.

Feature: #67319 - Add field "copyright" to EXT:filemetadata


The field "copyright" has been added to the meta data of a FAL record


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