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: #15619 - Access module: Allow selector as "unchanged"


In order to only overwrite permissions in the access module and not the owner/group it is now possible to set the selector to " - leave unchanged - ".

Feature: #16794 - Linking of Indexed Search result sections


Per default the section headlines of indexed search results are links. It is possible to disable those links, thus having the sections displayed as simple text.

plugin.tx_indexedsearch.linkSectionTitles = 0

Will result in not linked section headlines. The setting is per default set to 1 in order to preserve current behaviour.

Feature: #20767 - Allow nested array access on getData of field


Right now the getData type in TS only allows to access nested arrays in types GPVar and TSFE. Now the same is allowed for field too.

If the field value is :code:`array('somekey' => array('level1' => array('level2' => 'somevalue')));`, you can get the somevalue by configuring the following TypoScript.

10 = TEXT = field:fieldname|level1|level2


You can now access nested keys via getData field:. Nested keys are not available with the default set of content objects, however just content objects and USER object may return such a field structure.

Feature: #22086 - Add .stdWrap to page.headTag option


The TypoScript setting page.headTag now has stdWrap functionality available.

The new option can be set like this:

page = PAGE
page.headTag = <head>
page.headTag.override = <head class="special">
page.headTag.override.if {
  isInList.field = uid
  value = 24

Feature: #24906 - Configuration for maximum chars in TextElement


TCA type text now supports the HTML5 attribute maxlength to restrict text to a given maximum length. Line breaks are usually counted as two characters.

Not every browser supports this, see sites like for details.

The new option can be used like this:

'teaser' => array(
    'label' => 'Teaser',
    'config' => array(
        'type' => 'text',
        'cols' => 60,
        'rows' => 2,
        'max' => '30',

Feature: #28382 - Add async property to JavaScript files


Add a property async="async" to JavaScript files via TypoScript

page.includeJSlibs.<array>.async = 1

This patch affects the TypoScript PAGE properties

  • includeJSLibs
  • includeJSFooterlibs
  • includeJS
  • includeJSFooter


page {
    includeJS {
        jsFile = /Path/To/jsFile.js
        jsFile.async = 1

Feature: #33491 - Add stdWrap functionality to <title> tag


The <title> tag of a frontend page can already be controlled by various settings via TypoScript. However, the stdWrap part was not available yet, but is now compliant and available as an option config.pageTitle. This option will be executed after all other existing processing options like config.titleTagFunction and config.pageTitleFirst.

The new option can be used like this, e.g. in order to write everything in uppercase in the title tag:

page = PAGE = upper

Feature: #34944 - PaginateViewHelper handles non-query-result objects


The PaginateViewHelper accepts input collections of following types:

  •  :code:`QueryResultInterface`
  •  :code:`ObjectStorage`
  •  :code:`ArrayAccess`
  •  :code:`array`
<f:widget.paginate objects="{blogs}" as="paginatedBlogs">
    <f:for each="{paginatedBlogs}" as="blog">

Feature: #35891 - FormEngine: Possibility to add icons via PageTSconfig


The possibility to add a new value/label pair for a select field in FormEngine is given via the pageTSconfig option "addItems". Now, it is also possible to give the items an icon. Either with the .icon subproperty or with the separate option "altIcons".

TCEFORM.pages.doktype.addItems {
    13 = My Label
    13.icon = EXT:t3skin/icons/gfx/i/pages.gif
TCEFORM.pages.doktype.altIcons {
    123 = EXT:myext/icon.gif

If the path is not prefixed with "EXT:" it needs to be relative to the typo3/ directory.

Feature: #46624 - HMENU item selection via additionalWhere


The TypoScript Content Object HMENU menu options have a new property called "additionalWhere" to allow for a more specific database query based on any page properties.

lib.authormenu = HMENU
lib.authormenu.1 = TMENU
lib.authormenu.1.additionalWhere = AND author!=""

Feature: #47666 - Attribute "multiple" for f:form.upload Viewhelper


The Viewhelper allows now an attribute "multiple", that will provide a possibility to upload several files at once.

<f:form.upload property="files" multiple="multiple" />

Will result in the according HTML tag providing the field content as array.

Be aware, that you need to prepare the incoming value for the property mapping yourself, by writing your own TypeConverter.

Feature: #49060 - MySql Comments reflected in SchemaMigrator


Comments in the :[file: file:]`*.sql` files are stored the database table and shown by the Schema Migration Feature in Install Tool.

Existing comments are overriden with changes provided by other extensions.

Feature: #50780 - Append element browser mount points


A new UserTSconfig option is introduced:


This option allows administrators to add additional mount points in the RTE and the Wizard element browser instead of replacing the configured database mount points of the user when using the existing UserTSconfig option:



Set these options in User TSconfig:

options.pageTree.altElementBrowserMountPoints = 20,31
options.pageTree.altElementBrowserMountPoints.append = 1


Mount point overriding is centralized in the BackendUser object and used by element browsers of rtehtmlarea and recordlist for calculating the page tree mount points that are displayed to the user.

Feature: #52131 - Hook for end of PageRepository->init()


A new hook at the very end of the PageRepository->init() has been introduced. This function allows manipulation of where clause in order to modify select queries that involve visibility of pages.

Register the hook as follows:


The hook class must implement the interface :code:`TYPO3CMSFrontendPagePageRepositoryInitHookInterface`.

Feature: #56236 - Multiple HTTP headers of the same type in Frontend Output


It is now possible to use config.additionalHeaders as a TypoScript array object to add multiple headers at the same time


config.additionalHeaders {
    10 {
        # the header string
        header = WWW-Authenticate: Negotiate

        # replace previous headers with the same name
        # optional, default is "on"
        replace = 0

        # optional, force the HTTP response code
        httpResponseCode = 401
    # always set cache headers to private, overwriting the sophisticated TYPO3 option
    20.header = Cache-control: Private

See also:


The previous option config.additionalHeaders = X-Header: ABC|X-Header2: DEF is deprecated in favor of the more flexible solution.

Feature: #56529 - Support "has*" Functions in ObjectAccess


ObjectAccess supports "is" and "get" functions to return property values. Another convenience method is "has*", which can be used in the same way.

Feature: #46624 - Additional HMENU browse menus


The TypoScript Content Object HMENU with a special=browse option does not exclude "not in menu" pages nor pages that have a "no search" checkbox set. The two new options allow for more fine-grained selection of the items within the menu.

The existing option "includeNotInMenu" was not available yet for the HMENU with special=browse enabled.

lib.browsemenu = HMENU
lib.browsemenu.special = browse
lib.browsemenu.special.excludeNoSearchPages = 1
lib.browsemenu.includeNotInMenu = 1

Feature: #50039 - Configurable width of the Element Browser


It is now possible to set the width and height of the element browser on a per-user basis via UserTSConfig.


options.popupWindowSize = 400x900 options.RTE.popupWindowSize = 200x200


The Element Browser width and height can be set for better usability and user experience.

Feature: #58033 - Enable label override of checkbox and radio buttons by TSconfig


Use TSconfig to override labels of radio buttons and checkboxes used in FormEngine.

For single checkboxes the key default is used:

TCEFORM.pages.hidden.altLabels.default = individual label
TCEFORM.pages.hidden.altLabels.default = LLL:path/to/languagefile.xlf:individualLabel

For fields with multiple checkboxes, the value or the corresponding numeration (0,1,2,3) of the checkbox is used:

TCEFORM.pages.l18n_cfg.altLabels.0 = individual label for the first checkbox
TCEFORM.pages.l18n_cfg.altLabels.1 = individual label for the second checkbox

The same functionality works on radio buttons, where the "key" is the value of the radio button.

As seen in the example, hard-coded strings or references to language files are allowed.


The feature enables even more customization for FormEngine for any custom crafted backend instance.

Feature: #58366 - Add "auto" Option for config.absRefPrefix


The TypoScript setting config.absRefPrefix can be used to allow URL rewriting like giving a hard prefix for all relative paths. As an alternative to config.baseURL to be set to a specific domain absRefPrefix can autodetect the site root and use that instead of manually setting this option.


The new option can be set like this:

config.absRefPrefix = auto

instead of hardcoded values for different environments or when moving installations in subfolders.

[ApplicationContext = Production]
config.absRefPrefix = /

[ApplicationContext = Testing]
config.absRefPrefix = /my_site_root/

As the feature only works with path prefixes, and not with host name variables from the server, the new option is also safe for multi-domain environments to avoid duplicate caching mechanism.


The new special option can be used to automatically set up installations and distributions like the Introduction Package where a site configuration is shipped with the system but might need to be adjusted.

Feature: #58929 - PageLayoutView: Add hook for tt_content_drawFooter


A hook has been added to the PageLayoutView to manipulate the rendering of the footer of a content element.

Feature: #60019 - New SplFileInfo implementation with new mimeTypeGuessers hook


A new class \TYPO3\CMS\Core\Type\File\FileInfo which extends SplFileInfo is now available as an API for fetching meta information from files.

Besides the native .. _SplFileInfo API:, it provides a new method getMimeType() to get the mime type of a file, e.g. text/html. It uses the native PHP function finfo_file() and mime_content_type() as a fallback.

Example: Get the MIME type of a file

$fileIdentifier = '/tmp/foo.html';
$fileInfo = GeneralUtility::makeInstance(\TYPO3\CMS\Core\Type\File\FileInfo::class, $fileIdentifier);
echo $fileInfo->getMimeType();
// text/html

New Hook 'mimeTypeGuessers'

Custom implementations to determine the MIME type can be added with a hook. Register the hook as follows:


Feature: #61542 - Add two-letter ISO 639-1 keys to sys_language


The handling of the languages is done by the sys_language database table, which is usually referenced via the common sys_language_uid. The commonly referenced ISO 639-1 two-letter-code is only in use when static_info_tables is installed, which brings all ISO 639-1 letter-codes in a separate table. The CMS Core uses a hard-coded dependency on the extension to retrieve the ISO codes where needed, however, already ships an empty and invisible field "static_lang_isocode" which is already supplied by the CMS Core.

As a first step to identify languages by their proper ISO 639-1 two-letter code a new DB field for sys_language called "language_isocode" is introduced, which is used in all places of the TYPO3 CMS Core.

Additionally the new TypoScript option config.sys_language_isocode can be used to set the existing $TSFE->sys_language_isocode variable via TypoScript. Previously this was done via static_info_tables.

The ISO code is also used for the language attribute of the HTML tag. Therefore the setting config.htmlTag_langKey is not needed anymore if it is the same as the ISO code.


Frontend: The value $TSFE->sys_language_isocode is now filled at any time. It can be set via TypoScript, or is automatically set if the config.sys_language_uid parameter is set > 0 from the language_isocode DB field.

# danish by default
config.sys_language_uid = 0
config.sys_language_isocode_default = da

[globalVar = GP:L = 1]
    # isocode is filled by the respective DB value from sys_language (uid 1)
    config.sys_language_uid = 1

    # you can override this of course
    config.sys_language_isocode = fr

The new field can be used in any TypoScript variable like

page.10 = TEXT = TSFE:sys_language_isocode
page.10.wrap = <div class="main" data-language="|">


All ISO code usages based on sys_language in the Backend (FormEngine, Translation Tools) is now done via the new field but still uses static_info_tables as fallback if already in use.

Each sys_language record is now editable with the new DB field to select the respective ISO 639-1 code.


The upgrade wizard makes sure that the new DB field is filled properly so no deprecation warnings are written if static_info_tables in conjunction with the DB field "static_lang_isocode" was used before. If this field is used in a 3rd party extension, the extension developers and site integrators need to make sure it is switched to the new DB field sys_language.language_isocode.

If a site uses multiple languages without static_info_tables each sys_language record should be modified to select the proper ISO 639-1 code for the languages.

Feature: #61711 - Signal at the very end of DataPreprocessor::fetchRecord()


This signal can be used to e.g. manipulate the regTableItems_data array to display that manipulated data in TCEForms.

Feature: #61725 - Hook for BackendUtility::countVersionsOfRecordsOnPage()


Hook to post-process BackendUtility::countVersionsOfRecordsOnPage result. BackendUtility::countVersionsOfRecordsOnPage is used to visualize workspace states in e.g. the page tree.

Register like this:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_befunc.php']['countVersionsOfRecordsOnPage'][] = 'My\Package\HookClass->hookMethod';

Feature: #62944 - UserFunc available as Display Condition


Being able to use userFunc as displayCondition makes it possible to check on any imaginable condition or state. If any situation can not be evaluated with any of the existing checks the developer is free to add an own user function which provides a boolean result whether to show or hide the TCA field.

$GLOBALS['TCA']['tt_content']['columns']['bodytext']['displayCond'] = 'USER:Evoweb\\Example\\User\\ElementConditionMatcher->checkHeaderGiven:any:more:information';

Any parameters can be added (separated by colons) that are sent to the ConditionMatcher class.

Feature: #62960 - Signal for mailer initialization


This signal allows for additional processing upon initialization of a mailer object, e.g. registering a Swift mailer plugin.

Registering the signal:

$signalSlotDispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\SignalSlot\Dispatcher::class);

The slot class:

namespace Vendor\Package\Slots;

use TYPO3\CMS\Core\Mail\Mailer;

class MailerSlot {
     * @param Mailer $mailer
     * @return void
    public function registerPlugin(Mailer $mailer) {
        // Processing here


Extensions may now perform arbitrary processing for every mail.

Feature: #63207 - Split buttons into two groups


The action buttons in Web>List for pages and content elements have been split into two groups to organize the actions as primary and secondary actions. Primary actions are common RUD actions: - Show - Edit - Hide - Delete - Move up/down

Secondary actions keep any other action. If "Extended view" is disabled, the primary actions are now still displayed, the secondary action are collapsed but can be expanded by clicking the expand trigger.


Existing hooks will work like before. If an action is added to one of the two sections, the icon on rootlevel must be reset, please see Migration_.


$cells['primary']['edit'] = '<a class="btn btn-default"><span class="t3-icon fa fa-trash"></span></a>';
$cells['secondary']['edit'] = '<a class="btn btn-default"><span class="t3-icon fa fa-trash"></span></a>';

Icons, that are not added into a section, will be sorted into the secondary group.

Feature: #61489 - Allow own TypoScript Conditions in Backend as well


It is now possible to add own TypoScript conditions via a separate API in the Backend. The API for the frontend was introduced with TYPO3 CMS 7.0.

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 fully namespaced class name. The class' main function "matchCondition" can flexibly evaluate any parameters given after the class name.



[BigCompanyName\TypoScriptLovePackage\MyCustomTypoScriptCondition = 7]

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

[BigCompanyName\TypoScriptLovePackage\MyCustomTypoScriptCondition = {$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: #63729 - API for Twitter Bootstrap modals


Actions that require a users' attention must be visualized by modal windows. TWBS provides those, but extension authors or core developers must take care of its creation and handling themselves.

This API provides a basis to create modal windows with severity representation. For a better UX, if actions (buttons) are attached to the modal, one button must be a positive action. This button should get a btnClass and set as active.

Modals should be used rarely and only for confirmations. For information the TYPO3.Flashmessage API should be used. For complex content, like forms or a lot of information, please use normal pages.



The API provides only two public methods:

  1.  :code:`TYPO3.Modal.confirm(title, content, severity, buttons)`
  2.  :code:`TYPO3.Modal.dismiss()`

Modal Settings

<thead> </thead> <tbody> </tbody>
Name DataType Mandatory Description
title string Yes The title displayed in the modal
content string|jQuery Yes The content displayed in the modal
severity int Represents the severity of a modal. Please see TYPO3.Severity. Default is :code:``.
buttons object[] Actions rendered into the modal footer. If empty, the footer is not rendered. See table below.

Button Settings

<thead> </thead> <tbody> </tbody>
Name DataType Mandatory Description
text string Yes The text rendered into the button.
trigger function Yes Callback that's triggered on button click.
active bool Marks the button as active. If true, the button gets the focus.
btnClass string The css class for the button


It is also possible to use data-attributes to trigger a modal. e.g. on an anchor element, which prevents the default behavior.

<thead> </thead> <tbody> </tbody>
Name Description
data-title the title text for the modal
data-content the content text for the modal
data-severity the severity for the modal, default is info (see TYPO3.Severity.*)
data-href the target URL, default is the href attribute of the element
data-button-close-text button text for the close/cancel button
data-button-ok-text button text for the ok button
code:`class="t3js-modal-trigger"` marks the element as modal trigger


A basic modal without any specials can be created this way:

TYPO3.Modal.confirm('The title of the modal', 'This the the body of the modal');

A modal as warning with button:

TYPO3.Modal.confirm('Warning', 'You may break the internet!', TYPO3.Severity.warning, [
        text: 'Break it',
        active: true,
        trigger: function() {
            // break the net
    }, {
        text: 'Abort!',
        trigger: function() {

A modal as warning:

TYPO3.Modal.confirm('Warning', 'You may break the internet!', TYPO3.Severity.warning);

A modal triggered on an anchor element:

<a href="delete.php" class="t3js-modal-trigger" data-title="Delete" data-content="Really delete?">delete</a>

Feature: #63913 - Allow ContainerViewHelper to load RequireJS modules


The ContainerViewHelper can load RequireJS modules via the includeRequireJsModules attribute. The scripts are passed as array.

<f:be.container pageTitle="Extension Module" loadJQuery="true"

Feature: #64031 - JavaScript Storage API


Accessing the Backend User configuration ($BE_USER->uc) can be handled in JavaScript with a common and simple key-value storage manner, allowing to store any data. Additionally, the use of HTML5s localStorage allows to store any data in the same way inside the browser. All localStorage data is prefixed with "t3-" in order to avoid collisions with other data from the same browserStorage.


API Methods

The API provides two objects available in the top frame attached to the global TYPO3 object:

  1. top.TYPO3.Storage.Client
  2. top.TYPO3.Storage.Persistent

Each object has the following API methods

  • get(key) To fetch the data behind the key.
  • set(key, value) To set/override a key with any arbitrary content.
  • isset(key) (bool) checks if the key is in use.
  • clear() to empty all data inside the storage.


To fetch data from the persistent user configuration, simple use the key known already:


Storing / Updating data in the storage works like this, and can contain any data type.

top.TYPO3.Storage.Persistent.set('startModule', 'web_info');

The same is possible for browserStorage using top.TYPO3.Storage.Client.

Feature: #64190 - Inline rendering for FormEngine Checkbox Element


The checkbox setting inline for cols can be used to render the checkboxes directly next to each other to reduce the amount of used space.

Example Configuration:

'weekdays' => array(
    'label' => 'Weekdays',
    'config' => array(
        'type' => 'check',
        'items' => array(
            array('Mo', ''),
            array('Tu', ''),
            array('We', ''),
            array('Th', ''),
            array('Fr', ''),
            array('Sa', ''),
            array('Su', ''),
        'cols' => 'inline',


Checkboxes will be placed directly next to each other to reduce the amount of used space.

Feature: #64257 - Support multiple UID in PageRepository::getMenu()


An array of uid values can be passed to PageRepository::getMenu(), providing the chance to build menus from several roots.

Example: Fetch children of pages #2 and #3:

$pageRepository = new \TYPO3\CMS\Frontend\Page\PageRepository();
$rows = $pageRepository->getMenu(array(2, 3));

Feature: #64386 - Public Content Object Registration


A new global option is now available to register and/or extend/overwrite content objects like TEXT. A list of all available Content Objects that was previously registered within the main ContentObjectRenderer class is now moved to the global array $GLOBALS['TYPO3_CONF_VARS']['FE']['ContentObjects'] which allows for modifications via third-party extensions.

Example: Register a new Content Object EXAMPLE in a third-party extension

$GLOBALS['TYPO3_CONF_VARS']['FE']['ContentObjects']['EXAMPLE'] = Acme\MyExtension\ContentObject\ExampleContentObject::class

The registered class must be a subclass of TYPO3\CMS\Frontend\ContentObject\AbstractContentObject.

For future autoloading mechanisms, it is encouraged to place the custom ContentObject class inside EXT:myextension/Classes/ContentObject/.

Feature: #64921 - Needed changes for flexible configuration of submodules


The additional configuration for submodules can now be configured with an extra parameter in ExtensionManagementUtility::addModule() since This makes it possible to remove the conf.php file by setting the configuration within ExtensionManagementUtility::addModule() in ext_tables.php.

When doing so you might have some issues with $this->MCONF not being set. This happens if your backend module extends from \TYPO3\CMS\Backend\Module\BaseScriptClass.

To fix this problem you need to add the module name in $this->MCONF.

 * The name of the module
 * @var string
protected $moduleName = 'file_list';

 * Constructor
public function __construct() {
    $this->MCONF = array(
        'name' => $this->moduleName