Typo3 Core API

TYPO3 Core APIs latest documentation
1 of 145
https://docs.typo3.org/typo3cms/CoreApiReference/latest/singlehtml/
Docs TYPO3 Core APIs latest documentation
Previous Key: doc_core_api

Version:
latest
Language:
en
Description:
Reference to the Core APIs of TYPO3, e.g. main classes, Extension API, RTE API.
Keywords:
tsref, typoscript, reference, forDevelopers, forAdvanced
Copyright:
2000-2015
Author:
Documentation Team
Email:
documentation@typo3.org
License:
Open Publication License available from www.opencontent.org/openpub/
Rendered:
2016-03-09 09:45
The content of this document is related to TYPO3 CMS, a GNU/GPL CMS/Framework available from www.typo3.org
Oicial Documentation
This document is included as part of the oicial TYPO3 documentation. It has been approved by the TYPO3 Documentation Team following a peer- review process. The reader should
expect the information in this document to be accurate - please report discrepancies to the Documentation Team (documentation@typo3.org). Oicial documents are kept up-to-date to
the best of the Documentation Teams abilities.
Core Manual
This document is a Core Manual. Core Manuals address the built in functionality of TYPO3 CMS and are designed to provide the reader with in- depth information. Each Core Manual
addresses a particular process or function and how it is implemented within the TYPO3 source code. These may include information on available APIs, specific configuration options, etc.
Core Manuals are written as reference manuals. The reader should rely on the Table of Contents to identify what particular section will best address the task at hand.
Tip
Sitemap
TYPO3 is known for its extensibility. However to really benefit from this power, a complete documentation is needed. Core APIs and its companion, Inside TYPO3, aim to provide such
information to developers and administrators. Not all areas are covered with the same amount of details, but at least some pointers are provided.
Inside TYPO3 contains the overall introduction to the architecture of the TYPO3 core. It also contains API descriptions to a certain degree but mostly in the form of examples and short
table listings. Core APIs goes into much more detail about such APIs and covers subjects more closely related to development.
These documents do not contain any significant information about the frontend of TYPO3. Creating templates, setting up TypoScript objects etc. is not the scope of these documents; they
are about the backend part of the core only.
The TYPO3 Documentation Team hopes that these two documents, Inside TYPO3 and TYPO3 Core APIs, will form a complete picture of the TYPO3 Core architecture, the backend and be
the reference of choice in your work with TYPO3. It took Kasper more than a year to get the first version published and weve tried to maintain it as best we could.
This version is updated for TYPO3 CMS 6.2.

Many recent changes in the TYPO3 CMS code base were documented in this new version of Core APIs, some dating back to version 6.1. The release of a new LTS version was the opportunity
to put extra eorts into the manuals.
Highlights from new features brought by TYPO3 CMS 6.2:
an Application Context, backported from TYPO3 Flow.
changes to the caching framework, in particuler the new cache groups.
well-known folder t3lib is now gone and so is constant PATH_t3lib .
a new API for registering AJAX handlers which provides CSRF protection (documentation yet missing, but will come very soon).
the system categories API has matured and the related chapter was extended. In particular, it is now possible to have more than one categories field per table.
3/17/2016 5:01 AM
2 of 145
usage of flash messages in Extbase has changed.

it is possible to define a custom mirror to fetch extension translations from.
Many of the code examples found in this document come from the TYPO3 Core itself.
Quite a few others come from the examples extension which is available in the TER. You can install it if you want to try out these examples yourself and use them as a basis for your own
stu.
Yet some other examples just belong to this manual. Some may be moved to the examples extension at some later stage.
For general questions about the documentation get in touch by writing to documentation@typo3.org .
If you find a bug in this manual, please be so kind as to check the online version on https://docs.typo3.org/typo3cms/CoreApiReference/. From there you can hit the Edit me on GitHub
button in the top right corner and submit a pull request via GitHub. Alternatively you can just file an issue using the bug tracker: https://github.com/TYPO3-Documentation/TYPO3CMSReference-CoreApi/issues.
Maintaining high quality documentation requires time and eort and the TYPO3 Documentation Team always appreciates support. If you want to support us, please join the
documentation mailing list/forum (http://forum.typo3.org/index.php/f/44/).
This manual was originally written by Kasper Skrhj. It was further maintained, refreshed and expanded by Franois Suter.
I want to dedicate this document to the people in the TYPO3 community who have the discipline to do the boring job of writing documentation for their extensions or contribute to the
TYPO3 documentation in general. Its great to have good coders, but its even more important to have coders with character to carry their work through till the end - even when it means
spending days writing good documents. Go for completeness!
- kasper
TYPO3 can be extended in nearly any direction without loosing backwards compatibility. The Extension API provides a powerful framework for easily adding, removing, installing and
developing such extensions to TYPO3. This is in particular powered by the Extension Manager (EM) inside TYPO3 and the online TYPO3 Extension Repository (TER) found at typo3.org for
easy sharing of extensions.
Extensions is a general term in TYPO3 which covers many kinds of additions to TYPO3. The main types are:
Plugins which play a role on the website itself, e.g. a discussion board, guestbook, shop, etc. It is normally enclosed in a PHP class and invoked through a USER or USER_INT cObject
from TypoScript. A plugin is an extension in the frontend.
Modules are backend applications which have their own entry in the main menu. They require a backend login and work inside the framework of the backend. We might also call
something a module if it exploits any connectivity of an existing module, that is if it simply adds itself to the function menu of existing modules. A module is an extension in the
backend.
Services are libraries that provide a given service through a clearly defined API. A service may exist both in the frontend and the backend. Please refer to the TYPO3 Services Reference
for more information about this type of extension.
Distributions are fully packaged TYPO3 CMS web installations, complete with files, templates, extensions, etc. Distributions are covered in their own chapter.
Extensions are designed in a way so that extensions can supplement the core seamlessly. This means that a TYPO3 system will appear as a whole while actually being composed of the
core application and a set of extensions providing various features. This philosophy allows TYPO3 to be developed by many individuals without loosing fine control since each developer
will have a special area (typically a system extension) of responsibility which is eectively encapsulated.
So, at one end of the spectrum system extensions make up what is known as TYPO3 to the outside world. At the other end, extensions can be entirely specific to a given project and
contain only files and functionality related to a single implementation.
An extension consists of:

1. a directory named by the extension key (which is a worldwide unique identification string for the extension)
3/17/2016 5:01 AM
3 of 145
2. standard files with reserved names for configuration related to TYPO3 (of which most are optional, see list below)
3. any number of additional files for the extension itself.
This list of filenames are all reserved filenames in the root directory of extensions. None of them are required but for example you cannot have a TYPO3 extension recognized by TYPO3
without the ext_emconf.php file etc. You can read more details like that in the table below.
In general, do not introduce your own files in the root directory of extensions with the name prefix ext_.
Filename
Description
Definition of extension properties.
Name, category, status etc. Used by the EM. The content of this file is described in more details below. Note that it is auto-written by EM when extensions are
ext_emconf.php
Note
If this file is not present the EM will not find the extension.
Addition to LocalConfiguration.php which is included if found. Should contain additional configuration of $TYPO3_CONF_VARS and may include addi
All ext_localconf.php files of included extensions are included right a er the typo3conf/LocalConfiguration.php file has been included and data
ext_localconf.php
Note
Observe rules for content of these files. See section on caching below.
Included if found. Contains extensions of existing tables, declaration of modules, backend styles etc. All code in such files is included a er all the default defi
ext_tables.php
Since TYPO3 CMS 6.1, definition of new database tables should be done entirely in Configuration/TCA/(name of the table).php . These files are exp
Since TYPO3 CMS 6.2, customizations of existing tables should be done entirely in Configuration/TCA/Overrides/(name of the table).php
SQL definition of database tables.
ext_tables.sql
This file should contain a table-structure dump of the tables used by the extension. It is used for evaluation of the database structure and is therefore import
The ext_tables.sql file may not necessarily be dumpable directly to MySQL (because of the semi-complete table definitions allowed defining only req
Static SQL tables and their data.
If the extension requires static data you can dump it into a sql-file by this name.Example for dumping mysql data from bash (being in the extension directory
mysqldump --password=[password] [database name] [tablename] --add-drop-table > ./ext_tables_static.sql
ext_tables_static+adt.sql
--add-drop-table will make sure to include a DROP TABLE statement so any data is inserted in a fresh table.
You can also drop the table content using the EM in the backend.
Note
The table structure of static tables needs to be in the ext_tables.sql file as well - otherwise an installed static table will be reported as being in excess in the
Preset TypoScript constants. Will be included in the constants section of all TypoScript templates.
ext_typoscript_constants.txt
Warning
Use such a file if you absolutely need to load some TS (because you would get serious errors without it). Otherwise static templates or usage of the
Preset TypoScript setup. Will be included in the setup section of all TypoScript templates.
ext_typoscript_setup.txt
Warning
Use such a file if you absolutely need to load some TS (because you would get serious errors without it). Otherwise static templates or usage of the
3/17/2016 5:01 AM
4 of 145
Filename
Description
Extension Configuration template.
Configuration code in TypoScript syntax setting up a series of values which can be configured for the extension in the EM.
ext_conf_template.txt
If this file is present the EM provides you with an interface for editing the configuration values defined in the file. The result is written as a serialized array to
If you want to do user processing before the content from the configuration form is saved (or shown for that sake) there is a hook in the EM which is configur
Extension Icon
18x16 GIF, PNG or SVG icon for the extension.

ext_icon.gif, ext_icon.png or ext_icon.svg
Note
Extension icon will look nicer when provided as vector graphics (SVG) rather than bitmaps (GIF or PNG).
Local Update tool class
class.ext_update.php
If this file is found it will install a new menu item, UPDATE, in the EM when looking at details for the extension. When this menu item is selected the class in
Also you must add the function access() and make it return a boolean value whether or not the menu item should be shown. This feature is meant to let yo
Since TYPO3 CMS 4.3, it is possible to declare classes in this file so that they will be automatically detected by the TYPO3 autoloader. This means that it is not
ext_autoload.php
Not needed anymore since TYPO3 CMS 6.1, when using namespaces.
PHP API data
ext_api_php.dat
A file containing a serialized PHP array with API information for the PHP classes in the extension. The file is created - and viewed! - with tools found in the ext
The current standard for files location - except for the special files mentioned above - is inspired by TYPO3 Flow. It is necessary to use such structure in Extbase-based extensions and
recommended for all extensions anyway.
In order to use Namespaces, class files must be located in a Classes folder.
Refer to the Extbase and Fluid book for more information on extension structure. Also look at the examples extension.
The Extension Builder extension will create the right structure for you. It is described below:
Classes/Controller
Contains MVC Controller classes.
Classes/Domain/Model
Contains MVC Domain model classes.
Classes/Domain/Model/Repository
Contains data repository classes.
Classes/ViewHelpers
Helper classes used in the views.
Configuration/TypoScript
TypoScript static setup ( setup.txt ) and constants ( constants.txt ). Use subfolders if your have several static templates.
Configuration/TCA
One file per database table, using the name of the table for the file, plus .php. Only for new tables.
Configuration/TCA/Overrides
For extending existing tables, one file per database table, using the name of the table for the file, plus .php.
Documentation
Contains the manual in reStructuredText format (read more on the topic).
Resources/Private/Language
XLIFF files for localized labels.
Resources/Private/Layouts
Main layouts for the views.
Resources/Private/Partials
Partial templates for repetitive use.
Resources/Private/Templates
One template per action, stored in a folder named a er each Controller.
Resources/Public/Css
Any CSS file used by the extension.
3/17/2016 5:01 AM
5 of 145
Resources/Public/Images
Any images used by the extension.
Resources/Public/JavaScript
Any JS file used by the extension.
Tests/Unit
Contains unit testing classes.
Legacy structure
The structure of older extensions was not so clearly defined, but it generally adhered to the following conventions:
Filename
Description
pi*/
Typical folder for a frontend plugin class.
mod*/
Typical folder for a backend module.
sv*/
Typical folder for a service.
Extensions normally consist of other files: Classes, images, html- files etc. Files not related to either a frontend plugin (pi/) or backend module (mod/) might be put in a subfolder of the exte
res*/
Files in this folder can also be selected in a selector box if you set up Extension configuration in a ext_conf_template.txt file.
The files for an extension are located in a folder named by the extension key . The location of this folder can be either inside typo3/sysext/ , typo3/ext/ or typo3conf/ext/ .
The extension must be programmed so that it does automatically detect where it is located and can work from all three locations. If it is not possible to make the extension that flexible, it is
possible to lock its installation requirement to one of these locations in the ext_emconf.php file (see lockType).
Local extensions are located in the typo3conf/ext/ directory.

This is where to put extensions which are local for a particular TYPO3 installation. The typo3conf directory is always local, containing local configuration (e.g.
LocalConfiguration.php ), local modules etc. If you put an extension here it will be available for a single TYPO3 installation only. This is a per-database way to install an extension.
Note
Local extension can successfully be symlinked to other local extensions on a server as long as they are running under the same TYPO3 source version (which would typically also be
symlinked). This method is useful for maintenance of the same local extension running under several sites on a server.
Global extensions are located in the typo3/ext/ directory.

This is a per-server way to install an extension; they are global for the TYPO3 source code on the web server. These extensions will be available for any TYPO3 installation sharing the
source code.
Note
This features has not been consistently supported in recent versions of TYPO3, so you may encounter problems when using it.
System extensions are located in the typo3/sysext/ directory.

This is system default extensions which cannot and should not be updated by the EM. They are distributed with TYPO3 core source code and generally understood to be a part of the core
system.
Local extensions take precedence which means that if an extension exists both in typo3conf/ext/ and typo3/ext/ the one in typo3conf/ext/ is loaded. Likewise global extension
takes precedence over system extensions. This means that extensions are loaded in the order of priority local-global-system.
In eect you can therefore have - say - a stable version of an extension installed in the global dir (typo3/ext/) which is used by all your projects on a server sharing source code, but on a
single experimental project you can import the same extension in a newer experimental version and for that particular project the locally available extension will be used instead.
The extension key is a string uniquely identifying the extension. The folder where the extension resides is named by this string. The string can contain characters a-z0-9 and underscore.
No uppercase characters should be used (keeps folder-,file- and table/field-names in lowercase). Furthermore the name must not start with an tx or u (this is prefixes used for modules)
and because backend modules related to the extension should be named by the extension name without underscores, the extension name must still be unique even if underscores are
removed (underscores are allowed to make the extension key easily readable).
The naming conventions of extension keys are automatically validated by the registration at the repository, so you have nothing to worry about here.
There are two ways to name an extension:
3/17/2016 5:01 AM
6 of 145
Project specific extensions (not generally usable or shareable): Select any name you like and prepend it user_ (which is the only allowed use of a key starting with u). This prefix
denotes that this extension is a local one which does not come from the central TYPO3 Extension Repository or is ever intended to be shared. Probably this is an adhoc extension you
have made for some special occasion.
General extensions: Register an extension name online at the TYPO3 Extension Repository. Your extension name will automatically be validated and you are sure to have a unique
name returned which nobody else in the world uses. This makes it very easy to share your extension later on with every one else, because it ensures that no conflicts with other
extension will happen. But by default a new extension you make is defined private which means nobody else but you have access to it until you permit it to be public. Its free of
charge to register an extension name. By definition all code in the TYPO3 Extension Repository is covered by the GPL license because it interfaces with TYPO3. You should really consider
making general extensions!
Tip
It is far easier to settle for the right extension key from the beginning. Changing it later involves a cascade of name changes to tables, modules, configuration files etc. Think carefully.
Remember that TYPO3 is GPL so ware and at the same moment you extend TYPO3 your extensions are legally covered by GPL. This does not force you to share your extension, but it should
inspire you to do so and legally you cannot prevent anyone who gets hold of your extension code from using it and further develop it.The TYPO3 Extension API is designed to make sharing
of your work easy as well as using others work easy. Remember TYPO3 is Open Source So ware and we rely on each other in the community to develop it further.
Important
Its also your responsibility to make sure that all content of your extensions is legally covered by GPL. The webmaster of TYPO3.org reserves the right to kick out any extension without
notice that is reported to contain non-GPL material.
You are responsible for security issues in your extensions. People may report security issues either directly to you or to the TYPO3 Security Team. Whatever the case you should get in touch
with the Security Team which will validate the security fixes. They will also include information about your (fixed) extension in their next Security bulletin. If you dont respond to requests
from the Security Team, your extension will be forcibly removed from the TYPO3 Extension Repository.
More details on the security teams policy on handling security issues can be found at http://typo3.org/teams/security/extension-security-policy/.
Before starting a new extension you should register an extension key on typo3.org (unless you plan to make an implementation-specific extension of course which it does not make
sense to share).
Go to typo3.org, log in with your (pre-created) username / password and go to Extensions > Extension Keys and click on the Register keys tab. On that page you can enter the key name
you want to register.
Based on the extension key of an extension these naming conventions should be followed:
General
Example
User-specific
Example
Assigned by the TYPO3 Extension Repository.
cool_shop
Determined by yourself, but prefixed user_
user_my_sho
Extension key
(Lowercase alnum + underscores. )
3/17/2016 5:01 AM
7 of 145
General
Example
User-specific
Example
Prefix: tx_coolshop_
Prefix:
Examples:
Database tables and fields
Prefix with tx_[ key ]_ where key is without underscores!
Examples:
Prefix with [ key ]_
tx_coolshop_products
user_my_sho
tx_coolshop_categories
user_my_sho
Backend module
Name: The extension key name without underscores, prefixed tx
txcoolshop
Name: No underscores, prefixed u
uMyShop or u
(Names are always without underscores!)

For frontend PHP classes, follow the same conventions as for database tables and field, but prepend class file names with class .
You may also want to refer to the TYPO3 Core Coding Guidelines for more on general naming conventions in TYPO3.
Tip
If you study the naming conventions above closely you will find that they are complicated due to varying rules for underscores in key names. Sometimes the underscores are stripped
o, sometimes not.
The best practice you can follow is to avoid using underscores in your extensions keys at all! That will make the rules simpler. This is highly encouraged.
Some the classic extensions from before the extension structure came about do not comply with these naming conventions. That is an exception made for backwards compatibility. The
assignment of new keys from the TYPO3 Extension Repository will make sure that any of these old names are not accidentially reassigned to new extensions.
Further, some of the classic plugins (tt_board, tt_guest etc) users the user_ prefix for their classes as well.
As a standard procedure you should include the class extension code even in your own extensions. This is placed at the bottom of every class file:
if (defined('TYPO3_MODE') && isset($GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['XCLASS']['ext/myext/pi1/class.tx_myext_pi1.php'])) {
include_once($GLOBALS['TYPO3_CONF_VARS'][TYPO3_MODE]['XCLASS']['ext/myext/pi1/class.tx_myext_pi1.php']);
}
Normally the key used as example here (ext/myext/pi1/class.tx_myext_pi1.php) would be the full path to the script relative to the PATH_site constant. However because modules are
required to work from both typo3/sysext/ , typo3/ext/ and typo3conf/ext/ it is a policy that any path before ext/ is omitted.
There are only two (possibly three) steps involved in using extensions with TYPO3:
1. You must import it.
This simply means to copy the extensions files into the correct directory in either typo3/ext/ (global) or typo3conf/ext/ (local). More commonly you import an extension directly from the
online TYPO3 Extension Repository (TER). When an extension is found located in one of the extension locations, it is available to the system.
The Extension Manager (EM) should take care of this process, including updates to newer versions if needed.Notice that backend modules will have their conf.php file modified in the
install process depending on whether they are installed locally or globally!
2. You must install it.
An extension is loaded only if its state is set to active in the PackageStates.php file. Extensions are loaded in the order they appear in this list.
An enabled extension is always global to the TYPO3 Installation - you cannot disable an extension from being loaded in a particular branch of the page tree.The EM takes care enabling
extensions. Its highly recommended that the EM is doing this, because the EM will make sure the priorities, dependencies and conflicts are managed according to the extension
characteristics, including clearing of the cache-files if any.
3. You might need to configure it.
Certain extensions may allow you to configure some settings. Again the EM is able to handle the configuration of the extensions based on a certain API for this. Any settings - if present configured for an extension are available as an array in the variable $TYPO3_CONF_VARS["EXT"]["extConf"][extension key] .
Loaded extensions are registered in a global variable, $TYPO3_LOADED_EXT , available in both frontend and backend of TYPO3.
This is how the data structure for an extension in this array looks:
3/17/2016 5:01 AM
8 of 145
$TYPO3_LOADED_EXT[extension key] = array(

"type" =>
S, G, L for system, global or local type of availability.
"siteRelPath" => Path of extension dir relative to the PATH_site constant
e.g. "typo3/ext/my_ext/" or "typo3conf/ext/my_ext/"
"typo3RelPath" => Path of extension dir relative to the "typo3/" admin folder
e.g. "ext/my_ext/" or "../typo3conf/ext/my_ext/"
"ext_localconf" => Contains absolute path to 'ext_localconf.php' file if present
"ext_tables" => [same]
"ext_tables_sql" => [same]
"ext_tables_static+adt.sql" => [same]
"ext_typoscript_constants.txt" => [same]
"ext_typoscript_setup.txt" => [same]
"ext_typoscript_editorcfg.txt" => [same]
)
The order of the registered extensions in this array corresponds to the order they were listed in PackageStates.php.
The inclusion of ext_tables.php or ext_localconf.php files (see next chapter) is done by traversing (a copy of) the $TYPO3_LOADED_EXT array.
The ext_emconf.php is the single most important file in an extension. Without it, the Extension Manager (EM) will not detect the extension, much less be able to install it. This file
contains a declaration of what the extension is or does for the EM. The only thing included is an associative array, $EM_CONF[extension key] . The keys are described in the table below.
When extensions are imported from the online repository this file is written anew! So dont put any custom stu in there - only change values in the $EM_CONF array if needed.
Key
Data type
Description
title
string, required
The name of the extension in English.
description
string, required
Short and precise description in English of what the extension does and for whom it might be useful.
Which category the extension belongs to:
be
Backend (Generally backend-oriented, but not a module)
module
Backend modules (When something is a module or connects with one)
fe
Frontend (Generally frontend oriented, but not a true plugin)
plugin
Frontend plugins (Plugins inserted as a Insert Plugin content element)
misc
category
string
Miscellaneous stu (Where not easily placed elsewhere)

services
Contains TYPO3 services
templates
Contains website templates
example
Example extension (Which serves as examples etc.)
doc
Documentation (e.g. tutorials, FAQs etc.)
distribution
Distribution, an extension kickstarting a full site
3/17/2016 5:01 AM
9 of 145
Key
Data type
Description
List of requirements, suggestions or conflicts with other extensions or TYPO3 or PHP version. Heres how a typical setup might look:
constraints
array
'constraints' => array(

'depends' => array(
'typo3' => '4.5.0-6.1.99',
'php' => '5.3.0-5.5.99'
),
'conflicts' => array(
'dam' => ''
),
'suggests' => array(
'tt_news' => '2.5.0-0.0.0'
)
)
depends
List of extensions that this extension depends on.
conflicts
List of extensions which will not work with this extension.
suggests
List of suggestions of extensions that work together or enhance this extension.
The above example indicated that the extension depends on a version of TYPO3 between 4.5 and 6.1 (as only bug and security fixes are integrated into TYPO3
Which state is the extension in
alpha
Alpha state is used for very initial work, basically the state is has during the very process of creating its foundation.
beta
Under current development. Beta extensions are functional but not complete in functionality. Most likely beta-extensions will not be reviewed.
stable
Stable extensions are complete, mature and ready for production environment. You will be approached for a review. Authors of stable extensions carry a re
experimental
state
string
Experimental state is useful for anything experimental - of course. Nobody knows if this is going anywhere yet... Maybe still just an idea.
test
Test extension, demonstrates concepts etc.
obsolete
The extension is obsolete or deprecated. This can be due to other extensions solving the same problem but in a better way or if the extension is not being m
excludeFromUpdates
This state makes it impossible to update the extension through the extension manager (neither by the Update mechanism, nor by uploading a newer versi
New since TYPO3 4.3.
uploadfolder
boolean
If set, then the folder named uploads/tx_[extKey-with-no- underscore] should be present!
createDirs
list of strings
Comma list of directories to create upon extension installation.
clearCacheOnLoad
boolean
If set, the EM will request the cache to be cleared when this extension is loaded.
author
string
Author name (Use a-z)
author_email
email address
Author email address
author_company
string
Author company (if any company sponsors the extension).
docPath
string
Path to documentation. This has never been fully supported neither by the TER nor by the Extension Manager. The documentation is expected to be in folder
Deprecated
Compliance level that the extension claims to adhere to. A compliance defines certain coding guidelines, level of documentation, technical requirements (like
CGLcompliance
keyword
Deprecated
Any remarks to the compliance status. Might describe some minor incompatibilities or other reservations.
CGLcompliance_note
string
Deprecated
If set, this version of the extension is not included in the public list!
private
boolean
Not supported anymore
If set, this password must additionally be specified if people want to access (import or see details for) this the extension.
download_password
string
version
main.sub.dev
Not supported anymore

Version of the extension. Automatically managed by EM / TER. Format is [int].[int].[int]
Files ext_tables.php and ext_localconf.php are the two most important files for the execution of extensions within TYPO3. They contain configuration used by the system on
almost every request. They should therefore be optimized for speed.
ext_localconf.php is always included in global scope of the script, either frontend or backend.
While you can put functions and classes into the script, it is a really bad practice because such classes and functions would always be loaded. It is better to have them included only as
3/17/2016 5:01 AM
needed.
So stick to changing values in TYPO3_CONF_VARS only!
ext_tables.php is not always included in global scope (in the frontend)
It should still not contain functions and classes as it still very o en loaded.
Use the API of class extMgm for tasks such as adding tables, merging information into arrays, etc.
Before the inclusion of any of the two files, the variables $_EXTKEY is set to the extension key and $_EXTCONF is set to the configuration from
$TYPO3_CONF_VARS["EXT"]["extConf"][extension key]
$TYPO3_LOADED_EXT[extension key] contains information about whether the module is loaded as local, global or system type, including the proper paths you might use, absolute
and relative.
The inclusion can happen in two ways:
Either the files are included individually on each request (many file includes) ( $TYPO3_CONF_VARS["EXT"]["extCache"]=0; )
or (better) the files are automatically imploded into one single temporary file (cached) in typo3conf/ directory (only one file include)
( $TYPO3_CONF_VARS["EXT"]["extCache"]=1; ). This is default.
In eect this means:
Your ext_tables.php and ext_localconf.php file must be designed so that they can safely be read and subsequently imploded into one single file with all the other
configuration scripts!
You must never use a return statement in the files global scope - that would make the cached script concept break.
You should not rely on the PHP constant __FILE__ for detection of include path of the script - the configuration might be executed from a cached script and therefore such
information should be derived from the $TYPO3_LOADED_EXT[extension key] array, e.g. $TYPO3_LOADED_EXT[$_EXTKEY]["siteRelPath"] .
In the ext_conf_template.txt file configuration options for an extension can be defined. They will be accessible in the TYPO3 BE from the Extension Manager.
Theres a specific syntax to declare these options properly, which is similar to the one used for TypoScript constants (see Declaring constants for the Constant editor in TypoScript
Syntax and In-depth Study). This syntax applies to the comment line that should be placed just before the constant. Consider the following example (taken from system extension
rsaauth):
# cat=basic/enable; type=string; label=Path to the temporary directory:This directory will contain...
temporaryDirectory =
First a category (cat) is defined (basic) with the subcategory enable. Then a type is given (string) and finally a label, which is itself split (on the colon :) into a title and a description
(this should actually be a localized string). The above example will be rendered like this in the EM:
The configuration tab displays all options from a single category. A selector is available to switch between categories. Inside an option screen, options are grouped by subcategory. At the
bottom of the screenshot, the label split between header and description is visible. Then comes the field itself, in this case an input, because the options type is string.
Extensions are managed from the Extension Manager inside TYPO3 by admin users. The module is located at Admin tools > Ext Manager and oers a menu with options to see loaded
extensions (those that are installed or activated), available extensions on the server and the possibility to import extensions from online resources, typically the TER (TYPO3 Extension
Repository) located at typo3.org.
10 of 145
3/17/2016 5:01 AM
The interface is really easy to use. You just click the +/- icon to the le of an extension in order to install it and follow the instructions.
This chapter is not a tutorial about how to create an Extension. It only aims to be a list of steps to perform and key information to remember.
First you have to register an extension key. This is the unique identifier for your extension.
Although it is possible to write every single line of an extension from scratch, there is tool which makes it easier to start. It is called Extension builder (key: extension_builder) and can
be installed from TER.
The Extension Builder comes with its own BE module:
11 of 145
3/17/2016 5:01 AM
Note that this tool is not a complete editor. It helps you creating the scaolding of your extension, generating the necessary files. Its then up to you to fill these with the relevant code.
Warning
The Extension Builder has some possibility to preserve code, but it should still be used with care.
A er the extension is written to your computers disk you will be able to install it locally and start using it.
Please refer to the Extension Builders manual for more information.
This chapter describes the main steps in creating a new distribution. It should not be considered as a full fledge tutorial.
Distributions are full TYPO3 CMS websites ready to be unpacked. They provide an easy quickstart for using TYPO3 CMS.
A distribution takes care of the following parts:
Deliver initial database data
Deliver fileadmin files
Deliver configuration for a package
Hook into the process a er saving configuration to trigger actions dependent on configuration values
Deliver dependent extensions (e.g., customized versions or extensions not available through TER)
A distribution is a special kind of extension. The first step is thus to create a new extension. Start by registering an extension key, which will be the unique identifier of your distribution.
Next create the Extension declaration file as usual, except for the category property which must be set to distribution.
Configuring the distribution display in the EM
You should provide two preview images for your distribution. Provide a small 220x150 pixels for the list in the extension manager as Resources/Public/Images/Distribution.png
and a larger 300x400 pixels welcome image as Resources/Public/Images/DistributionWelcome.png . The welcome image is displayed in the distribution detail view inside the
extension manager.
Fileadmin files
12 of 145
3/17/2016 5:01 AM
Create the following folder structure inside your extension:

Initialisation
Initialisation/Files
All the files inside that second folder will be copied to fileadmin/<extkey> during installation, where extkey is the extension key of your distribution.
Database data
The database data is delivered as TYPO3 CMS export data.t3d . Generate this file by exporting your whole installation from the tree root with the import/export module. Make sure to
include all tables in the export.
The file has to be name data.t3d and must be located in the Initialisation folder.
Distribution configuration
A distribution is technically handled as an extension. Therefore your can make use of all configuration options as needed.
A er saving the configuration, the signal afterExtensionConfigurationWrite is dispatched. You may use this to alter your website configuration (e.g. color scheme) on the fly.
Delivering custom dependencies
Normally extension dependencies are setup in the Extension declaration file.
However sometimes, extensions are not available in the TYPO3 Extension Repository (TER). Therefore, a distribution can act as its own extension repository. Add unpacked extensions to
Initialisation/Extensions/ to provide dependencies. Your main extension has to be dependent on these extension as normal dependencies in ext_emconf.php .
Extensions delivered inside an extension have the highest priority when extensions need to be fetched.
Caution
This will not overwrite extensions already present in the system.
To test your distribution, simply copy your extension to an empty TYPO3 CMS installation and try to install it from the Extension Manager.
Warning
It is not enough to clean all files and the page tree if you want to try again to install your distribution. Indeed, TYPO3 CMS remembers that it previously imported your distribution and
will skip any known files. Make sure to clean the table sys_registry if you want to work around that.
Some additional backgrounds can be retrieved from the blueprint for this feature.
If you plan to upload your extension to the TYPO3 Extension Repository (TER), you should first consider adding a documentation to your extension. A documentation will help users and
administrators to quickly install and configure your extension and give it more weight.
The documentation platform https://docs.typo3.org centralizes documentation for every project. It supports three dierent kind of documentation:
1. (recommended) A Sphinx project, stored within EXT:extkey/Documentation/
2. A simple README file stored as EXT:extkey/README.rst as seen on Github
3. (legacy) An OpenOice manual, stored as EXT:extkey/doc/manual.sxw
Sphinx is the oicial format for oicial TYPO3 documentation. A Sphinx-based documentation is a set of plain text files making up the chapters or sections of the documentation. It uses a
markup language called reStructuredText (reST).
Advantages of this new documentation format are numerous:
Output formats: Sphinx projects may be automatically rendered as HTML or TYPO3-branded PDF.
Cross-references: It is easy to cross-reference other chapters and sections of other manuals (either TYPO3 references or extension manuals).
Multilingual: Unlike OpenOice, Sphinx projects may be easily localized and automatically presented in the most appropriate language to TYPO3 users.
Collaboration: As the documentation is plain text, it is easy to work as a team on the same manual or quickly review changes using any versioning system.
Although it is possible to write every single line of a Sphinx-based documentation from scratch, the TYPO3 community provides tools that help write and manage Sphinx projects:
13 of 145
The extension Sphinx (Sphinx Python Documentation Generator and Viewer) installs a local Sphinx environment to view, edit and compile documentation in the backend of your
TYPO3 website. It can be installed from the TYPO3 Extension Repository (TER) like any other extension.
The Sphinx extension is able to convert existing OpenOice manuals (manual.sxw) into Sphinx projects with just one click.
3/17/2016 5:01 AM
An example manual is available in the TYPO3 Git repository.

The Extension Builder provides a skeleton documentation based on the above-mentioned Git repository.
A good primer to get started using the reStructuredText markup.
A README.rst is a simple text file stored at the root of your extension directory and briefly describing the purpose of your extension. It is best suited when installing or using your
extension is straightforward. The format of this file is reStructuredText, as for chapters of a Sphinx project.
Tip
In TYPO3 6.2, the system extension documentation is using such a simple manual.
The OpenOice SXW format used to be the oicial documentation format for TYPO3. Use of this format is highly discouraged since support on docs.typo3.org is about to be dropped.
Please use the tools mentioned above to convert your existing SXW file into a Sphinx project instead.
OpenOice example manual in the TYPO3 extension repository.
Beyond the general overview given in this chapter, other sections in this manual will be of particular interest to extension developers:
Adding elements to the Content Element Wizard
Using custom permission options
Namespaces
The source is the documentation! (General wisdom)

The TYPO3 APIs are first and foremost documented inside of the source scripts. It would be impossible to maintain documentation at more than one location given the fact that things
change and sometimes fast. This chapter describes the most important elements of the API. Some other elements have their own chapter further on.
In general the TYPO3 Active Contributors Team and all contributors aim to produce well-documented source code. As such the best way to look up a particular class or method is to use the
online API browser at http://typo3.org/documentation/api/.
Since version 6.0, TYPO3 CMS uses PHP namespaces for all classes in the Core.
The general structure of namespaces is the following:
\{VendorName}\{PackageName}${CategoryName}$*{ClassName}
For the Core, the vendor name is TYPO3\CMS and the package name corresponds to a system extension.
All classes must be located inside the Classes folder at the root of the (system) extension. The category name may contain several segments that correspond to the path inside the
Classes folder.
Finally the class name is the same as the corresponding file name, without the .php extension.
UpperCamelCase is used for all segments.
Tip
File typo3/sysext/core/Migrations/Code/LegacyClassesForIde.php contains a full mapping of old to new class names, which will help you find your way around the new
naming.
The good old t3lib_div class has been renamed to:

\TYPO3\CMS\Core\Utility\GeneralUtility
This means that the class is now found in the core system extension, in folder Classes/Utility , in a file named GeneralUtility.php .
Extension developers are free to use their own vendor name. Important: It may consist of one segment only. Vendor names must start with an uppercase character and are usually written
14 of 145
3/17/2016 5:01 AM
in UpperCamelCase style. In order to avoid problems with dierent filesystems, only the characters a-z, A-Z, 0-9 and the dash sign - are allowed for package names dont use special
characters:
// good vendor name:
\Webcompany
// wrong vendor name:
\Web\Company
Attention
The vendor name TYPO3\CMS is reserved and may not be used by extensions!
The package name corresponds to the extension key. Underscores in the extension key are removed in the namespace and replaced by upper camel-case. So extension key:
weird-name_examples
would become:
Weird-nameExamples
in the namespace.
As mentioned above, all classes must be located in the Classes folder inside your extension. All sub-folders translate to a segment of the category name and the class name is the file
name without the .php extension.
Looking at the examples extension, class:
examples/Classes/Controller/DefaultController.php
corresponds to namespace:
\Documentation\Examples\Controller\DefaultController
Inside the class, the namespace is declared as:

<?php
namespace Documentation\Examples\Controller;
When registering components in Extbase, the vendor name must be used on top of the extension key.
For a backend module:
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule(
'<vendorName>.<ExtensionName>,
...
);
For a frontend module:

\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
'<vendorName>.<ExtensionName>,
...
);
Important
Do not forget the dot a er the vendor name.
Do not use dots inside the vendor name.
As for ordinary classes, namespaces for test classes start with a vendor name followed by the extension key.
All test classes reside in a Tests folder and thus the third segment of the namespace must be Tests. Unit tests are located in a Unit folder which is the fourth segment of the
namespace. Any further subfolders will be subsequent segments.
So a test class in EXT:foo_bar_baz/Tests/Unit/Bla/ will have as namespace \Vendor\FooBarBaz\Tests\Unit\Bla .
15 of 145
3/17/2016 5:01 AM
When creating instances using \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() the leading backslash must be omitted and all other backslashes escaped, even when
using single quotes. Thus the following code is correct:
$contentObject = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer::class);
There is no need to use require() or include() statements. All classes that follow namespace conventions will automatically located and included by the autoloader.
For more information about PHP namespaces in general, you may want to refer to the PHP documentation and in particular the Namespaces FAQ.
The autoloader takes care of finding classes in TYPO3. It is closely related to \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() which takes care of singleton and
XCLASS handling.
As a developer you should always instantiate classes either through \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() or with the Extbase ObjectManager (which
internally uses makeInstance() again).
Important
Since TYPO3 CMS 6.0 and the introduction of namespaces, developers are strongly encouraged to use the namespaces. When using namespaces it is not necessary to explicitely declare
classes in an autoloader files. All namespaced classes are automatically autoloaded.
Please refer to the Namespaces chapter for more information.
In TYPO3 every class must reside in its own file, i.e. there should be only one class per PHP file. Extensions must not use require() or include() to load class files, but instead use the
TYPO3 core API to automatically require a file upon request of the class.
A developer has two options to help the core find a specific class:
Use the class naming convention and file location.
Register a class name together with its location in an ext_autoload.php file.
If its not possible to stick to the class naming and file location conventions - for whatever reason - or if you dont want to use namespaces, you can add a file to your extension called
ext_autoload.php , in the base directory. Its goal is to inform the autoloader about the location of each class files. The autoloader automatically searches for this file when a class is
requested.
The ext_autoload.php file must simply return a one-dimensional array with the class name as key, and the file location as value. No other code is allowed in this file.
The examples below are related to non-namespaced classes. When using namespaces, autoloading will happen without any extra eort on your part.
Consider the following:

Extension name: my_extension
Extension location: typo3conf/ext/my_extension
Class name: Tx_MyExtension_Utility_FooBar
Required file location: typo3conf/ext/my_extension/Classes/Utility/FooBar.php
which respects the following rules:
The class name must start with Tx_
In the extension name underscores are converted to upper camel case, hence MyExtension
Every underscore a er the extension name in the class name is resolved to a uppercases folder name below the Classes directory, i.e. "_utility" becomes folder "Utility"
The last part of the class name resolves to the file name with suix .php
For a file which doesnt follow any particular conventions, an entry must be created in the extensions ext_autoload.php file.
Example taken from an oldish version of extension news:
16 of 145
3/17/2016 5:01 AM
$extensionClassesPath = \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('news') . 'Classes/';

$default = array(
'tx_news_domain_model_dto_emconfiguration' => $extensionClassesPath . 'Domain/Model/Dto/EmConfiguration.php',
'tx_news_hooks_suggestreceiver' => $extensionClassesPath . 'Hooks/SuggestReceiver.php',
'tx_news_hooks_suggestreceivercall' => $extensionClassesPath . 'Hooks/SuggestReceiverCall.php',
'tx_news_utility_compatibility' => $extensionClassesPath . 'Utility/Compatibility.php',
'tx_news_utility_importjob' => $extensionClassesPath . 'Utility/ImportJob.php',
'tx_news_utility_emconfiguration' => $extensionClassesPath . 'Utility/EmConfiguration.php',
'tx_news_service_cacheservice' => $extensionClassesPath . 'Service/CacheService.php',
);
return $default;
Note
The class names used as keys in the array must be in lower case, until TYPO3 4.7. This limitation was removed in TYPO3 6.0.
TYPO3 CMS has a clean bootstrapping process driven mostly by class \TYPO3\CMS\Core\Core\Bootstrap . This class contains a host of methods each responsible for a little step along
the initialization of a full TYPO3 process, be it the backend or other contexts.
Some contexts add their own bootstrap class (like the command line, which additionally requires \TYPO3\CMS\Core\Core\CliBootstrap .
Note
The frontends bootstrapping process is not yet fully encapsulated in a bootstrap class.
Warning
This boostrapping API is internal and may change any time in the near future even in minor updates. It is thus discouraged to use it in third party code. Choose this solution only if other
extensbility features such as Hooks, Signals or XCLASS are not enough to reach your goals.
One can see the bootstrapping process in action in file typo3/init.php :
define('TYPO3_MODE', 'BE');
require 'sysext/core/Classes/Core/Bootstrap.php';
\TYPO3\CMS\Core\Core\Bootstrap::getInstance()
->baseSetup('typo3/')
->redirectToInstallToolIfLocalConfigurationFileDoesNotExist('../')
->startOutputBuffering()
->loadConfigurationAndInitialize()
->loadTypo3LoadedExtAndExtLocalconf(TRUE)
->applyAdditionalConfigurationSettings()
->initializeTypo3DbGlobal()
->checkLockedBackendAndRedirectOrDie()
->checkBackendIpOrDie()
->checkSslBackendAndRedirectIfNeeded()
->checkValidBrowserOrDie()
->loadExtensionTables(TRUE)
->initializeSpriteManager()
->initializeBackendUser()
->initializeBackendUserMounts()
->initializeLanguageObject()
->initializeModuleMenuObject()
->initializeBackendTemplate()
->endOutputBufferingAndCleanPreviousOutput()
->initializeOutputCompression();
Note that most methods of the Bootstrap class must be called in a precise order. It is perfectly possible to define ones own bootstrapping process, but care should be taken about the call
order.
Also note that all bootstrapping methods return the instance of the Bootstrap class itself, allowing calls to be chained.
Each request, no matter if it runs from the command line or through HTTP, runs in a specific application context. TYPO3 CMS provides exactly three built-in contexts:
Production (default) - should be used for a live site
Development - used for development
Testing - is used for functional tests
The context TYPO3 CMS runs in is specified through the environment variable TYPO3_CONTEXT . It can be set on the command line:
17 of 145
# run the TYPO3 CMS CLI commands in development context

TYPO3_CONTEXT=Development ./typo3/cli_dispatch.phpsh
3/17/2016 5:01 AM
or be part of the web server configuration:

# In your Apache configuration, you usually use:
SetEnv TYPO3_CONTEXT Development
# Set context with mod_rewrite
# Rules to set ApplicationContext based on hostname
RewriteCond %{HTTP_HOST} ^dev\.example\.com$
RewriteRule .? - [E=TYPO3_CONTEXT:Development]
RewriteCond %{HTTP_HOST} ^staging\.example\.com$
RewriteRule .? - [E=TYPO3_CONTEXT:Production/Staging]
RewriteCond %{HTTP_HOST} ^www\.example\.com$
RewriteRule .? - [E=TYPO3_CONTEXT:Production]
In certain situations, more specific contexts are desirable:

a staging system may run in a Production context, but requires a dierent set of credentials than the production server.
developers working on a project may need dierent application specific settings but prefer to maintain all configuration files in a common Git repository.
By defining custom contexts which inherit from one of the three base contexts, more specific configuration sets can be realized.
While it is not possible to add new top-level contexts at the same level like Production and Testing, you can create arbitrary sub-contexts, just by specifying them like
<MainContext>/<SubContext> .
For a staging environment a custom context Production/Staging may provide the necessary settings while the Production/Live context is used on the live instance.
Note
This even works recursively, so if you have a multiple-server staging setup, you could use the context Production/Staging/Server1 and Production/Staging/Server2 if both
staging servers needed dierent configuration.
The current Application Context is set very early in the bootstrap process can be accessed through public API for example in the AdditionalConfiguration.php file to automatically set
dierent configuration for dierent contexts.
In file typo3conf/AdditionalConfiguration.php :
switch (\TYPO3\CMS\Core\Utility\GeneralUtility::getApplicationContext()) {
case 'Development':
$GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors'] = 1;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask'] = '*';
break;
case 'Production/Staging':
$GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask'] = '192.168.1.*';
break;
default:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask'] = '127.0.0.1';
}
There are a number of core classes in TYPO3 which contain general functionality and are available most of or even all the time. These classes are either static or exist as singletons stored in
global variables.
This table lists some of the most important classes to know about in TYPO3:
18 of 145
Class name
Description
Database Abstraction Base API
\TYPO3\CMS\Core\Database\DatabaseConnection
All access to the database must go through this object. That is the first step towards DBAL compliance in your code. The class contains MySQL w
Character Set handling API
\TYPO3\CMS\Core\Charset\CharsetConverter
Contains native PHP code to handle character set conversion based on charset tables from Unicode.org. You should use this class whenever yo
General Purpose Functions
\TYPO3\CMS\Core\Utility\GeneralUtility
A collection of multi-purpose PHP functions. Some are TYPO3 specific but not all.
There are more specific utility classes in EXT:core/Classes/Utility .
3/17/2016 5:01 AM

Class name
Description
Backend Specific Functions
\TYPO3\CMS\Backend\Utility\BackendUtility
Contains functions specific to the TYPO3 backend. You will typically need these when programming backend modules or other backend functio
This class is NOT available in the frontend!
Extension API functions
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility
Functions for extensions to interface with the core system. Many of these functions are used in ext\_localconf.php and ext\_tables.ph
Icons / Part of skinning API
\TYPO3\CMS\Backend\Utility\IconUtility
Contains a few functions for getting the right icon for a database table record or the skinned version of any other icon.
This class is NOT available in the frontend!
Backend Template Class
\TYPO3\CMS\Backend\Template\DocumentTemplate
Contains functions for producing the layout of backend modules, setting up HTML headers, wrapping JavaScript sections correctly for XHTML,
These classes are always included and available in the TYPO3 backend and frontend (except \TYPO3\CMS\Backend\Utility\BackendUtility and
\TYPO3\CMS\Backend\Utility\IconUtility ).
The next sections highlight a selection of methods from these classes. They were chosen for their general importance with regards to the whole of TYPO3. You should at least acquaint
yourself with all these high- priority functions, in order to write code the TYPO3 way. These lists also include some other methods selected for their usefulness.
The functions listed in this table are of high priority. Generally they provide APIs to functionality which TYPO3 should always handle in the same way. This will help you to code TYPO3
applications with less bugs and greater compatibility with various system conditions it will run under.
Remember, this list only serves to point out important functions! The real documentation is found in the source scripts (and the online API). The comments given are only a supplement to
that.
19 of 145
Function
Comments
Getting values from GET or POST vars
APIs for getting values in GET or POST variables with slashes stripped regardless of PHP environment. Always use these functions instead of direct access to $_GET
\TYPO3\CMS\Core\Utility\GeneralUtility::_GP($varname) will give you the value of either the GET or POST variable with priority to POST if present. This is useful i
_GP
\_GET
\_POST
// Setting GPvars:
$this->file = \TYPO3\CMS\Core\Utility\GeneralUtility::_GP('file');
$this->size = \TYPO3\CMS\Core\Utility\GeneralUtility::_GP('size');
\TYPO3\CMS\Core\Utility\GeneralUtility::_GET() will give you GET vars. For security reasons you should use this if you know your parameters are passed as GET v
$params = \TYPO3\CMS\Core\Utility\GeneralUtility::_GET();
\TYPO3\CMS\Core\Utility\GeneralUtility::_POST() will give you POST variables. Works like \TYPO3\CMS\Core\Utility\GeneralUtility::_GET()
This example gives you the content of the POST variable TSFE_ADMIN_PANEL, for instance it could come from a form field like <input name="TSFE_ADMIN_PANEL[comman
$input = \TYPO3\CMS\Core\Utility\GeneralUtility::_POST('TSFE_ADMIN_PANEL');
Creating objects
Factory API for creating an instance of an object given a class name. This function makes sure the XCLASS extension principle can be used on (almost) any class in TYPO3
Examples:
makeInstance
// Making an instance of class "\\TYPO3\\CMS\\Core\\TypoScript\\Parser\\TypoScriptParser":

$parseObj = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\TypoScript\\Parser\\TypoScriptParser');
// Make an object with arguments passed to the constructor:
$message = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Messaging\\FlashMessage',
'My message text',
'Message Header',
\TYPO3\CMS\Core\Messaging\FlashMessage::WARNING,
TRUE
);
3/17/2016 5:01 AM
20 of 145
Function
Comments
Environment-safe server and environment variables.
API function for delivery of system and environment variables on any web-server brand and server OS. Always use this API instead of $_ENV/$_SERVER or getenv()
Examples:
getIndpEnv
if (\TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('HTTP_ACCEPT_LANGUAGE') == $test)...
if (\TYPO3\CMS\Core\Utility\GeneralUtility::cmpIP(\TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('REMOTE_ADDR'), $pcs[1]))
$prefix = \TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('TYPO3_REQUEST_URL');
$redirectTo = \TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('TYPO3_SITE_URL').$redirectTo;
if (!\TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('TYPO3_SSL')) ...
Evaluate files and directories for security reasons

When you allow references to files to be input from users there is always the risk that they try to cheat the system to include something else than intended. These functi
Here the functions are described in order of importance:
\TYPO3\CMS\Core\Utility\GeneralUtility::getFileAbsFileName() - Returns the absolute filename of a relative reference, resolves the EXT: prefix (way of referri
getFileAbsFileName
// Getting absolute path of a temporary file

$cacheFile = \TYPO3\CMS\Core\Utility\GeneralUtility::getFileAbsFileName('typo3temp/tempfile.tmp');
// Include file if it exists:
$file = \TYPO3\CMS\Core\Utility\GeneralUtility::getFileAbsFileName($fileRef);
if (@is_file($file)) {
include($file);
}
validPathStr
\TYPO3\CMS\Core\Utility\GeneralUtility::validPathStr() - Checks for malicious file paths. Returns true if no //, .. or \ is in the $theFile. This should make sure
isAbsPath
// If the path is true and validates as a valid path string

if ($path && \TYPO3\CMS\Core\Utility\GeneralUtility::validPathStr($path)) {
...
}
isAllowedAbsPath
fixWindowsFilePath
\TYPO3\CMS\Core\Utility\GeneralUtility::isAbsPath() - Checks if the input path is absolute or relative (detecting either / or x:/ as first part of string) and return
// Returns relative filename for icon:
if (\TYPO3\CMS\Core\Utility\GeneralUtility::isAbsPath($Ifilename)) {
$Ifilename = '../' . substr($Ifilename, strlen(PATH_site));
}
\TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedAbsPath() - Returns true if the path is absolute, without backpath .. and within the PATH_site
if (@file_exists($path) && \TYPO3\CMS\Core\Utility\GeneralUtility::isAllowedAbsPath($path)) {
$fI = pathinfo($path);
....
\TYPO3\CMS\Core\Utility\GeneralUtility::fixWindowsFilePath() - Fixes a path for Windows- backslashes and reduces double-slashes to single slashes
Creates directory
One would think that creating directories is one thing you can do directly with PHP. Well, it turns out to be quite error-prone if it should be compatible with Windows se
Example:
mkdir
$root.=$dirParts . '/';
if (!is_dir($extDirPath . $root))
{
\TYPO3\CMS\Core\Utility\GeneralUtility::mkdir($extDirPath . $root);
if (!@is_dir($extDirPath . $root))
{
return 'Error: The directory "' .
$extDirPath . $root .
'" could not be created...';
}
}
3/17/2016 5:01 AM
21 of 145
Function
Comments
Functions for handling uploads and temporary files
You need to use these functions for managing uploaded files you want to access as well as creating temporary files within the same session. These functions are safe_mode
\TYPO3\CMS\Core\Utility\GeneralUtility::upload_to_tempfile() - Will move an uploaded file (normally in /tmp/xxxxx) to a temporary filename in
\TYPO3\CMS\Core\Utility\GeneralUtility::unlink_tempfile() - Deletes (unlink) a temporary filename in PATH\_site . 'typo3temp/' given as input. The fun
This example shows how to handle an uploaded file you just want to read and then delete again:
upload_to_tempfile
unlink_tempfile
// Read uploaded file:

$uploadedTempFile = \TYPO3\CMS\Core\Utility\GeneralUtility::upload_to_tempfile(
$_FILES['upload_ext_file']['tmp_name']
);
$fileContent = \TYPO3\CMS\Core\Utility\GeneralUtility::getUrl($uploadedTempFile);
\TYPO3\CMS\Core\Utility\GeneralUtility::unlink_tempfile($uploadedTempFile);
\TYPO3\CMS\Core\Utility\GeneralUtility::tempnam() - Create temporary filename (creates file with unique file name). This function should be used for getting tem
tempnam
In the following example it is shown how two temporary filenames are created for being processed with an external program (di) a er which they are deleted again:
// Create file 1 and write string
$file1 = \TYPO3\CMS\Core\Utility\GeneralUtility::tempnam('diff1_');
\TYPO3\CMS\Core\Utility\GeneralUtility::writeFile($file1, $str1);
// Create file 2 and write string
$file2 = \TYPO3\CMS\Core\Utility\GeneralUtility::tempnam('diff2_');
\TYPO3\CMS\Core\Utility\GeneralUtility::writeFile($file2, $str2);
// Perform diff.
$cmd = $GLOBALS['TYPO3_CONF_VARS']['BE']['diff_path'].
' '.$this->diffOptions . ' ' . $file1 . ' ' . $file2;
exec($cmd, $res);
unlink($file1);
unlink($file2);
Truncating a string for visual display, observing the character set (backend only)
This function allows you to truncate a string from e.g. Hello World to Hello Wo... so for example very long titles of records etc. will not break the visual appearanc
Since text strings cannot be cropped at any byte if the character set is utf-8 or another multibyte charset this function will process the string assuming the character s
It is recommended to use $BE_USER->uc[titleLen] for the length parameter.
fixed_lgd_cs
// Limits Record title to 30 chars

\TYPO3\CMS\Core\Utility\GeneralUtility::fixed_lgd_cs($thisRecTitle, 30);
// Limits string to title-length configured for backend user:
$title = \TYPO3\CMS\Core\Utility\GeneralUtility::fixed_lgd_cs(
$row['title'],
$this->BE_USER->uc['titleLen']
);
Preparing a string for output between <textarea> tags.

Use this function to prepare content for <textarea> tags. Then you will avoid extra / stripped whitespace when the form is submitted multiple times.
formatForTextarea
// Create item:
$item = '
<textarea>' .
\TYPO3\CMS\Core\Utility\GeneralUtility::formatForTextarea($value) .
'</textarea>';
Preparing a URL for a HTTP location-header

locationHeaderUrl
Use this to prepare redirection URLs for location-headers. It will convert the URL to be absolute. This is also useful in other cases where an absolute URL must be used,
header('Location: ' . \TYPO3\CMS\Core\Utility\GeneralUtility::locationHeaderUrl($this->retUrl));
exit;
Function
Comments
3/17/2016 5:01 AM
22 of 145
Function
Comments
Get SQL WHERE-clause filtering deleted records
Tables from $TCA might be configured to set an integer flag when deleting a record instead of actually removing it from the database. Records with the deleted-flag set should never
Note
In the frontend this is built into the enableFields() method.
deleteClause
Example:
$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
'pid, uid, title, TSconfig, is_siteroot, storage_pid',
'pages',
'uid = ' . intval($uid) . ' ' .
\TYPO3\CMS\Backend\Utility\BackendUtility::deleteClause('pages') . ' ' .
$clause
);
Create Function menu in backend modules

Creates a selector box menu or checkbox with states automatically saved in the backend user session. Such a function menu could look like this:
The selector box is made by this function call. It sets the ID variable (zero if not available), the GET var name, SET[mode], the current value from MOD_SETTINGS and finally the arr
\TYPO3\CMS\Backend\Utility\BackendUtility::getFuncMenu(
$this->id,
'SET[mode]',
$this->MOD_SETTINGS['mode'],
$this->MOD_MENU['mode']
)
Prior to making the menu it is required that the MOD_MENU array is set up with an array of options. This could look like this (getting some labels from the locallang system). In add
getFuncMenu
getFuncCheck
$this->MOD_MENU = array(
'mode' => array(
0 => $LANG->getLL('user_overview'),
'perms' => $LANG->getLL('permissions')
)
);
// Clean up settings:
$this->MOD_SETTINGS = \TYPO3\CMS\Backend\Utility\BackendUtility::getModuleData(
$this->MOD_MENU,
\TYPO3\CMS\Core\Utility\GeneralUtility::_GP('SET'),
$this->MCONF['name']
);
You can have checkboxes as well:
Then the function call looks like this. Notice the fourth argument is gone because a checkbox does not have any information about options like a selector box would have.
\TYPO3\CMS\Backend\Utility\BackendUtility::getFuncCheck(
0,
'SET[own_member_only]',
$this->MOD_SETTINGS['own_member_only']
);
For checkboxes you must set the key in the MOD_MENU array as well. Otherwise the values are not registered in the user session:
'own_member_only' => '',
3/17/2016 5:01 AM
23 of 145
Function
Comments
Create onclick-JavaScript code that links to edit form for a record
Use this function to create a link to the alt_doc.php core script which can generate editing forms for any $TCA configured record. The actual editing command is passed to alt_d
For detailed examples, see Links to edit records.
editOnClick
Example:
$params = '&edit[pages][' . $row['uid'] . ']=edit';
$link = '<a href="#" onclick="' .
htmlspecialchars(\TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick($params, '', -1)).
'">Edit</a>';
Create onclick-JavaScript code that opens a page in the frontend

It will detect the correct domain name if needed and provide the link with the right back path. Also it will re-use any window already open.
viewOnClick
// "View page" link is added:

$link = '<a href="#" onclick="' .
htmlspecialchars(\TYPO3\CMS\Backend\Utility\BackendUtility::viewOnClick(
$pageId,
$GLOBALS['BACK_PATH'],
\TYPO3\CMS\Backend\Utility\BackendUtility::BEgetRootLine($pageId)
)) . '">View page</a>';
Create icon or short description for Context Sensitive Help (CSH)

You are encouraged to integrate Content Sensitive Help in your backend modules and for your database tables. This will help users to use TYPO3 and your TYPO3 applications
wrapInHelp
Example:
// Setting "table name" to module name with prefix
$tableIdentifier = '_MOD_' . $this->MCONF['name'];
// Creating CSH icon and short description (for item "property"):
$HTMLcode .= \TYPO3\CMS\Backend\Utility\BackendUtility::wrapInHelp($tableIdentifier, 'property');
Function
Comments
Returns true if an extension is loaded (installed)
Use if you just need to check if an extension is loaded in a TYPO3 installation.
Example:
// If the extension "sys_note" is loaded, then...
if (\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('sys_note'))
isLoaded
...
// Check if the "indexed_search" extension is loaded.

// If not, an exception will be thrown!
try {
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('indexed_search', TRUE);
}
catch (BadFunctionCallException $e) {
...
}
// Assign value "popup" if extension "tsconfig_help" is loaded
$type = \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('tsconfig_help') ? 'popup' : '';
3/17/2016 5:01 AM

Function
Comments
Get file path to an extension directory
If you need to get the absolute or relative filepaths to an extension you should use these functions. Extension can be located in three dierent positions in the filesystem whether they
Examples:
extPath
extRelPath
siteRelPath
// Include a PHP file from the extension "extrep_wizard".

// \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath() returns the absolute path to the
// extension directory.
require_once(
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('extrep_wizard') .
'pi/class.tx_extrepwizard.php'
);
// Get relative path (relative to PATH_typo3) to an icon (backend)
$icon = \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extRelPath('tt_rating') . 'rating.gif';
// Get relative path (relative to PATH_site) to an icon (frontend)
return '<img src="'.
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::siteRelPath('indexed_search') . 'pi/res/locked.gif'
... />';
Function
Comments
Getting correct icons
Always use these functions if you need to get some arbitrary icon ( getSpriteIcon() ), the correct icon for a record ( getSpriteIconForRecord() ) or for a file (
More information about skinning is found in the TYPO3 CMS Skinning Reference.
getSpriteIcon
getSpriteIconForFile
getSpriteIconForRecord
// Getting default icon for the "tt_content" table

$icon = \TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIconForRecord(
'tt_content',
array()
);
// Getting an icon where record content may define the look
$icon = \TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIconForRecord(
$table,
$row
);
// Getting a given icon, for example the "new document" action
\TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIcon('actions-document-new');
This class is always accessed via its global instance $GLOBALS['TYPO3_DB'] .
24 of 145
Function
Comments
3/17/2016 5:01 AM

Function
Comments
Database Access API
To be compatible with the DataBase Abstraction Layer (DBAL) you should always use the global object $GLOBALS['TYPO3_DB'] for database access. The class \TYPO3\CMS\
Note
When writing code for the TYPO3 backend, you should rely on TCEmain whenever possible.
Inserting a record:
Just fill an array with fieldname => value pairs and pass it to exec_INSERTquery() along with the table name in which it should be inserted:
$insertFields = array(
'md5hash' => $md5,
'tstamp' => time(),
'type' => 2,
'params' => $inUrl
);
$GLOBALS['TYPO3_DB']->exec_INSERTquery(
'cache_md5params',
$insertFields
);
Updating a record:
Create an array of fieldname => value pairs before calling exec_UPDATEquery() . The function call is almost like inserting, but you need to add a WHERE clause to target the
exec_INSERTquery
exec_UPDATEquery
exec_DELETEquery
exec_SELECTquery
$fields_values = array(
'title' => $data['sys_todos'][$key]['title'],
'deadline' => $data['sys_todos'][$key]['deadline'],
'description' => $data['sys_todos'][$key]['description'],
'tstamp' => time()
);
$GLOBALS['TYPO3_DB']->exec_UPDATEquery(
'sys_todos',
'uid=' . intval($key),
$fields_values
);
Deleting a record:
Call exec_DELETEquery() with the tablename and the WHERE clause selecting the record to delete:
$GLOBALS['TYPO3_DB']->exec_DELETEquery(
'sys_todos',
'uid=' . intval($key)
);
Selecting a record:
Call exec_SELECTquery() with at least the first three arguments (field list to select, table name and WHERE clause). The return value is a result pointer (or object) which shou
'*',
$theTable,
$theField . '="' .
$GLOBALS['TYPO3_DB']->quoteStr($theValue, $theTable) . '"' .
$this->deleteClause($theTable) . ' ' .
$whereClause,
$groupBy,
$orderBy,
$limit
);
$rows = array();
while(($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res))) {
$rows[] = $row;
}
$GLOBALS['TYPO3_DB']->sql_free_result($res);
if (count($rows))
return $rows;
Tip
There are many more select methods in \TYPO3\CMS\Dbal\Database\DatabaseConnection , look at its API for details.
This class is always accessed via its global instance $GLOBALS['BE_USER'] .
25 of 145
Function
Comments
3/17/2016 5:01 AM

Function
Comments
Returns true if current backend user is admin
Use this if you need to restrict a user from doing something unless he is admin:
isAdmin
if ($GLOBALS['BE_USER']->isAdmin()) {
...
}
Return WHERE clause for filtering pages for which the current user has the requested permission
getPagePermsClause
The most typical usage of this is to call the function with the value 1 (= show). Then the WHERE clause returned will filter away all pages to which the user has no r
You should also refer to the TYPO3 Core Coding Guidelines (CGL) document which is the authoritative source to know about which coding practices are required for TYPO3 core and
extension programming.
These functions are generally just nice to know. They provide functionality which you will o en need in TYPO3 applications and therefore they will save you time and make your
applications easier for others to understand as well since you use commonly known functions.
Please take time to learn these functions!
26 of 145
Function
Comments
Check if an item exists in a comma-separated list of items.
inList
if (\TYPO3\CMS\Core\Utility\GeneralUtility::inList('gif,jpg,png', $ext)) {//...}
Returns true if the first part of input string matches the second argument.
isFirstPartOfStr
\TYPO3\CMS\Core\Utility\GeneralUtility::isFirstPartOfStr($path, PATH_site);
Formats a number of bytes as Kb/Mb/Gb for visual output.

Size formatting supports two keywords additionally to the list of labels:
iec: uses the Ki, Mi, etc prefixes and binary base (power of two, 1024)
si: uses the k, M, etc prefixes and decimal base (power of ten, 1000)
The default formatting is set to iec base size calculations on the same base as before. The fractional part, when present, will be two numbers.
formatSize
The list of labels is still supported and defaults to using binary base. It is also possible to explicitly choose between binary or decimal base when it is used.
$size = \TYPO3\CMS\Core\Utility\GeneralUtility::formatSize(85123) . 'B';
echo $size; // output: 83.13 KiB
$size = \TYPO3\CMS\Core\Utility\GeneralUtility::formatSize(85123, 'si') . 'B';
echo $size; // output: 85.12 kB
$size = \TYPO3\CMS\Core\Utility\GeneralUtility::formatSize(85123, '| kB| MB| GB| TB| PB| EB| ZB| YB');
$size = \TYPO3\CMS\Core\Utility\GeneralUtility::formatSize(85123, '| kB| MB| GB| TB| PB| EB| ZB| YB', 1000);
Evaluates a string as an email address.

validEmail
if ($email && \TYPO3\CMS\Core\Utility\GeneralUtility::validEmail($email)) {
Various flavors of exploding a string by a token.
\TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode() - Explodes a string by a token and trims the whitespace away around each item. Optiona
trimExplode
array_unique(\TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode(',', $rawExtList, 1));

\TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode(chr(10), $content);
intExplode
\TYPO3\CMS\Core\Utility\GeneralUtility::intExplode() - Explodes a by a token and converts each item to an integer value. Very useful to force int
revExplode
// Make integer list

implode(\TYPO3\CMS\Core\Utility\GeneralUtility::intExplode(',', $row['subgroup']), ',');
\TYPO3\CMS\Core\Utility\GeneralUtility::revExplode() - Reverse explode() which allows you to explode a string into X parts but from the back of
$p = \TYPO3\CMS\Core\Utility\GeneralUtility::revExplode('/', $path, 2);
3/17/2016 5:01 AM
27 of 145
Function
Comments
Merging arrays with fixes for PHP-bugs
array_merge_recursive_overrule
\TYPO3\CMS\Core\Utility\GeneralUtility::array_merge_recursive_overrule() - Merges two arrays recursively and binary safe (integer keys a
array_merge
\TYPO3\CMS\Core\Utility\GeneralUtility::array_merge() - An array_merge function where the keys are NOT renumbered as they happen to be wi
Serialization of PHP variables into XML.
These functions are made to serialize and unserialize PHParrays to XML files. They are used for the FlexForms content in TYPO3, Data Structure definitions etc
\TYPO3\CMS\Core\Utility\GeneralUtility::array2xml_cs() - Converts a PHP array into an XML string:
array2xml_cs
\TYPO3\CMS\Core\Utility\GeneralUtility::array2xml_cs($this->FORMCFG['c'],'T3FormWizard');
xml2array
\TYPO3\CMS\Core\Utility\GeneralUtility::xml2array() - Converts an XML string to a PHP array. This is the reverse function of array2xml_cs()
if ($this->xmlStorage)
{
$cfgArr = \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array($row[$this->P['field']]);
}
Reading / Writing files
\TYPO3\CMS\Core\Utility\GeneralUtility::getURL() - Reads the full content of a file or URL. Used throughout the TYPO3 sources. Transparently tak
getURL
writeFile
$templateCode = \TYPO3\CMS\Core\Utility\GeneralUtility::getURL($templateFile);
\TYPO3\CMS\Core\Utility\GeneralUtility::writeFile() - Writes a string into an absolute filename:
\TYPO3\CMS\Core\Utility\GeneralUtility::writeFile($extDirPath . $theFile, $fileData['content']);
split_fileref
Splits a reference to a file in 5 parts. Alternative to path_info and fixes some PHP-bugs which makes page_info() unattractive at times.
Read content of file system directories.
\TYPO3\CMS\Core\Utility\GeneralUtility::get_dirs() - Returns an array with the names of folders in a specific path
get_dirs
if (@is_dir($path))
{
$directories = \TYPO3\CMS\Core\Utility\GeneralUtility::get_dirs($path);
if (is_array($directories))
{
foreach($directories as $dirName)
{
...
}
}
}
getFilesInDir
\TYPO3\CMS\Core\Utility\GeneralUtility::getFilesInDir() - Returns an array with the names of files in a specific path
getAllFilesAndFoldersInPath
$sFiles = \TYPO3\CMS\Core\Utility\GeneralUtility::getFilesInDir(PATH_typo3conf ,'', 1, 1);

$files = \TYPO3\CMS\Core\Utility\GeneralUtility::getFilesInDir($dir, 'png,jpg,gif');
removePrefixPathFromList
\TYPO3\CMS\Core\Utility\GeneralUtility::getAllFilesAndFoldersInPath() - Recursively gather all files and folders of a path.

\TYPO3\CMS\Core\Utility\GeneralUtility::removePrefixPathFromList() - Removes the absolute part of all files/folders in fileArr (useful for post
// Get all files with absolute paths prefixed:
$fileList_abs =
\TYPO3\CMS\Core\Utility\GeneralUtility::getAllFilesAndFoldersInPath(array(), $absPath, 'php,inc');
// Traverse files and remove abs path from each (becomes relative)
$fileList_rel =
\TYPO3\CMS\Core\Utility\GeneralUtility::removePrefixPathFromList($fileList_abs, $absPath);
Implodes a multidimensional array into GET-parameters (e.g. &param[key][key2]=value2&param[key][key3]=value3 )

implodeArrayForUrl
$pString = \TYPO3\CMS\Core\Utility\GeneralUtility::implodeArrayForUrl('', $params);
Works on HTML tag attributes
\TYPO3\CMS\Core\Utility\GeneralUtility::get_tag_attributes() - Returns an array with all attributes of the input HTML tag as key/value pairs. A
get_tag_attributes
$attribs = \TYPO3\CMS\Core\Utility\GeneralUtility::get_tag_attributes('<' . $subparts[0] . '>');
implodeAttributes
\TYPO3\CMS\Core\Utility\GeneralUtility::implodeAttributes() - Implodes attributes in the array $arr for an attribute list in e.g. and HTML tag (w
$tag = '<img ' . \TYPO3\CMS\Core\Utility\GeneralUtility::implodeAttributes($attribs, 1) . ' />';
resolveBackPath
Resolves ../ sections in the input path string. For example fileadmin/directory/../other_directory/ will be resolved to fileadmin/other_dire
3/17/2016 5:01 AM
28 of 145
Function
Comments
General purpose functions for calling user functions (creating hooks).
See the chapter about Creating hooks in this document for detailed description of these functions.
\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction() - Calls a user-defined function/method in class. Such a function/method should lo

function procItems($items,$iArray,$config,$table,$row,$field) {
global $TCA;
$params=array();
$params['items'] = &$items;
$params['config'] = $config;
$params['TSconfig'] = $iArray;
$params['table'] = $table;
$params['row'] = $row;
$params['field'] = $field;
callUserFunction
getUserObj
\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction(
$config['itemsProcFunc'],
$params,
$this
);
return $items;
}
\TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj() - Creates and returns reference to a user defined object:
$_procObj = &\TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj($_classRef);
$_procObj->pObj = &$this;
$value = $_procObj->transform_rte($value,$this);
Returns the URL to the current script. You can pass an array with associative keys corresponding to the GET-vars you wish to add to the URL. If you set them em
linkThisScript
Function
Comments
Forces the input variable (integer) into the boundaries of $min and $max:
forceIntegerInRange
\TYPO3\CMS\Core\Utility\MathUtility::forceIntegerInRange($row['priority'], 1, 5);
canBeInterpretedAsInteger
Function
Tests if the input is an integer.
Comments
Functions for selecting records by uid or field value.
\TYPO3\CMS\Backend\Utility\BackendUtility::getRecord() - Gets record with uid=$uid from $table
// Getting array with title field from a page:
\TYPO3\CMS\Backend\Utility\BackendUtility::getRecord('pages', intval($row['shortcut']), 'title');
getRecord
getRecordsByField
// Getting a full record with permission WHERE clause

$pageinfo = \TYPO3\CMS\Backend\Utility\BackendUtility::getRecord(
'pages',
$id,
'*',
($perms_clause ? ' AND ' . $perms_clause : '')
);
\TYPO3\CMS\Backend\Utility\BackendUtility::getRecordsByField() - Returns records from table, $theTable , where a field ($theField) equals the value, $the
// Checking if the id-parameter is an alias.
if (!\TYPO3\CMS\Core\Utility\GeneralUtility::testInt($id))
{
list($idPartR) =
\TYPO3\CMS\Backend\Utility\BackendUtility::getRecordsByField('pages', 'alias', $id);
$id = intval($idPartR['uid']);
}
Returns the path (visually) of a page $uid, fx. /First page/Second page/Another subpage
getRecordPath
$label = \TYPO3\CMS\Backend\Utility\BackendUtility::getRecordPath(
intval($row['shortcut']),
$perms_clause,
20
);
Returns a page record (of page with $id) with an extra field _thePath set to the record path if the WHERE clause, $perms_clause, selects the record. Thus is works as an ac
readPageAccess
$perms_clause = $GLOBALS['BE_USER']->getPagePermsClause(1);
$pageinfo = \TYPO3\CMS\Backend\Utility\BackendUtility::readPageAccess($id, $perms_clause);
3/17/2016 5:01 AM
29 of 145
Function
Comments
Date/Time formatting functions using date/time format from $TYPO3_CONF_VARS .
\TYPO3\CMS\Backend\Utility\BackendUtility::date() - Returns $tstamp formatted as ddmmyy (According to $TYPO3_CONF_VARS['SYS']['ddmmyy']
date
datetime
calcAge
\TYPO3\CMS\Backend\Utility\BackendUtility::datetime($row['crdate'])
\TYPO3\CMS\Backend\Utility\BackendUtility::datetime() - Returns $tstamp formatted as ddmmyy hhmm (According to $TYPO3_CONF_VARS['SYS']['ddmm

\TYPO3\CMS\Backend\Utility\BackendUtility::datetime($row['item_mtime'])
\TYPO3\CMS\Backend\Utility\BackendUtility::calcAge() - Returns the age in minutes / hours / days / years of the number of $seconds given as input.
$agePrefixes = ' min| hrs| days| yrs';
\TYPO3\CMS\Backend\Utility\BackendUtility::calcAge(time()-$row['crdate'], $agePrefixes);
Returns title attribute information for a page-record informing about id, alias, doktype, hidden, starttime, endtime, fe_group etc.
titleAttribForPages
$out = \TYPO3\CMS\Backend\Utility\BackendUtility::titleAttribForPages($row, '', 0);

$out = \TYPO3\CMS\Backend\Utility\BackendUtility::titleAttribForPages($row, '1=1 ' . $this->clause, 0);
Returns image tags for thumbnails
\TYPO3\CMS\Backend\Utility\BackendUtility::thumbCode() - Returns a linked image-tag for thumbnail(s)/fileicons/truetype-font-previews from a database row w

thumbCode
\TYPO3\CMS\Backend\Utility\BackendUtility::getThumbNail() - Returns single image tag to thumbnail using a thumbnail script (like thumbs.php
getThumbNail
\TYPO3\CMS\Backend\Utility\BackendUtility::getThumbNail(
$this->doc->backPath . 'thumbs.php',
$filepath,
'hspace="5" vspace="5" border="1"'
);
Get/Set cache values.
\TYPO3\CMS\Backend\Utility\BackendUtility::storeHash() - Stores the string value $data in the cache hash table with the hash key, $hash , and visual/sym
\TYPO3\CMS\Backend\Utility\BackendUtility::getHash() - Retrieves the string content stored with hash key, $hash , in cache hash.
Example of how both functions are used together; first getHash() to fetch any possible content and if nothing was found how the content is generated and stored in the c
storeHash
getHash
// Parsing the user TS (or getting from cache)

$userTS = implode($TSdataArray,chr(10) . '[GLOBAL]' . chr(10));
$hash = md5('pageTS:' . $userTS);
$cachedContent = \TYPO3\CMS\Backend\Utility\BackendUtility::getHash($hash, 0);
$TSconfig = array();
if (isset($cachedContent))
{
$TSconfig = unserialize($cachedContent);
} else {
$parseObj = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\TypoScript\\Parser\\TypoScriptParser'
$parseObj->parse($userTS);
$TSconfig = $parseObj->setup;
\TYPO3\CMS\Backend\Utility\BackendUtility::storeHash($hash,serialize($TSconfig), 'IDENT');
}
\TYPO3\CMS\Backend\Utility\BackendUtility::getRecordTitle() - Returns the title value from the input records field content.
$line.= \TYPO3\CMS\Backend\Utility\BackendUtility::getRecordTitle('tt_content', $row, 1);
\TYPO3\CMS\Backend\Utility\BackendUtility::getProcessedValue() - Returns a human readable output of a value from a record. For instance a database record
getRecordTitle
getProcessedValue
$outputValue = nl2br(
htmlspecialchars(
trim(
\TYPO3\CMS\Core\Utility\GeneralUtility::fixed_lgd_cs(
\TYPO3\CMS\Backend\Utility\BackendUtility::getProcessedValue(
$table,
$fieldName,
$row[$fieldName]
),
250
)
)
)
);
Returns the Page TSconfig for page with id, $id.

This example shows how an object path, mod.web_list is extracted from the Page TSconfig for page $id:
getPagesTSconfig
$modTSconfig = $GLOBALS['BE_USER']->getTSConfig(
'mod.web_list',
\TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfig($id)
);
3/17/2016 5:01 AM
30 of 145
Function
Comments
Adding fields to an existing table definition in $TCA
For usage in ext_tables.php or Configuration/TCA/Overrides files.
addTCAcolumns
// tt_address modified
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTCAcolumns(
'tt_address',
array(
'module_sys_dmail_category' => array('config' => array('type' => 'passthrough')),
'module_sys_dmail_html' => array('config' => array('type' => 'passthrough'))
)
);
Makes fields visible in the TCEforms by adding them to all or selected types-configurations
For usage in ext_tables.php or Configuration/TCA/Overrides files.
addToAllTCAtypes
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTCAtypes(
'fe_users',
'tx_myext_newfield;;;;1-1-1, tx_myext_another_field'
);
Add table name to default list of allowed tables on pages (in $PAGES_TYPES)
allowTableOnStandardPages
For usage in ext_tables.php files.

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::allowTableOnStandardPages('tt_board');
Adds a module (main or sub) to the backend interface.

Note
Extbase-based modules use a dierent registration API.
addModule
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addModule(
'user',
'setup',
'after:task',
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY) . 'mod/'
);
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addModule(
'tools',
'txcoreunittestM1',
'',
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY) . 'mod1/'
);
Adds a Function menu module (third level module) to an existing function menu for some other backend module
insertModuleFunction
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::insertModuleFunction(
'web_func',
'tx_cmsplaintextimport_webfunc',
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY) .
'class.tx_cmsplaintextimport_webfunc.php',
'LLL:EXT:cms_plaintext_import/locallang.xlf:menu_1'
);
Adds an entry to the list of plugins in content elements of type Insert plugin
Note
Extbase-based plug-ins use a dierent registration API.
addPlugin

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin(
array(
'LLL:EXT:examples/Resources/Private/Language/locallang_db.xlf:tt_content.list_type_pi1',
$_EXTKEY . '_pi1'
),
'list_type'
);
Add PlugIn to Static Template #43
When adding a frontend plugin you will have to add both an entry to the TCA definition of tt_content table AND to the TypoScript template which must initiate th
addPItoST43
For usage in ext_localconf.php files.

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPItoST43($_EXTKEY);
3/17/2016 5:01 AM

Function
Comments
Adds an option in the page properties to include a page TSconfig file (the same way as TypoScript static templates are included).
Register PageTS config files in Configuration/TCA/Overrides/pages.php of any extension, which will be shown a erwards at the newly introduced field.
registerPageTSConfigFile
Note
The included files from the pages in the rootline are included a er the default page TSconfig and before the normal TSconfig from the pages in the rootline.
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerPageTSConfigFile('extension_name', 'Configuration/PageTS/myPageTSconf
A er TYPO3s bootstrap sequence has completed, a number of global variables, constants and classes available to any script.
The column Avail. in FE is an indicator that tells you if the constant, variable or class mentioned is also available to scripts running under the frontend of the cms extension.
Constants normally define paths and database information. These values are global and cannot be changed when they are first defined. This is why constants are used for such vital
information.
These constants are defined at various points during the bootstrap sequence.
31 of 145
Note
To make the table below a bit more compact, namespaces were le out. Here are the fully qualified class names referred to below:
SystemEnvironmentBuilder = \TYPO3\CMS\Core\Core\SystemEnvironmentBuilder
Bootstrap = \TYPO3\CMS\Core\Core\Bootstrap
Constant
Defined in
Description
TYPO3_MODE
init.php
Mode of TYPO3: Set to either FE or BE depending on frontend or backend execution. So in init.php
TYPO3_OS
SystemEnvironmentBuilder::getTypo3Os()
Operating systen; Windows = WIN, other = (presumed to be some sort of Unix)
PATH_thisScript
SystemEnvironmentBuilder::definePaths()
Abs. path to current script.
TYPO3_mainDir
This is the directory of the backend administration for the sites of this TYPO3 installation. Hardcoded to
PATH_typo3
Abs. path of the TYPO3 admin dir ( PATH_site + TYPO3_mainDir ).
PATH_typo3_mod
Relative path (from the PATH_typo3 ) to a properly configured module.
PATH_site
Absolute path to directory with the frontend (one directory above PATH_typo3 )
PATH_typo3conf
Absolute TYPO3 configuration path (local, not part of source).
TYPO3_db
Bootstrap::populateLocalConfiguration()
Name of the database, for example t3_coreinstall. Is defined a er the inclusion of typo3conf/LocalConfigu
TYPO3_db_username
Database username
TYPO3_db_password
Database password
TYPO3_db_host
Database hostname, e.g. localhost
TYPO3_extTableDef_script
TYPO3_DLOG
Bootstrap::defineLoggingAndExceptionConstants()
If true, calls to \TYPO3\CMS\Core\Utility\GeneralUtility::devLog() can be made in both frontend and
TYPO3_MOD_PATH
[prior to init.php]
Path to module relative to PATH_typo3 (as defined in the module configuration). Must be defined prior to
Name of a php-include script found in typo3conf/ that contains PHP code that further modifies the table defini
Deprecated. Make Extensions instead.
If defined and set true the Install Tool is activated and the script exits a er that. Used in typo3/install/index
TYPO3_enterInstallScript
[prior to init.php]
Example:
define('TYPO3_enterInstallScript', '1');
If defined and set true the bootstrapping process will return to the parent script even if no backend user was auth
For example, this constant is set by the index.php script so it can include init.php and still show the login f
TYPO3_PROCEED_IF_NO_USER
[prior to init.php]
define('TYPO3_PROCEED_IF_NO_USER', 1);
require ('init.php');
Please be very careful with this feature - use it only when you have total control of what you are doing!
Initiates CLI (Command Line Interface) mode. This is used when you want a shell executable PHP script to initiali
TYPO3_cliMode
[prior to init.php]
For more details see Initializing TYPO3 backend in a PHP shell script in Inside TYPO3.
3/17/2016 5:01 AM
Constant
Defined in
Description
TYPO3_version
SystemEnvironmentBuilder::defineBaseConstants()
The TYPO3 version, as a x.y.z number. Development versions will be either x.y.z-dev for stable versions or x.y
TYPO3_branch
SystemEnvironmentBuilder::defineBaseConstants()
The TYPO3 version Branch, as a x.y number. Without the patch level.
Check \TYPO3\CMS\Core\Core\SystemEnvironmentBuilder::defineBaseConstants() for updates.
32 of 145
Constant
Example value
TYPO3_version
7.6.1-dev
TYPO3_branch
7.6
TYPO3_copyright_year
1998-2015
Constant
Example value
TYPO3_URL_GENERAL
https://typo3.org/
TYPO3_URL_LICENSE
https://typo3.org/typo3-cms/overview/licenses/
TYPO3_URL_EXCEPTION
https://typo3.org/go/exception/CMS/
TYPO3_URL_MAILINGLISTS
http://lists.typo3.org/cgi-bin/mailman/listinfo
TYPO3_URL_DOCUMENTATION
https://typo3.org/documentation/
TYPO3_URL_DOCUMENTATION_TSREF
https://docs.typo3.org/typo3cms/TyposcriptReference/
TYPO3_URL_DOCUMENTATION_TSCONFIG
https://docs.typo3.org/typo3cms/TSconfigReference/
TYPO3_URL_CONSULTANCY
https://typo3.org/support/professional-services/
TYPO3_URL_CONTRIBUTE
https://typo3.org/contribute/
TYPO3_URL_SECURITY
https://typo3.org/teams/security/
TYPO3_URL_DOWNLOAD
https://typo3.org/download/
TYPO3_URL_SYSTEMREQUIREMENTS
https://typo3.org/typo3-cms/overview/requirements/
TYPO3_URL_DONATE
https://typo3.org/donate/online-donation/
TYPO3_URL_WIKI_OPCODECACHE
https://wiki.typo3.org/Opcode_Cache
Constant
Value
Description
NUL
chr(0)
A null
TAB
chr(9)
A tabulator
LF
chr(10)
A linefeed
CR
chr(13)
A carriage return
SUB
chr(26)
A sub (substitute) character
CRLF
CR + LF
Carriage return + linefeed pair
Constant
Value
Description
FILE_DENY_PATTERN_DEFAULT
\.(php[3-7]?|phpsh|phtml)(\..*)?$|^\.htaccess$
Default value of fileDenyPattern
PHP_EXTENSIONS_DEFAULT
php,php3,php4,php5,php6,php7,phpsh,inc,phtml
List of file extensions that should be registered as php script file extensions
Constant
Value
Description
TYPO3_OS
self::getTypo3Os())
Either WIN or empty string
Constant
Value
Description
T3_ERR_SV_GENERAL
-1
General error - something went wrong
T3_ERR_SV_NOT_AVAIL
-2
During execution it showed that the service is not available and should be ignored. The service itself should call $this->setNonAvailable()
T3_ERR_SV_WRONG_SUBTYPE
-3
Passed subtype is not possible with this service
T3_ERR_SV_NO_INPUT
-4
T3_ERR_SV_FILE_NOT_FOUND
-20
File not found which the service should process
T3_ERR_SV_FILE_READ
-21
File not readable
T3_ERR_SV_FILE_WRITE
-22
File not writable
T3_ERR_SV_PROG_NOT_FOUND
-40
T3_ERR_SV_PROG_FAILED
-41
3/17/2016 5:01 AM
Note
Variables in italics may be set in a script prior to inclusion of init.php so they are optional.
Note
To make the table below a bit more compact, namespaces were le out. Here are the fully qualified class names referred to below:
SystemEnvironmentBuilder = \TYPO3\CMS\Core\Core\SystemEnvironmentBuilder
Bootstrap = \TYPO3\CMS\Core\Core\Bootstrap
Global variable
$TYPO3_CONF_VARS
$TYPO3_LOADED_EXT
Defined in
typo3/sysext/core/Configuration/DefaultConfiguration.php
Bootstrap::populateTypo3LoadedExtGlobal()
Description
TYPO3 configuration array. Please refer to mentioned file where each option is described in detail as
Array with all loaded extensions listed with a set of paths. You can check if an extension is loaded by
An instance of the TYPO3 DB wrapper class, \TYPO3\CMS\Core\Database\DatabaseConnection
$TYPO3_DB
Bootstrap::initializeTypo3DbGlobal()
You have to use this object for all interaction with the database.
$EXEC_TIME
SystemEnvironmentBuilder::initializeGlobalTimeTrackingVariables()
Is set to time() so that the rest of the script has a common value for the script execution time.
$SIM_EXEC_TIME
Is set to $EXEC_TIME but can be altered later in the script if we want to simulate another execution
$PARSETIME_START
Time in milliseconds right a er inclusion of the configuration.
$TYPO3_AJAX
ajax.php
Set to true to indicate that an AJAX call is being processed
$PAGES_TYPES
typo3/sysext/core/ext_tables.php
See Page types
$TCA
Bootstrap::loadExtensionTables()
See TCA Reference
$TBE_MODULES
The backend main/sub-module structure. See section elsewhere plus source code of class
$TBE_STYLES
Contains information related to BE skinning.
$T3_SERVICES
SystemEnvironmentBuilder::initializeGlobalVariables()
Global registration of services.
\TYPO3\CMS\Core\Database\DatabaseConnection contains MySQL wrapper functions so you e
Space for various internal global data storage in TYPO3. Each key in this array is a data space for an a
[callUserFunction] + [callUserFunction_classPool]: Used by \TYPO3\CMS\Core\Utility\Gener

$T3_VAR
SystemEnvironmentBuilder::initializeGlobalVariables()
[getUserObj] : Used by \TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj
[RTEobj] : Used to hold the current RTE object if any. See \TYPO3\CMS\Backend\Utility\Backe
[ext][ extension-key ] : Free space for extensions.
$FILEMOUNTS
Bootstrap::initializeBackendUserMounts()
Array of filepaths on the server to be mounted in the directory tree.
$BE_USER
Bootstrap::initializeBackendUser()
Backend user object. See Backend User Object.
$TBE_MODULES_EXT
[In ext_tables.php files of extensions]
Used to store information about modules from extensions that should be included in function men
$TCA_DESCR
[tables.php files]
Can be set to contain file references to local lang files containing TCA_DESCR labels. See section ab
Many of the global variables described above can be inspected using the Admin Tools > Configuration module.
33 of 145
Warning
This module is always viewed in the BE context. Variables defined only in the FE context will not be visible there.
3/17/2016 5:01 AM
$TCA
The backend user of a session is always available to the backend scripts as the global variable $BE_USER . The object is created in
\TYPO3\CMS\Core\Core\Bootstrap::initializeBackendUser() and is an instance of the class \TYPO3\CMS\Core\Authentication\BackendUserAuthentication (which
extends \TYPO3\CMS\Core\Authentication\AbstractUserAuthentication ).
In addition to $BE_USER one other global variables is of interest - $FILEMOUNTS , holding an array with the File mounts of the $BE_USER .
The $BE_USER object is mostly used to check user access right, but contains other helpful information. This is presented here by way of a few examples:
$MCONF is module configuration and the key $MCONF['access'] determines the access scope for the module. This function call will check if the $BE_USER is allowed to access the
module and if not, the function will exit with an error message.
$BE_USER->modAccess($MCONF, 1);
If you know the module key you can check if the module is included in the access list by this function call:
$BE_USER->check('modules', 'web_list');
Here access to the module Web > List is checked.
The same function ->check() can actually check all the ->groupLists inside $BE_USER . For instance:
Checking modify access to the table pages:
$BE_USER->check('tables_modify', 'pages');
Checking read access to the table tt_content:

$BE_USER->check('tables_select', 'tt_content');
Checking if a table/field pair is allowed explicitly through the Allowed Excludefields:
34 of 145
3/17/2016 5:01 AM
$BE_USER->check('non_exclude_fields', $table . ':' . $field);
If you want to know if a user is an admin user (has complete access), just call this method:
$BE_USER->isAdmin();
This function call will return true if the user has read access to a page (represented by its database record, $pageRec ):
$BE_USER->doesUserHaveAccess($pageRec, 1);
Changing the 1 for other values will check other permissions:

use 2 for checking if the user may edit the page
use 4 for checking if the user may delete the page.
Access to a page should not be checked only based on page permissions but also if a page is found within a DB mount for ther user. This can be checked by this function call ( $id is the
page uid):
$BE_USER->isInWebMount($id)
If you wish to make a SQL statement which selects pages from the database and you want it to be only pages that the user has read access to, you can have a proper WHERE clause returned
by this function call:
$BE_USER->getPagePermsClause(1);
Again the number 1 represents the read permission; 2 is edit and 4 is delete permission. The result from the above query could be this string:
((pages.perms_everybody & 1 = 1)OR(pages.perms_userid = 2 AND pages.perms_user & 1 = 1)OR(pages.perms_groupid in (1) AND pages.perms_group & 1 =
1))
This stores the input variable $compareFlags (an array!) with the key tools_beuser/index.php/compare
$compareFlags = \TYPO3\CMS\Core\Utility\GeneralUtility::_GP('compareFlags');
$BE_USER->pushModuleData('tools_beuser/index.php/compare', $compareFlags);
This gets the module data with the key tools_beuser/index.php/compare (lasting only for the session)
$compareFlags = $BE_USER->getModuleData('tools_beuser/index.php/compare', 'ses');
This function can return a value from the User TSconfig structure of the user. In this case the value for options.clipboardNumberPads:
$BE_USER->getTSConfigVal('options.clipboardNumberPads');
The full be_users record of a authenticated user is available in $BE_USER ->user as an array. This will return the username:
$BE_USER->user['username']
The internal ->uc array contains options which are managed by the User Tools > User Settings module (extensions setup). These values are accessible in the $BE_USER->uc array. This
will return the current state of Condensed mode for the user:
35 of 145
3/17/2016 5:01 AM
$BE_USER->uc['condensedMode']
The TYPO3 Core Engine is the class that handles all *data* writing to database tables configured in $TCA. In addition the class handles commands such as copy, move, delete. It will handle
undo/history and versioning of records and everything will be logged to the sys_log. And it will make sure that write permissions are evaluated correctly for the user trying to write to the
database. Generally, any processing specific option in the $TCA array is handled by TCE.
Using TCE for manipulation of the database content in the $TCA-configured tables guarantees that the data integrity of TYPO3 is respected. This cannot be safely guaranteed if you write to
$TCA-configured database tables directly. It will also manage the relations to files and other records.
TCE requires a backend login to work. This is due to the fact that permissions are observed (of course) and thus TCE needs a backend user to evaluate against. This means you cannot use
TCEmain from the frontend scope. Thus writing to tables (such as a guestbook) will have to be done from the frontend without TCEmain.
The features of the $TCA are described in the TCA Reference.
TCE also has a part for handling files. The file operations are normally performed in the File > List module where you can manage a directory on the server by copying, moving,
deleting and editing files and directories. The file operations are managed by two core classes, \TYPO3\CMS\Core\Utility\File\BasicFileUtility and
\TYPO3\CMS\Core\Utility\File\ExtendedFileUtility .
When you are using TCE from your backend applications you need to prepare two arrays of information which contain the instructions to TCEmain
( \TYPO3\CMS\Core\DataHandling\DataHandler ) of what actions to perform. They fall into two categories: data and commands.
Data is when you want to write information to a database table or create a new record.
Commands is when you want to move, copy or delete a record in the system.
The data and commands are created as multidimensional arrays and to understand the API of TCEmain you simply need to understand the hierarchy of these two arrays.
Syntax:
$cmd[ tablename ][ uid ][ command ] = value
Description of keywords in syntax:
36 of 145
Key
Data type
Description
tablename
string
Name of the database table. Must be configured in $TCA array, otherwise it cannot be processed.
uid
integer
The UID of the record that is manipulated. This is always an integer.

The command type you want to execute.
Note
command
string (command keyword)
Only one command can be executed at a time for each record! The first command in the array will be taken.
See table below for :ref:`command keywords and values<tce-command-keywords>`
The value for the command
value
mixed
See table below for :ref:`command keywords and values<tce-command-keywords>`
Command
Data type
Value
The significance of the value depends on whether it is positive or negative:
Positive value: The value points to a page UID. A copy of the record (and possibly child elements/tree below) will be inserted inside that page as the first element.
copy
integer
Negative value: The (absolute) value points to another record from the same table as the record being copied. The new record will be inserted on the same page as that re
Zero value: Record is inserted on tree root level.
move
integer
Works like copy but moves the record instead of making a copy.
3/17/2016 5:01 AM

Command
Data type
delete
Value
Value should always be 1
This action will delete the record (or mark the record deleted if configured in $TCA ).
Value should always be 1.
undelete
1
This action will set the deleted-flag back to 0.
Pointer to a sys_language uid to localize the record into. Basically a localization of a record is making a copy of the record (possibly excluding certain fields defined with
Requirements for a successful localization is this:
[ctrl] options languageField and transOrigPointerField must be defined for the table
localize
integer
A sys_language record with the given sys_language_uid must exist.

The record to be localized by currently be set to Default language and not have any value set for the transOrigPointerField either.
There cannot exist another localization to the given language for the record (looking in the original record PID).
Apart from this, ordinary permissions apply as if the user wants to make a copy of the record on the same page.
Versioning action.
Keys:
[action] : Keyword determining the versioning action. Options are:
new: Indicates that a new version of the record should be created.Additional keys, specific for new action:
[treeLevels]: (Only pages) Integer, -1 to 4, indicating the number of levels of the page tree to version together with a page. This is also referred to as the versioning ty
[label]: Indicates the version label to apply. If not given, a standard label including version number and date is added.
swap: Indicates that the current online version should be swapped with another.Additional keys, specific for swap action:
version
array
[swapWith]: Indicates the uid of the record to swap current version with!
[swapIntoWS]: Boolean, indicates that when a version is published it should be swapped into the workspace of the oline record.
clearWSID: Indicates that the workspace of the record should be set to zero (0). This removes versions out of workspaces without publishing them.
flush: Completely deletes a version without publishing it.
setStage: Sets the stage of an element. Special feature: The id- key in the array can be a comma list of ids in order to perform the stageChange over a number of records
[stageId]: Values are: -1 (rejected), 0 (editing, default), 1 (review), 10 (publish)
[comment]: Comment string that goes into the log.
$cmd['tt_content'][54]['delete'] = 1;
// Deletes tt_content record with uid=54
$cmd['pages'][1203]['copy'] = -303;
//Copies page id=1203 to the position after page 303
$cmd['pages'][1203]['move'] = 303; // Moves page id=1203 to the first position in page 303
Syntax:
$data[tablename][uid][fieldname] = value
37 of 145
Key
Data type
Description
tablename
string
Name of the database table. Must be configured in $TCA array, otherwise it cannot be processed.
uid
mixed
The UID of the record that is modified. If the record already exists, this is an integer. If youre creating new records, use a random string prefixed with NEW, e.g. N
fieldname
string
Name of the database field you want to set a value for. Must be configure in $TCA[ tablename ][columns]
Value for fieldname.
value
string
Important
Always make sure $this->stripslashes_values is false before using TCEmain.)
Note
For FlexForms the data array of the FlexForm field is deeper than three levels. The number of possible levels for FlexForms is infinite and defined by the data structure of the FlexForm.
But FlexForm fields always end with a regular value of course.
3/17/2016 5:01 AM
This creates a new page titled The page title as the first page inside page id 45:
$data['pages']['NEW9823be87'] = array(
'title' => 'The page title',
'subtitle' => 'Other title stuff',
'pid' => '45'
);
This creates a new page titled The page title right a er page id 45 in the tree:
'title' => 'The page title',
'subtitle' => 'Other title stuff',
'pid' => '-45'
);
This creates two new pages right a er each other, located right a er the page id 45:
'title' => 'Page 1',
'pid' => '-45'
);
$data['pages']['NEWbe68s587'] = array(
'title' => 'Page 2',
'pid' => '-NEW9823be87'
);
Notice how the second pid value points to the NEW... id placeholder of the first record. This works because the new id of the first record can be accessed by the second record. However
it works only when the order in the array is as above since the processing happens in that order!
This updates the page with uid=9834 to a new title, New title for this page, and no_cache checked:
$data['pages'][9834] = array(
'title' => 'New title for this page',
'no_cache' => '1'
);
TCE also has an API for clearing the cache tables of TYPO3:
Syntax:
$tce->clear_cacheCmd($cacheCmd);
$cacheCmd values
Description
[integer]
Clear the cache for the page id given.

Clears all cache tables ( cache_pages , cache_pagesection , cache_hash ).
all
Only available for admin-users unless explicitly allowed by User TSconfig options.clearCache.all.
Clears all pages from cache_pages .
pages
Only available for admin-users unless explicitly allowed by User TSconfig options.clearCache.pages.
temp_CACHED
Clears the temp_CACHED files in typo3conf/ .
You can configure cache post-processing with a user defined PHP function. Configuration of the hook can be done from ext_localconf.php . An example might look like:
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearCachePostProc'][] = 'myext_cacheProc->proc';
require_once(\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('myext') . 'class.myext_cacheProc.php');
There are a few internal variables you can set prior to executing commands or data submission. These are the most significant:
38 of 145
Internal variable
Data type
Description
Sets whether a page tree branch can be recursively deleted.
->deleteTree
Boolean
If this is set, then a page is deleted by deleting the whole branch under it (user must have delete permissions to it all). If not set, then the page is deleted
Default is false.
Sets the number of branches on a page tree to copy.
->copyTree
Integer
If 0 then branch is not copied. If 1 then pages on the 1st level is copied. If 2 then pages on the second level is copied, and so on.
Default is zero.
3/17/2016 5:01 AM

Internal variable
Data type
->reverseOrder
Boolean
Description
If set, the data array is reversed in the order, which is a nice thing if youre creating a whole bunch of new records.
Default is zero.
This list of tables decides which tables will be copied. If empty then none will. If * then all will (that the user has permission to of course).
->copyWhichTables
list of strings (tables)

Default is *.
If set, then all values will be passed through stripslashes(). This has been the default since the birth of TYPO3 in times when input from POST forms were
Warning
->stripslashes_values
boolean
It is highly recommended to set this value to zero every time the class is used!
If you set this value to false you can pass values as-is to the class and it is most like that this is what you want. Otherwise you would have to pass all value
Default is (currently) 1 (true) but might be changed in the future!
Its really easy to use the class \TYPO3\CMS\Core\DataHandling\DataHandler in your own scripts. All you need to do is include the class, build a $data/$cmd array you want to pass to
the class and call a few methods.
Important
Mind that these scripts have to be run in the backend scope! There must be a global $BE_USER object.
In your script you simply insert this line to include the class:
What follows are a few code listings with comments which will provide you with enough knowledge to get started. It is assumed that you have populated the $data and $cmd arrays
correctly prior to these chunks of code. The syntax for these two arrays is explained in the previous chapter.
This is the most basic example of how to submit data into the database. It is four lines. Line 1 instantiates the class, line 2 defines that values will be provided without escaped characters
(recommended!), line 3 registers the $data array inside the class and initializes the class internally! Finally line 4 will execute the data submission.
1
2
3
4
$tce = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\DataHandling\\DataHandler');
$tce->stripslashes_values = 0;
$tce->start($data, array());
$tce->process_datamap();
The most basic way of executing commands. Line 1 creates the object, line 2 defines that values will be provided without escaped characters (recommended), line 3 registers the $cmd
array inside the class and initializes the class internally! Finally line 4 will execute the commands.
1
2
3
4
$tce->start(array(), $cmd);
$tce->process_cmdmap();
In this example the cache clearing API is used. No data is submitted, no commands executed. Still you will have to initialize the class by calling the start() method (which will initialize
internal variables).
Note
Clearing a given cache is possible only for users that are admin or have specific permissions to do so.
1 $tce = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\DataHandling\\DataHandler');
2 $tce->start(array(), array());
3 $tce->clear_cacheCmd('all');
Since TYPO3 CMS 6.2, caches are organized in groups. Clearing all caches will actually clear caches from the all group and not really all caches. Check the caching framework
architecture section for more details about available caches and groups.
Imagine the $data array something like this:
39 of 145
3/17/2016 5:01 AM
1 $data = array(
2
'pages' => array(
3
'NEW_1' => array(
4
'pid' => 456,
5
'title' => 'Title for page 1',
6
),
7
'NEW_2' => array(
8
'pid' => 456,
9
'title' => 'Title for page 2',
10
),
11
)
12 );
This aims to create two new pages in the page with uid 456. In the follow code this is submitted to the database. Notice how line 3 reverses the order of the array. This is done because
otherwise page 1 is created first, then page 2 in the same PID meaning that page 2 will end up above page 1 in the order. Reversing the array will create page 2 first and then page
1 so the expected order is preserved.
To insert a record a er a given record, set the other records negative uid as pid in the new record youre setting as data.
Apart from this line 6 will send a signal that the page tree should be updated at the earliest occasion possible. Finally, the cache for all pages is cleared in line 7.
1
2
3
4
5
6
7
$tce->reverseOrder = 1;
$tce->start($data, array());
\TYPO3\CMS\Backend\Utility\BackendUtility::setUpdateSignal('updatePageTree');
$tce->clear_cacheCmd('pages');
In this case it is shown how you can use the same object instance to submit both data and execute commands if you like. The order will depend on the order of line 4 and 5.
In line 3 the start() method is called, but this time with the third possible argument which is an alternative $BE_USER object. This allows you to force another backend user account to
create stu in the database. This may be useful in certain special cases. Normally you should not set this argument since you want TCE to use the global $BE\_USER .
1
2
3
4
5
$tce->start($data, $cmd, $alternative_BE_USER);
$tce->process_cmdmap();
This script is a gateway for POST forms to class \TYPO3\CMS\Core\DataHandling\DataHandler . It has historically been the script to which data was posted when you wanted to update
something in the database.
Today it is used for editing by only a few scripts, actually only the Quick Edit module in Web>Page (frontend). The standard forms you find in TYPO3 are normally rendered and handled
by alt_doc.php which includes \TYPO3\CMS\Core\DataHandling\DataHandler on its own.
For commands it is still used from various locations.
You can send data to this file either as GET or POST vars where POST takes precedence. The variable names you can use are:
GP var name
Data type
Description
Data array on the form [tablename][uid][fieldname] = value .
data
array
Typically it comes from a POST form which submits a form field like <input name="data[tt_content][123][header]" value="This is the headline"
Command array on the form [tablename][uid][command] = value . This array may get additional data set internally based on clipboard commands send in CB var!
cmd
array
cacheCmd
string
Cache command sent to ->clear_cacheCmd
redirect
string
Redirect URL. Script will redirect to this location a er performing operations (unless errors has occurred)
flags
array
Accepts options to be set in TCE object. Currently it supports reverseOrder (boolean).
mirror
array
Example: [mirror][table][11] = '22,33' will look for content in [data][table][11] and copy it to [data][table][22] and [data][table][33]
prErr
boolean
If set, errors will be printed on screen instead of redirection. Should always be used, otherwise you will see no errors if they happen.
CB
array
Clipboard command array. May trigger changes in cmd.
vC
string
Verification code
uPT
string
Update Page Tree Trigger. If set and the manipulated records are pages then the update page tree signal will be set.
Typically this comes from GET vars passed to the script like &cmd[tt\_content][123][delete]=1 which will delete Content Element with UID 123.
File operations in the TCE are handled by the class \TYPO3\CMS\Core\Utility\File\ExtendedFileUtility which extends
40 of 145
\TYPO3\CMS\Core\Utility\File\BasicFileUtility . The instructions for file manipulation are passed to this class as a multidimensional array.
3/17/2016 5:01 AM
Syntax:
$file[ command ][ index ][ key ] = value

Key
Data type
Description
The command type you want to execute.
command
string (command keyword)
index
integer
See table below for :ref:`command keywords, keys and values<tce-file-keywords>`

Integer index in the array which separates multiple commands of the same type.
Depending on the command type. The keys will carry the information needed to perform the action. Typically a target key is used to point to the target dire
key
string
The value for the command
value
string
Command
Keys
Value
delete
data
data = Absolute path to the file/folder to delete
data
data = Absolute path to the file/folder to copy
target
target = Absolute path to the folder to copy to (destination)
altName
altName = (boolean): If set, a new filename is made by appending numbers/unique-string in case the target already exists.
copy
data
move
target
(Exactly like copy, just replace the word copy with move)
altName
data
data = New name, max 30 characters alphanumeric
target
target = Absolute path to the target file/folder
data
data = Folder name, max 30 characters alphanumeric
target
target = Absolute path to the folder where to create it
data
data = New filename
target
target = Absolute path to the folder where to create it
data
data = The new content
target
target = Absolute path to the target file
rename
newfolder
newfile
editfile
data = ID-number (points to the global var that holds the filename- ref ( $_FILES["upload_" . $id]["name"] ).
data
target = Absolute path to the target folder (destination)
upload
target
upload_$id = File reference. $id must equal value of file[upload][...][data] !
upload_$id
See \TYPO3\CMS\Core\Utility\File\ExtendedFileUtility::func_upload() .
data
data = Absolute path to the zip-file. (file extension must be zip)
target
target = The absolute path to the target folder (destination) (if not set, default is the same as the zip-file)
unzip
It is unlikely that you will need to use this internally in your scripts like you will need \TYPO3\CMS\Core\DataHandling\DataHandler . It is fairly uncommon to need the file
manipulations in own scripts unless you make a special application. Therefore the most typical usage of this API is from tce_file.php and the core scripts that are activated by the File >
List module.
However, if you need it this is an example (taken from tce_file.php ) of how to initialize the usage.
1
2
3
4
5
6
7
// Initializing:
$this->fileProcessor = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Utility\\File\\ExtendedFileUtility');
$this->fileProcessor->init($FILEMOUNTS, $TYPO3_CONF_VARS['BE']['fileExtensions']);
$this->fileProcessor->init_actionPerms($BE_USER->user['fileoper_perms']);
$this->fileProcessor->start($this->file);
$this->fileProcessor->processData();
Line 2 makes an instance of the class and line 3 initializes the object with the filemounts of the current user and the array of allow/deny file extensions in web-space and p-space (see
below). Then the file operation permissions are loaded from the user object in line 4. Finally, the file command array is loaded in line 6 (and internally additional configuration takes place
from $TYPO3_CONF_VARS !). In line 7 the command map is executed.
The control of file extensions goes in two categories. Webspace and pspace. Webspace is folders accessible from a web browser (below TYPO3_DOCUMENT_ROOT) and pspace is
41 of 145
3/17/2016 5:01 AM
everything else.
The control is done like this: if an extension matches allow then the check returns true. If not and an extension matches deny then the check return false. If no match at all, returns true.
You list extensions comma-separated. If the value is a * every extension is matched. If no file extension, true is returned if allow is *, false if deny is * and true if none of these matches.
This (default) configuration below accepts everything in pspace and everything in webspace except php files:
$TYPO3_CONF_VARS['BE']['fileExtensions'] = array (
'webspace' => array('allow' => '', 'deny' => 'php'),
'ftpspace' => array('allow' => '*', 'deny' => '')
);
This script serves as the file administration part of the TYPO3 Core Engine. Its a gateway for TCE (TYPO3 Core Engine) file-handling through POST forms. It uses
\TYPO3\CMS\Core\Utility\File\ExtendedFileUtility for the manipulation of the files.
This script is used from the File > List module where you can rename, create, delete etc. files and directories on the server.
You can send data to this file either as GET or POST vars where POST takes precedence. The variable names you can use are:
GP var name
Data type
Description
Array of file operations. See previous information about basic file functions.
This could typically be a GET var like &file[delete][0][data]=[absolute file path] or a POST form field like:
file
array
"<input type="text" name="file[newfolder][0][data]" value=""/>
<input type="hidden" name="file[newfolder][0][target]"
value="[absolute path to folder to create in]"/>"
redirect
string
Redirect URL. Script will redirect to this location a er performing operations.
CB
array
Clipboard command array. May trigger changes in file
vC
string
Verification code
overwriteExistingFiles
boolean
If existing files should be overridden.
The concept of workspaces needs attention from extension programmers. The implementation of workspaces is however made so that no critical problems can appear with old extensions;
First of all the Live workspace is no dierent from how TYPO3 has been working for years so that will be supported out of the box (except placeholder records must be filtered out in
the frontend with t3ver_state != , see below).
Secondly, all permission related issues are implemented in TCEmain so the worst your users can experience is an error message.
However, you probably want to update your extension so that in the backend the current workspace is reflected in the records shown and the preview of content in the frontend works as
well. Therefore this chapter has been written with instructions and insight into the issues you are facing.
For the frontend the challenges are mostly related to creating correct previews of content in workspaces. For most extensions this will work transparently as long as they use the API
functions in TYPO3 to request records from the system.
The most basic form of a preview is when a live record is selected and you lookup a future version of that record belonging to the current workspace of the logged in backend user. This is
very easy as long as a record is selected based on its uid or pid fields which are not subject to versioning; You simply call sys_page->versionOL() a er record selection.
However, when other fields are involved in the where clause it gets dirty. This happens all the time! For instance, all records displayed in the frontend must be selected with respect to
enableFields configuration! What if the future version is hidden and the live version is not? Since the live version is selected first (not hidden) and then overlaid with the content of the
future version (hidden) the eect of the hidden field we wanted to preview is lost unless we also check the overlaid record for its hidden field ( ->versionOL() actually does this). But
what about the opposite; if the live record was hidden and the future version not? Since the live version is never selected the future version will never have a chance to display itself! So we
must first select the live records with no regard to the hidden state, then overlay the future version and eventually check if it is hidden and if so exclude it. The same problem applies to all
other enableFields, future versions with delete flags and current versions which are invisible placeholders for future records. Anyway, all that is handled by the
\TYPO3\CMS\Frontend\Page\PageRepository class which includes functions for enableFields and deleted so it will work out of the box for you. But as soon as you do selection
based on other fields like email, username, alias etc. it will fail.
Challenge: How to preview elements which are disabled by enableFields in the live version but not necessarily in the oline version. Also, how to filter out new live records with
t3ver_state set to 1 (placeholder for new elements) but only when not previewed.
Solution: Disable check for enableFields / where_del_hidden on live records and check for them in versionOL on input record.
42 of 145
Any place where enableFields() are not used for selecting in the frontend you must at least check that t3ver_state != 1 so placeholders for new records are not displayed.
3/17/2016 5:01 AM
Make sure never to select any record with pid = -1 ! (oline records - related to versioning).
If you need to detect preview mode for versioning and workspaces you can read these variables:
$GLOBALS['TSFE']->sys_page->versioningPreview : If true, you are allowed to display previews of other record versions.
$GLOBALS['TSFE']->sys_page->versioningWorkspaceId : Will tell you the id of the workspace of the current backend user. Used for preview of workspaces.
Use these API functions for support of version previews in the frontend:
Function
Description
Versioning Preview Overlay.
Generally ALWAYS used when records are selected based on uid or pid. If records are selected on other fields tha
Principle: Record online! => Find oline?
Example:
This is how simple it is to use this record in your frontend plugins when you do queries directly (not using API fu
$GLOBALS[TSFE]->sys_page->versionOL($table, &$row, $unsetMovePointers=FALSE)
$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(...);
while (($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res))) {
$GLOBALS['TSFE']->sys_page->versionOL($table,$row);
if (is_array($row)) {
...
When the live record is selected, call ->versionOL() and make sure to check if the input row (passed by refer
The third argument, $unsetMovePointers = FALSE , can be set to TRUE when selecting records for display o
Finding online PID for oline version record.
Will look if the pid value of the input record is -1 (it is an oline version) and if the table supports versioning; if
$GLOBALS[TSFE]->sys_page->fixVersioningPid()
Used whenever you are tracking something back, like making the root line. In fact, it is currently only used by th
Principle: Record oline! => Find online?
These issues are not planned to be supported for preview:

Lookups and searching for records based on other fields than uid, pid or enableFields will never reflect workspace content since overlays happen to online records a er they are
selected.
This problem can largely be avoided for versions of new records because versions of a New-placeholder can mirror certain fields down onto the placeholder record. For the
tt\_content table this is configured as
shadowColumnsForNewPlaceholders'=> 'sys\_language\_uid,l18n\_parent,colPos,header'
so that these fields used for column position, language and header title are also updated in the placeholder thus creating a correct preview in the frontend.
For versions of existing records the problem is in reality reduced a lot because normally you dont change the column or language fields a er the record is first created anyway! But in
theory the preview can fail.
When changing the type of a page (e.g. from Standard to External URL) the preview might fail in cases where a look up is done on the :code`doktype` field of the live record.
Page shortcuts might not work properly in preview.
Mount Points might not work properly in preview.
It is impossible to preview the value of count(*) selections since we would have to traverse all records and pass them through ->versionOL() before we would have a reliable
result!
In \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::getPageShortcut() , sys_page->getMenu() is called with an additional WHERE clause which will
not respect if those fields are changed for a future version. This could be the case other places where getmenu() is used (but a search shows it is not a big problem). In this case we will
for now accept that a wrong shortcut destination can be experienced during previews.
The main challenge in the backend is to reflect how the system will look when the workspace gets published. To create a transparent experience for backend users we have to overlay
almost every selected record with any possible new version it might have. Also when we are tracking records back to the page tree root point we will have to correct pid-values. All issues
related to selecting on fields other than pid and uid also relates to the backend as they did for the frontend.
43 of 145
Function
Description
3/17/2016 5:01 AM

Function
Description
Overlaying record with workspace version if any. Works like ->sys_page->versionOL() does, but for the backend. I
Example:
\TYPO3\CMS\Backend\Utility\BackendUtility::workspaceOL()
$result = $GLOBALS['TYPO3_DB']->exec_SELECTquery('*', 'pages', 'uid=' . intval($id)
$row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($result);
\TYPO3\CMS\Backend\Utility\BackendUtility::workspaceOL('pages', $row);
Gets record from table and overlays the record with workspace version if any.
Example:
\TYPO3\CMS\Backend\Utility\BackendUtility::getRecordWSOL()
$row = \TYPO3\CMS\Backend\Utility\BackendUtility::getRecordWSOL($table, $uid);
// This is the same as:

$row = \TYPO3\CMS\Backend\Utility\BackendUtility::getRecord($table, $uid);
\TYPO3\CMS\Backend\Utility\BackendUtility::workspaceOL($table, $row);
\TYPO3\CMS\Backend\Utility\BackendUtility::fixVersioningPid()
Translating versioning PID -1 to the pid of the live record. Same as sys_page->fixVersioningPid() but for the bac
\TYPO3\CMS\Backend\Utility\BackendUtility::isPidInVersionizedBranch()
Will fetch the rootline for the pid, then check if anywhere in the rootline there is a branch point. Returns either branch
\TYPO3\CMS\Backend\Utility\BackendUtility::getWorkspaceVersionOfRecord()
Returns oline workspace version of a record, if found.
\TYPO3\CMS\Backend\Utility\BackendUtility::getLiveVersionOfRecord()
Returns live version of workspace version.

Returns a WHERE-clause which will deselect placeholder records from other workspaces. This should be implemented
Example:
\TYPO3\CMS\Backend\Utility\BackendUtility::versioningPlaceholderClause()
'count(*)',
$this->table,
$this->parentField . '=' . $GLOBALS['TYPO3_DB']->fullQuoteStr($uid, $this->table
\TYPO3\CMS\Backend\Utility\BackendUtility::deleteClause($this->table) .
\TYPO3\CMS\Backend\Utility\BackendUtility::versioningPlaceholderClause($this->table
$this->clause
);
$BE_USER->workspaceCannotEditRecord()
Checking if editing of an existing record is allowed in current workspace if that is oline.
$BE_USER->workspaceCannotEditOlineVersion()
Like $BE_USER->workspaceCannotEditRecord() but also requires version to be oline.
$BE_USER->workspaceCreateNewRecord()
Checks if new records can be created in a certain page (according to workspace restrictions).
$BE_USER->workspacePublishAccess($wsid)
Returns true if user has access to publish in workspace.
$BE_USER->workspaceSwapAccess()
Returns true if user has access to swap versions.
$BE_USER->checkWorkspace()
Checks how the users access is for a specific workspace.
$BE_USER->checkWorkspaceCurrent()
Like ->checkWorkspace() but returns status for the current workspace.
$BE_USER->setWorkspace()
Setting another workspace for backend user.
$BE_USER->setWorkspacePreview()
Setting frontend preview state.
You can restrict access to backend modules by using $MCONF['workspaces'] in the conf.php files. The variable is a list of keywords defining where the module is available:
$MCONF['workspaces'] = online,offline,custom
You can also restrict function menu items to certain workspaces if you like. This is done by an argument sent to the function
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::insertModuleFunction() . See that file for more details.
You can always check what the current workspace of the backend user is by reading $GLOBALS['BE_USER']->workspace . If the workspace is a custom workspace you will find its record
loaded in $GLOBALS['BE_USER']->workspaceRec .
The values for workspaces is either 0 (online/live) or the uid of the corresponding entry in the sys_workspace table.
Since admin users are also restricted by the workspace it is not possible to save any live records when in a workspace. However for very special occasions you might need to bypass this
and to do so, you can set the instance variable \TYPO3\CMS\Core\DataHandling\DataHandler::bypassWorkspaceRestrictions to TRUE. An example of this is when users are
updating their user profile using the User Tool > User Settings module; that actually allows them to save to a live record (their user record) while in a dra workspace.
TYPO3 4.2 and beyond supports moving for Element type versions in workspaces. Technically this works by creating a new online placeholder record (like for new elements in a
workspace) in the target location with t3ver_state = 3 (move-to placeholder) and a field, t3ver_move_id , holding the uid of the record to move (source record) upon publishing. In
addition, a new version of the source record is made and has t3ver_state = 4 (move-to pointer). This version is simply necessary in order for the versioning system to have something
to publish for the move operation.
So in summary, two records are created for a move operation in a workspace: The placeholder (online, with t3ver_state = 3 and t3ver_move_id set) and a new version
44 of 145
3/17/2016 5:01 AM
( t3ver_state = 4 ) of the online source record (the one being moved).

When the version of the source is published a look up will be made to see if a placeholder exists for a move operation and if so the record will take over the pid / sortby value upon
publishing.
Preview of move operations is almost fully functional through the \TYPO3\CMS\Frontend\Page\PageRepository::versionOL() and
\TYPO3\CMS\Backend\Utility\BackendUtility::workspaceOL() functions. When the online placeholder is selected it simply looks up the source record, overlays any version on
top and displays it. When the source record is selected it should simply be discarded in case shown in context where ordering or position matters (like in menus or column based page
content). This is done in the appropriate places.
Note
A new logging API was introduced in TYPO3 CMS 6.0. It is far more flexible than the old one described here, but is not yet in use in the Core. Thus this section remains valid if you want to
write to the sys_log table. Otherwise please consider using the new API.
Writing to the system log is done using the backend user object, which writes to the sys_log table:
$this->BE_USER->writelog($type, $action, $error, $details_nr, $details, $data, $table, $recuid, $recpid,$event_pid, $NEWid);
Here is a description of the arguments to this function call, and corresponding database fields in table sys_log:
45 of 145
Field
Type
Var
Description
Value telling which module in TYPO3 set the log entry. The type values are paired with an action-integer which is telling in more detail what the event was. Her
1 : \TYPO3\CMS\Core\DataHandling\DataHandler (TYPO3 Core Engine where database records are manipulated)

Action values are:
0 = no category
1 = new record
2 = update record
3 = delete record
4 = move record
5 = check/evaluate
type
tinyint
$type
2 : tce_file (File handling in fileadmin/ and absolute filemounts)

Action values are for various file handling types like upload, rename, edit etc.
3 : System (e.g. sys_history save)
4 : Modules: This is the mode you may use for extensions having backend module functionality. Probably you would like to use BE_USER->simplelog()
254 : Personal settings changed
255 : Login or Logout action
1 = login
2 = logout
3 = failed login (+ errorcode 3)
4 = failure_warning_email sent
See type above
action
tinyint
$action
When not available, use value 0
Error level:
0 = message, a notice of an action that happened.
error
tinyint
$error
1 = error, typically a permission problem for the user

2 = System Error, something which should not happen for technical reasons.
3 = Security notice, like login failures
3/17/2016 5:01 AM

Field
Type
Var
Description
Number of detail message. This number should be unique for the combination of type/action
-1 is a temporary detail number you can use while developing and error messages are not fixed yet.
details_nr
tinyint
$details_nr
0 is a value that means the message is not supposed to be translated
>= 1 means the message is fixed and ready for translation.
The log message text (in english). By identification through type/action/details_nr this can be translated through the localization system.
details
tinytext
$details
log_data
tinyblob
$data
Data that follows the log entry. Can be an array. See details for more info.
tablename
varchar(40)
$table
Table name. Special field used by tce_main.php.
recuid
int
$recuid
Record UID. Special field used by tce_main.php.
recpid
int
$recpid
Record PID. Special field used by tce_main.php. [OBSOLETE; not used anymore.]
event_pid
int
$event_pid
The page ID (pid) where the event occurred. Used to select log-content for specific pages.
NEWid
varchar(20)
$NEWid
Special field used by tce_main.php. NEWid string of newly created records.
tstamp
int
EXEC_TIME of event, UNIX time in seconds.
uid
int
Unique ID for log entry, automatically inserted
userid
int
User ID of backend user, automatically set for you
IP
varchar(39)
REMOTE_ADDR of client
workspace
int
Workspace ID
If you insert %s markers in the details message and set $data to an array the first 5 entries (keys 0-4) from $data will substitute the markers sequentially
While it is nice to have log message categorized and numbered during development and sometimes beyond that point a simpler logging API is necessary. Therefore you can also call this
function:
BE_USER->simplelog($message, $extKey='', $error=0);
All you need is to set $message to store a log message. If you call it from an extension it is good practice to also supply the extension key. Finally you can add the error number (according
to the table above) if you need to signal an error.
TYPO3 Logging consists of the following components:

A Logger that receives the log message and related details, like a severity
A LogRecord model which encapsulates the data
Configuration of the logging system
Writers which write the log records to dierent targets (like file, database, rsyslog server, etc.)
Processors which add more detailed information to the log record.
Instantiate a logger for the current class:

/** @var $logger \TYPO3\CMS\Core\Log\Logger */
$logger = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Core\Log\LogManager')->getLogger(__CLASS__);
Log a simple message:

$logger->info('Everything went fine.');
$logger->warning('Something went awry, check your configuration!');
Provide additional information with the log message:
46 of 145
$logger->error(
'This was not a good idea',
array(
'foo' => $bar,
'bar' => $foo,
)
);
$logger->warning() etc. are only shorthands - you can also call $logger->log() directly and pass the severity level:
$logger->log(
\TYPO3\CMS\Core\Log\LogLevel::CRITICAL,
'This is an utter failure!'
);
3/17/2016 5:01 AM
By default the log entries are written to file typo3temp/logs/typo3.log . A sample output looks like this:
Fri, 08 Mar 2013 09:45:00
Fri, 08 Mar 2013 09:45:00
check your configuration!
Fri, 08 Mar 2013 09:45:00
- {"foo":"bar","bar":{}}
Fri, 08 Mar 2013 09:45:00
failure!
+0100 [INFO] request="5139a50bee3a1" component="TYPO3.Examples.Controller.DefaultController": Everything went fine.

+0100 [WARNING] request="5139a50bee3a1" component="TYPO3.Examples.Controller.DefaultController": Something went awry,
+0100 [ERROR] request="5139a50bee3a1" component="TYPO3.Examples.Controller.DefaultController": This was not a good idea
+0100 [CRITICAL] request="5139a50bee3a1" component="TYPO3.Examples.Controller.DefaultController": This is an utter
The LogManager enables an auto-configured usage of loggers in your PHP code by reading the logging configuration and setting the minimum severity level of the Logger accordingly.
/** @var $logger \TYPO3\CMS\Core\Log\Logger */
$logger = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Core\Log\LogManager')->getLogger(__CLASS__);
Using __CLASS__ as name for the logger is recommended to enable logging configuration based on the class hierarchy.
\TYPO3\CMS\Core\Log\Logger provides a central point for submitting log messages, the log() method:
$logger->log($level, $message, $data);
which takes three parameters:

Parameter
Type
Description
One of either:
\TYPO3\CMS\Core\Log\LogLevel::EMERGENCY
\TYPO3\CMS\Core\Log\LogLevel::ALERT
\TYPO3\CMS\Core\Log\LogLevel::CRITICAL
$level
Type integer
\TYPO3\CMS\Core\Log\LogLevel::ERROR
\TYPO3\CMS\Core\Log\LogLevel::WARNING
\TYPO3\CMS\Core\Log\LogLevel::NOTICE
\TYPO3\CMS\Core\Log\LogLevel::INFO
\TYPO3\CMS\Core\Log\LogLevel::DEBUG
$message
Type string
The log message itself.
$data
Type array
Optional parameter, can contain additional data, which is added to the log record in the form of an array.
An early return in the log() method prevents unneeded computation work to be done. So you are safe to call $logger->debug() frequently without slowing down your code too
much. The Logger will know by its configuration, what the most explicit severity level is.
As next step, all registered Processors are notified. They can modify the log records or add extra information.
The Logger then forwards the log records to all of its configured Writers, which will then persist the log record.
For each of the severity levels mentioned above, a shorthand method exists in \TYPO3\CMS\Core\Log\Logger , like
$logger->debug($message, array $data = array());
$logger->info($message, array $data = array());
$logger->notice($message, array $data = array());
etc.
Instantiation of Loggers is configuration-free, as the LogManager automatically applies its configuration.

The Logger configuration is read from $GLOBALS['TYPO3_CONF_VARS']['LOG'] , which contains an array reflecting the namespace and class hierarchy of your TYPO3 project.
Example:
To apply a configuration for all Loggers within the \TYPO3\CMS\Core\Cache namespace, the configuration is read from
47 of 145
3/17/2016 5:01 AM
$GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['Cache'] . So every logger requested for classes like \TYPO3\CMS\Core\Cache\CacheFactory ,

\TYPO3\CMS\Core\Cache\Backend\NullBackend , etc. will get this configuration applied. The same holds for the old pseudo-namespaces with underscore separator which are still
common in extensions.
Configuring Logging for extensions works the same. If an extension uses namespaces, the syntax for the configuration is as above.
For older extensions, configuration is searched for in $GLOBALS['TYPO3_CONF_VARS']['LOG']['tx'] to dierentiate extension classes from Core classes (as extension class names
start with tx or Tx and all class names are converted to lowercase).
The Log Writer configuration is read from the subkey writerConfiguration of the configuration array:
$GLOBALS['TYPO3_CONF_VARS']['LOG']['writerConfiguration'] = array(
// configuration for ERROR level log entries
\TYPO3\CMS\Core\Log\LogLevel::ERROR => array(
// add a FileWriter
'TYPO3\\CMS\\Core\\Log\\Writer\\FileWriter' => array(
// configuration for the writer
'logFile' => 'typo3temp/logs/typo3_7ac500bce5.log'
)
)
);
The above configuration applies to all log entries of level ERROR or above.
To apply a special configuration for the controllers of the examples extension, use the following configuration:
$GLOBALS['TYPO3_CONF_VARS']['LOG']['Documentation']['Examples']['Controller']['writerConfiguration'] = array(
// configuration for WARNING severity, including all
// levels with higher severity (ERROR, CRITICAL, EMERGENCY)
\TYPO3\CMS\Core\Log\LogLevel::WARNING => array(
// add a SyslogWriter
'TYPO3\\CMS\\Core\\Log\\Writer\\SyslogWriter' => array(),
),
);
This overwrites the default configuration shown in the first example for classes located in the namespace \Documentation\Examples\Controller .
For extension foo with key tx_foo (not using namespaces), the configuration would be located at:
$GLOBALS['TYPO3_CONF_VARS']['LOG']['tx']['foo']['writerConfiguration'] = array(
...
);
An arbitrary number of writers can be added for every severity level (INFO, WARNING, ERROR, ...). The configuration based on severity levels is applied to log entries of the particular
severity level plus all levels with a higher severity. Thus, a log messages created with $logger->warning() will be aected by a writerConfiguration for
\TYPO3\CMS\Core\Log\LogLevel::DEBUG, \TYPO3\CMS\Core\Log\LogLevel::INFO, \TYPO3\CMS\Core\Log\LogLevel::NOTICE and \TYPO3\CMS\Core\Log\LogLevel::WARNING .
For the above example code that means:

Calling $logger->warning($msg); will result in $msg being written to the computers syslog on top of the default configuration.
Calling $logger->debug($msg); will result in $msg being written only to the default log file ( typo3temp/logs/typo3.log ).
For a list of writers shipped with the TYPO3 Core see the section about Log Writers.
Similar to the writer configuration, log record processors can be configured on a per-class and per-namespace basis from the subkey processorConfiguration
$GLOBALS['TYPO3_CONF_VARS']['LOG']['Documentation']['Examples']['Controller']['processorConfiguration'] = array(
// configuration for ERROR level log entries
\TYPO3\CMS\Core\Log\LogLevel::ERROR => array(
// add a MemoyUsageProcessor
'TYPO3\\CMS\\Core\\Log\\Processor\\MemoryUsage' => array(
'formatSize' => TRUE
)
)
);
For a list of processors shipped with the TYPO3 Core, see the section about Log Processors.
All logging data is modeled using \TYPO3\CMS\Core\Log\LogRecord.

This model has the following properties:
requestId
A unique identifier for each request which is created by the TYPO3 bootstrap.
48 of 145
3/17/2016 5:01 AM
created
The micro-timestamp when the record is created.
component
The name of the logger which created the LogRecord, usually the fully qualified class name where the Logger has been instanciated.
level
An integer severity level from \TYPO3\CMS\Core\Log\LogLevel.
message
The log message string.
data
Any additional data, encapsulated within an array.
The API to create a new instance of LogRecord is \TYPO3\CMS\Core\Log\Logger:log() or one of the shorthand methods.
LogRecord implements the ArrayAccess interface so that the properties can be accessed like a native array, for example: $logRecord['requestId'] . It also implements a
__toString() method for your convenience, which returns the log records as a simplified string.
A LogRecord can be processed using LogProcessors or LogWriters. LogProcessors are meant to add values to the data property of LogRecord . For example, if you would like to
add a stack trace, use \TYPO3\CMS\Core\Log\Processor\IntrospectionProcessor.
LogWriters are used to write a LogRecord to a particular target, for example a log file.
The purpose of a log writer is (usually) to save all log records into a persistent storage, like a log file, a database table, or to a remote syslog server.
Dierent log writers oer possibilities to log into dierent targets. Custom log writers can extend the functionality shipped with TYPO3 core.
This section describes the log writers shipped with the TYPO3 core. Some writers have options to allow customization of the particular writer. See the Configuration section for how to use
these options.
DatabaseWriter
The database writer logs into a database table. This table has to reside in the database used by TYPO3 and is not automatically created.
Option
Mandatory
Description
logTable
no
Database table
Default
sys_log
Warning
The Admin Tools > Log module is not adapted to the records written by the DatabaseWriter into the sys_log table. If you write such records there, you will not be able to see them
using that module. A tool for viewing such records in the TYPO3 backend is currently missing.
FileWriter
The file writer logs into a log file, one log record per line. If the log file does not exist, it will be created (including parent directories, if needed). Please make sure that your web server has
write-permissions to that path and it is below the root directory of your web site (defined by PATH_site ). The filename is appended with a hash, that depends on the encryption key. If
$GLOBALS['TYPO3_CONF_VARS']['SYS']['generateApacheHtaccess'] is set, an .htaccess file is added to the directory. It protects your log files from being accessed from the
web.
Option
Mandatory
Description
logFile
no
Path to log file
Default
typo3temp/logs/typo3_7ac500bce5.log
PhpErrorLogWriter
Logs into the PHP error log using error_log()
SyslogWriter
Logs into the syslog (Unix only).
Option
Mandatory
Description
facility
no
Syslog Facility to log into.
Default
USER
Custom Log Writers

Custom log writers can be added through extensions. Every log writer has to implement the interface \TYPO3\CMS\Core\Log\Writer\WriterInterface . It is suggested to extend the
abstract class \TYPO3\CMS\Core\Log\Writer\AbstractWriter which allows you use configuration options by adding the corresponding properties and setter methods.
Please keep in mind that TYPO3 will silently continue operating, in case a log writer is throwing an exception while executing the writeLog() method. Only in the case that all registered
writers fail, the log entry plus additional information will be added to the configured fallback logger (which defaults to the PhpErrorLog writer).
The purpose of a log processor is (usually) to modify a log record or add more detailed information to it.
49 of 145
3/17/2016 5:01 AM
Log processors allow to manipulate log records without changing the code where the log method actually is called (inversion of control). This enables you to add any information from
outside the scope of the actual calling function, for example webserver environment variables. The TYPO3 core ships some basic log processors, but more can be added with extensions.
This section describes the log processors shipped with the TYPO3 core. Some processors have options to allow customization of the particular processor. See the Configuration section for
how to use these options.
IntrospectionProcessor
The introspection processor adds backtrace data about where the log event was triggered.
By default the following parameters from the original function call are added:
file
absolute path to the file.
line
line number.
class
class name.
function
function name.
If appendFullBackTrace is set, the full backstrace stack is added instead.
Option
Mandatory
Description
appendFullBackTrace
no
Adds a full backtrace stack to the log.
Default
TRUE
shi BackTraceLevel
no
Removes the given number of entries from the top of the backtrace stack.
MemoryUsageProcessor
The memory usage processor adds the amount of used memory to the log record (result from memory_get_usage()).
Option
Mandatory
Description
realMemoryUsage
no
Use real size of memory allocated from system instead of emalloc() value.
Default
TRUE
formatSize
no
Whether the size is formatted with GeneralUtility::formatSize()
TRUE
MemoryPeakUsageProcessor
The memory peak usage processor adds the peak amount of used memory to the log record (result from memory_get_peak_usage()).
Option
Mandatory
Description
realMemoryUsage
no
Use real size of memory allocated from system instead of emalloc() value.
Default
TRUE
formatSize
no
Whether the size is formatted with GeneralUtility::formatSize()
TRUE
WebProcessor
The web processor adds selected webserver environment variables to the log record, i.e. all possible values from
\TYPO3\CMS\Core\Utility\GeneralUtility::getIndpEnv('_ARRAY') .
Custom log processors can be added through extensions. Every log processor has to implement the interface \TYPO3\CMS\Core\Log\Processor\ProcessorInterface . It is suggested
to extend the abstract class \TYPO3\CMS\Core\Log\Processor\AbstractProcessor which allows you use configuration options by adding the corresponding properties and setter
methods.
Please keep in mind that TYPO3 will silently continue operating, in case a log processor is throwing an exception while executing the processLogRecord() method.
The purpose of the registry (introduced in TYPO3 4.3) is to hold key- value pairs of information. You can actually think of it being an equivalent to the Windows registry (just not as
complicated).
You might use the registry to store information that your script needs to store across sessions or request.
An example would be a setting that needs to be altered by a PHP script, which currently is not possible with TypoScript.
Another example: The scheduler system extension stores when it ran the last time. The reports system extension then checks that value, in case it determines that the scheduler hasnt run
for a while it issues a warning. While this might not be of great use to anyone with an actual cron job set up for the scheduler, it is of use for users that have to run the scheduler tasks by
hand due to missing access to a cron job.
The registry is not meant to store things that are supposed to go into a session or a cache, use the appropriate API for these instead.
Heres a description of the fields found in the sys_registry table:
50 of 145
3/17/2016 5:01 AM
Field
Type
Description
uid
int
Primary key, needed for replication and also useful as an index.
entry_namespace
varchar (128)
entry_key
varchar (255)
The entrys key. Together with the namespace the key is unique for the whole table. The key can be any string to identify the entry. Its recommended to use dots as
entry_value
blob
The entrys actual value. The value is stored as a serialized string, thus you can even store arrays or objects in a registry entry its not recommended though. Using
Represents an entrys namespace. In general the namespace is an extension key starting with tx_, a user scripts prefix user_, or core for entries that belong to
The point of namespaces is that entries with the same key can exist inside dierent namespaces.
To use the registry, theres an easy to use API. Simply use the code below to retrieve an instance of the registry. The instance returned will always be the same as the registry is a singleton:
$registry = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Registry');
A er retrieving an instance of the registry you can access the registry values through its get() method. The get() method oers an interesting third parameter to specify a default
value, that value is returned in case the requested entry was not found in the registry. That happens when accessing an entry for the first time for example. Setting a value is easy as well
using the set() method.
Method
Parameters
Description
$namespace : namespace in which to set the value

set
$key : the key of the value to set
Represents an entrys namespace. In general the namespace is an extension key starting w
$value : the value to store

$namespace : namespace to get the value from
get
$key : the key of the value to retrieve
Used to get a value from the registry.
$defaultValue : a default value if the key was not found in the given namespace
$namespace : namespace to remove the value from
remove
Remove an entry from a given namespace.

$key : the key of the value to remove
removeAllByNamespace
$namespace : namespace to empty
Deletes all value for a given namespace.
Note that you should not store binary data into the registry, its not designed to do that. Use the filesystem instead, if you have such needs.
Heres an example taken from the Scheduler system extension:

$runInformation = array('start' => $GLOBALS['EXEC_TIME'], 'end' => time(), 'type' => $type);
$registry->set('tx_scheduler', 'lastRun', $runInformation);
It is retrieved later using:

$lastRun = $registry->get('tx_scheduler', 'lastRun');
Since version 4.5 TYPO3 CMS provides a RFC compliant mailing solution, based on Swi Mailer.
Several settings are available in the Install Tool (All Configuration) aecting the sending process. The most important one is
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] , which can take the following values:
51 of 145
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'mail';
Default and backwards compatible setting. This is the most unreliable option. If you are serious about sending mails, consider using smtp or sendmail.
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'smtp';
Sends messages over SMTP. It can deal with encryption and authentication. Works exactly the same on Windows, Unix and MacOS. Requires a mail server and the following additional
settings:
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_server'] = '<server:port>';
Mailserver name and port to connect to. Port defaults to 25.

$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_encrypt'] = '<transport protocol>';
Connect to the server using the specified transport protocol. Requires openssl library. Usually available: ssl, sslv2, sslv3, tls. Check stream_get_transports() .
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_username] = '<username>';
If your SMTP server requires authentication, the username.
3/17/2016 5:01 AM
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_password] = '<password>';
If your SMTP server requires authentication, the password.

Example:
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'smtp';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_server'] = 'localhost';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_encrypt'] = 'ssl'; // ssl, sslv3, tls
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_username'] = 'johndoe';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_smtp_password'] = 'cooLSecret';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'sendmail';
Sends messages by communicating with a locally installed MTA - such as sendmail. This may require setting the additional option:
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_sendmail_command'] = '<command>';
The command to call to send a mail locally. The default works on most modern UNIX based mail servers (sendmail, postfix, exim).
Example:
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'sendmail';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_sendmail_command'] = '/usr/sbin/sendmail -bs';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = 'mbox';
This doesnt send any mail out, but instead will write every outgoing mail to a file adhering to the RFC 4155 mbox format, which is a simple text file where the mails are concatenated.
Useful for debugging the mail sending process and on development machines which cannot send mails to the outside. The file to write to is defined by:
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_mbox_file'] = '<abs/path/to/mbox/file>';
The file where to write the mails into. Path must be absolute.
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] = '<classname>';
Custom class which implements Swi _Transport. The constructor receives all settings from the MAIL section to make it possible to add custom settings.
This shows how to generate and send a mail in TYPO3:

// Create the message
$mail = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Mail\\MailMessage');
// Prepare and send the message
$mail
// Give the message a subject
->setSubject('Your subject')
// Set the From address with an associative array
->setFrom(array('john@doe.com' => 'John Doe'))
// Set the To addresses with an associative array
->setTo(array('receiver@domain.org', 'other@domain.org' => 'A name'))
// Give it a body
->setBody('Here is the message itself')
// And optionally an alternative body
->addPart('<q>Here is the message itself</q>', 'text/html')
// Optionally add any attachments
->attach(Swift_Attachment::fromPath('my-document.pdf'))
// And finally do send it
->send()
;
Or if you prefer, dont concatenate the calls:

$mail = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Mail\\MailMessage');
$mail->setSubject('Your subject');
$mail->setFrom(array('john@doe.com' => 'John Doe'));
$mail->setTo(array('receiver@domain.org', 'other@domain.org' => 'A name'));
$mail->setBody('Here is the message itself');
$mail->addPart('<q>Here is the message itself</q>', 'text/html');
$mail->attach(Swift_Attachment::fromPath('my-document.pdf'));
$mail->send();
Here is a code sample for attaching a file to mail:
52 of 145
3/17/2016 5:01 AM
// Create the attachment, the content-type parameter is optional

$attachment = \Swift_Attachment::fromPath('</path/to/image.jpg>', 'image/jpeg');
// Set the filename (optional)
$attachment->setFilename('<cool.jpg>');
// Attach attachment to message
$mail->attach($attachment);
Here is how to add some inline media like images in a mail:

// Attach the message with a "cid"
$cid = $mail->embed(\Swift_Image::fromPath('<path/to/image.png>'));
// Create HTML body refering to it
$mail->setBody(
'<html><head></head><body>' .
' Here is an image <img src="' . $cid . '" alt="Image" />' .
' Rest of message' .
' </body></html>',
'text/html' //Mark the content-type as HTML
);
It is possible to define a default email sender (From:) in the Install Tool:

$GLOBALS['TYPO3_CONF_VARS']['MAIL']['defaultMailFromAddress'] = 'john@doe.com';
$GLOBALS['TYPO3_CONF_VARS']['MAIL']['defaultMailFromName'] = 'John Doe';
This is how you can use these defaults:

$from = \TYPO3\CMS\Core\Utility\MailUtility::getSystemFrom();
$mail = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
'TYPO3\\CMS\\Core\\Mail\\MailMessage');
$mail->setFrom($from);
// ...
$mail->send();
Please refer to the Swi Mailer documentation for more information about available methods,
See also
Swi mailer: General
Swi mailer: Content, attachments, basic headers
Adding and manipulating complex or custom headers
Since TYPO3 4.5, the TYPO3 Core provides a generic way of protecting forms against Cross-Site Request Forgery (CSRF).
For each form in the BE (or link that changes some data), create a token and insert is as a hidden form element. The name of the form element does not matter; you only need it to get the
form token for verifying it.
$formToken = TYPO3\CMS\Core\FormProtection\FormProtectionFactory::get()
->generateToken('BE user setup', 'edit')
);
$this->content .= '<input type="hidden" name="formToken" value="' . $formToken . '" />';
The three parameters $formName , $action and $formInstanceName can be arbitrary strings, but they should make the form token as specific as possible. For dierent forms (e.g. BE
user setup and editing a tt_content record) or dierent records (with dierent UIDs) from the same table, those values should be dierent.
For editing a tt_content record, the call could look like this:
$formToken = TYPO3\CMS\Core\FormProtection\FormProtectionFactory::get()->generateToken('tt_content', 'edit', $uid);
At the end of the form, you need to persist the tokens. This makes sure that generated tokens get saved, and also that removed tokens stay removed:
53 of 145
TYPO3\CMS\Core\FormProtection\FormProtectionFactory::get()->persistTokens();
3/17/2016 5:01 AM
In BE lists, it might be necessary to generate hundreds of tokens. So the tokens do not get automatically persisted a er creation for performance reasons.
When processing the data that has been submitted by the form, you can check that the form token is valid like this:
if ($dataHasBeenSubmitted &&
TYPO3\CMS\Core\FormProtection\FormProtectionFactory::get()->validateToken(
(string) \TYPO3\CMS\Core\Utility\GeneralUtility::_POST('formToken'),
'BE user setup', 'edit'
) ) {
// processes the data
} else {
// no need to do anything here as the BE form protection will create a
// flash message for an invalid token
}
Note that validateToken invalidates the token with the token ID. So calling the validation with the same parameters twice in a row will always return FALSE for the second call.
It is important that the tokens get validated before the tokens are persisted. This makes sure that the tokens that get invalidated by validateToken cannot be used again.
For each form in the install tool (or link that changes some data), create a token and insert is as a hidden form element. The name of the form element does not matter; you only need it to
get the form token for verifying it.
$formToken = $this->formProtection->generateToken('installToolPassword', 'change');
// then puts the generated form token in a hidden field in the template
The three parameters $formName , $action and $formInstanceName can be arbitrary strings, but they should make the form token as specific as possible. For dierent forms (e.g.
the password change and editing a the configuration), those values should be dierent.
At the end of the form, you need to persist the tokens. This makes sure that generated tokens get saved, and also that removed tokens stay removed:
$this->formProtection()->persistTokens();
When processing the data that has been submitted by the form, you can check that the form token is valid like this:
if ($dataHasBeenSubmitted &&
$this->formProtection()->validateToken(
(string) $_POST['formToken'],
'installToolPassword',
'change')
) {
// processes the data
} else {
// no need to do anything here as the install tool form protection will
// create an error message for an invalid token
}
Note that validateToken invalidates the token with the token ID. So calling the validation with the same parameters twice in a row will always return FALSE for the second call.
It is important that the tokens get validated before the tokens are persisted. This makes sure that the tokens that get invalidated by validateToken cannot be used again.
There exists a generic system to show users that an action was performed successfully, or more importantly, failed. This system is known as flash messages. The screenshot below shows
the various severity levels of messages that can be emitted.
54 of 145
3/17/2016 5:01 AM
The dierent severity levels are described below:

Notifications are used to show very low severity information. Such information usually is so unimportant that it can be le out, unless running in some kind of debug mode.
Information messages are to give the user some information that might be good to know.
OK messages are to signal a user about a successfully executed action.
Warning messages show a user that some action might be dangerous, cause trouble or might have partially failed.
Error messages are to signal failed actions, security issues, errors and the like.
Creating a flash message is achieved by simply instantiating an object of class \TYPO3\CMS\Core\Messaging\FlashMessage :

$message = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Messaging\\FlashMessage',
'My message text',
'Message Header', // the header is optional
\TYPO3\CMS\Core\Messaging\FlashMessage::WARNING, // the severity is optional as well and defaults to \TYPO3\CMS\Core\Messaging\FlashMessage::OK
TRUE // optional, whether the message should be stored in the session or only in the \TYPO3\CMS\Core\Messaging\FlashMessageQueue object
(default is FALSE)
);
The severity is defined by using class constants provided by \TYPO3\CMS\Core\Messaging\FlashMessage :

\TYPO3\CMS\Core\Messaging\FlashMessage::NOTICE for notifications
\TYPO3\CMS\Core\Messaging\FlashMessage::INFO for information messages
\TYPO3\CMS\Core\Messaging\FlashMessage::OK for success messages
\TYPO3\CMS\Core\Messaging\FlashMessage::WARNING for warnings
\TYPO3\CMS\Core\Messaging\FlashMessage::ERROR for errors
The fourth parameter passed to the constructor is a flag that indicates whether the message should be stored in the session or not (the default is not). Storage in the session should be used
if you need the message to be still present a er a redirection.
In backend modules you can then make that message appear on top of the module a er a page refresh or the rendering of the next page request or render it on your own where ever you
want.
This example adds the flash message at the top of modules when rendering the next request:
$flashMessageService = $this->objectManager->get(
\TYPO3\CMS\Core\Messaging\FlashMessageService::class);
$messageQueue = $flashMessageService->getMessageQueueByIdentifier();
$messageQueue->addMessage($message);
The message is added to the queue and then the template class calls \TYPO3\CMS\Core\Messaging\FlashMessageQueue::renderFlashMessages() which renders all messages from
the queue. Heres how such a message looks like in a module:
By default flash messages are shown atop the content of a module. However, if needed, you can change where the messages are shown by manipulating a modules template and inserting
the ###FLASHMESSAGES### marker. Messages will then replace that marker instead of appearing at the top of the module.
It is also possible to render a single message directly instead of adding it to the queue. This makes it possible to display flash messages absolutely anywhere. Heres how this is achieved:
55 of 145
3/17/2016 5:01 AM
$message->render();
In Extbase the standard way of issuing flash messages is to add them in the controller. Code from the examples extension:
$this->addFlashMessage('This is a simple success message');
The full API of this function is:

$this->addFlashMessage(
$messageBody,
$messageTitle = '',
$severity = \TYPO3\CMS\Core\Messaging\AbstractMessage::OK,
$storeInSession = TRUE
);
The messages are then displayed by Fluid with the relevant View Helper as shown in this excerpt of EXT:examples/Resources/Private/Layouts/Module.html :
<div id="typo3-docbody">
<div id="typo3-inner-docbody">
<f:flashMessages renderMode="div" />
<f:render section="main" />
</div>
</div>
Where to display the flash messages in an Extbase-based BE module is as simple as moving the View Helper around.
Flash messages can also be fired up from JavaScript, coming up as small pop up windows. Here is sample code taken from the examples extension:
TYPO3.Flashmessage.display(
TYPO3.Severity.ok,
title,
message,
5
);
The last parameter is the duration (in seconds) a er which the message should fade out.
Since version 6.0, TYPO3 CMS provides a generic categorization system. Categories can be created in the backend like any other type of record. Any table can be made categorizable and
thus be attached to system categories.
Since version 6.2, pages, content elements and files are categorizable by default.
System categories are defined just like any other record. Each category can have a parent, making for a tree-like structure.
56 of 145
3/17/2016 5:01 AM
The items tab shows all related records, i.e. all records that have been marked as belonging to this category.
There are two way to activate categories on a given table. The first one is to use the global setting $GLOBALS['TYPO3_CONF_VARS']['SYS']['defaultCategorizedTables'] . It is a
comma-separated list of tables for which categories should be activated. The default value is pages,tt_content,sys_file_metadata .
Important
It is recommended to avoid changing this setting. You should rather use the API described just below so as to avoid overriding a default which may change in future versions of TYPO3
CMS. The API is also more powerful.
The second way is to call \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable() . This method adds a new entry into the registry managed by \TYPO3
\CMS\Core\Category\CategoryRegistry. The registry will take care of adding the relevant $TCA definition to create a field for making relations to the system categories. The call to
makeCategorizable() must be located in an extensions ext_tables.php file or (since TYPO3 CMS 6.2.1) in a file from the Configuration/TCA/Overrides folder.
The default $GLOBALS['TCA'] structure provided by the registry can be overridden by an array options passed to makeCategorizable() . The example below illustrates how this is
done:
// Add an extra categories selection field to the pages table
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable(
'examples',
'pages',
// Do not use the default field name ("categories"), which is already used
'tx_examples_cats',
array(
// Set a custom label
'label' => 'LLL:EXT:examples/Resources/Private/Language/locallang.xlf:additional_categories',
// This field should not be an exclude-field
'exclude' => FALSE,
// Override generic configuration, e.g. sort by title rather than by sorting
'fieldConfiguration' => array(
'foreign_table_where' => ' AND sys_category.sys_language_uid IN (-1, 0) ORDER BY sys_category.title ASC',
),
// string (keyword), see TCA reference for details
'l10n_mode' => 'exclude',
// list of keywords, see TCA reference for details
'l10n_display' => 'hideDiff',
),
);
The above code will add a categories field to the pages table, which will be called tx_examples_cats . The fieldConfiguration part of the options array is the one which overrides
the base $TCA structure. In this case we would like categories to be listed alphabetically instead of using the sorting field.
If no label part is set in the options array, the field will be labelled Categories.
By default, the field will be an exclude-field. The exclude part can be used to override this.
This is the result of the above code:
57 of 145
3/17/2016 5:01 AM
It is possible to create relations to categories also in Flexforms, although this has to be done manually since no API exists for this.
The code will look something like:
<settings.categoriesList>
<TCEforms>
<exclude>1</exclude>
<label>Categories:</label>
<config>
<type>select</type>
<autoSizeMax>50</autoSizeMax>
<foreign_table>sys_category</foreign_table>
<foreign_table_where> AND sys_category.sys_language_uid IN (-1, 0) ORDER BY sys_category.sorting ASC</foreign_table_where>
<MM>sys_category_record_mm</MM>
<MM_opposite_field>items</MM_opposite_field>
<MM_match_fields>
<tablenames>tt_content</tablenames>
<fieldname>tx_myextension_categories</fieldname>
</MM_match_fields>
<maxitems>9999</maxitems>
<renderMode>tree</renderMode>
<size>10</size>
<treeConfig>
<appearance>
<expandAll>1</expandAll>
<showHeader>1</showHeader>
</appearance>
<parentField>parent</parentField>
</treeConfig>
</config>
</TCEforms>
</settings.categoriesList>
Properties tablenames and fieldname would need to be adjusted.
Beyond makeCategorizable() , class \TYPO3\CMS\Core\Category\CategoryRegistry has many other methods related to the management of categorized table. The best way to discover
is to follow the link above and explore the methods provided by this class. They are all quite specialized and should not be needed most of the time.
The \TYPO3\CMS\Core\Category\Collection\CategoryCollection classe provides the API for retrieving records related to a given category. Since TYPO3 CMS 6.2, it is extended by class
\TYPO3\CMS\Frontend\Category\Collection\CategoryCollection which does the same job but in the frontend, i.e. respecting all enable fields and performing version and language overlays.
The main method is load() which will return a traversable list of items related to the given category. Here is an example usage, taken from the RECORDS content object:
58 of 145
3/17/2016 5:01 AM
$collection = \TYPO3\CMS\Frontend\Category\Collection\CategoryCollection::load(
$aCategory,
TRUE,
$table,
$relationField
);
if ($collection->count() > 0) {
// Add items to the collection of records for the current table
foreach ($collection as $item) {
$tableRecords[$item['uid']] = $item;
// Keep track of all categories a given item belongs to
if (!isset($categoriesPerRecord[$item['uid']])) {
$categoriesPerRecord[$item['uid']] = array();
}
$categoriesPerRecord[$item['uid']][] = $aCategory;
}
}
As all collection classes in the TYPO3 CMS Core implement the Iterator interface, it is also possible to use expected methods like next() , rewind() , etc. Note that methods such as
add() will only add items to the collection temporarily. The relations are not persisted in the database.
(since TYPO3 CMS 6.2)

In the frontend, it is possible to get collections of categorized records loaded into a RECORDS content object for rendering. Check out the categories property.
The HMENU object also has a categories special type, to display a menu based on categorized pages.
Since TYPO3 CMS 4.7 there exists a generic interface for managing collections of records. The File Abstraction Layer itself extends this mechanism for managing file collections.
Record collections are managed via the TYPO3 backend. They can only be created in Folders.
Note
In the above image, the third record in the collection is actually a page. This will be ignored in all process using the Collections API, because the chosen table prevails.
Record collections are stored in the sys_collection table. The selected records are stored in the sys_collection_entries table.
Record collections can also have a type. Only the static type exits so far. Others might be added in the future.
File collections are similar in principle, but reference files. They are used by the File links (download) content element.
59 of 145
3/17/2016 5:01 AM
File collections are stored in the sys_file_collection table. The selected files are stored in the sys_file_reference table.
Note that a file collection may also reference a folder, in which case all files inside the folder will be returned when calling that collection.
The TYPO3 CMS Core provides an API to enable usage of collections inside extensions. The most important classes are:
\TYPO3\CMS\Core\Collection\RecordCollectionRepository
Used to retrieve collections. Its not exactly an Extbase repository but functions in a similar way. The default find methods refer to the sys_collection table and will fetch
static-type collections. Method findByTypeAndTableName() makes it possible to fetch collections from other tables and of a dierent type.
\TYPO3\CMS\Core\Collection\StaticRecordCollection
This class models the static record collection. It is important to note that collections returned by the repository (described above) are empty. If you need to access their records, you
need to load them first, using method loadContents() . On top of some specific API methods, this class includes all setters and getters that you may need to access the collections
data. For accessing the selected records, just loop on the collection (see example).
\TYPO3\CMS\Core\Resource\FileCollectionRepository
Similar to the record collection repository, but for file collections.

\TYPO3\CMS\Core\Resource\Collection\StaticFileCollection
Similar to the static record collection, but for files.

\TYPO3\CMS\Core\Resource\Collection\FolderBasedFileCollection
Again similar, but for file collections based on a folder.
The examples extension provides a simple frontend plugin to demonstrate usage of collections. Here is what happens in the controller:
60 of 145
3/17/2016 5:01 AM
/**
* Renders the list of all existing collections and their content
*
* @return void
*/
public function indexAction() {
// Get all existing collections
/** @var \TYPO3\CMS\Core\Collection\AbstractRecordCollection $collections */
$collections = $this->collectionRepository->findAll();
// Load the records in each collection
/** @var \TYPO3\CMS\Core\Collection\StaticRecordCollection $aCollection */
foreach ($collections as $aCollection) {
$aCollection->loadContents();
}
// Assign the "loaded" collections to the view
$this->view->assign('collections', $collections);
}
The base is code is quite simple: all collections are fetched and passed to the view. The one specific step is the loop over all collections to load their referenced records. Remember that a
collection is otherwise empty.
In the view we can then either use collection member variables as usual (like their title) or put them directly in a loop to iterate over the record selection:
<f:section name="main">
<ul>
<f:for each="{collections}" as="collection">
<li>
{collection.title} (Records from <code>{collection.itemTableName}</code>)
<ul>
<f:for each="{collection}" as="record">
<li>{record.title}</li>
</f:for>
</ul>
</li>
</f:for>
</ul>
</f:section>
Note that the above code is a bit rough as it assumes that each record has a title property. This may of course not be the case and proper checks should be made.
Here is what the result may look like (the exact result will obviously depend on the content of the selection):
Since TYPO3 CMS 4.6, a library for easily making HTTP requests is available. It is actually a wrapper around the HTTP_Request2 PEAR package, which is shipped with the Core.
The basic usage is as simple as it gets:

$request = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
'TYPO3\\CMS\\Core\\Http\\HttpRequest',
'http://typo3.org/'
);
$result = $request->send();
$content = $result->getBody();
The above example will read the content of the typo3.org home page.
This example is taken from the linkvalidator system extension.
61 of 145
3/17/2016 5:01 AM
$config = array(
'follow_redirects' => TRUE,
'strict_redirects' => TRUE
);
/** @var \TYPO3\CMS\Core\Http\HttpRequest|\HTTP_Request2 $request */
$request = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
'TYPO3\\CMS\\Core\\Http\\HttpRequest',
$url,
'HEAD',
$config
);
// Observe cookies
$request->setCookieJar(TRUE);
try {
/** @var \HTTP_Request2_Response $response */
$response = $request->send();
// HEAD was not allowed, now trying GET
if (isset($response) && $response->getStatus() === 405) {
$request->setMethod('GET');
$request->setHeader('Range', 'bytes = 0 - 4048');
/** @var \HTTP_Request2_Response $response */
$response = $request->send();
}
} catch (\Exception $e) {
$isValidUrl = FALSE;
// A redirect loop occurred
if ($e->getCode() === 40) {
// Parse the exception for more information
$trace = $e->getTrace();
$traceUrl = $trace[0]['args'][0]->getUrl()->getUrl();
$traceCode = $trace[0]['args'][1]->getStatus();
$errorParams['errorType'] = 'loop';
$errorParams['location'] = $traceUrl;
$errorParams['errorCode'] = $traceCode;
} else {
$errorParams['errorType'] = 'exception';
}
$errorParams['message'] = $e->getMessage();
}
This is the code that checks external links. To keep the traic low, it first checks only with HEAD . In case the server does not allow this, the check is retried with GET . In such a case, we get
only the first 4 kilobytes, as we dont really care about the content itself.
It may happen that the check gets stuck in a redirect loop, in which case an exception is thrown. This particular case it tested for in the catch block above to better inform the user about
what happened.
Hooks are basically places in the source code where a user function will be called for processing if such has been configured. Hooks provide a way to extend functionality of TYPO3 and
extensions easily and without blocking for others to do the same.
Hooks are the recommended way of extending TYPO3 compared to extending the PHP classes with a child class (see XCLASS extensions). It is so because only one extension of a PHP
class can exist at a time while hooks may allow many dierent user-designed processing functions to occur. On the other hand hooks have to be implemented in the core before you can
use them while extending a PHP class via the XCLASS method allows you to extend anything spontaneously.
If you need to extend something which has no hook yet, then you should suggest implementing a hook. Normally that is rather easily done by the author of the source you want to extend.
The two lines of code below are an example of how a hook is used for clear-cache post-processing. The objective of this need could be to perform additional actions whenever the cache is
cleared for a specific page.
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearCachePostProc'][] = 'myext_cacheProc->proc';
This registers the class/method name to a hook inside of \TYPO3\CMS\Core\DataHandling\DataHandler . The hook will call the user function a er the clear-cache command has been
executed. The user function will receive parameters which allows it to see what clear-cache action was performed and typically also an object reference to the parent object. Then the user
function can take additional actions as needed.
The class has to be declared with the TYPO3 autoloader.
If we take a look inside of \TYPO3\CMS\Core\DataHandling\DataHandler we find the hook to be activated like this:
62 of 145
3/17/2016 5:01 AM
1
// Call post processing function for clear-cache:
2 if (is_array($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearCachePostProc'])) {
3
$_params = array('cacheCmd' => $cacheCmd);
4
foreach($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearCachePostProc'] as $_funcRef) {
5
\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction($_funcRef, $_params, $this);
6
}
7 }
This is how hooks are typically constructed. The main action happens in line 5 where the function \TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction() is called. The
user function is called with two arguments, an array with variable parameters and the parent object.
In line 3 the contents of the parameter array is prepared. This is of high interest to you because this is where you see what data is passed to you and what data might possibly be passed by
reference and thereby possible to manipulate from your hook function.
Finally, notice how the array $TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib\_tcemain.php']['clearCachePostProc'] is traversed and for each entry the value is
expected to be a function reference which will be called. This allows many hooks to be called at the same place. The hooks can even rearrange the calling order if they dare.
The syntax of a function reference (or object reference if \TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj is used in the hook instead) can be seen in the API documentation
of \TYPO3\CMS\Core\Utility\GeneralUtility .
Note
The example hook shown above refers to old class names. All these old class names were le in hooks, for obvious reasons of backwards-compatibility.
There is no complete index of hooks in the core. But they are easy to search for and find. And typically it comes quite naturally since you will find the hooks in the code you want to extend if they exist.
This index will list the main variable spaces for configuration of hooks. By the names of these you can easily scan the source code to find which hooks are available or might be interesting
for you.
The index below also includes some variable spaces which do not only carry hook configuration but might be used for other purposes as well.
Configuration space for extensions.

This will contain all kinds of configuration options for specific extensions including possible hooks in them! What options are available to you will depend on a search in the documentation
for that particular extension.
$TYPO3_CONF_VARS['EXTCONF'][ extension_key ][ sub_key ] = value
extension_key : The unique extension key

sub_key : Whatever the script defines. Typically it identifies the context of the hook
value : It is up to the extension what the values mean, if they are mere configuration options or hooks or whatever and how deep the arrays go. Read the source code where the options
are implemented to see. Or the documentation of the extension, if available.
Note
$TYPO3_CONF_VARS['EXTCONF'] is the recommended place to put hook configuration that are available inside your extensions!
This example shows hooks used in the linkvalidator system extension. The code looks inside the $TYPO3_CONF_VARS['EXTCONF'] array for items listed under the checkLinks key of
the linkvalidator extension itself. All found classes are stored in an array, to be instantiated and used at a later point.
/**
* Fill hookObjectsArr with different link types and possible XClasses.
*/
public function __construct() {
// Hook to handle own checks
if (is_array($GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['checkLinks'])) {
foreach ($GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkvalidator']['checkLinks'] as $key => $classRef) {
$this->hookObjectsArr[$key] = \TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj($classRef);
}
}
}
Configuration space for core scripts.

This array is created as an ad hoc space for creating hooks from any script. This will typically be used from the core scripts of TYPO3 which do not have a natural identifier like extensions
have their extension keys.
63 of 145
3/17/2016 5:01 AM
$TYPO3_CONF_VARS['SC_OPTIONS'][ main_key ][ sub_key ][ index ] = function_reference
main_key : The relative path of a script (for output scripts it should be the script ID as found in a comment in the HTML header )
sub_key : Whatever the script defines. Typically it identifies the context of the hook.
index : Integer index typically. Can be unique string if you have a reason to use that. Normally it has no greater significance since the value of the key is not used. The hooks normally
traverse over the array and uses only the value (function reference)
function_reference : A function reference using the syntax of \TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction() or
\TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj() depending on implementation of the hook.
The above syntax is how a hook is typically defined but it might dier and it might not be a hook at all, but just configuration. Depends on implementation in any case.
The following example shows a hook from \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController . In this case the function
\TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj() is used for the hook. The function_reference is referring to the class name only since the function returns an object
instance of that class. The method name to call is predefined by the hook, in this case sendFormmail_preProcessVariables() . This method allows to pass any number of variables
along instead of the limited $params and $pObj variables from \TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction() .
// Hook for preprocessing of the content for formmails:
if (is_array($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['sendFormmail-PreProcClass'])) {
foreach($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['sendFormmail-PreProcClass'] as $_classRef) {
$_procObj = \TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj($_classRef);
$EMAIL_VARS = $_procObj->sendFormmail_preProcessVariables($EMAIL_VARS, $this);
}
}
In this example we are looking at a special hook, namely the one for RTE transformations. It is not a hook in the strict sense, but the same principles are used. In this case the index key
is defined to be the transformation key name, not a random integer since we do not iterate over the array as usual. \TYPO3\CMS\Core\Utility\GeneralUtility::getUserObj() is
also used.
if ($_classRef = $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_parsehtml_proc.php']['transformation'][$cmd]) {
$_procObj->pObj = &$this;
$_procObj->transformationKey = $cmd;
$value = $_procObj->transform_db($value, $this);
}
A classic hook also from \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController . This one is based on

\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction() and it passes a reference to $this along to the function via $_params . In the user-defined function
$_params['pObj']->content is meant to be manipulated in some way. The return value is insignificant - everything works by the reference to the parent object.
// Hook for post-processing of page content cached/non-cached:
if (is_array($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-all'])) {
$_params = array('pObj' => &$this);
foreach($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-all'] as $_funcRef) {
\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction($_funcRef, $_params, $this);
}
}
** Configuration space for backend modules.**

Among these configuration options you might find entry points for hooks in the backend. This somehow overlaps the intention of SC_OPTIONS above but this array is an older invention
and slightly outdated.
$TBE_MODULES_EXT[ backend_module_key ][ sub_key ] = value
backend_module_key : The backend module key for which the configuration is used.
sub_key : Whatever the backend module defines.
value : Whatever the backend module defines.
The following example shows TBE_MODULES_EXT being used for adding items to the Context Sensitive Menus (Clickmenu) in the backend. The hook value is an array with a key pointing
to a file reference to class file to include. Later each class is instantiated and a fixed method inside is called to do processing on the array of menu items. This kind of hook is non-standard in
the way it is made.
64 of 145
Warning
The API for registering context-sensitive menus was changed completely in TYPO3 4.5.
3/17/2016 5:01 AM
// Setting internal array of classes for extending the clickmenu:

$this->extClassArray = $GLOBALS['TBE_MODULES_EXT']['xMOD_alt_clickmenu']['extendCMclasses'];
// Traversing that array and setting files for inclusion:
if (is_array($this->extClassArray)) {
foreach($this->extClassArray as $extClassConf) {
if ($extClassConf['path'])
$this->include_once[]=$extClassConf['path'];
}
}
The following code listings works in the same way. First, a list of class files to include is registered. Then in the second code listing the same array is traversed and each class is instantiated
and a fixed function name is called for processing.
// Setting class files to include:
if (is_array($TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses'])) {
$this->include_once = array_merge($this->include_once,$TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses']);
}
// PLUG-INS:
if (is_array($TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses'])) {
reset($TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses']);
while(list($class,$path)=each($TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses'])) {
$modObj = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance($class);
$wizardItems = $modObj->proc($wizardItems);
}
}
You are encouraged to create hooks in your extensions if they seem meaningful. Typically someone would request a hook somewhere. Before you implement it, consider if it is the right
place to put it etc. On the one hand we want to have many hooks but not more than needed. Redundant hooks or hooks which are implemented in the wrong context is just confusing. So
put a little thought into it first, but be generous.
There are two main methods of calling a user defined function in TYPO3.
\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction() - The classic way. Takes a file/class/method reference as value and calls that function. The argument list is
fixed to a parameter array and a parent object. So this is the limitation. The freedom is that the reference defines the function name to call. This method is mostly useful for small-scale
hooks in the sources.
\TYPO3\CMS\Core\Utility\GeneralUtility::getUserObject() - Create an object from a user defined file/class. The method called in the object is fixed by the hook, so this is
the non-flexible part. But it is cleaner in other ways, in particular that you can even call many methods in the object and you can pass an arbitrary argument list which makes the API
more beautiful. You can also define the objects to be singletons, instantiated only once in the global scope.
Here follows some examples.
// Hook for pre-processing of the content for formmails:

if (is_array($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['sendFormmail-PreProcClass'])) {
foreach($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['sendFormmail-PreProcClass'] as $_classRef) {
$EMAIL_VARS = $_procObj->sendFormmail_preProcessVariables($EMAIL_VARS, $this);
}
}
// Call post-processing function for constructor:

if (is_array($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['tslib_fe-PostProc'])) {
$_params = array('pObj' => &$this);
foreach($this->TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['tslib_fe-PostProc'] as $_funcRef) {
\TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction($_funcRef,$_params, $this);
}
}
XCLASSing is a mechanism in TYPO3 CMS to extend classes or overwrite methods from the Core or extensions with ones own code. This enables a developer to easily change a given
functionality, if other options like hooks, signals or the extbase dependency injection mechanisms do not work or do not exist.
However there are several limitations.
65 of 145
Note
If you need a hook or a signal that does not exist, feel free to submit a feature request and - even better - a patch.
3/17/2016 5:01 AM
In general every class instance in the Core and in extensions that stick to the recommended TYPO3 coding guidelines is created with the API call
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() . The methods takes care of singletons and also searches for existing XCLASSes. If there is an XCLASS registered for
the specific class that should be instantiated, an instance of that XCLASS is returned instead of an instance of the original class.
Using XCLASSes is risky: neither the core, nor extensions authors can guarantee that XCLASSes will not break if the underlying code changes (for example during upgrades). Be aware
that your XCLASS can easily break and has to be maintained and fixed if the underlying code changes. If possible, you should use a hook instead of an XCLASS.
XCLASSes do not work for static classes, static methods or final classes.
There can be only one XCLASS per base class, but an XCLASS can be XCLASSed again. Be aware that such a construct is even more risky and definitely not advisable.
A small number of Core classes are required very early during bootstrap before configuration and other things are loaded. XCLASSing those classes will fail if they are singletons or
might have unexpected side-eects.
The $GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects'] global array acts as a registry of overloaded (XCLASSed) classes.

The syntax is as follows and is commonly located in an extensions ext_localconf.php file:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects']['TYPO3\\CMS\\Backend\\Controller\\NewRecordController'] = array(
'className' => 'Documentation\\Examples\\Xclass\\NewRecordController'
);
In this example, we declare that the \TYPO3\CMS\Backend\Controller\NewRecordController class will be overridden by the
\Documentation\Examples\Xclass\NewRecordController class, the latter being part of the examples extension.
Note
In the above declaration, namespaced classes are entered without the leading backslash.
When XCLASSing a class that does not use namespaces, simply use that class name in the declaration.
Note
To be compatible with older versions of TYPO3 CMS, you need to also add old-style XCLASS declarations. Please refer to older versions of this document for more information.
The recommended way of writing an XCLASS is to extend the original class and overwrite only the methods where a change is needed. This lowers the chances of the XCLASS breaking a er
a code update.
Tip
Youre even safer if you can do your changes before or a er the parent method and just call the latter with parent:: .
The example below extends the new record wizard screen. It first calls the original method and then adds its own content:
class NewRecordController extends \TYPO3\CMS\Backend\Controller\NewRecordController {
function regularNew() {
parent::regularNew();
$this->code .= $this->doc->section(
$GLOBALS['LANG']->sL('LLL:EXT:examples/locallang.xml:help'),
$GLOBALS['LANG']->sL('LLL:EXT:examples/locallang.xml:make_choice'),
0,
1
);
}
}
The result can be seen here:
66 of 145
3/17/2016 5:01 AM
This chapter presents some examples of how you can use the APIs of Core libraries. They are not meant to be exhaustive, ultimately the source code is the best documentation. These
examples are here to get you started.
The Core itself along with its many system extensions provide another whole lot of examples.
Before diving into the topic here are a few hints about debugging in TYPO3 CMS.
The TYPO3 Core provides a simple debug() (defined in EXT:core/Classes/Core/GlobalDebugFunctions.php ). It wraps around
\TYPO3\CMS\Core\Utility\DebugUtility::debug() and will output debug information only if it matches a set of IP addresses (defined in
$GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask'] ).
For example, the following code:

debug($_COOKIE, 'cookie');
will produce such an output:
Tip
The debug() function allows for adding your own debugging object. Put an instance of your class in $GLOBALS['error'] and its debug() method, receiving the same parameters
as the original debug() function.
In general, look at class \TYPO3\CMS\Core\Utility\DebugUtility for useful debugging tools.
In your backend modules you might like to show information or perform processing for a part of the page tree. There is a whole family of libraries in the core for making trees from records,
static page trees or page trees that can be browsed (open/close nodes).
This simple example demonstrates how to produce the HTML for a static page tree. The result looks like:
The tree object itself is prepared this way (taken from EXT:examples/Classes/Controller/DefaultController.php ):
67 of 145
3/17/2016 5:01 AM

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public function treeAction() {

// Get page record for tree starting point
$startingPoint = 1;
$pageRecord = \TYPO3\CMS\Backend\Utility\BackendUtility::getRecord(
'pages',
$startingPoint
);
// Create and initialize the tree object
/** @var $tree \TYPO3\CMS\Backend\Tree\View\PageTreeView */
$tree = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Backend\\Tree\\View\\PageTreeView');
$tree->init('AND ' . $GLOBALS['BE_USER']->getPagePermsClause(1));
// Creating the icon for the current page and add it to the tree
$html = \TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIconForRecord(
'pages',
$pageRecord,
array(
'title' => $pageRecord['title']
)
);
$tree->tree[] = array(
'row' => $pageRecord,
'HTML' => $html
);
// Create the page tree, from the starting point, 2 levels deep
$depth = 2;
$tree->getTree(
$startingPoint,
$depth,
''
);
// Pass the tree to the view
$this->view->assign(
'tree',
$tree->tree
);
}
At the top of the code we define the starting page and get the corresponding page record using \TYPO3\CMS\Backend\Utility\BackendUtility::getRecord() .
Next we create an instance of \TYPO3\CMS\Backend\Tree\View\PageTreeView , which we use for generating the tree. Notice how the BE_USER object is called to get a SQL where
clause that will ensure that only pages that are accessible for the user will be shown in the tree!
As a next step we manually add the starting page to the page tree. This is not done automatically because it is not always a desirable behavior. Note the use of
\TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIconForRecord() to fetch the right icon for the page.
Finally we get the tree to prepare itself, up to a certain depth. Internally this will - in particular - generate a HTML part containing the tree elements and the page icon itself.
The rendered page tree is stored in a data array inside of the tree object. We need to traverse the tree data to create the tree in HTML. This gives us the chance to organize the tree in a
table for instance. It is this part that we pass on to the view.
The result is rendered with a very simple Fluid template:
<f:for each="{tree}" as="page">
<tr class="db_list_normal">
<td><f:format.raw>{page.HTML}</f:format.raw> {page.row.title}</td>
<td>{page.row.uid}</td>
</tr>
</f:for>
We do a simple loop on the tree array of pages and display the relevant elements.
You can easily access the internal clipboard in TYPO3 from your backend modules:
/** @var $clipboard \TYPO3\CMS\Backend\Clipboard\Clipboard */
$clipboard = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Backend\\Clipboard\\Clipboard');
// Read the clipboard content from the user session
$clipboard->initializeClipboard();
\TYPO3\CMS\Core\Utility\DebugUtility::debug($clipboard->clipData);
In this simple piece of code we instantiate a clipboard object and make it load its content. We then simply dump this content into the BE modules debug window, with the following result:
68 of 145
3/17/2016 5:01 AM
This tells us what objects are registered on the default tab (normal) (a content element with id 216 in copy mode) and the numeric tabs (which can each contain more than one
element). It also tells us that the current tab is number 2. We can compare with the BE view of the clipboard:
which indeed contains two files.

Clipboard content should not be accessed directly, but using the elFromTable() method of the clipboard object:
// Access files and pages content of current pad
$currentPad = array(
'files' => $clipboard->elFromTable('_FILE'),
'pages' => $clipboard->elFromTable('pages'),
);
// Switch to normal pad and retrieve files and pages content
$clipboard->setCurrentPad('normal');
$normalPad = array(
'files' => $clipboard->elFromTable('_FILE'),
'pages' => $clipboard->elFromTable('pages'),
);
Here we first try to get all files and then all page records on the current pad (which is pad 2). Then we change to the Normal pad, call the elFromTable() method again.
In the examples extension, this data is passed to a BE module view for display, which is really just information:
This is too complicated to describe in detail. The following codelisting is from the Web > List module where selections for the clipboard are posted from a form and registered:
69 of 145
3/17/2016 5:01 AM
// Clipboard is initialized:
// Start clipboard
$dblist->clipObj = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Backend\\Clipboard\\Clipboard');
// Initialize - reads the clipboard content from the user session
$dblist->clipObj->initializeClipboard();
// Clipboard actions are handled:
// CB is the clipboard command array
$CB = \TYPO3\CMS\Core\Utility\GeneralUtility::_GET('CB');
if ($this->cmd == 'setCB') {
// CBH is all the fields selected for the clipboard, CBC is the checkbox fields which were checked.
// By merging we get a full array of checked/unchecked elements
// This is set to the 'el' array of the CB after being parsed so only the table in question is registered.
$CB['el'] = $dblist->clipObj->cleanUpCBC(array_merge((array) \TYPO3\CMS\Core\Utility\GeneralUtility::_POST('CBH'), (array) \TYPO3\CMS\Core
\Utility\GeneralUtility::_POST('CBC')), $this->cmd_table);
}
if (!$this->MOD_SETTINGS['clipBoard']) {
// If the clipboard is NOT shown, set the pad to 'normal'.
$CB['setP'] = 'normal';
}
// Execute commands.
$dblist->clipObj->setCmd($CB);
// Clean up pad
$dblist->clipObj->cleanCurrent();
// Save the clipboard content
$dblist->clipObj->endClipboard();
Warning
The context-sensitive menu for the page tree is built using a dierent approach.
The context-sensitive menu (CSM) is made of a list of menu items. Before that list is actually rendered into a HTML pop-up menu, it is passed to external processing scripts, which can be
configured in the following global array:
$GLOBALS['TBE_MODULES_EXT']['xMOD_alt_clickmenu']['extendCMclasses'];
Each script can manipulate the list of menu items, in particular add or remove some. Registration example (taken from the ext_tables.php file of the examples extension):
$GLOBALS['TBE_MODULES_EXT']['xMOD_alt_clickmenu']['extendCMclasses'][] = array(
'name' => 'Documentation\\Examples\\Service\\ContextMenuOptions'
);
The class ( \Documentation\Examples\Service\ContextMenuOptions ) looks like this:

class ContextMenuOptions {
/**
* Adds a sample item to the CSM
*
* @param \TYPO3\CMS\Backend\ClickMenu\ClickMenu $parentObject Back-reference to the calling object
* @param array $menuItems Current list of menu items
* @param string $table Name of the table the clicked on item belongs to
* @param integer $uid Id of the clicked on item
*
* @return array Modified list of menu items
*/
public function main(\TYPO3\CMS\Backend\ClickMenu\ClickMenu $parentObject, $menuItems, $table, $uid) {
// Activate the menu item only for "pages" table
if ($table == 'pages') {
// URL for the menu item. Point to the page tree example module, passing the page id.
$baseUrl = 'mod.php?M=tools_ExamplesExamples&tx_examples_tools_examplesexamples%5Baction%5D=tree&
tx_examples_tools_examplesexamples%5Bcontroller%5D=Default';
$baseUrl .= '&tx_examples_tools_examplesexamples%5Bpage%5D=' . $uid;
// Add new menu item with the following parameters:
// 1) Label
// 2) Icon
// 3) URL
// 4) = 1 disable item in docheader
$menuItems[] = $parentObject->linkItem(
$GLOBALS['LANG']->sL('LLL:EXT:examples/Resources/Private/Language/locallang.xml:csm_view_page'),
\TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIcon('extensions-examples-page-tree'),
$parentObject->urlRefForCM($baseUrl),
1
);
}
return $menuItems;
}
}
Since TYPO3 CMS 6.2, a dedicated API must be used to assemble the destination URL of the context menu item. This adds CSRF protection to the link.
70 of 145
3/17/2016 5:01 AM
$baseUrl = \TYPO3\CMS\Backend\Utility\BackendUtility::getModuleUrl(
'tools_ExamplesExamples',
array(
'tx_examples_tools_examplesexamples[action]' => 'tree',
'tx_examples_tools_examplesexamples[controller]' => 'Default',
'tx_examples_tools_examplesexamples[page]' => $uid
)
);
The important points to notice are what properties are used for defining a new menu item and what API calls are used (namely
\TYPO3\CMS\Backend\ClickMenu\ClickMenu\linkItem() and \TYPO3\CMS\Backend\ClickMenu\ClickMenu\urlRefForCM() ). The new menu item now appears when clicking a
pages record icon in the TYPO3 CMS backend.
As an example action, our item points to the Page tree demo screen of the examples BE module, transferring the id of the page that was clicked. The eect is that this page is used as
tree root in the modules display.
Tip
In the example class above, a test is performed early on to add the menu item only for a record from the pages table. When an element representing a file is clicked on, the table
parameter will be filled with the file path. The best way to check whether it is a file or not is to simply call is_file() on it.
Implement a CSM in your own backend modules is quite straightforward. The examples below are taken from the beuser system extension and assume that the module is Extbase-based.
For old style modules, refer to older versions of this manual.
The first step is to include the needed JavaScript using an argument of the standard BE container Fluid view helper. Actually the CSM-related JavaScript is included by default, so just using:
<f:be.container>
...
</f:be.container>
in your Layout is suicient (see typo3/sysext/beuser/Resources/Private/Layouts/Default.html ). Looking under the hood (in class
71 of 145
\TYPO3\CMS\Fluid\ViewHelpers\Be\ContainerViewHelper ), the relevant JS inclusion is:
3/17/2016 5:01 AM
if ($enableClickMenu) {
$doc->loadJavascriptLib('js/clickmenu.js');
}
The second step is to activate the click menu on the icons. This kind of markup is required (taken from
typo3/sysext/beuser/Resources/Private/Templates/BackendUser/Index.html ):
<td class="col-icon">
<a href="#" onClick="TYPO3.Clickmenu.show('be_users', '{backendUser.uid}', '1', '', '', ''); return false;" title="id=
{backendUser.uid}">
<bu:spriteIconForRecord table="be_users" object="{backendUser}" />
</a>
</td>
the relevant line being highlighted.

The same code works for files. In this case however, the first argument to TYPO3.Clickmenu.show() should be the absolute file path (instead of the table) and the second parameter (the
uid) should be le blank.
TYPO3 CMS provides its own HTML parsing class: \TYPO3\CMS\Core\Html\HtmlParser . This chapter shows some example uses.
The first example shows how to extract parts of a document. Consider the following code:
$testHTML = '
<DIV>
<IMG src="welcome.gif">
<p>Line 1</p>
<p>Line <B class="test">2</B></p>
<p>Line <b><i>3</i></p>
<img src="test.gif" />
<BR><br/>
<TABLE>
<tr>
<td>Another line here</td>
</tr>
</TABLE>
</div>
<B>Text outside div tag</B>
<table>
<tr>
<td>Another line here</td>
</tr>
</table>
';
// Splitting HTML into blocks defined by <div> and <table> tags
$parseObj = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Html\\HtmlParser');
$result = $parseObj->splitIntoBlock('div,table', $testHTML);
A er loading some dummy HTML code into a variable, we create an instance of \TYPO3\CMS\Core\Html\HtmlParser and ask it to split the HTML structure on div and table tags. A
debug output of the result shows the following:
As you can see the HTML source has been divided so the div section and the table section are found in key 1 and 3. Odd key always correspond to the extracted content and even keys
to the content outside of the extracted parts.
72 of 145
3/17/2016 5:01 AM
Notice that the table inside of the div section was not found. When you split content like this you get only elements on the same block-level in the source. You have to traverse the
content recursively to find all tables - or just split on <table> only (which will not give you tables nested inside of tables though).
Note also how the HTML parser does not care for case (upper or lower, all tags were found).
It is also possible to split by non-block tags, for example img and br:
$result = $parseObj->splitTags('img,br', $testHTML);
with the following result:
Again, all the odd keys in the array contain the tags that were found. Note how the parser handled transparently simple tags or self-closing tags.
The HTML parsing class also provides a tool for manipulating HTML with the HTMLcleaner() method. The cleanup configuration is quite extensive. Please refer to the phpDoc comments
of the HTMLcleaner() method for more details.
Here is a sample usage:
$tagCfg = array(
'b' => array(
'nesting' => 1,
'remap' => 'strong',
'allowedAttribs' => 0
),
'img' => array(),
'div' => array(),
'br' => array(),
'p' => array(
'fixAttrib' => array(
'class' => array(
'set' => 'bodytext'
)
)
)
);
$result = $parseObj->HTMLcleaner(
$testHTML,
$tagCfg,
FALSE,
FALSE,
array('xhtml' => 1)
);
We first define our cleanup/transformation configuration. We define that only five tags should be kept (b, img, div, br and p). All others are removed ( HTMLcleaner() can be
configured to keep all possible tags).
Additionally we indicate that b tags should be changed to strong and that correct nesting is required (otherwise the tag is removed). Also no attributed are allowed on b tags.
For p tags we indicate that the attribute should be added with value bodytext.
73 of 145
3/17/2016 5:01 AM
Lastly - in the call to HTMLcleaner() itself, we request xhtml cleanup.

This is the result:
Theres much more that can be achieved with \TYPO3\CMS\Core\Html\HtmlParser in particular more advanced processing using callback methods that can perform additional work
on each parsed element, including calling the HTML parser recursively.
This is too extensive to cover here.
It is o en needed to create links to edit records in the TYPO3 backend. The same syntax is also used for creating new records. TYPO3 provides an API for creating such links, namely
\TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick() . This script will creates an onclick-JavaScript event linking to the alt_doc.php script in the PATH_typo3
directory.
This is not always needed, especially in backend modules using the dispatcher method (which should be all backend modules, since the dispatched was introduced in TYPO3 4.1). A simple
link to alt_doc.php (with the proper parameters) works just as well.
Furthermore when using Fluid templates, you cannot call PHP code directly but have to wrap it in a view helper. The examples extensions demonstrates with the edit link view helper
( \Documentation\Examples\ViewHelpers\Be\EditLinkViewHelper ):
public function render($parameters, $returnUrl = '') {
$uri = 'alt_doc.php?' . $parameters;
if (!empty($returnUrl)) {
$uri .= '&returnUrl=' . rawurlencode($returnUrl);
}
$this->tag->addAttribute('href', $uri);
$this->tag->setContent($this->renderChildren());
$this->tag->forceClosingTag(TRUE);
return $this->tag->render();
}
This can then be used in the Fluid template. Below are a few examples, also demonstrating what kind of parameters must be passed to achieve various results:
<p>
<Ex:be.editLink parameters="edit[pages][1]=edit" returnUrl="mod.php?M=tools_ExamplesExamples&
tx_examples_tools_examplesexamples[action]=links" title="{f:translate(key: 'function_links_edit_page_1')}">
<Ex:be.icon icon="actions-document-open" title="{f:translate(key: 'function_links_edit_page_1')}" />
<f:translate key="function_links_edit_page_1" />
</Ex:be.editLink>
</p>
<p>
<Ex:be.editLink parameters="edit[pages][1]=edit&columnsOnly=title,hidden" returnUrl="mod.php?M=tools_ExamplesExamples&
tx_examples_tools_examplesexamples[action]=links" title="{f:translate(key: 'function_links_edit_page_1_restricted')}">
<Ex:be.icon icon="actions-document-open" title="{f:translate(key: 'function_links_edit_page_1_restricted')}" />
<f:translate key="function_links_edit_page_1_restricted" />
</Ex:be.editLink>
</p>
<p>
<Ex:be.editLink parameters="&edit[tx_examples_haiku][1]=new&defVals[tx_examples_haiku][title]=New%20haiku"
returnUrl="mod.php?M=tools_ExamplesExamples&tx_examples_tools_examplesexamples[action]=links" title="{f:translate(key:
'function_links_new_haiku')}">
<Ex:be.icon icon="actions-document-new" title="{f:translate(key: 'function_links_new_haiku')}" />
<f:translate key="function_links_new_haiku" />
</Ex:be.editLink>
</p>
The links appear as one can expect:
74 of 145
3/17/2016 5:01 AM
The first example ( edit[pages][1]=edit ) opens the page with uid 1 for editing.
The general syntax is thus &edit[tablename][uid]=edit. You can specify as many tables and uids you like and you will get them all in one single form! The uid variable can even be a
comma list of uids (short way of editing more records from the same table at once).
The examples above leads to the normal edit form for a page:
The second example does the same, but restricts the display to only the title and hidden fields ( edit[pages][1]=edit&columnsOnly=title,hidden ).
The fields can be listed in the columnsOnly parameter, as a comma-separated list. The example above results in the following:
The third example uses somewhat more complex parameters:

&edit[tx_examples_haiku][1]=new&defVals[tx_examples_haiku][title]=New%20haiku
The link triggers the creation a new record for the table tx_examples_haiku on page 1. It also sets a default value for the title field (New haiku). Note the following things:
the first parameter is still called edit even if this is about creating a new record. The creation of a record is indicated by the value new.
the value in the second pair of square brackets ( [1] ) indicates the page where the new record will be stored.
you need to URL-encode the values yourself, if needed (e.g. New%20haiku ).
This results in the following form, standard but with a pre-filled title field.
75 of 145
3/17/2016 5:01 AM
In the Web > Page module you can have listings of other records than Content Elements. Any table can be displayed by adding to the array $TYPO3_CONF_VARS['EXTCONF']['cms'] .
The TYPO3 CMS Core itself defines such a listing for the fe_users table:
'EXTCONF' => array(
'cms' => array(
'db_layout' => array(
'addTables' => array(
'fe_users' => array(
0 => array(
'MENU' => '',
'fList' => 'username,usergroup,name,email,telephone,address,zip,city',
'icon' => TRUE
)
)
)
)
)
),
as found in typo3/sysext/core/Configuration/DefaultConfiguration.php .
The fList key value is a list of field names separated first by comma and then ; (semi-colon). The comma separates table columns while the semi-colon allows you to list more than one
field to be displayed inside a single column.
So placing yourself on a page containing frontend users in the Web > Page module, you will see the following:
The content element wizard can be fully configured using TSConfig. The API described here should not be used for the purpose of customizing this wizard.
However for extension authors, it provides a way of registering their plugin with the new content element wizard.
76 of 145
3/17/2016 5:01 AM
Basically it is about adding a class reference to the $GLOBALS['TBE_MODULES_EXT']['xMOD_db_new_content_el']['addElClasses'] global array. The keys in this array are class
names and the values are the absolute paths to these class. The class must have a proc() method.
Here is some code from the examples extension, to register the pierror plugin with the wizard. First of all, the class is declared:
// Add "pierror" plugin to new element wizard
if (TYPO3_MODE == 'BE') {
$TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses']['tx_examples_pierror_wizicon'] = \TYPO3\CMS\Core\Utility
\ExtensionManagementUtility::extPath($_EXTKEY) . 'pierror/class.tx_examples_pierror_wizicon.php';
}
The EXT:examples/pierror/class.tx_examples_pierror_wizicon.php file looks like:

class tx_examples_pierror_wizicon {
/**
* Processing the wizard items array
*
* @param array $wizardItems The wizard items
* @return array Modified array with wizard items
*/
function proc($wizardItems)
{
$wizardItems['plugins_tx_examples_pierror'] = array(
'icon' => \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extRelPath('examples') . 'Resources/Public/Images
/PiErrorWizard.png',
'title' => $GLOBALS['LANG']->sL('LLL:EXT:examples/locallang.xlf:pierror_wizard_title'),
'description' => $GLOBALS['LANG']->sL('LLL:EXT:examples/locallang.xlf:pierror_wizard_description'),
'params' => '&defVals[tt_content][CType]=list&&defVals[tt_content][list_type]=examples_pierror'
);
return $wizardItems;
}
}
The proc() method receives the list of existing items in the wizard and adds a new one to it. The first three properties are quite easy to understand. The params property defines the
default values to be added to the new record link so that the right type of content element (and plugin in this case) is already selected. This uses the syntax demonstrated in the Links to
edit records chapter.
The result can be seen in the new content element wizard:
TYPO3 allows extension developers to register their own permission options, managed automatically by the built-in user group access lists. The options can be grouped in categories. A
custom permission option is always a checkbox (on/o).
The scope of such options is the backend only.
Options are configured in the global variable $TYPO3_CONF_VARS['BE']['customPermOptions'] . The syntax is demonstrated in the following example, which adds three options
under a given header:
$GLOBALS['TYPO3_CONF_VARS']['BE']['customPermOptions'] = array(
'tx_examples_cat1' => array(
'header' => 'LLL:EXT:examples/Resources/Private/Language/locallang.xlf:permissions_header',
'items' => array(
'key1' => array(
'LLL:EXT:examples/Resources/Private/Language/locallang.xlf:permissions_option1',
'EXT:t3skin/icons/gfx/savedok.gif',
'LLL:EXT:examples/Resources/Private/Language/locallang.xlf:permissions_option1_description',
),
'key2' => array('LLL:EXT:examples/Resources/Private/Language/locallang.xlf:permissions_option2'),
'key3' => array('LLL:EXT:examples/Resources/Private/Language/locallang.xlf:permissions_option3'),
)
)
);
The result is that these options appear in the group access lists like this:
77 of 145
3/17/2016 5:01 AM
As you can see it is possible to add both an icon and a description text, that will be displayed as context-sensitive help.
Note
As this is a rather old API the icon is actually pointed to using a reference to an actual file rather than using a sprite class.
To check if a custom permission option is set simply call the API function from the user object:
$BE_USER->check('custom_options', $catKey . ':' . $itemKey);
$catKey is the category in which the option resides. From the example above this would be tx_examples_cat1 .
$itemKey is the key of the item in the category you are evaluating. From the example above this could be key1 , key2 or key3 depending on which one of them you want to evaluate.
The function returns true if the option is set, otherwise false.
It is good practice to use the extension keys prefixed with tx_ on the first level of the array to avoid potential conflicts with other custom options.
Important
Never pick a key containing any of the characters ,:\|. They are reserved delimiter characters.
Some thid-party JavaScript libraries are packaged with the TYPO3 source code. The TYPO3 backend itself relies on quite a lot of JavaScript to do its job. The topic of this chapter is to
present how to use JavaScript properly with TYPO3, in particular in the backend. It presents the most important APIs in that regard.
Warning
Since TYPO3 4.4, the TYPO3 backend relies primarily on ExtJS. As of TYPO3 6.0, jQuery was introduced in the new Extension Manager and is the library of choice for the future. Since
TYPO3 7.4, Prototype and Scriptaculous are not packed with the Core anymore. If you need them for your projects, you need to take care of shipping them yourself, preferable by usage
of requireJs.
In TYPO3 4.2 a new model for writing AJAX code in the TYPO3 Backend was introduced. Although there were some parts in the TYPO3 Backend that used AJAX already, they are now unified
into a single interface that handles errors and dispatches the dierent calls to their final locations. This way it is ensured that e.g. a BE user is logged in and all TYPO3 variables are loaded.
The whole architecture builds on top of successful techniques developers already know. Its a mixture between the eID concept from the TYPO3 Frontend, the hooking idea we know from
other places in TYPO3, piped through the single entrypoint file index.php?ajaxID=foobar that creates a PHP AJAX object to see if an error occurred or not. If something went wrong,
the X-JSON header is set to false and the client-side AjaxRequestHandler will know that there is an error.
Note
This paragraph describes obsolete processes using Prototype and Scriptaculous
On the client-side we are using the Prototype JS library (located in typo3/contrib/prototype/prototype.js). If you have used it already, you know that you can make AJAX calls with
AJAX.Request, AJAX.Updater and AJAX.PeriodicalUpdater. We extended the library and hooked in these objects, or better: in the callbacks users can define. If an AJAX request is made to
our server-side component (typo3/ajax.php), everything developers need to do is to call this URL and add a unique, already registered parameter for their ajaxID. Their defined
onComplete and onSuccess are only rendered if the X-JSON header is set to true by the server-side script. If the X-JSON header is set to false, the Responder checks if there is a callback
function named onT3Error and executes it instead of the onComplete method. If the onT3Error method is not defined, the default TYPO3 error handler will be displaying the error in
the TYPO3 backend. If the X-JSON header is set to false, the onSuccess callback will not be executed as well as but an error message will be shown in the notification area. This behaviour
78 of 145
3/17/2016 5:01 AM
is done automatically with every AJAX call to ajax.php made through Prototypes AJAX classes. This responder is also only active if typo3/js/common.js is added to the base script.
Since TYPO3 4.4, ExtJS is used instead for AJAX calls. TYPO3 even supports usage of Ext.Direct.
If you look into typo3/ajax.php, it is only a small dispatcher script. It checks for an ajaxID in the $TYPO3_CONF_VARS['BE']['AJAX'] array and tries to execute the function pointer. The
function has two parameters, where the first (an array) is not used yet. The second parameter is the TYPO3 AJAX Object (located in typo3/classes/typo3ajax.php ) that is used to add
the content that should be returned as the server-response to the Javascript part, or the error message that should be displayed. The X-JSON header will be set depending on whether
setError() was called on this AJAX object. You can also specify if the object should return the result in a valid XML object tree, as text/html (default) or as a JSON object, see below.
The ajaxID is a unique identifier and can be used to override the existing AJAX calls. Therefore you can extend existing AJAX calls that already exist in the backend by redirecting it to your
function. But be aware of the side-eects of this feature: Other extensions could overwrite this function as well (similar problem as with XCLASSing or single inheritance in OOP).
Also, for every TYPO3 request, you will now have a TYPO3_REQUESTTYPE variable that can be used for bitwise comparison. You can now check if youre in Backend or Frontend or in an
valid AJAX request with
if (TYPO3_REQUESTTYPE && TYPO3_REQUESTTYPE_AJAX)
to see if youre calling through the new AJAX interface.
As with every AJAX response you can send it in dierent response formats.
text/html - plain text
text/xml - strict XML formatting
application/json - JSON notation
You can also specify the contentFormat in the AJAX object like this:
$ajaxObj->setContentFormat('json');
For the keyword you can choose between plain (default), xml and json, jsonbody and jsonhead.
Here are the specifics for each format.
The content array in the backend will be concatenated and returned uninterpreted.
The result will be available in the transport object as a string through xhr.responseText.
The content needs to be valid XML and will be available in javascript as xhr.responseXML.
The content is transformed to JSON using PHPs built-in functions and is then available in JSON notation through the second parameter in the onComplete / onSuccess methods, and
additionally in the responseText part of the transport object (xhr.responseText). If it is set to jsonbody, only the latter variable is filled, if jsonhead is set, it is only in the second
parameter. This is useful to save traic and you can use it with whatever format you like.
This section describes how to correctly make AJAX calls in the TYPO3 CMS BE.
Note
This section was fully updated for TYPO3 CMS 6.2. For older versions, please refer to the related version of this manual.
An AJAX call is represented by a system-wide identifier which is used to register the handler that will receive the call. The ajaxID consists of two parts, the class name and the action name,
delimited by :: ( <class>::<action> ).
Although it looks like a static function call, it is really just a key. Developers must stick to a common naming scheme as described above, to avoid using identical names in dierent
extensions.
Some good examples for an ajaxID:
79 of 145
SC_alt_db_navframe::expandCollapse
BackendLogin::refreshLogin
3/17/2016 5:01 AM
tx_myext_module1::executeSomething
Some bad examples for an ajaxID (the first part is too generic or the identifier contains a single part):
search::findRecordByTitle
core::reloadReferences
inline::processAjaxRequest
updateRecordList
Since TYPO3 CMS 6.2, the registration is done via an API, which provides CSRF protection on the AJAX call and an automatic registration of the AJAX call URL (in
typo3conf/opendocs/ext_tables.php ):
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerAjaxHandler (
'OpendocsController::renderMenu',
'TYPO3\\CMS\\Opendocs\\Controller\\OpendocsController->renderAjax'
);
This is how the opendocs system extension registers the AJAX call to render the open documents menu in the top toolbar. The first argument is the ajaxID (as described above) and the
second argument is a pointer to a class and method. This code must be located in an extensions ext_tables.php file.
The target method receives an array of parameters (depending on the call context) and a backreference to the general AJAX handler (\TYPO3\CMS\Core\Http\AjaxRequestHandler). The API
of this object is used to set the content to output or to write an error message if something went wrong.
In the above example, heres how the handling method looks like (in typo3conf/opendocs/Classes/Controller/OpendocsController.php ):
/**
* Renders the menu so that it can be returned as response to an AJAX call
*
* @param array $params Array of parameters from the AJAX interface, currently unused
* @param \TYPO3\CMS\Core\Http\AjaxRequestHandler $ajaxObj Object of type AjaxRequestHandler
* @return void
*/
public function renderAjax($params = array(), \TYPO3\CMS\Core\Http\AjaxRequestHandler &$ajaxObj = NULL) {
$menuContent = $this->renderMenu();
// addContent('key', 'content to add')
// 'key' = the new content key where the content should be added in the content array
$ajaxObj->addContent('opendocsMenu', $menuContent);
// the new content, "$menuContent" can now be referenced like this:
// $ajaxObj->getContent('opendocsMenu');
}
The API mentioned above registers a corresponding AJAX URL in the global TYPO3.settings.ajaxUrls JavaScript array.
Whatever library you use, this URL can easily be accessed by using the registration key.
var ajaxUrl = TYPO3.settings.ajaxUrls['<registration key>'];
Here is the client-side part corresponding to the above example (an extract of typo3/sysext/backend/Resources/Public/JavaScript/shortcutmenu.js ):
var del = new Ajax.Request(TYPO3.settings.ajaxUrls['ShortcutMenu::delete'], {
parameters : '&shortcutId=' + shortcutId,
onComplete : this.reRenderMenu.bind(this)
});
To load the ExtJS library use this syntax:

$this->doc->loadExtJS();
There are 2 optional parameters in this call:
80 of 145
$this->doc->loadExtJS($css = TRUE, $theme = TRUE);
The first parameter is a boolean. If set to true, ext-all.css is added automatically.
3/17/2016 5:01 AM
The second parameter is also a boolean. If set to true, theme-grey is added automatically.
Additionally the function takes care of:
adding the correct adapter
adding the localization file of BE-User language
adding Ext.BLANK_IMAGE_URL
To do debugging in the ExtJS library, use the following call to force the debug variant to be loaded:
$this->doc->setExtJSdebug();
Ext Direct is a platform and language agnostic technology to remote server-side methods to the client-side. Ext Direct allows for seamless communication between the client-side of an
Ext JS application and all popular server platforms.
Source: http://www.sencha.com/products/extjs/extdirect
In eect it means that JavaScript functions can be mapped - in the case of TYPO3 - to PHP methods on the server. AJAX calls are made transparently and TYPO3 dispatches the request and
sends back the response. Its like calling the PHP function in JavaScript.
Lets look the old fashioned way of creating a server-side request:
new Ajax.Request('ajax.php', {
method: 'get',
parameters: 'ajaxID=tx_myext_module1::executeSomething',
onComplete: function(xhr, json) {
// Do something with the response
}.bind(this)
});
and the same with Ext.Direct:

TYPO3.Backend.MyModule.doSomething('someValue', function(response, options) {
// Do something with the response
});
This features exists since TYPO3 4.4.
First of all, the PHP method and the JavaScript function must be declared in order to paired together (code taken from the examples extension):
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerExtDirectComponent(
'TYPO3.Examples.ExtDirect',
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY, 'Classes/ExtDirect/Server.php:Tx_Examples_ExtDirect_Server'),
NULL,
'user,group'
);
The last two parameters are used to define the access level of your Ext.Direct code for the BE! The third one can limit access to special modules and the fourth can be used to define
authorized access only.
The next step is to make sure that the Ext.Direct code is loaded and registered with the proper namespace. This is achieved by calling up the page renderer from the BE module or from a
specially designed Fluid View Helper, when making Extbase-based modules. Example taken from file EXT:examples/Classes/ViewHelpers/Be/HeaderViewHelper.php :
/** @var $pageRenderer \TYPO3\CMS\Core\Page\PageRenderer */
$pageRenderer = $this->getDocInstance()->getPageRenderer();
// Add base Ext.Direct code
$pageRenderer->addExtDirectCode(
array('TYPO3.Examples')
);
// Make localized labels available in JavaScript context
$pageRenderer->addInlineLanguageLabelFile('EXT:examples/Resources/Private/Language/locallang.xml');
On the server-side, the method is implement as any other PHP method, receiving the same arguments as the JavaScript function and returning whatever data it is expected to produce:
81 of 145
public function countRecords($table) {

// Return the count of all non-deleted records for the given table
return array(
'data' => $GLOBALS['TYPO3_DB']->exec_SELECTcountRows('uid', $table, '1 = 1' . \TYPO3\CMS\Backend\Utility
\BackendUtility::deleteClause($table))
);
}
3/17/2016 5:01 AM
Here the method receives a table name and sends back the count of undeleted records. The corresponding JavaScript looks like:
TYPO3.Examples.ExtDirect.countRecords(table, function(response) {
// If the response contains data, display it in a JavaScript flash message
if (response.data) {
var message = String.format(TYPO3.lang['record_count_message'], response.data, table);
TYPO3.Flashmessage.display(TYPO3.Severity.ok, TYPO3.lang['record_count_title'], message, 5);
}
});
The data is handled inside a callback function as is usual with asynchronous calls. In this case we simple display a popup flash message.
Note
This chapter should include an example about using Ext.Direct in the FE too. The last time I tried to do this it didnt work. I dont have time to dig into that now (Franois - 10.11.2012)
The Ext.Direct implementation in the TYPO3 BE makes it possible both to catch exceptions and perform some debugging output. Exceptions are simply caught and displayed as error-level
flash messages. Debugging output is redirected to the debug console. Just call the debug() function.
Looking at what happens under the hood, the following call:

$pageRenderer->addExtDirectCode(
array('TYPO3.Examples')
);
not only adds all the base JavaScript code related to Ext.Direct, but also uses reflection to analyze the declared PHP class and build an API out of it.
In particular if your server-side method is expected to handle a form submission, it must be declared with the @formHandler annotation. Example taken from the Extension Managers
code:
/**
* Save extension configuration
*
* @formHandler
* @param array $parameter
* @return array
*/
public function saveExtensionConfiguration($parameter) {
...
}
The TYPO3 backend is structured with an ExtJS viewport. This makes it easy to display various panels in dierent parts of the user interface and to resize those parts.
The viewport is defined in the files found in typo3/js/extjs/viewport* . It consists of a configuration file and the viewport component code itself. The viewport component is an
extension of the Ext.Viewport component, meaning you can use all methods and functionalities from that component.
The viewport is structured in the following way:

+--------------------------------------------------------+
| Top Menu
|
+--------------------------------------------------------+
| +----------------------------------------------------+ |
| | +-------------+-------------------+--------------+ | |
| | | Module Menu | Navigation Widget | Content Area | | |
| | +-------------+-------------------+--------------+ | |
| +----------------------------------------------------+ |
| | Debug Panel
| |
| +----------------------------------------------------+ |
+--------------------------------------------------------+
It is possible to add custom components like a navigation tree, information box or whatever else to the navigation container of the viewport. This can be achieved for any backend module
with a simple call to the registration API inside the ext_tables.php of an extension.
The registration method takes two required parameters, the component id and the event name (see below for the details):
82 of 145
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addNavigationComponent('tools_Examples', 'typo3-navigation');
3/17/2016 5:01 AM
Additionally for an Extbase module, usage of a navigation component must be declared in the options list (notice the highlighted line below):
1 Tx_Extbase_Utility_Extension::registerModule(
2
$_EXTKEY,
3
'tools', // Make module a submodule of 'Admin Tools'
4
'examples', // Submodule key
5
'', // Position
6
array(
7
// An array holding the controller-action-combinations that are accessible
8
'Default' => 'flash'
9
),
10
array(
11
'access' => 'user,group',
12
'icon'
=> 'EXT:' . $_EXTKEY . '/Resources/Public/Images/moduleIcon.png',
13
'labels' => 'LLL:EXT:' . $_EXTKEY . '/Resources/Private/Language/locallang.xml',
14
'navigationComponentId' => 'typo3-navigation'
15
)
16 );
The directory structure is predefined. This means that there is no additional information to pass in the registration call. On the other hand the necessary files must fit the defined paths (the
structure below is that of the examples extension and starts with the extensions folder):
- examples
|- components
|- navigation
|- css
|- javascript
The components directory contains all navigation components of your module. Any files inside the css and javascript directories are automatically loaded during backend
initialization. The components themselves are created lazily.
The components very own folder must be named without the typo3- prefix (i.e. navigation in the example above).
One of the JavaScript files must contain the following code to create the component if requested. Example (taken from
EXT:examples/components/navigation/javascript/Navigation.js ):
Ext.ns('TYPO3.Navigation');
TYPO3.Navigation.Navigator = Ext.extend(Ext.Panel, {
id: 'typo3-navigation',
html: 'Hello World!'
});
TYPO3.ModuleMenu.App.registerNavigationComponent('typo3-navigation', function() {
return new TYPO3.Navigation.Navigator();
});
The created components id is the component name with the given prefix.
If you have written a navigation component that should be used by a whole group of modules sharing the same prefix like web or tools, just register the component like this:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addNavigationComponent('web', 'typo3-pagetree');
Anything else is like above. It is still possible to use more specialized navigation components for the submodules of such a group.
It may be necessary to set the loading order of CSS and JavaScript files. This can be achieved by creating a file called loadingOrder.txt in the designated directory. This file will contain the
names of all other files in the needed order.
It is not necessary to define all files, umentioned ones will be loaded following natural order.
You can extend the TYPO3 viewport yourself if you need some special configuration options. The next example demonstrates this by adding a collapse/expand functionality to the module
menu.
Warning
The example below works in that it achieves its aim, but breaks the rest of the TYPO3 backend. If someone knows how to make it work properly, your help is very welcome.
First a class must be declared to use the render-preProcess hook of the \TYPO3\CMS\Core\Page\PageRenderer class (in the ext_localconf.php file):
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_pagerenderer.php']['render-preProcess'][] =
'EXT:' . $_EXTKEY . '/Classes/Utilities/Viewport.php:Tx_Examples_Utilities_Viewport->renderPreProcess';
Then here is the class itself (as usual taken from the examples extension):
83 of 145
3/17/2016 5:01 AM
public function renderPreProcess($parameters, $pageRenderer) {

$pageRenderer->addExtOnReadyCode('
Ext.apply(TYPO3.Viewport.configuration.items[1], {
split: true,
collapsible: true,
collapseMode: "mini",
hideCollapseTool: true,
animCollapse: false
});',
true
);
}
The debug console is located inside the debug panel position at the south of the viewport. Its based upon an extended ExtJS tabPanel component. A new tab can be added to the debug
console by calling \TYPO3\CMS\Core\Utility\DebugUtility::debug() :
\TYPO3\CMS\Core\Utility\DebugUtility::debug('New debug console message', 'Title', 'My new tab');
It seems possible to also manipulate the debug console with JavaScript, but working examples are missing for now (examples from the TYPO3 wiki dont work (anymore?)).
Since TYPO3 4.5, the page tree is powered by ExtJS. It is implemented in the global viewport as a navigation component.
Note
Unfortunately the components were never cleaned up nor generalized, so its not possible to reuse them in dierent contexts. However it does provide a clean API for context-sensitive
menu items.
The options available to configure the page tree are described in the TSconfig reference.
Additionally a limit can be set to the number of pages preloaded by the tree. Loading more pages will make it more responsive, but also increases the number of queries executed. The
setting is:
$GLOBALS['TYPO3_CONF_VARS']['BE']['pageTree']['preloadLimit']
With the new page tree the implementation of the context-sensitive menu (CSM) items was made more flexible and easier to configure.
84 of 145
Warning
3/17/2016 5:01 AM
The section below applies only to the CSM for the page tree. Other CSM still use the old way of doing things.
The CSM is entirely described in User TSconfig. The configuration is found in typo3/sysext/core/Configuration/DefaultConfiguration.php . Here is a sample:
options.contextMenu {
table {
pages_root {
disableItems =
items {
100 = ITEM
100 {
name = view
label = LLL:EXT:lang/locallang_core.xml:cm.view
spriteIcon = actions-document-view
displayCondition = canBeViewed != 0
callbackAction = viewPage
}
...
}
}
pages {
disableItems =
items {
...
700 = ITEM
700 {
name = history
label = LLL:EXT:lang/locallang_misc.xml:CM_history
spriteIcon = actions-document-history-open
displayCondition = canShowHistory != 0
callbackAction = openHistoryPopUp
}
800 = DIVIDER
900 = SUBMENU
900 {
label = LLL:EXT:lang/locallang_core.xml:cm.copyPasteActions
100 = ITEM
100 {
name = new
label = LLL:EXT:lang/locallang_core.xml:cm.new
spriteIcon = actions-page-new
displayCondition = canCreateNewPages != 0
callbackAction = newPageWizard
}
...
}
...
}
}
}
}
As one can see the page tree is organized in tables (thats really just pages for now), with a special case for the tree root. Then comes a list of items, which are either ITEM or SUBMENU
components. The latter are comprised of more ITEM components. A DIVIDER component can also be used to introduce a visual separator.
The numbered keys determine the order the items appear in. The default configuration uses multiples of hundred, so that there is plenty of room to introduce custom items in between the
default ones (e.g. item 751 will appear between items 700 and 800).
Delivering custom menu items via an extension is a several step process. The code samples presented below come from extension sm_clearcachecm by Steen Mller. Thanks to him for
allowing these samples to be shared. The extension adds an item in the Page actions and the Branc actions submenus to clear the cache of the page, respectively the branch.
85 of 145
3/17/2016 5:01 AM
The first step is to add the necessary User TSconfig in the extensions ext_tables.php file, to declare and position the custom item in the existing menu:
$GLOBALS['TYPO3_CONF_VARS']['BE']['defaultUserTSconfig'] .= '
options.contextMenu.table.pages.items {
900 {
1010 = DIVIDER
1020 = ITEM
1020 {
name = clearPageCache
label = LLL:EXT:sm_clearcachecm/Ressources/Private/Language/locallang_cm:clearPageCache
spriteIcon = actions-system-cache-clear
callbackAction = clearPageCache
}
}
1000 {
410 = DIVIDER
420 = ITEM
420 {
name = clearBranchCache
label = LLL:EXT:sm_clearcachecm/Ressources/Private/Language/locallang_cm:clearBranchCache
spriteIcon = actions-system-cache-clear-impact-medium
callbackAction = clearBranchCache
}
}
}
';
Here are the various parameters that must or should be used when declaring menu items:
Name
Description
name
Name of the action (can be used to disable it).
label
Language label of the action.
icon
Image that should be shown to the le of the action item.
spriteIcon
Key of the sprite icon to use instead of some arbitrary image (see icon above).
Condition that is parsed and interpreted to decide whether the action item should be shown or not for a given tree node.
The syntax is similar to PHP conditions, with the usual comparison operators and the logical operators && and || to chain conditions. The values that can be used for comp
displayCondition
displayCondition = getRecord|hidden = 1 && canBeDisabledAndEnabled != 0
In the above example the condition calls the getRecord() method which returns the complete record array of the page the node corresponds to. The index hidden of this array
For more examples look up the default configuration found in t3lib/stddb/DefaultConfiguration.php .
callbackAction
Javascript callback action that should be triggered a er the action item is clicked.
customAttributes
TypoScript array of custom attributes that can be used for your actions.
The next step is to add the JavaScript actions triggered by a click to the actions of the page tree component. This script must be loaded as an additional backend item, using the
dedicated API (in file ext_tables.php :
86 of 145
$GLOBALS['TYPO3_CONF_VARS']['typo3/backend.php']['additionalBackendItems'][] = \TYPO3\CMS\Core\Utility
\ExtensionManagementUtility::extPath($_EXTKEY, 'Ressources/Private/Php/RegisterJavaScriptForPagetreeAction.php');
3/17/2016 5:01 AM
This file contains the following code:

Ext.onReady(function() {
Ext.apply(TYPO3.Components.PageTree.Actions, {
clearPageCache: function(node, tree) {
TYPO3.SmClearcachecm.ClickmenuAction.clearPageCache(
node.attributes.nodeData,
function(response) {
if (response) {
TYPO3.Flashmessage.display(TYPO3.Severity.error, '', response);
} else {
TYPO3.Flashmessage.display(TYPO3.Severity.ok, '', TYPO3.lang.sm_clearcachecm_clearPageCacheSuccess);
}
},
this
);
}
});
Ext.apply(TYPO3.Components.PageTree.Actions, {
clearBranchCache: function(node, tree) {
TYPO3.SmClearcachecm.ClickmenuAction.clearBranchCache(
node.attributes.nodeData,
function(response) {
if (response) {
TYPO3.Flashmessage.display(TYPO3.Severity.error, '', response);
} else {
TYPO3.Flashmessage.display(TYPO3.Severity.ok, '',
TYPO3.lang.sm_clearcachecm_clearBranchCacheSuccess);
}
},
this
);
}
});
});
The above code adds Ext.Direct callbacks to the new menu items.
The last step is to write the PHP code that will answer to the Ext.Direct calls. First the PHP class must be registered as usual:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::registerExtDirectComponent(
'TYPO3.SmClearcachecm.ClickmenuAction',
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath($_EXTKEY) . 'Classes/Hooks
/ClickmenuAction.php:Tx_SmClearcachecm_Hooks_ClickmenuAction'
);
The PHP class itself contains the methods corresponding to the Ext.Direct JavaScript methods, in this case clearPageCache and clearBranchCache . They receive information about
which node was clicked. This information can be made into a node object, as demonstrated below:
public function clearPageCache($nodeData) {
$nodeUids = array();
/* @var $node \TYPO3\CMS\Backend\Tree\Pagetree\PagetreeNode */
$node = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Backend\\Tree\\Pagetree\\PagetreeNode', (array) $nodeData);
// Get uid of page
$nodeUids[] = $node->getId();
// Clear the page cache of the page
$success = $this->performClearCache($nodeUids);
if (!$success) {
return $GLOBALS['LANG']->sL('LLL:EXT:sm_clearcachecm/Ressources/Private/Language/locallang_cm.xml:clearPageCacheError', TRUE);
}
}
The TYPO3 Core provides one predefined callback which can be used to open a defined URL inside the content frame. Its called openCustomUrlInContentFrame and needs a defined
custom attribute named contentUrl. The keyword ###ID### is automatically replaced with the selected page id. Example:
720 = ITEM
720 {
name = someCustomeAction
label = LLL:EXT:extension/locallang.xml:someCustomeAction
icon = ' . \TYPO3\CMS\Core\Utility\GeneralUtility::locationHeaderUrl(\TYPO3\CMS\Core\Utility
\ExtensionManagementUtility::extRelPath($_EXTKEY) . 'ext_icon.gif') . '
spriteIcon =
displayCondition =
callbackAction = openCustomUrlInContentFrame
customAttributes.contentUrl = mod.php?M=web_WorkspacesWorkspaces&id=###ID###
}
The class diagram may help understanding the code structure.
87 of 145
3/17/2016 5:01 AM
Since TYPO3 CMS 4.3, the core contains a data caching framework which supports a wide variety of storage solutions and options for dierent caching needs. Each cache can be configured
individually and can implement its own specific storage strategy. Major parts of the system are backported from TYPO3 Flow and are kept in sync between the two systems.
The caching framework exists to help speeding up TYPO3 sites, especially heavily loaded ones. It is possible to move all caches to a dedicated cache server with specialized cache systems
like the Redis key-value store (a so called NoSQL database).
Since TYPO3 CMS 4.6, the caching framework is always enabled, the old and unflexible approach to cache content is gone. This document covers settings for TYPO3 CMS 6.0 and beyond.
This section gives come simple instructions for getting started with using the caching framework without giving the whole details under the hood.
By default, most core caches use the database backend. Default cache configuration is defined in typo3/sysext/core/Configuration/DefaultConfiguration.php and can be
overridden in LocalConfiguration.php .
If specific settings should be applied to the configuration, they should be added to LocalConfiguration.php . All settings in LocalConfiguration.php will be merged with
DefaultConfiguration.php . The easiest way to see the final cache configuration is to use the TYPO3 Backend module Admin Tools > Configuration > $TYPO3_CONF_VARS.
Example for a configuration of redis cache backend on redis database number 42 instead of the default database backend with compression for the pages cache:
88 of 145
return array(
...
'SYS' => array(
...
'caching' => array(
...
'cache_pages' => array(
'backend' => 'TYPO3\CMS\Core\Cache\Backend\RedisBackend',
'options' => array(
'database' => 42,
),
),
),
),
);
3/17/2016 5:01 AM
Most cache backends do not have an internal system to remove old cache entries that exceeded their lifetime. A cleanup must be triggered externally to find and remove those entries,
otherwise caches could grow to arbitrary size. This could lead to a slow website performance, might sum up to significant hard disk or memory usage and could render the server system
unusable.
It is advised to always enable the scheduler and run the Caching framework garbage collection task to retain clean and small caches. This housekeeping could be done once a day when
the system is otherwise mostly idle.
Caches are configured in the array $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching'] . The basic structure is predefined in
typo3/sysext/core/Configuration/DefaultConfiguration.php , and consists of the single section:
cacheConfigurations: Registry of all configured caches. Each cache is identified by its array key. Each cache can have the sub keys frontend, backend and options to configure the
used frontend, backend and possible backend options.
Unfortunately in TYPO3 CMS, all ext_localconf.php files are loaded a er the instance specific configuration from LocalConfiguration.php and
AdditionalConfiguration.php . This enables extensions to overwrite cache configuration already done for the instance. Any extension should avoid this situation and should just
define the very required minimum of cache configuration. This boils down to define just the array key to populate a new cache to the system. Without further configuration, the cache
system fall back to default backend and default frontend settings:
if (!is_array($GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['myext_mycache'])) {
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['myext_mycache'] = array();
}
Extensions like extbase define default caches this way, giving administrators full freedom for specific and possibly quicker setups (eg. a memory driven cache for the extbase reflection
cache).
Administrators can overwrite specific settings of the cache configuration in LocalConfiguration.php , example configuration to switch cache_pages to the redis backend using
database 3:
return array(
'SYS' => array(
'caching' => array(
'cache_pages' => array(
'backend' => 'TYPO3\CMS\Core\Cache\Backend\RedisBackend',
'options' => array(
'database' => 3,
),
),
),
),
);
Some backends have mandatory as well as optional parameters (which are documented below). If not all mandatory options are defined, the specific backend will throw an exception if
accessed.
During development, it can be convenient to disable certain caches. This is especially helpful since TYPO3 CMS 4.6 for central caches like the language or autoloader cache. This can be
achieved by using the null backend (see below) as storage backend.
Warning
Do not use this in production, it will strongly slow down the system!
Example entry to switch the phpcode cache (used for the autoloader cache) to use the null backend:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_phpcode']['backend'] = 'TYPO3\CMS\Core\Cache\Backend\NullBackend';
The caching framework can handle multiple caches with dierent configurations. A single cache consists of any number of cache entries.
A single cache entry is defined by these fields:
89 of 145
identifier: A string as unique identifier within this cache. Used to store and retrieve entries.
data: The data to be cached.
lifetime: A lifetime in seconds of this cache entry. An entry can not be retrieved from cache if lifetime expired.
3/17/2016 5:01 AM
tags: Additional tags (an array of strings) assigned to the entry. Used to remove specific cache entries.
Tip
The dierence between identifier and tags is quite simple: an identifier uniquely identifies a cache entry, and a tag is additional data applied to an entry (used for cache eviction). Thus,
an identifier refers to a single cache entry to store and retrieve an entry, and a tag can refer to multiple cache entries.
The identifier is used to store (set) and retrieve (get) entries from the cache and holds all information to dierentiate entries from each other. For performance reasons, it should be
quick to calculate.
Suppose there is an resource-intensive extension added as a plugin on two dierent pages. The calculated content depends on the page on which it is inserted and if a user is logged in or
not. So, the plugin creates at maximum four dierent content outputs, which can be cached in four dierent cache entries:
page 1, no user logged in
page 1, a user is logged in
page 2, no user logged in
page 2, a user is logged in
To dierentiate all entries from each other, the identifier is built from the page ID where the plugin is located, combined with the information whether a user is logged in. These are
concatenated and hashed. In PHP this could look like this:
$identifier = sha1((string)$this->getPageUid() . (string)$this->isUserLoggedIn());
Tip
sha1 is a good hash algorithm in this case, as collisions are extremely unlikely. It scales O(n) with the input length.
When the plugin is accessed, the identifier is calculated early in the program flow. Next, the plugin looks up for a cache entry with this identifier. If such an entry exists, the plugin can return
the cached content, else it calculates the content and stores a new cache entry with this identifier.
In general, the identifier is constructed from all dependencies which specify an unique set of data. The identifier should be based on information which already exist in the system at the
point of its calculation. In the above scenario the page id and whether or not a user is logged in are already determined during the frontend bootstrap and can be retrieved from the system
quickly.
Tags are used to drop specific cache entries when some information they are based on is changed.
Suppose the above plugin displays content based on dierent news entries. If one news entry is changed in the backend, all cache entries which are compiled from this news row must be
dropped to ensure that the frontend renders the plugin content again and does not deliver old content on the next frontend call.
If - for example - the plugin uses news number one and two on one page, and news one on another page, the related cache entries should be tagged with these tags:
page 1, tags news_1, news_2
page 2, tag news_1
If entry 2 is changed, a simple backend logic (probably a hook in TCEMAIN) could be created, which drops all cache entries tagged with news_2 . In this case the first entry would be
invalidated while the second entry still exists in the cache a er the operation.
While there is always exactly one identifier for each cache entry, an arbitrary number of tags can be assigned to an entry and one specific tag can be assigned to multiple cache entries. All
tags a cache entry has are given to the cache when the entry is stored (set).
The TYPO3 core defines and uses several caching framework caches by default. This section gives an overview of default caches, its usage and behaviour. If not stated otherwise, the
default database backend with variable frontend is used.
Since TYPO3 CMS 6.2, the various caches are organized in groups. Three groups currently exist:
pages
Frontend-related caches.
system
Low-level caches. Flushing low-level caches should be avoided as much as possible, as rebuilding them requires significant resources.
all
All other caches.
Cache clearing commands can be issued to target a particular group. If a cache does not belong to a group, it will be flushed when the all group is flushed, but such caches should
normally be transient anyway.
90 of 145
3/17/2016 5:01 AM
There are TSconfig options for permissions corresponding to each group.

The following caches exist in the TYPO3 CMS Core:
91 of 145
cache_core
Core cache for compiled php code. It should not be used by extensions.
Uses PhpFrontend with the SimpleFileBackend for maximum performance.
Stores core internal compiled PHP code like concatenated ext_tables.php and ext_localconf.php files, autoloader and sprite configuration PHP files.
This cache is instantiated very early during bootstrap and can not be re configured by instance specific LocalConfiguration.php or similar.
Cache entries are located in directory typo3temp/Cache/Code/cache_code . The full directory and any file in this directory can be safely removed and will be re-created upon
next request. This is especially useful during development
group: system
cache_classes
Maps class names (ant potentially one or more aliases) to the location of the class files in the filesystem. This cache is used by the class loader in oder to require the correct class file
when that class needs to be instantiated.
group: system
cache_hash
Stores several key-value based cache entries, mostly used during frontend rendering.
groups: all, pages
cache_pages
The frontend page cache. Stores full frontend pages.
Content is compressed by default to reduce database memory and storage overhead.
groups: all, pages
cache_pagesection
Used to store parts of a page, for example used to store typo3script snippets and compiled frontend templates.
Content is compressed by default to reduce database memory and storage overhead.
groups: all, pages
cache_phpcode
Code cache with PhpFrontend and FileBackend.
Unused by core since TYPO3 CMS 6.0.
group: system
cache_runtime
Runtime cache to store data specific for current request.
Used by several core parts during rendering to re-use already calculated data.
Valid for one request only.
Can be re-used by extensions that have similar caching needs.
cache_rootline
Cache for rootline calculations.
Quick and simple cache dedicated for core usage, Should not be re-used by extenions.
groups: all, pages
l10n
Cache for the localized labels.
group: system
extbase_object
Contains general information about classes, name, interfaces implemented, etc..
group: system
extbase_reflection
Contains detailed information about a class member variables and methods.
group: system
Tip
3/17/2016 5:01 AM
In rare cases, for example when classes that are required during the bootstrap process are introduced (usually when working on the TYPO3 core), cache clearings requests themselves
might throw fatal errors. The solution here is to manually remove the cache files from typo3temp/Cache/Code/ .
The core system provides a Scheduler task to collect the garbage of all cache backends. This is important for backends like the database backend that do not remove old cache entries and
tags internally. It is highly recommended to add this Scheduler task and run it once in a while (maybe once a day at night) for all used backends that do not delete entries which exceeded
their lifetime on their own to free up memory or hard disk space.
The caching framework architecture is based on the following classes:

\TYPO3\CMS\Core\Cache\Cache: Adapter class between TYPO3 FLOW cache logic and TYPO3 CMS core implementation. Used by core and extensions to initialize the framework.
Creates singleton instances of \TYPO3\CMS\Core\Cache\CacheFactory and \TYPO3\CMS\Core\Cache\CacheManager .
\TYPO3\CMS\Core\Cache\CacheManager: Returns the cache frontend of a specific cache. This is the main class used by core and extensions to access the instance of a specific cache.
Handles configuration settings and default configuration.
\TYPO3\CMS\Core\Cache\CacheFactory: Factory class to instantiate cache manager and caches. Extensions usually do not need to fiddle with this class.
\TYPO3\CMS\Core\Cache\Frontend\FrontendInterface: Main interface to handle cache entries of a specific cache. Dierent frontends and further interfaces exist to handle dierent
data types.
\TYPO3\CMS\Core\Cache\Backend\BackendInterface: Main interface every valid storage backend must implement. Several backends und further interfaces exist to specify specific
backend capabilities. Some frontends require backends to implement additional interfaces.
All frontends must implement the API defined in interface TYPO3\CMS\Core\Cache\Frontend\FrontendInterface . All operations on a specific cache must be done with these
methods. The frontend object of a cache is the main object any cache manipulation is done with, usually the assigned backend object should not be used directly.
Method
Description
getIdentifier
Returns the cache identifier.
getBackend
Returns the backend instance of this cache. It is seldom needed in usual code.
set
Sets/overwrites an entry in the cache.
get
Returns the cache entry for the given identifier.
has
Checks for existence of a cache entry. Do no use this prior to get() since get() returns NULL if an entry does not exist.
remove
Removes the entry for the given identifier from the cache.
flushByTag
Flushes all cache entries which are tagged with the given tag.
collectGarbage
Calls the garbage collection method of the backend. This is important for backends which are unable to do this internally (like the DB backend).
isValidEntryIdentifier
Checks if a given identifier is valid.
isValidTag
Checks if a given tag is valid.
requireOnce
PhpFrontend only Requires a cached PHP file directly.
Currenly three dierent frontends are implemented. The main dierence is the data types which can be stored using a specific frontend.
The string frontend accepts strings as data to be cached.
Strings, arrays and objects are accepted by this frontend. Data is serialized before it is passed to the backend.
Note
Since version 4.5, the igbinary serializer is used transparently (if available in the system), which speeds up both serialization and unserialization while also reducing data size.
Tip
The variable frontend is the most frequently used frontend and handles the widest range of data types. While it can also handle string data, the string frontend should be used if the
cache needs to store strings, if only to avoid the additional serialization done by the variable frontend.
This is a special frontend to cache PHP files. It extends the string frontend with the method requireOnce() which allows PHP files to be require() d if a cache entry exists. This can be
used by extensions to cache and speed up loading of calculated PHP code and becomes handy if a lot of reflection and dynamic PHP class construction is done.
92 of 145
3/17/2016 5:01 AM
A backend to be used in combination with the PHP frontend must implement the interface TYPO3\CMS\Core\Cache\Backend\PhpCapableBackendInterface . Currently the file
backend and the simple file backend fulfill this requirement.
Note
The PHP frontend can only be used to cache PHP files. It does not work with strings, arrays or objects. It is not intended as a page content cache.
A variety of storage backends exists. They have dierent characteristics and can be used for dierent caching needs. The best backend depends on a given server setup and hardware, as
well as cache type and usage. A backend should be chosen wisely, as a wrong decision could end up actually slowing down a TYPO3 installation.
All backends must implement at least implement interface TYPO3\CMS\Core\Cache\Backend\BackendInterface . All operations on a specific cache must be done with these methods.
There are several further interfaces that can be implemented by backends to declare additional capabilities. Usually, extension code should not handle cache backend operations directly,
but should use the frontend object instead.
Method
Description
setCache
Reference to the frontend which uses the backend. This method is mostly used internally.
set
Save data in the cache.
get
Load data from the cache.
has
Checks if a cache entry with the specified identifier exists.
remove
Remove a cache entry with the specified identifier.
flush
Remove all cache entries.
collectGarbage
Does garabage collection.
flushByTag
TaggableBackendInterface only Removes all cache entries which are tagged by the specified tag.
findIdentifiersByTag
TaggableBackendInterface only Finds and returns all cache entry identifiers which are tagged by the specified tag.
requireOnce
PhpCapableBackendInterface only Loads PHP code from the cache and require_onces it right away.
freeze
FreezableBackendInterface only Freezes this cache backend.
isFrozen
FreezableBackendInterface only Tells if this backend is frozen.
Option
Description
Mandatory
Type
Default
defaultLifetime
Default lifetime in seconds of a cache entry if it is not specified for a specific entry on set()
No
integer
3600
This is the main backend suitable for most storage needs. It does not require additional server daemons nor server configuration.
The database backend does not automatically perform garbage collection. Instead the Scheduler garbage collection task should be used.
It stores data in the configured database (usually MySQL) and can handle large amounts of data with reasonable performance. Data and tags are stored in two dierent tables, every cache
needs its own set of tables. In terms of performance the database backend is already pretty well optimized and should be used as default backend if in doubt. This backend is the default
backend if no backend is specifically set in the configuration.
The core takes care of creating and updating required database tables.
For caches with a lot of read and write operations, it is important to tune the MySQL setup. The most important setting is innodb_buffer_pool_size . A generic goal is to give MySQL as
much RAM as needed to have the main table space loaded completely in memory.
The database backend tends to slow down if there are many write operations and big caches which do not fit into memory because of slow harddrive seek and write performance. If the
data table grows too big to fit into memory, it is possible to compress given data transparently with this backend, which o en shrinks the amount of needed space to 1/4 or less. The
overhead of the compress/uncrompress operation is usually not high. A good candidate for a cache with enabled compression is the core pages cache: it is only read or written once per
request and the data size is pretty large. The compression should not be enabled for caches which are read or written multiple times during one request.
The database backend for MySQL uses InnoDB tables. Due to the nature of InnoDB, deleting records does not reclaim the actual disk space. E.g. if the cache uses 10GB, cleaning it will still
keep 10GB allocated on the disk even though phpMyAdmin will show 0 as the cache table size. To reclaim the space, turn on the MySQL option file_per_table, drop the cache tables and
re-create them using the Install tool. This does not by any mean that you should skip the scheduler task. Deleting records still improves performance.
93 of 145
Option
Description
compression
Whether or not data should be compressed with gzip. This can reduce size of the cache data table, but incurs CPU overhead for compression and decompression.
compressionLevel
Gzip compression level (if the compression option is set to true ). The default compression level is usually suicient. - -1: Default gzip compression (recommended) - 0: No com
3/17/2016 5:01 AM
Memcached is a simple, distributed key/value RAM database. To use this backend, at least one memcached daemon must be reachable, and the PECL module memcache must be loaded.
There are two PHP memcached implementations: memcache and memcached. Currently, only memcache is supported by this backend.
Memcached is by design a simple key-value store. Values must be strings and there is no relation between keys. Since the caching framework needs to structure it to store the identifierdata-tags relations, for each cache entry it stores an identifier->data, identifier->tags and a tag->identifiers entry.
This leads to structural problems:
If memcache runs out of memory but must store new entries, it will toss some other entry out of the cache (this is called an eviction in memcached speak).
If data is shared over multiple memcache servers and some server fails, key/value pairs on this system will just vanish from cache.
Both cases lead to corrupted caches. If, for example, a tags->identifier entry is lost, dropByTag() will not be able to find the corresponding identifier->data entries which should be
removed and they will not be deleted. This results in old data delivered by the cache. Additionally, there is currently no implementation of the garbage collection that could rebuild cache
integrity.
It is important to monitor a memcached system for evictions and server outages and to clear clear caches if that happens.
Furthermore memcache has no sort of namespacing. To distinguish entries of multiple caches from each other, every entry is prefixed with the cache name. This can lead to very long
runtimes if a big cache needs to be flushed, because every entry has to be handled separately and it is not possible to just truncate the whole cache with one call as this would clear the
whole memcached data which might even hold non TYPO3 related entries.
Because of the mentioned drawbacks, the memcached backend should be used with care or in situations where cache integrity is not important or if a cache has no need to use tags at all.
Currently, the memcache backend implements the TaggableBackendInterface, so the implementation does allow tagging, even if it is not advised to used this backend together with heavy
tagging.
Warning
Since memcached has no sort of namespacing and access control, this backend should not be used if other third party systems have access to the same memcached daemon for
security reasons. This is a typical problem in cloud deployments where access to memcache is cheap (but could be read by third parties) and access to databases is expensive.
Option
Description
Array of used memcached servers. At least one server must be defined. Each server definition is a string, allowed syntaxes:
hostname or IP: TCP connect to host on memcached default port (usually 11211, defined by PHP ini variable memcache.default_port )
servers
hostname:port: TCP connect to host on port

tcp://hostname:port: Same as above
unix:///path/to/memcached.sock: Connect to memcached server using unix sockets
compression
Enable memcached internal data compression. Can be used to reduce memcached memory consumption, but adds additional compression / decompression CPU overhead on the relat
Redis is a key-value storage/database. In contrast to memcached, it allows structured values. Data is stored in RAM but it allows persistence to disk and doesnt suer from the design
problems of the memcached backend implementation. The redis backend can be used as an alternative to the database backend for big cache tables and helps to reduce load on database
servers this way. The implementation can handle millions of cache entries each with hundreds of tags if the underlying server has enough memory.
Redis is known to be extremely fast but very memory hungry. The implementation is an option for big caches with lots of data because most important operations perform O(1) in
proportion to the number of (redis) keys. This basically means that the access to an entry in a cache with a million entries is not slower than to a cache with only 10 entries, at least if there
is enough memory available to hold the complete set in memory. At the moment only one redis server can be used at a time per cache, but one redis instance can handle multiple caches
without performance loss when flushing a single cache.
The garbage collection task should be run every once in a while to find and delete old tags.
The implementation is based on the PHP phpredis module, which must be available on the system.
94 of 145
Note
It is important to monitor the redis server and tune its settings to the specific caching needs and hardware capabilities. There are several articles on the net and the redis configuration
file contains some important hints on how to speed up the system if it reaches bounds. A full documentation of available options is far beyond this documentation.
Warning
The redis implementation is pretty young and should be considered as experimental. The redis project itself has a very high development speed and it might happen that the TYPO3
implementation changes to adapt to new versions.
3/17/2016 5:01 AM

Option
Description
hostname
IP address or name of redis server to connect to.
port
Port of the redis daemon.
database
Number of the database to store entries. Each cache should use its own database, otherwise all caches sharing a database are flushed if the flush operation is issued to o
Password used to connect to the redis instance if the redis server needs authentication.
password
Warning
The password is sent to the redis server in plain text.
compression
Whether or not data compression with gzip should be enabled. This can reduce cache size, but adds some CPU overhead for the compression and decompression operations in PH
Set gzip compression level to a specific value. The default compression level is usually suicient.
-1: Default gzip compression (recommended)
compressionLevel
0: No compression
9: Maximum compression (but more CPU overhead)
APC is mostly known as an opcode cache for PHP source files but can be used to store user data in shared memory as well. Its main advantage is that data can be shared between dierent
PHP processes and requests. All calls directly access shared memory. This makes this backend lightning fast for get() and set() operations. It can be an option for relatively small
caches (few dozens of megabytes) which are read and written very o en and becomes handy if APC is used as opcode cache anyway.
The implementation is very similar to the memcached backend implementation and suers from the same problems if APC runs out of memory. Garbage collection is currently not
implemented. In its latest version, APC will fail to store data with a PHP warning if it runs out of memory. This may change in the future. Even without using the cache backend, it is
advisable to increase the memory cache size of APC to at least 64MB when working with TYPO3, simply due to the large number of PHP files to be cached. A minimum of 128MB is
recommended when using the additional content cache. Cache TTL for file and user data should be set to zero (disabled) to avoid heavy memory fragmentation.
Note
It is not advisable to use the APC backend in shared hosting environments for security reasons. The user cache in APC is not aware of dierent virtual hosts. Basically every PHP script
which is executed on the system can read and write any data to this shared cache, given data is not encapsulated or namespaced in any way. Only use the APC backend in environments
which are completely under your control and where no third party can read or tamper your data.
Xcache is a PHP opcode cache similar to APC. It can also store in-memory key/value user data.
The cache backend implementation is nearly identical to the implementation of APC backend and has the same design constraints.
Important
Xcache does not work in command-line context. The Xcache backend implementation is constructed to silently discard any cache operation if in CLI context. That means if Xcache
backend is used, it is of no eect in CLI.
Furthermore, it is important to set the PHP ini value xcache.var_size to a value (eg. 100M) that is big enough to store the needed data. The usage of this capacity should be
monitored.
(Available since TYPO3 CMS 6.1)
Wincache is a PHP opcode cache similar to APC, but dedicated to the Windows OS platform. Similar to APC, the cache can also be used as in-memory key/value cache.
The cache backend implementation is nearly identical to the implementation of APC backend and has the same design constrains.
The file backend stores every cache entry as a single file to the file system. The lifetime and tags are added a er the data part in the same file.
This backend is the big brother of the Simple file backend and implements additional interfaces. Like the simple file backend it also implements the PhpCapableInterface , so it can be
used with PhpFrontend . In contrast to the simple file backend it furthermore implements TaggableInterface and FreezableInterface .
A frozen cache does no lifetime check and has a list of all existing cache entries that is reconstituted during initialization. As a result, a frozen cache needs less file system look ups and
calculation time if accessing cache entries. On the other hand, a frozen cache can not manipulate (remove, set) cache entries anymore. A frozen cache must flush the complete cache again
to make cache entries writable again. Freezing caches is currently not used in TYPO3 CMS core. It can be an option for code logic that is able to calculate and set all possible cache entries
during some initialization phase, to then freeze the cache and use those entries until the whole thing is flushed again. This can be useful especially if caching PHP code.
In general, the backend was specifically optimized to cache PHP code, the get and set operations have low overhead. The file backend is not very good with tagging and does not scale
well with the number of tags. Do not use this backend if cached data has many tags.
95 of 145
3/17/2016 5:01 AM
Warning
The performance of flushByTag() is bad and scales just O(n).
On the contrary performance of get() and set() operations. is good and scales well. Of course if many entries have to be handled, this might still slow down a er a while and a
dierent storage strategy should be used (e.g. RAM disks, battery backed up RAID systems or SSD hard disks).
Option
Description
cacheDirectory
The directory where the cache files are stored. By default it is assumed that the directory is below TYPO3_DOCUMENT_ROOT . However, an absolute path can be selected, too. Every cac
The simple file backend is the small brother of the file backend. In contrast to most other backends, it does not implement the TaggableInterface , so cache entries can not be tagged
and flushed by tag. This improves the performance if cache entries do not need such tagging. TYPO3 CMS core uses this backend for its central core cache (that hold autoloader cache
entries and other important cache entries). The core cache is usually flushed completly and does not need specific cache entry eviction.
The PDO backend can be used as a native PDO interface to databases which are connected to PHP via PDO. It is an alternative to the database backend if a cache should be stored in a
database which is otherwise only supported by TYPO3 dbal to reduce the parser overhead.
The garbage collection is implemented for this backend and should be called to clean up hard disk space or memory.
Note
There is currently very little production experience with this backend, especially not with a capable database like Oracle. Any feedback for real life use cases of this cache is appreciated.
Option
Description
Mandatory
Type
Default
Yes
string
Data source name for connecting to the database. Examples:

mysql:host=localhost;dbname=test
dataSourceName
sqlite:/path/to/sqlite.db
sqlite::memory
username
Username for the database connection.
No
string
password
Password to use for the database connection.
No
string
The transient memory backend stores data in a PHP array. It is only valid for one request. This becomes handy if code logic needs to do expensive calculations or must look up identical
information from a database over and over again during its execution. In this case it is useful to store the data in an array once and just lookup the entry from the cache for consecutive calls
to get rid of the otherwise additional overhead. Since caches are available system wide and shared between core and extensions they can profit from each other if they need the same
information.
Since the data is stored directly in memory, this backend is the quickest backend available. The stored data adds to the memory consumed by the PHP process and can hit the
memory_limit PHP setting.
The null backend is a dummy backend which doesnt store any data and always returns false on get() . This backend becomes handy in development context to practically switch
o a cache.
This chapter is targeted at extension authors who want to use the caching framework for their needs. It is about how to use the framework properly. For details about its inner working,
please refer to the section about architecture.
Example usages can be found throughout the TYPO3 CMS Core, in particular in system extension core and extbase.
Registration of a new cache should be done in ext_localconf.php . The example below just defines an empty sub-array in cacheConfigurations. Neither frontend nor backend are
defined, meaning that the cache manager will choose the default variable frontend and the database backend by default.
96 of 145
}
3/17/2016 5:01 AM
Tip
The is_array() check is done to enable administrators to overwrite configuration of caches in LocalConfiguration.php . During bootstrap, any ext_localconf.php is loaded
a er DefaultConfiguration.php and AdditionalConfiguration.php are loaded, so it is important to make sure that the administrator did not already set any configuration of
the extensions cache.
If special settings are needed, for example a specific backend (like the transient memory backend), it can be defined with an additional line below the cache array declaration. The
extension documentation should hint an integrator about specific caching needs or setups in this case.
Tip
Extensions should not force specific settings, therefore the selection is again encapsulated in a if (!isset()) check to allow administrators to overwrite those settings. It is
recommended to set up a cache configuration with sane defaults, but administrators should always be able to overwrite them for whatever reason.
}
if (!isset($GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['myext_mycache']['backend'])) {
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['myext_mycache']['backend'] = 'TYPO3\\CMS\\Core\\Cache\\Backend
\\TransientMemoryBackend';
}
To get an instance of a cache, GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Cache\\CacheManager')->getCache('myext_mycache') should be used. The cache

manager will return the fully initialized cache instance:
$myCacheInstance = GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Cache\\CacheManager')->getCache('myext_mycache');
Cache usage patterns are usually wrappers around the main code sections. Here is some example code:
protected function getCachedMagic() {
$cacheIdentifier = $this->calculateCacheIdentifier();
// If $entry is null, it hasn't been cached. Calculate the value and store it in the cache:
if (($entry = GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Cache\\CacheManager')->getCache('myext_mycache')->get($cacheIdentifier)) ===
FALSE) {
$entry = $this->calculateMagic();
// [calculate lifetime and assigned tags]
// Save value in cache
GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Cache\\CacheManager')->getCache('myext_mycache')->set($cacheIdentifier, $entry, $tags,
$lifetime);
}
return $entry;
}
Tip
It isnt needed to call has() before accessing cache entries with get() as the latter returns FALSE if no entry exists.
Internationalization is achieved in TYPO3 with the use of files containing localizable strings. Since TYPO3 CMS 4.6, the XLIFF format is used. It is described further in this section. Until TYPO3
CMS 4.5, a proprietary format called locallang XML was used.
The XML Localisation Interchange File Format (or XLIFF) is an OASIS-blessed standard format for translations.
Note
In a nutshell an XLIFF document contains one or more <file> elements. Each file element usually corresponds to a source (file or database table) and contains the source of the
localizable data. Once translated, the corresponding localized data for one, and only one, locale is added.
Localizable data are stored in <trans-unit> elements. The <trans-unit> contains a <source> element to store the source text and a (non-mandatory) <target> element to
store the translated text.
Note that having several <file> elements in the same XLIFF document is not supported by the TYPO3 CMS Core.
Here is a sample XLIFF file:
97 of 145
3/17/2016 5:01 AM
<?xml version="1.0" encoding="UTF-8"?>

<xliff version="1.0">
<file source-language="en" datatype="plaintext" original="messages" date="2011-10-18T18:20:51Z" product-name="my-ext">
<header/>
<body>
<trans-unit id="headerComment" xml:space="preserve">
<source>The default Header Comment.</source>
</trans-unit>
<trans-unit id="generator" xml:space="preserve">
<source>The "Generator" Meta Tag.</source>
</trans-unit>
</body>
</file>
</xliff>
The translated file is very similar. If the original file was named locallang.xlf , the translated file for German (code de) will be named de.locallang.xlf . Inside the file itself, a
<target-language> attribute is added in the <file> tag to indicate the translation language (de in our example). Then for each <source> tag theres a sibling <target> tag
containing the translated string.

Here is what the translation of our sample file could look like:
<file source-language="en" target-language="de" datatype="plaintext" original="messages" date="2011-10-18T18:20:51Z" product-name="my-ext">
<header/>
<body>
<trans-unit id="headerComment" xml:space="preserve">
<source>The default Header Comment.</source>
<target>Der Standard-Header-Kommentar.</target>
</trans-unit>
<trans-unit id="generator" xml:space="preserve">
<source>The "Generator" Meta Tag.</source>
<target>Der "Generator"-Meta-Tag.</target>
</trans-unit>
</body>
</file>
</xliff>
Contrary to locallang XML files, only one language can be stored per file. Each translation in a dierent language goes to an additional file.
The files follow the same naming conventions as the locallang XML files, except they use extension xlf instead of xml.
In the TYPO3 Core, XLIFF files are located in the various system extensions as needed. The system extension lang provides several general purpose files plus the classes related to the
localization API.
In Extbase-based extensions, XLIFF files are expected to be located in Resources/Private/Language . The main file ( locallang.xlf ) will be loaded automatically and available in the
controller and Fluid views without further work needed. Other files will need to be referred to explicitly.
As mentioned above, the translation files follow the same naming conventions, but are prepended with the language code and a dot. They are stored alongside the default language files.
Migrating the locallang files from ones own extension from the proprietary XML format to XLIFF is very easy. Extension extdeveval provides a tool for changing the file format.
XLIFF files are not supported by TYPO3 CMS 4.5 or older versions. If you still want to migrate your files to XLIFF and stay compatible with older TYPO3 versions, you can make your
extensions depend on extension xli. This extension takes care of creating the locallang-XML files out of the XLIFF versions.
98 of 145
3/17/2016 5:01 AM
Tip
When referring to a localized file, the file extension does not matter. This means that both LLL:EXT:foo/locallang.xml:bar and LLL:EXT:foo/locallang.xlf:bar can be used
interchangeably.
This sections highlights the dierent ways to translate XLIFF files.
The TYPO3 community manages an oicial translation server, running Pootle. Localization files in English are uploaded on that server and translations are packaged nightly. They are
fecthed in the TYPO3 CMS backend, via the Extension Manager (or the new Language module since version 6.0).
It is not the point of this manual to go into the details of the translation process. More information can be found in the TYPO3 wiki.
Using Virtaal, it is possible to translate XLIFF files locally. Virtaal is an open source, cross-platform application.
Translating files locally is useful for extensions which are not meant to be published or for creating custom translations.
The $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride'] allows to override both locallang-XML and XLIFF files. Actually this is not just about translations. Default
language files can also be overridden. In the case of XLIFF files, the syntax is as follows (to be placed in an extensions ext_localconf.php file):
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:cms/locallang_tca.xlf'][] = 'EXT:examples/Resources/Private/Language/custom.xlf';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['de']['EXT:cms/locallang_tca.xlf'][] = 'EXT:examples/Resources/Private/Language
/de.custom.xlf';
The first line shows how to override a file in the default language, the second how to override a German (de) translation. The German language file looks like this:
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<file source-language="en" datatype="plaintext" original="messages" date="2013-03-09T18:44:59Z" product-name="examples">
<header/>
<body>
<trans-unit id="pages.title_formlabel" xml:space="preserve">
<source>Most important tile</source>
<target>Wichtigster Titel</target>
</trans-unit>
</body>
</file>
</xliff>
and the result can be easily seen in the backend:
99 of 145
3/17/2016 5:01 AM
Important
Please note that you do not have to copy the full reference file, but only the labels you want to translate.
The path to the file to override must be expressed as EXT:foo/bar/... . For the extension xlf or xml can be used interchangeably. The TYPO3 Core will try both anyway, but
using xlf is more correct and future-proof.
Attention
The following is a bug but must be taken as a constraint for now:
The files containing the custom labels must be located inside an extension. Other locations will not be considered.
The original translation needs to exist in typo3temp/l10n/ or next to the base translation file in extensions, for example in
typo3conf/ext/myext/Resources/Private/Language/ .
Going further it is even possible - since TYPO3 CMS 4.6 - to add custom languages to the TYPO3 backend and create the translations locally using XLIFF files.
First of all, the language must be declared:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['localization']['locales']['user'] = array(
'gsw_CH' => 'Swiss German',
);
This new language does not need to be entirely translated. It can be defined as falling back to another language, so that only diering labels need be translated:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['localization']['locales']['dependencies'] = array(
'gsw_CH' => array('de_AT', 'de'),
);
In this case we define that gsw_CH (which is the oicial code for Schwiizerttsch - that is, Swiss German) can fall back on de_AT (another custom translation) and then on de.
The translations have to be stored in the appopriate folder, in this case typo3conf/l10n/gsw_CH .
The very least you need is to translate the label containing the name of the language itself, so that it appears in the user preferences. In our example this would be in file
typo3conf/l10n/gsw_CH/setup/mod/gsw_CH.locallang.xlf .
<?xml version='1.0' encoding='utf-8'?>
<file source-language="en" target-language="gsw_CH" datatype="plaintext" original="messages" product-name="setup">
<header/>
<body>
<trans-unit id="lang_gsw_CH" approved="yes">
<source>Swiss German</source>
<target state="translated">Schwiizerttsch</target>
</trans-unit>
</body>
</file>
</xliff>
100 of 145
3/17/2016 5:01 AM
Note
Any language will always fall back on the default one (i.e. English) when a translation is not found. A custom language will fall back on its parent language automatically. Thus - in our
second example of de_AT (German for Austria) - no fallback would have to be defined for de_AT if it were just falling back on de.
With the use of XLIFF and the freely available Pootle translation server, companies and individuals may easily set up a custom translation server for their extensions.
There is a signal that can be caught to change the translation server URL to use. The first step is to register ones code for handling the signal. Such code would be placed in an extensions
ext_localconf.php file:
$signalSlotDispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\SignalSlot\\Dispatcher');
$signalSlotDispatcher->connect(
version_compare(TYPO3_version, '7.0', '<')
? 'TYPO3\\CMS\\Lang\\Service\\UpdateTranslationService'
: 'TYPO3\\CMS\\Lang\\Service\\TranslationService',
'postProcessMirrorUrl',
'Company\\Extension\Slots\\CustomMirror',
'postProcessMirrorUrl'
);
The class (slot) which receives the signal ( EXT:myext/Classes/Slots/CustomMirror.php ) could look something like:
<?php
namespace Company\Extensions\Slots;
class CustomMirror {
/** @var string */
static protected $extKey = 'myext';
public function postProcessMirrorUrl($extensionKey, &$mirrorUrl) {
if ($extensionKey === self::$extKey) {
$mirrorUrl = 'http://mycompany.tld/typo3-packages/';
}
}
}
Note that the mirror URL is passed as a reference, so that it can be modified. In the above example, the URL is changed only for a given extension, but of course it could be changed on a
more general basis.
On the custom translation server side, the structure needs to be:
https://mycompany.tld/typo3-packages/
`-- <first-letter-of-extension-key>
`-- <second-letter-of-extension-key>
`-- <extension-key>-l10n
|-- <extension-key>-l10n-de.zip
|-- <extension-key>-l10n-fr.zip
|-- <extension-key>-l10n-it.zip
`-- <extension-key>-l10n.xml
hence in our example:

https://mycompany.tld/typo3-packages/
`-- m
`-- y
`-- myext-l10n
|-- myext-l10n-de.zip
|-- myext-l10n-fr.zip
|-- myext-l10n-it.zip
`-- myext-l10n.xml
101 of 145
3/17/2016 5:01 AM
And the myext-l10n.xml file contains something like:

<?xml version="1.0" standalone="yes" ?>
<TERlanguagePackIndex>
<meta>
<timestamp>1374841386</timestamp>
<date>2013-07-26 14:23:06</date>
</meta>
<languagePackIndex>
<languagepack language="de">
<md5>1cc7046c3b624ba1fb1ef565343b84a1</md5>
</languagepack>
<languagepack language="fr">
<md5>f00f73ae5c43cb68392e6c508b65de7a</md5>
</languagepack>
<languagepack language="it">
<md5>cd59530ce1ee0a38e6309544be6bcb3d</md5>
</languagepack>
</languagePackIndex>
</TERlanguagePackIndex>
Global array $PAGES_TYPES defines the various types of pages (field: doktype ) the system can handle and what restrictions may apply to them. Here you can define which tables are
allowed on a certain page type.
Note
The default entry in the $PAGES_TYPES array is the base for all types, and for every type the entries simply overrides the entries in the default type!!
This is the default array as set in EXT:core/ext_tables.php :

$GLOBALS['PAGES_TYPES'] = array(
(string) \TYPO3\CMS\Frontend\Page\PageRepository::DOKTYPE_LINK => array(
),
(string) \TYPO3\CMS\Frontend\Page\PageRepository::DOKTYPE_SHORTCUT => array(
),
...
// Doktype 254 is a 'Folder' - a general purpose storage folder for whatever you like. In CMS context it's NOT a viewable page. Can contain any
element.
(string) \TYPO3\CMS\Frontend\Page\PageRepository::DOKTYPE_SYSFOLDER => array(
'type' => 'sys',
'allowedTables' => '*'
),
...
'default' => array(
'type' => 'web',
'allowedTables' => 'pages',
'onlyAllowedTables' => '0'
)
);
The key used in the array above is the value that will be stored in the doktype field of the pages table.
Important
The choice of value for the doktype is critical. If you want your custom page type to be displayed in the frontend, you must make sure to choose a doktype smaller than 200. If its
supposed to be just some storage, choose a doktype larger than 200.
Each array has the following options available:

Key
Description
type
Can be sys or web. This is purely informative, as TYPO3 CMS does nothing with that piece of data.
allowedTables
The tables that may reside on pages with that doktype. Comma-separated list of tables allowed on this page doktype. * = all.
onlyAllowedTables
Boolean. If set to true, changing the page type will be blocked if the chosen page type contains records that it would not allow.
Note
All above options must be set for the default type while the rest can choose as they like.
The following example adds a new page type called Archive.
102 of 145
3/17/2016 5:01 AM
The whole code to add a page type is shown below with the according file names above.
The first step is to add the new page type to the global array described above. Then you need to add the icon chosen for the new page type and allow users to drag and drop the new page
type to the page tree. All the changes are applied in ext_tables.php :
call_user_func(
function ($extKey) {
$archiveDoktype = 116;
// Add new page type:
$GLOBALS['PAGES_TYPES'][$archiveDoktype] = [
'type' => 'web',
'allowedTables' => '*',
];
// Provide icon for page tree, list view, ... :
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Imaging\IconRegistry::class)
->registerIcon(
'apps-pagetree-archive',
TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
[
'source' => 'EXT:' . $extKey . '/Resources/Public/Icons/Archive.svg',
]
);
// Allow backend users to drag and drop the new page type:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addUserTSConfig(
'options.pageTree.doktypesToShowInNewPageDragArea := addToList(' . $archiveDoktype . ')'
);
},
'example'
);
Furthermore we need to modify the configuration of pages records. As one can modify the pages. We need to add the new doktype as select item and associate it with the configured
icon. Thats done in Configuration/TCA/Overrides/pages.php :
103 of 145
3/17/2016 5:01 AM
call_user_func(
function ($extKey, $table) {
$extRelPath = \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extRelPath($extKey);
$customPageIcon = $extRelPath . 'Resources/Public/Images/Archive.svg';
// Add new page type as possible select item:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTcaSelectItem(
$table,
'doktype',
[
'LLL:EXT:' . $extKey . '/Resources/Private/Language/locallang.xlf:archive_page_type',
$archiveDoktype,
$customPageIcon
],
'1',
'after'
);
// Add icon for new page type:
\TYPO3\CMS\Core\Utility\ArrayUtility::mergeRecursiveWithOverrule(
$GLOBALS['TCA']['pages'],
[
'ctrl' => [
'typeicon_classes' => [
$archiveDoktype => 'apps-pagetree-archive',
],
],
]
);
},
'example',
'pages'
);
The same must be done with the pages_language_overlay, so that the new page type can also be translated Configuration/TCA/Overrides/pages_language_overlay.php :
// Also add the new doktype to the page language overlays type selector (so that translations can inherit the same type)
call_user_func(
function ($extKey, $table) {
$extRelPath = \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extRelPath($extKey);
$customPageIcon = $extRelPath . 'Resources/Public/Images/Archive.svg';
// Add new page type as possible select item:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTcaSelectItem(
$table,
'doktype',
[
'LLL:EXT:' . $extKey . '/Resources/Private/Language/locallang.xlf:archive_page_type',
$archiveDoktype,
$customPageIcon
],
'1',
'after'
);
},
'example',
'pages_language_overlay'
);
The User Settings module has the most complex form in the TYPO3 backend not driven by TCA/TCEforms. Instead it uses its own configuration array. It is quite similar to the $TCA, but with
less options.
Just like with the $TCA, the [ctrl] section contains some general options that aect the global rendering of the form.
Key
Data type
Description
Default
Render user setup with or without tabs. Possible values are:

0 = no tabs,
dividers2tabs
integer
1 = tabs, empty tabs are hidden
2 = tabs, empty tabs are disabled
This contains the configuration array for single fields in the user settings. This array allows the following configurations:
104 of 145
3/17/2016 5:01 AM

Key
Data type
Description
Defines the type of the input field
If type=user you need to define userFunc too.
Example:
'startModule' => array(
'type' => 'select',
'itemsProcFunc' => 'TYPO3\\CMS\\Setup\\Controller\\SetupModuleController->renderStartModuleSelect',
'label' => 'LLL:EXT:setup/mod/locallang.xlf:startModule',
'csh' => 'startModule'
),
type
string
label
string
Label for the input field, should be a pointer to a localized label using the LLL: syntax.
buttonLabel
string
Text of the button for type=button fields. Should be a pointer to a localized label using the LLL: syntax.
csh
string
CSH key for the input field
access
string
Allowed values: button, check, password, select, text, user
Access control. At the moment only a admin-check is implemented

Allowed values: admin
If the user setting is saved in a DB table, this property sets the table. At the moment only be_users is implemented.
table
string
Allowed values: be_users
Evaluates a field with a given function. Currently only md5 is implemented, for password field.
Allowed values: md5
eval
string
Note
In the specific case of the password field, the md5 value defined by default in the TYPO3 CMS Core is overridden to an empty string by system extension saltedpassw
eval
array
Array of key-value pair for select items Only used by type=select.
items
array
List of items for type=select fields. This should be a simple associative array with key-value pairs.
itemsProcFunc
array
onClick
string
JavaScript code added to a buttons onClick attribute. Only used by type=button. May contain sprintf() markers which will be replaced by the strings provided in prop
onClickLabels
array
List of strings used to replace the markers defined in onClick . Each string should point to a localized label using the LLL: syntax.
Defines an external method for rendering items of select-type fields. Contrary to what is done with the TCA you have to render the <select> tag too. Only used by type=sel
Use the usual class->method syntax.
This string is used for rendering the form in the user setup module. It contains a comma-separated list of fields, which will be rendered in that order.
To use a tab insert a --div--;LLL:EXT:foo/... item in the list.
Example (taken from typo3/sysext/setup/ext_tables.php ):
'showitem' => '--div--;LLL:EXT:setup/mod/locallang.xlf:personal_data,realName,email,emailMeAtLogin,password,password2,lang,

--div--;LLL:EXT:setup/mod/locallang.xlf:opening,startModule,thumbnailsByDefault,titleLen,
--div--;LLL:EXT:setup/mod
/locallang.xlf:editFunctionsTab,edit_RTE,edit_wideDocument,edit_docModuleUpload,showHiddenFilesAndFolders,resizeTextareas,resizeTextareas_Flexible,resizeTexta
--div--;LLL:EXT:setup/mod/locallang.xlf:adminFunctions,simulate,debugInWindow'
Adding fields to the User Settings is done in two steps. First of all, the new fields are added directly to the $GLOBALS['TYPO3_USER_SETTINGS'] array. Then the field is made visible by
calling \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addFieldsToUserSettings() .
Here is an example, taken from the examples extension:
$GLOBALS['TYPO3_USER_SETTINGS']['columns']['tx_examples_mobile'] = array(
'label' => 'LLL:EXT:examples/Resources/Private/Language/locallang_db.xlf:be_users.tx_examples_mobile',
'type' => 'text',
'table' => 'be_users',
);
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addFieldsToUserSettings(
'LLL:EXT:examples/Resources/Private/Language/locallang_db.xlf:be_users.tx_examples_mobile,tx_examples_mobile',
'after:email'
);
The second parameter in the call to addFieldsToUserSettings() is used to position the new field. In this example, we decide to add it a er the existing email field.
In this example the field is also added to the be_users table. This is not described here as it belongs to extending the $TCA array.
And here is the new field in the User Tools > User Settings module:
105 of 145
3/17/2016 5:01 AM
It is possible to check the configuration via the Admin Tools > Configuration module, just like for the $TCA.
This chapter is about Rich Text Editors (RTE), how they are integrated in the TYPO3 Backend and what transformations get applied along the various processes (saving to the database,
rendering to the frontend, etc.)
When you configure a table in $TCA and add a field of the type text which is edited by a <textarea> , you can choose to use a Rich Text Editor (RTE) instead of the simple form field. A
RTE enables the users to use visual formatting aids to create bold, italic, paragraphs, tables, etc.
106 of 145
3/17/2016 5:01 AM
For full details about setting up a field to use a RTE, please refer to the Special Configuration options chapter in the TCA Reference.
The short story is that its enough to add the key defaultExtras to the configuration of the column with the string richtext[] as value:
'poem' => array(
'exclude' => 0,
'label' => 'LLL:EXT:examples/locallang_db.xml:tx_examples_haiku.poem',
'config' => array(
'type' => 'text',
'cols' => 40,
'rows' => 6
),
'defaultExtras' => 'richtext[]'
),
This works for FlexForms too.

Note
Dont forget to enable Rich Text Editor in the back end, in User Settings -> Edit and Advanced functions, check Enable Rich Text Editor, if not already done.
TYPO3 supports any Rich Text Editor for which someone might write a connector to the RTE API. This means that you can freely choose whatever RTE you want to use among those
available from the Extension Repository on typo3.org.
TYPO3 comes with a built-in RTE called rtehtmlarea, but other RTEs are available in the TYPO3 Extension Repository.
You can enable more than one RTE if you like but only one will be active at a time. Since Rich Text Editors o en depend on browser versions, operating systems etc. each RTE must have a
method in the API class which reports back to the system if the RTE is available in the current environment. The Rich Text Editor available to the backend user will be the first loaded RTE
which reports back to TYPO3 that it is available in the environment. If the RTE is not available, the next RTE Extension loaded will be asked.
Connecting an RTE in an extension to TYPO3 is easy.

Create a class file in your extension that extends the system class, \TYPO3\CMS\Backend\Rte\AbstractRte and override functions from the parent class to the degree needed.
In the ext_localconf.php file put an entry in $TYPO3_CONF_VARS['BE']['RTE_reg'] which registers the new RTE with the system. For example:
$TYPO3_CONF_VARS['BE']['RTE_reg']['myrte'] = array(
'objRef' => 'Foo\\MyRte\\Editors\\RteBase');
where the value of objRef is the fully qualified name of the class you declared in the first step.
There are three main methods of interest in the base class for the RTE API ( \TYPO3\CMS\Backend\Rte\AbstractRte ):
107 of 145
isAvailable() This method is asked for the availability of the RTE. This is where you should check for environmental requirements that is needed for your RTE. Basically the method
must return TRUE if the RTE is available. If it is not, the RTE can put text entries in the internal array ->errorLog which is used to report back the reason why it was not available.
drawRTE(&$pObj, $table, $field, $row, $PA, $specConf, $thisConfig, $RTEtypeVal, $RTErelPath, $thePidValue) This method draws the content for the editing
form of the RTE. It is called from the \TYPO3\CMS\Backend\Form\FormEngine class which also passes a reference to itself in $pObj . For details on the arguments in the method
call, please see inside \TYPO3\CMS\Backend\Rte\AbstractRte .
transformContent($dirRTE, $value, $table, $field, $row, $specConf, $thisConfig, $RTErelPath,$pid) This method is used both from ->drawRTE() and from
3/17/2016 5:01 AM
\TYPO3\CMS\Core\DataHandling\DataHandler to transform the content between the database and RTE. When content is loaded from the database to the RTE (and vice versa) it
may need some degree of transformation. For instance references to links and images in the database might have to be relative while the RTE requires absolute references. This is just a
simple example of what transformations can do for you and why you need them. See the next chapter for more details about transformations.
Transformation of content between the database and an RTE is needed if the format of the content in the database is dierent than the format understood by an RTE. A simple example
could be that bold-tags in the database <b> should be converted to <strong> tags in the RTE or that references to images in <img> tags in the database should be relative while
absolute in the RTE. In such cases a transformation is needed to do the conversion both ways: from database (DB) to RTE and from RTE to DB.
Generally transformations are needed for two reasons:
Data Formats: If the agreed format of the stored content in TYPO3 is dierent from the HTML format the RTE produces. This could be issues like XHTML, banning of certain tags or
maybe a hybrid format in the database. (See section 3 in the illustration some pages ahead)
RTE specifics: If the RTE has special requirements to the content before it can be edited and if that format is dierent from what we want to store in the database. For instance an RTE
could require a full HTML document with <html> , <head> and <body> - obviously we dont want that in the database and likewise we will have to wrap content in such a
dummy-body before it can be edited.
Many of the transformations performed back and forth in the TYPO3 backend date back to when it was a challenge to incorporate a RTE in a browser. It was then sometimes needed to fall
back an a simple <textarea> where rich text had to be presented in a simple enough way so that editors could work with it with no visual help.
This is what the two modes, ts_transform and css_transform try to achieve: maintain a data format that is as human readable as possible while still oering an RTE for editing if
applicable.
To know the details of those transformations, please refer to the Transformation overview. Here is a short example of a hybrid mode:
This is how the content in the database could look for a hybrid mode (such as css_transform ):
1
2
3
4
This is line number 1 with a <link 123>link</link> inside

This is line number 2 with a <b>bold part</b> in the text
<p align="center">This line is centered.</p>
This line is just plain
As you can see the TYPO3-specific tag, <link> is used for the link to page 123. This tag is designed to be easy for editors to insert. It is of course converted to a real <a> tag when the
page is rendered in the frontend. Further line 2 shows bold text. In line 3 the situation is that the paragraph should be centered - and there seems to be no other way than wrapping the line
in a <p> tag with the align attribute. Not so human readable but we can do no better without an RTE. Line 4 is just plain.
Generally this content will be processed before output on a page of course. Typically the rule will be this: Wrap each line in a <p> tag which is not already wrapped in a <p> tag and
convert all TYPO3-specific <link> -tags to real <a> tags. and thus the final result will be valid HTML.
The content in the database can easily be edited as plain text thanks to the hybrid-mode used to store the content. But when the content above from the database has to go into the RTE
it will not work if every line is not wrapped in a <p> tag! The same is true for the <link> tag, which has to be converted for the RTE to understand it. This is what eventually goes into the
RTE:
<p>This is line number 1 with a <a href="index.php?id=123">link</a> inside</p>
<p>This is line number 2 with a <strong>bold part</strong> in the text</p>
<p align="center">This line is centered.</p>
<p>This line is just plain</p>
This process of conversion from one format to the other is what transformations do!
Transformations are mainly defined in the special configurations of the $TCA types-configuration.
In addition transformations can be fine-tuned by Page TSconfig which means that RTE behaviour can be determined even on page branch level!
The transformations you can do with TYPO3 are done in the class \TYPO3\CMS\Core\Html\RteHtmlParser . There is typically a function for each direction; From DB to RTE (suixed
_rte ) and from RTE to DB (suixed _db ).
The transformations are invoked in two cases:
108 of 145
Before content enters the editing form This is done by the RTE API itself, calling the method \TYPO3\CMS\Backend\Rte\AbstractRte::transformContent() .
Before content is saved in the database This is done in \TYPO3\CMS\Core\DataHandling\DataHandler class and the transformation is triggered by a pseudo- field from the
3/17/2016 5:01 AM
submitted form! This field is added by the RTE API (calling \TYPO3\CMS\Backend\Rte\AbstractRte::triggerField() ). Lets say the fieldname is
data[tt_content][456][bodytext] then the trigger field is named data[tt_content][456][_TRANSFORM_bodytext] and in
\TYPO3\CMS\Core\DataHandling\DataHandler this pseudo-field will be detected and used to trigger the transformation process from RTE to DB. Of course the pseudo field will
never go into the database (since it is not found in $TCA ).

The rationale for transformations is discussed in Appendix A: Historical perspective on RTE transformations.
The following illustration shows the process of transformations graphically.
This is the various possible RTE applications, including the bare <textarea> .
Some RTEs might need to apply additional transformation of the content in addition to the general transformation. RTE specific transformations is normally programmed directly into the
RTE API class. In the case of rtehtmlarea that is \TYPO3\CMS\Rtehtmlarea\RteHtmlAreaBase which extends \TYPO3\CMS\Backend\Rte\AbstractRte .
The main transformation of content between browser format for RTEs and the database storage format. This is general for all RTEs. Normally consists of converting links and image
references from absolute to relative and further HTML processing as needed. This is the kind of transformation specifically described in this section!
The main transformations are done with \TYPO3\CMS\Core\Html\RteHtmlParser .
The database where the content is stored for use in both backend and frontend.
Content from the database is processed for display on the website. Depending on the storage format this might also involve transformation of content. For instance the internal <link>
tag has to be converted into an HTML <a> tag.
The processing is configurated using TypoScript. System extension CSS Styled Content extension provides such an object ( lib.parseFunc_RTE ). Refer to the description of the TS
function parsefunc for more details.
The website made with TYPO3 CMS.
This table gives some examples of how content will look in the RTE, in the database and on the final website.
Note
These are just examples! It might not happen exactly like that in real life since it depends on which exact transformations you apply. But it illustrates the point that the content needs to
be in dierent states whether in the RTE, Database or Website frontend.
RTE (#1)
Database (#4)
Website (#6)
<p>Hello World</p>
Hello World
<p>Hello World</p>
<p align=right>Right aligned text</p>
<table ...>....</table>
[stripped out]
<a href=http://localhost/.../index.php?id=123>
<link 123>
109 of 145
Comment
<p> omitted in DB to make it plain-text editable.
Had to keep <p> tag in DB because align attribute was found.

Tables were not allowed and so were stripped.
<a href=Contact_us.123.html>
Links are stored with the <link>-tag and needs processing for bo
3/17/2016 5:01 AM
RTE (#1)
Database (#4)
Website (#6)
Comment
<img src=http://localhost/fileadmin/image.jpg>
<img src=fileadmin/image.jpg>
<img src=fileadmin/image.jpg>
References to images must usually be absolute paths in RTEs w
The transformation of the content can be configured by listing which transformation filters to pass it through. The order of the list is the order in which the transformations are performed
when saved to the database. The order is reversed when the content is loaded into the RTE again.
Transformation filter
ts_transform
Description
Transforms the content with regard to most of the issues related to content elements types Text and Text & Images. The mode is optimized for the content rendering of the static
template content (default) which uses old <font> tag style rendering.
The mode is a hybrid mode which tries to save only the necessary HTML in the database so that content might still be easily edited without the RTE. For instance a text paragraph will
be encapsulated in <p> tags while in the database it will just be a single line ended by a line break character.
Tip
This transformation produces rather old style output and you should avoid it.
css_transform
Description
Like ts_transform, but producing a modern markup.

This mode is optimized for the content rendering done by css_styled_content.
ts_preserve
Description
Converts the list of preserved tags - if any - to <span> tags with a custom parameter specialtag which holds the value of the original tag.
Deprecated
ts_images
Description
Checks if any images on the page is from external URLs and if so they are fetched and stored in the uploads/ folder. In addition magic images are evaluated to see if their size has
changed and if so the image is recalculated on the server. Finally absolute URLs are converted to relative URLs for all local images.
ts_links
Description
Converts the absolute URLs of links to the TypoScript specific <LINK>-tag. This process is designed to make links in concordance with the typolink function in the TypoScript frontend.
ts_reglinks
Description
Converts the absolute URLs of links to relative. Keeping the <a> tag.
110 of 145
3/17/2016 5:01 AM
Meta transformations are special modes that include several filters.
ts
Description
Includes the following filters: ts_transform, ts_preserve, ts_images, ts_links. Obsolete.
ts_css
Description
Includes the following filters: css_transform, ts_images, ts_links. Recommended transformation. Use this for your RTE-enables fields and you should be safe.
In addition, it is possible to define custom transformations can be created allowing your to add your own tailor made transformations with a PHP class where you can program how content
is processed to and from the database.
Warning
Some explanations and descriptions may contain slightly obsolete references. The principles are still valid though.
The RTEs can be configured by Page TSconfig. There is a top level object named RTE , that is used for this. The main object paths looks like this:
Property
Data type
Description
default.[...]
RTEconf
These objects contain the actual configuration of the RTE interface. For
the properties available, refer to the table below.This is a description of
how you can customize in general and override for specific fields/types.
config.[ tablename ].[ field ].[...]

config.[ tablename ].[ field ].types.[ type ].[...]
RTE.default configures the RTE for all tables/fields/types

RTE.config.[tablename].[field] configures a specific field. The values inherit the values from RTE.default overriding
them if redefined.
RTE.config.[tablename].[field].types.[type] configures a specific field in case the type-value of the field matches type . Again this overrides the former settings.
Property
Data type
[individual RTE options]
Description
There are other options to set for the :code.`RTE` toplevel object. These
depend on the individual RTEs. Please refer to their respective manuals.
This configuration in Page TSconfig will disable the RTE altogether:

RTE.default.disabled = 1
In the case below the RTE is still disabled generally, but this is overridden specifically for the table tt_content where the RTE is used in the field bodytext. The disabled flag is set to
false again which means that for Content Elements the RTE will be available.
RTE.config.tt_content.bodytext.disabled = 0
In this example the RTE is still enabled for content elements in generally but if the Content Element type is set to Text (text) then the RTE will be disabled again!
RTE.config.tt_content.bodytext.disabled = 0
RTE.config.tt_content.bodytext.types.text.disabled = 1
The RTE object contains configuration of the RTE application. There are a few properties which are used externally from the RTE. The property disabled will simply disable the rendering
of the RTE and proc is reserved to contain additional configuration of transformations.
111 of 145
3/17/2016 5:01 AM
Property
Data type
Description
disabled
boolean
If set, the editor is disabled.

This option is evaluated in \TYPO3\CMS\Backend\Form\FormEngine
where it determines whether the RTE is rendered or not.
Property
Data type
Description
proc
proc
Customization of the server processing of the content - also called

transformations. See table below.
The transformations are only initialized, if they are configured ( rte_transform must be set for the field in the types definition in TCA).
The proc object is processed in \TYPO3\CMS\Core\Html\RteHtmlParser and is independant of the particular RTE used (like transformations generally are!).
Property
Data type
[individual RTE options]
Description
Each RTE may use additional properties for the RTE. Please refer to their
respective manuals.
This object contains configuration of the transformations used. These options are universal for all RTEs and used inside the class \TYPO3\CMS\Core\Html\RteHtmlParser .
The main objective of these options is to allow for minor configuration of the transformations. For instance you may disable the mapping between <b>-<strong> and <i>-<em> tags
which is done by the ts_transform transformation. Or you could disable the default transfer of images from external URL to the local server. This is all possible through the options.
Notice how many properties relate to specific transformations only! Also notice that the meta-transformations ts_css imply other transformations as explained in the overview. This
means that options limited to ts_transform will also work for ts_css of course.
Property
Data type
Description
overruleMode
List of RTE transformations
This can overrule the RTE transformation set from TCA.

Notice, this is a comma list of transformation keys. (Not a dash- list like
in $TCA).
Property
Data type
Description
preserveTags
list of tags
(DEPRECATED)
Here you may specify a list of tags - possibly user-defined pseudo tags which you wish to preserve from being removed by the RTE. See the information about preservation in the description of transformations.
Example:
In the default TypoScript configuration of content rendering the tags typotags <LINK> are the most widely used. However the <TYPOCODE>-tag is also configured to let you define a
section being formatted in monospace. Lets also imaging, you have defined a custom tag, <MYTAG>. In order to preserve these tag from removal by the RTE, you should configure like
this.
RTE.default.proc {
preserveTags = TYPOCODE, MYTAG
}
Relates to the transformation ts_preserve
Description
(Applies for ts_transform and css_transform only (function divideIntoLines))
112 of 145
3/17/2016 5:01 AM
Property
Data type
By default <BR> tags in the contentare converted to paragraphs. Setting
dontConvBRtoParagraph
boolean
this value will prevent the convertion of <BR>-tags to new- lines (chr(10))
Property
Data type
Description
allowTagsOutside
commalist of strings
(Applies for ts_transform and css_transform only (function

divideIntoLines))
Enter tags which are allowed outsideof <P> and <DIV> sections when converted back to database.
Default is img
Example:
IMG,HR
Property
Data type
Description
allowTags

getKeepTags))
Tags to allow. Notice, this list is added to the default list, which you see here:
b,i,u,a,img,br,div,center,pre,font,hr,sub,sup,p,strong,em,li,ul,ol,blo ckquote,strike,span
If you wish to deny some tags, see below.
Property
Data type
Description
denyTags

getKeepTags))
Property
Data type
Description
blockElementList
string
Comma-separated list of uppercase tags (e.g. P,HR ) that overrides the
Tags from above list to disallow.
list of HTML elements that will be treated as block elements by the RTE
transformations.
Property
Data type
Description
transformBoldAndItalicTags
boolean

getKeepTags))
Default is to convert b and i tags to strong and em tags respectively in the direction of the database, and to convert back strong and em tags to b and i tags in the direction of the RTE.
This transformation may be disabled by setting this property to 0.
Property
Data type
Description
HTMLparser_rte
HTMLparser

getKeepTags))
HTMLparser_db
113 of 145
This is additional options to the HTML-parser calls which strips of tags when the content is prepared for the RTE and DB
respectively. You can configure additional rules, like which other tags to preserve, which attributes to preserve, which values are
3/17/2016 5:01 AM
allowed as attributes of a certain tag etc.

Note
This configuration is similar in TypoScript and Page TSconfig. This is why the link for the data type points to the TypoScript reference.
Note
The HTMLparser options, keepNonMatchedTags and htmlSpecialChars are not observed. They are preset internally.
Property
Data type
Description
dontRemoveUnknownTags_db
boolean

HTMLcleaner_db))
Direction: To database
Default is to remove all unknown tags in the content going to the database. (See HTMLparser_db above for default tags). Generally this is a very usefull thing, because all kinds of bogus
tags from pasted content like that from Word etc. will be removed to have clean content in the database.
However this disables that and allows all tags, that are not in the HTMLparser_db-list.
Property
Data type
Description
dontUndoHSC_db
boolean

HTMLcleaner_db))
Direction: To database
Default is to re-convert literals to characters (that is < to <) outside of HTML-tags. This is disabled by this boolean. (HSC means HtmlSpecialChars - which is a PHP function)
Property
Data type
Description
dontProtectUnknownTags_rte
boolean
(Applies for ts_transform and css_transform only (function setDivTags))

Direction: To RTE
Default is that tags unknown to HTMLparser_rte is protected when sent to the RTE. This means they are converted from eg <MYTAG> to <MYTAG>. This is normally very fine,
because it can be edited plainly by the editor and when returned to thedatabase the tag is (by default, disabled by .dontUndoHSC_db) converted back.
Setting this option will prevent unknown tags from becoming protected.
Property
Data type
Description
dontHSC_rte
boolean

Direction: To RTE
Default is that all content outside of HTML-tags is passed through htmlspecialchars(). This will disable that. (opposite to .dontUndoHSC_db)
This option disables the default htmlspecialchars() conversion.
Property
Data type
Description
dontConvAmpInNBSP_rte
boolean
114 of 145
Direction: To RTE
3/17/2016 5:01 AM
By default all codes are NOT converted to   which they naturally word (unless .dontHSC_rte is set). You can disable that by this flag.
Property
Data type
Description
allowedFontColors
list of HTMLcolors

getKeepTags))
Direction: To DB
If set, this is the only colors which will be allowed in font-tags! Case insensitive.
Property
Data type
Description
allowedClasses
list of strings

getKeepTags))
Direction: To DB
Allowed general classnames when content is stored in database. Could be a list matching the number of defined classes you have.Case- insensitive.
This might be a really good idea to do, because when pasting in content from MS word for instance there are a lot of <SPAN> and <P> tags which may have class-names in. So by setting a
list of allowed classes, such foreign classnames are removed.
If a classname is not found in this list, the default is to remove the class-attribute.
Property
Data type
Description
skipAlign
boolean

divideIntoLines))
skipClass
If set, then the align and class attributes of <P>/<DIV> sections (respectively) will be ignored. Normally <P>/<DIV> tags are
preserved if one or both of these attributes are present in the tag. Otherwise its removed.
Property
Data type
Description
keepPDIVattribs
list of tag attributes (strings)

divideIntoLines))
align and class are the only attributes preserved for <P>/<DIV> tags. Here you can specify a list of other attributes to preserve.
Property
Data type
Description
remapParagraphTag
string / boolean

divideIntoLines))
When <P>/<DIV> sections are converted to be put into the database, the tag - P or DIV - is preserved. However setting this options to either P or DIV will force the section to be converted
to the one or the other.
If the value is set true (1), then it works as a general disable-flag for the whole section-convertion stu here and the result will be no tags preserved what so ever. Just removed.
Property
Data type
useDIVasParagraphTagForRTE
string
115 of 145
3/17/2016 5:01 AM
Description
(Applies for ts_transform only and css_transform (function TS_transform_rte))

Use <DIV>-tags for sections when converting lines from database to RTE. Default is <P>. Applies only to lines which has NO tag wrapped around already.
Property
Data type
Description
preserveDIVSections
boolean
(Applies for ts_transform and css_transform only)

If set, div sections will be treated just like blockquotes. They will be
treated recursively as external blocks.
Property
Data type
Description
preserveTables
boolean
(Applies for ts_transform)

If set, tables are preserved
Property
Data type
Description
dontFetchExtPictures
boolean
(Applies for ts_images)

If set, images from external urls are not fetched for the page if content is
pasted from external sources. Normally this process of copying is done.
Property
Data type
Description
plainImageMode
boolean/string
(Applies for ts_images)

If set, all plain local images (those that are not magic images) will be
cleaned up in some way.

If the value is just set, then the style attribute will be removed a er detecting any special width/height CSS attributes (which is what the RTE will set if you scale the image manually) and
the border attribute is set to zero.
You can also configure with special keywords. So setting plainImageMode to any of the value below will perform special processing:
lockDimensions : This will read the real dimensions of the image file and force these values into the <img> tag. Thus this option will prevent any user applied scaling in the image!
lockRatio : This will allow users to scale the image but will automatically correct the height dimension so the aspect ratio from the original image file is preserved.
lockRatioWhenSmaller : Like lockRatio, but will not allow any scaling larger than the original size of the image.
Property
Data type
Description
exitHTMLparser_rte
boolean/HTMLparser
(Applies for all kinds of processing)
exitHTMLparser_db
Allows you to enable/disable the HTMLparser for the content before

(entry) and a er (exit) the content is processed with the predefined processors (e.g. ts_images or ts_transform).
entryHTMLparser_rte
There are no default values set.
entryHTMLparser_db
Property
Data type
Description
disableUnifyLineBreaks
boolean
(Applies for all kinds of processing)
116 of 145
3/17/2016 5:01 AM
When entering the processor all \r\n linebreaks are converted to \n (13-10 to 10). When leaving the processor all \n is reconverted to \r\n (10 to 13-10).
This options disables that processing.
Property
Data type
usertrans.[user-defined transformation key]
Description
Custom option-space for userdefined transformations.

See example from section about custom transformations.
Instead of using the built-in transformations of TYPO3 you can program your own. This is done by creating a PHP class with two methods for transformation. Additionally you have to define
a key (like css_transform) for your transformation so you can refer to it in the configuration of Rich Text Editors.
You should pick a custom transformation key prefixed by tx_ , something like tx_[extension key]_[suffix] . The key must not contain dashes (see Using the transformation).
Note
If you pick one of the default transformation keys (except the meta-transformations) you will actually override it and your transformation will be called instead!
In ext_localconf.php , simply set a $TYPO3_CONF_VARS variable to point to the class which contains the transformation methods:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_parsehtml_proc.php']['transformation']['tx_examples_transformation']
= 'Documentation\Examples\Service\RteTransformation';
Here the transformation key is defined to be tx_examples_transformation and the value is the fully qualified class name.
This class must contain two public methods, transform_db() and transform_rte() .
It must also contain two public variables called by TYPO3 Core (this is an old part, which doesnt use a proper API):
$pObj which will contain an instance of \TYPO3\CMS\Core\Html\RteHtmlParser .
$transformationKey which should contain your transformations key (in this case tx_examples_transformation ).
This code listing shows a simple transformation. When content is delivered to the RTE it will add a <hr/> tag to the end of the content. When the content is stored in the database any
<hr/> tag at the end of the content will be removed and substituted with whitespace.
117 of 145
3/17/2016 5:01 AM
class RteTransformation {
/**
* NOTE: must be public as it is accessed by \TYPO3\CMS\Core\Html\RteHtmlParser without API
*
* @var \TYPO3\CMS\Core\Html\RteHtmlParser
*/
public $pObj;
/**
* NOTE: must be public as it is accessed by \TYPO3\CMS\Core\Html\RteHtmlParser without API
*
* @var string
*/
public $transformationKey = 'tx_examples_transformation';
/**
* @var array
*/
protected $configuration;
/**
* Loads the transformation's configuration
*
* @return void
*/
protected function loadConfiguration() {
$this->configuration = $this->pObj->procOptions['usertrans.'][$this->transformationKey . '.'];
}
/**
* Transforms RTE content prior to database storage
*
* @param string $value RTE HTML to clean for database storage
* @return string
*/
public function transform_db($value) {
$this->loadConfiguration();
if ($this->configuration['addHrulerInRTE'])
{
$value = preg_replace('/<hr[[:space:]]*[\/]>[[:space:]]*$/i', '', $value);
}
return $value;
}
/**
* Transforms database content for RTE display
*
* @param string $value Database content to transform into RTE-ready HTML
* @return string
*/
public function transform_rte($value) {
$this->loadConfiguration();
if ($this->configuration['addHrulerInRTE'])
$value .= '<hr/>';
}
return $value;
}
}
The transformation methods transform_rte and transform_db take a single argument which is the value to transform. They have to return that value again, modified as needed.
Notice that both transformation functions call initConfig() which uses the reference to the parser object to retrieve configuration related to the custom transformation.
The transformation is not yet used. It is only registered. The basic way of applying it to some rich-text field is to declare it in the rte_transform option of the defaultExtras TCA
property. For example, this is what you will find in the definition of the poem field of the haiku table from the examples extension:
'poem' => array(
'exclude' => 0,
'label' => 'LLL:EXT:examples/locallang_db.xml:tx_examples_haiku.poem',
'config' => array(
'type' => 'text',
'cols' => 40,
'rows' => 6,
'softref' => 'typolink_tag,images,email[subst],url',
),
'defaultExtras' => 'richtext[]:rte_transform[mode=tx_examples_transformation-ts_css]'
),
The order is important. The order in this list is the order of calling when the direction is db. The order is reversed on the way to the RTE. This means that on the way to the RTE, all
transformations covered by ts_css will happen first and then our custom transformation adds its <hr/> tag. On the way to the database, the opposite happens. The extra <hr/> tag is
removed first, then all other transformations are applied.
Important
Notice how transformation keys are separated by a dash (-) in this case and not a comma. This means that your transformation key should not contain dashes.
118 of 145
3/17/2016 5:01 AM
However the above code will not work in most cases, because both rtehtmlarea and css_styled_content overrule any default processing (using the overruleMode property). In order
for the haiku table to have its own custom transformations, it must also be registered as an overruleMode with the following Page TSconfig:
RTE.config.tx_examples_haiku.poem.proc.overruleMode = tx_examples_transformation,ts_css
As a last step we must set the custom option ( addHrulerInRTE ) that we decided to use in our script. Again in Page TSconfig:
RTE.default.proc.usertrans.tx_examples_transformation.addHrulerInRTE = 1
Since version 4.3.0 TYPO3 comes with an build-in error and exception handling system. Admins can configure how errors and exceptions should be displayed in Backend and Frontend.
Errors and exception can be logged to all available logging systems in TYPO3 including \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() which is among other features
able to send error messages by mail (see example setups below).
This section shows some sample output to demonstrate the capabilities of error and exception handling in TYPO3.
119 of 145
3/17/2016 5:01 AM
All configuration options related to error and exception handling are found in $TYPO3_CONF_VARS[SYS] :
Key
Data type
Description
Configures whether PHP errors should be displayed.
0 = Do not display any PHP error messages. Overrides the value of exceptionalErrors and sets it to 0 (= no errors are turned into exceptions),the configu
displayErrors
integer
1 = Display error messages with the registered error handler,the configured debugExceptionHandler is used as exception handler
2 = Display errors only if client matches $TYPO3_CONF_VARS[SYS][devIPmask] . If devIPmask matches the users IP address the configured debugExc
-1 = Default setting. With this option, you can override the PHP setting display_errors . If devIPmask matches the users IP address the configured
Classname to handle PHP errors. Leave empty to disable error handling.
Default: \TYPO3\CMS\Core\Error\ErrorHandler . This class will register itself as error handler. It is able to write error messages to all available logging
errorHandler
120 of 145
string
Additionally the errors can be displayed as flash messages in the Backend or in the adminpanel in Frontend. The flash messages in Backend are only displa
Errors which are registered as exceptionalErrors will be turned into exceptions (to be handled by the configured exceptionHandler).
3/17/2016 5:01 AM

Key
Data type
errorHandlerErrors
integer
Description
The E_* constant that will be handled by the error handler
Default: E_ALL ^ E_NOTICE
The E_* constant that will be handled as an exception by the error handler.
exceptionalErrors
integer
Default: E_ALL ^ E_NOTICE ^ E_WARNING ^ E_USER\_ERROR ^ E_USER\_NOTICE ^ E_USER\_WARNING (4341) and 0 if $TYPO3_CONF_VARS[SYS]
Refer to the PHP documentation for more details on this value.
Classname to handle exceptions that might happen in the TYPO3-code.
Leave empty to disable exception handling.
productionExceptionHandler
Default: \TYPO3\CMS\Core\Error\ProductionExceptionHandler . This exception handler displays a nice error message when something went wrong.
string
Note
The configured productionExceptionHandler is used if $TYPO3_CONF_VARS[SYS][displayErrors] is set to 0 or to -1 and $TYPO3_CONF_VARS[SY
Classname to handle exceptions that might happen in the TYPO3 code.

Leave empty to disable exception handling.
debugExceptionHandler
Default: \TYPO3\CMS\Core\Error\DebugExceptionHandler . This exception handler displays the complete stack trace of any encountered exception. T
string
Note
The configured debugExceptionHandler is used if $TYPO3_CONF_VARS[SYS][displayErrors] is set to 1 or if $TYPO3_CONF_VARS[SYS][displayEr
enable_errorDLOG
boolean
Whether errors should be written to the Developers Log (requires an installed *devlog extension).
enable_exceptions
boolean
Whether exceptions should be written to the Developers Log (requires an installed *devlog extension).
syslogErrorReporting
integer
Configures which PHP errors should be logged to the configured syslogs (see: [SYS][systemLog]). If set to 0 no PHP errors are logged to the syslog.
Default: E_ALL ^ E_NOTICE (6135).
Configures which PHP errors should be logged to the sys_log table (extension: belog). If set to 0 no PHP errors are logged to the sys_log table.
belogErrorReporting
integer
Default: E_ALL ^ E_NOTICE (6135).
Configures which mechanism is used to log errors being logged using GeneralUtility::sysLog() calls. Multiple settings are possible by separating them with a
Every distinct option can contain up to three values separated by comma. The first option defines the mechanism which is used for logging. The second opt
file,<abs-path-to-file>[,<level>] = Writes the error messages to the specified file.
systemLog
string
mail,<to>[/<from>][,<level>] = Sends an email for every error message to the configured email <to>. Additionally sets the e-mail From header.
syslog,<facility>[,<level>] = Uses the PHP method syslog to send the log message. Depending on the operating system the message will get logged in d
error_log[,,<level>] = This setting will use the PHP method error_log to log the message. The message will get handled according to the settings of the
Using the method file is very reliable but could also pose a security risk if you write error logs into the webroot of your site. The option error_log allows
The table below shows which values can be set by the user and which are set by TYPO3.
Values in plain text can be changed in LocalConfiguration.php.
Values in bold are set by TYPO3.
displayErrors
errorHandlerErrors
exceptionalErrors
errorHandler
devIPmask
-1
E_ALL ^ E_NOTICE
E_ALL ^ E_NOTICE ^ E_WARNING ^ E_USER_ERROR ^ E_USER_NOTICE
TYPO3CMS CoreError ErrorHandler
Matters
E_ALL ^ E_NOTICE
0 (no errors are turned into exceptions)
Doesnt matter
E_ALL ^ E_NOTICE
E_ALL ^ E_NOTICE ^ E_WARNING ^ E_USER_ERROR ^ E_USER_NOTICE ^ E_USER_WARNING
Doesnt matter
E_ALL ^ E_NOTICE
E_ALL ^ E_NOTICE ^ E_WARNING ^ E_USER_ERROR ^ E_USER_NOTICE ^ E_USER_WARNING
Matters
The following sections highlight the roles and goals of the various classes related to error and exception handling. Examples and custom handlers are also discussed.
Class \TYPO3\CMS\Core\Error\ErrorHandler is the default error handler in TYPO3.
121 of 145
3/17/2016 5:01 AM
Functions:
Can be registered for all, or for only a subset of the PHP errors which can be handled by an error handler
Displays error messages as flash messages in the Backend (if exceptionHandler is set to \TYPO3\CMS\Core\Error\DebugExceptionHandler ). Since flash messages are integrated in
the Backend template, PHP messages will not destroy the Backend layout.
Displays errors as TsLog messages in the adminpanel.
Logs error messages to \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() which is able to write error messages to a file, to the web servers error_log, the systems log and
it can send you errors and exceptions in an email. \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() oers a hook and can be extended by user-defined logging methods.
Logs error messages to \TYPO3\CMS\Core\Utility\GeneralUtility::devLog() if $TYPO3_CONF_VARS[SYS][enable_errorDLOG] is enabled (depending on the devlog
extension used, this might require an existing DB connection).
Logs error messages to the sys_log table. Logged errors are displayed in the belog extension (Admin Tools > Log) (works only if there is an existing DB connection).
Functions of \TYPO3\CMS\Core\Error\ProductionExceptionHandler :
Shows brief exception message using \TYPO3\CMS\Core\TimeTracker\TimeTracker::debug_typo3PrintError() which can be manipulated by a hook
Logs exception messages to \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() which is able to write exception messages to a file, to the web servers error_log, the
systems log and it can send you errors and exceptions in an email. \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() oers a hook an can be extended by user-defined
logging methods.
Logs exception messages to \TYPO3\CMS\Core\Utility\GeneralUtility::devLog() if $TYPO3_CONF_VARS[SYS][enable_errorDLOG] is enabled (depending on the devlog
Logs exception messages to the sys_log table. Logged errors are displayed in the belog extension (Admin Tools > Log) (works only if there is an existing DB connection).
Functions of \TYPO3\CMS\Core\Error\DebugExceptionHandler :
Shows detailed exception messages and full trace of an exception.
Logs exception messages to \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() which is able to write exception messages to a file, to the web servers error_log, the
systems log and it can send you errors and exceptions in an email. \TYPO3\CMS\Core\Utility\GeneralUtility::syslog() oers a hook an can be extended by user-defined
logging methods.
Logs exception messages to \TYPO3\CMS\Core\Utility\GeneralUtility::devLog() if $TYPO3_CONF_VARS[SYS][enable_errorDLOG] is enabled (depending on the devlog
Logs exception messages to the sys_log table. Logged errors are displayed in the belog extension (Admin Tools > Log) (works only if there is an existing DB connection).
Very verbose configuration which logs and displays all errors and exceptions.
In LocalConfiguration.php :
'SYS' => array(
'displayErrors' => '1',
'devIPmask' => '*',
'errorHandler' => 'TYPO3\\CMS\\Core\\Error\\ErrorHandler',
'errorHandlerErrors' => E_ALL ^ E_NOTICE,
'exceptionalErrors' => E_ALL ^ E_NOTICE ^ E_WARNING ^ E_USER_ERROR ^ E_USER_NOTICE ^ E_USER_WARNING,
'debugExceptionHandler' => 'TYPO3\\CMS\\Core\\Error\\DebugExceptionHandler',
'productionExceptionHandler' => 'TYPO3\\CMS\\Core\\Error\\DebugExceptionHandler',
'systemLogLevel' => '0',
'systemLog' => 'mail,test@localhost.local,4;error_log,,2;syslog,LOCAL0,,3;file,/abs/path/to/logfile.log',
'enable_errorDLOG' => '1',
'enable_exceptionDLOG' => '1',
),
In .htaccess :
php_flag display_errors on
php_flag log_errors on
php_value error_log /path/to/php_error.log
Example for a production configuration which displays only errors and exceptions if the devIPmask matches. Errors and exceptions are only logged if their level is at least 2 (=Warning).
122 of 145
3/17/2016 5:01 AM
'SYS' => array(

'devIPmask' => '[your.IP.address]',
'errorHandler' => 'TYPO3\\CMS\\Core\\Error\\ErrorHandler',
'systemLogLevel' => '2',
'systemLog' => 'mail,test@localhost.local,4;error_log,,2;syslog,LOCAL0,,3',
'syslogErrorReporting' => E_ALL ^ E_NOTICE ^ E_WARNING,
'belogErrorReporting' => '0',
),
In .htaccess :
php_flag display_errors off
php_flag log_errors on
php_value error_log /path/to/php_error.log
Since the error and exception handling and also the logging need some performance, heres an example how to disable error and exception handling completely.
'SYS' => array(
'devIPmask' => '',
'errorHandler' => '',
'debugExceptionHandler' => '',
'productionExceptionHandler' => '',
'systemLog' => '',
'syslogErrorReporting' => '0',
'belogErrorReporting' => '0',
),
In .htaccess :
php_flag display_errors off
php_flag log_errors off
If you want to register your own error or exception handler, simply include the class and insert its name into productionExceptionHandler, debugExceptionHandler or errorHandler:
$TYPO3_CONF_VARS['SYS']['errorHandler'] = 'myOwnErrorHandler';
$TYPO3_CONF_VARS['SYS']['debugExceptionHandler'] = 'myOwnDebugExceptionHandler';
$TYPO3_CONF_VARS['SYS']['productionExceptionHandler'] = 'myOwnProductionExceptionHandler';
An error or exception handler class must register an error (exception) handler in its constructor. Have a look at the files in EXT:core/Classes/Error/ to see how this should be done.
If you want to use the built-in error and exception handling but extend it with your own functionality, simply derive your class from the error and exception handling classes shipped with
TYPO3 and register this class as error (exception) handler:
class tx_postExceptionsOnTwitter extends \TYPO3\CMS\Core\Error\DebugExceptionHandler {
function echoExceptionWeb(Exception $exception) {
$this->postExceptionsOnTwitter($exception);
}
function postExceptionsOnTwitter($exception) {
// do it ;-)
}
}
$TYPO3_CONF_VARS['SYS']['debugExceptionHandler'] = 'tx_postExceptionsOnTwitter';
$TYPO3_CONF_VARS['SYS']['productionExceptionHandler'] = 'tx_postExceptionsOnTwitter';
TYPO3 oers an XML format, T3DataStructure, which defines a hierarchical data structure. In itself the data structure definition doesnt do much - it is only a back bone for higher level
applications which can add their own configuration inside.
Such applications can be:
123 of 145
FlexForms - a TCEform type which will allow users to build information hierarchies (in XML) according to the Data Structure. In this sense the Data Structure is like a DTD (Document
Type Definition) for the backend which can render a dynamic form based on the Data Structure;
3/17/2016 5:01 AM
TemplaVoila! - an extension which uses the Data Structure as backbone for mapping template HTML to data.
This documentation of a data structure will document the general aspects of the XML format and leave the details about FlexForms and TemplaVoila to be documented elsewhere.
Some other facts about Data Structures (DS):
A Data Structure is defined in XML with the document tag named <T3DataStructure>
The XML format generally complies with what can be converted into a PHP array by \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array() - thus it directly reflects how a
multidimensional PHP array is constructed.
A Data Structure can be arranged in a set of sheets. The purpose of sheets will depend on the application. Basically sheets are like a one-dimensional internal categorization of Data
Structures.
Parsing a Data Structure into a PHP array is incredibly easy - just pass it to \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array() (see the Parsing a Data Structure section).
DS is sometimes used as short for Data Structure
This is the list of elements and their nesting in the Data Structure.
All elements defined here cannot contain any string value but must contain another set of elements.
(In a PHP array this corresponds to saying that all these elements must be arrays.)
Element
Description
<T3DataStructure>
Document tag
<meta>
Can contain application specific meta settings

Defines an object in the Data Structure
<ROOT>
<ROOT> is reserved as tag for the first element in the Data Structure.The <ROOT> element must have a <type> tag with the value array and then define other objects neste
<[field name]>
[field name] defines the objects name
<sheets>
Defines a collection of sheets which is like a one-dimensional list of independent Data Structures
<TCEforms>
Contains details about visual representation of sheets. If there is only a single sheet, applies to implicit single sheet.
<sheetTitle>
Title of the sheet. Mandatory for any sheet except the first (which gets General in this case). Can be a plain string or a reference to language file using standard LLL syntax. Ignore
<cshFile>
CSH language file for fields inside the flexform. Refer to section on T3locallang for the format of language files and to section Content Sensitive Help of Inside TYPO3 document f
Condition that must be met in order for the sheet to be displayed. If the condition is not met, the sheet is hidden.
<displayCond>
For more details refer to the description of the displayCond property in the TCA Reference.
Defines an independent data structure starting with a <ROOT> tag.
<[sheet ident]>
Note
Alternatively it can be a plain value referring to another XML file which contains the <ROOT> structure. See example later.
<el>
Contains a collection of Data Structure objects
All elements defined here must contain a string value and no other XML tags whatsoever!
(In a PHP array this corresponds to saying that all these elements must be strings or integers.)
Element
124 of 145
Format
Description
3/17/2016 5:01 AM

Element
Format
Description
Defines the type of object.
array means that the object simply contains a collection of other objects defined inside the <el> tag on the same level. If the value is array you can use th
Keyword string:
Default value means that the object does not contain sub objects. The meaning of such an object is determined by the application using the data structure. F
<type>
array, [blank] (=default)
Note
If the object was <ROOT> this tag must have the value array
<section>
Boolean
Defines for an object of the type <array> that it must contain other array type objects in each item of <el>. The meaning of this is application specific. For FlexF
Below is the (truncated) structure for the plugin options of system extension felogin. It shows an example of relative complex data structure used in a FlexForm. More information about
such usage of FlexForms can be found in the relevant section of the TCA reference.
125 of 145
3/17/2016 5:01 AM
<T3DataStructure>
<meta>
<langDisable>1</langDisable>
</meta>
<sheets>
<sDEF>
<ROOT>
<TCEforms>
<sheetTitle>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.sheet_general</sheetTitle>
</TCEforms>
<type>array</type>
<el>
<showForgotPassword>
<TCEforms>
<label>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.show_forgot_password</label>
<config>
<type>check</type>
<items type="array">
<numIndex index="1" type="array">
<numIndex
index="0">LLL:EXT:lang/locallang_core.xml:labels.enabled</numIndex>
<numIndex index="1">1</numIndex>
</numIndex>
</items>
</config>
</TCEforms>
</showForgotPassword>
<showPermaLogin>
<TCEforms>
<label>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.show_permalogin</label>
<config>
<default>1</default>
<type>check</type>
<numIndex
index="0">LLL:EXT:lang/locallang_core.xml:labels.enabled</numIndex>
</numIndex>
</items>
</config>
</TCEforms>
</showPermaLogin>
...
</el>
</ROOT>
</sDEF>
<s_redirect>
<ROOT>
<TCEforms>
<sheetTitle>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.sheet_redirect</sheetTitle>
</TCEforms>
<type>array</type>
<el>
<redirectMode>
<TCEforms>
<label>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.redirectMode</label>
<config>
<type>select</type>
<numIndex
index="0">LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.redirectMode.I.0</numIndex>
<numIndex index="1">groupLogin</numIndex>
</numIndex>
<numIndex
index="0">LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.redirectMode.I.1</numIndex>
<numIndex index="1">userLogin</numIndex>
</numIndex>
...
</items>
<size>8</size>
<minitems>0</minitems>
<maxitems>8</maxitems>
</config>
</TCEforms>
</redirectMode>
</el>
</ROOT>
</s_redirect>
<s_messages>
...
</s_messages>
</sheets>
</T3DataStructure>
If Data Structures are arranged in a collection of sheets you can choose to store one or more sheets externally in separate files. This is done by setting the value of the <[sheet ident]> tag to
a relative file reference instead of being a definition of the <ROOT> element.
126 of 145
3/17/2016 5:01 AM
Taking the Data Structure from the previous example we could rearrange it in separate files:
Main Data Structure:
<T3DataStructure>
<sheets>
<sDEF>fileadmin/sheets/default_sheet.xml</sDEF>
<s_welcome>fileadmin/sheets/welcome_sheet.xml</s_welcome>
</sheets>
</T3DataStructure>
EXT:news/Configuration/FlexForms/Sheets/Default.xml :
<T3DataStructure>
<ROOT>
<TCEforms>
<sheetTitle>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.sheet_general</sheetTitle>
</TCEforms>
<type>array</type>
<el>
<showForgotPassword>
<TCEforms>
<label>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.show_forgot_password</label>
<config>
<type>check</type>
<numIndex index="0">LLL:EXT:lang/locallang_core.xml:labels.enabled</numIndex>
</numIndex>
</items>
</config>
</TCEforms>
</showForgotPassword>
<showPermaLogin>
<TCEforms>
<label>LLL:EXT:felogin/locallang_db.xml:tt_content.pi_flexform.show_permalogin</label>
<config>
<default>1</default>
<type>check</type>
<numIndex index="0">LLL:EXT:lang/locallang_core.xml:labels.enabled</numIndex>
</numIndex>
</items>
</config>
</TCEforms>
</showPermaLogin>
...
</el>
</ROOT>
</T3DataStructure>
and so on for the two other sheets.
FlexForms being XML any code editor can help in checking out their syntax and highlighting the various elements inside them. However extension extdeveval contains additional tools
and utilities for highlightind such code. Just copy the DS XML content into the form:
127 of 145
3/17/2016 5:01 AM
You can convert a Data Structure XML document into a PHP array by using the function \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array() . The reverse transformation is
achieved using \TYPO3\CMS\Core\Utility\GeneralUtility::array2xml_cs() .
If the Data Structure uses referenced sheets, for example
<T3DataStructure>
<sheets>
<sDEF>fileadmin/sheets/default_sheet.xml</sDEF>
<s_welcome>fileadmin/sheets/welcome_sheet.xml</s_welcome>
</sheets>
</T3DataStructure>
additional operations must be performed to resolve the sheets content:

$treeDat = \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array($inputCode);
$treeDat = \TYPO3\CMS\Core\Utility\GeneralUtility::resolveAllSheetsInDS($treeDat);
This will produce the following debug output:
128 of 145
3/17/2016 5:01 AM
This XML format is used for locallang-XML (llXML) files, a format TYPO3 uses for storage of interface labels and translations of them. The format is parsed by
\TYPO3\CMS\Core\Utility\GeneralUtility::xml2array() which means that tag- names and index attribute values are inter-related in significance. The content is always in utf-8.
llXML files must be used from inside extension directories (system/global/local).
See Inside TYPO3 for more details about these files and the application of this format.
llXML files from installed extensions can be translated locally by a backend tool (extension llxmltranslate) and remotely on the TYPO3 translation server.
A locallang-XML file contains a set of labels in the default language (must always English!). The translated labels are located in systematically named external files in
typo3conf/l10n/[language key]/ . Optionally the main files can contain the translations directly but that should only be used in special cases since it constrains the translation
process too much. It is also possible with a specific file reference to use other external files than the automated ones.
Important
Since TYPO3 CMS 4.6, a new format was introduced for managing internationalization. The XLIFF format is an open source standard. See the related chapter for more information
about, in particular how to migrate to it and how to ensure backwards-compatibility.
This is the elements and their nesting in the locallang-XML format.
All elements defined here cannot contain any string value but must contain another set of elements.
(In a PHP array this corresponds to saying that all these elements must be arrays.)
Element
Description
<T3locallang>
Document tag
<meta>
Contains meta data about the locallang-XML file. Used in translation, but not inside TYPO3 directly.
129 of 145
3/17/2016 5:01 AM

Element
Description
Contains the data for translations
Note
<data>
The contents in the <data> tag is all that is needed for labels inside TYPO3. Everything else is meta information for the translation tool!
<orig_hash>
<orig_text>
Contains hash-integers for each translated label of the default label at the point of translation. This is used to determine if the default label has changed since the translation was mad
Contains the text of the default label that was the basis of the translated version! The original text is used to show a di between the original base of the translation and the new defau
Array of labels for a language. The index attribute contains language key.
There are two cases in the context <data> to note:
index = default: Array of default labels.
index = [language key] :
<languageKey>
If string: Pointer to external file containing translation, e.g. EXT:csh_dk/lang/dk.locallang_csh_web_info.xml

If array: Translations inline in main file (deprecated)
[If not existing, recommended ]: Translations in external default file typo3conf/l10n/
Array of context descriptions of the default labels.
<labelContext>
The index attribute contains label key
All elements defined here must contain a string value and no other XML tags whatsoever!
All values are in utf-8.
(In a PHP array this corresponds to saying that all these elements must be strings or integers.)
Element
Format
<label>
Description
Value of a original/translated label.
string
(under <data>)
The index attribute contains label key.
<label>
Hash of a translated label.

integer
(under <orig_hash>)
<label>
Original default value of a translated label used for making a di if the original has changed.
string
(under <orig_text>)
<label>
Description of a default labels context. This should be used where it cannot be clear for the translation where the default labels occur. Sometimes the context is im
string
(child of <labelContext>)
<description>

string
Description of the file contents.

Type of content. Possible values are:
module : Used for labels in the backend modules.
<type>
string
database : Used for labels of database tables and fields.

CSH : Used for Context Sensitive Help (both database tables, fields, backend modules etc.)
(Only when the type is CSH!)
For CSH it is important to know what table the labels belong to. A table in the context of CSH is an identification of a group of labels. This can be an actual table
<csh_table>
string
Examples:
<csh_table>xMOD_csh_corebe</csh_table> (General Core CSH)
<csh_table>_MOD_tools_em</csh_table> (For Extension Mgm. module)
<csh_table>pages</csh_table> (For "pages" table)
External include files contains a sub-set of the tags of the <T3locallang> format. Basically they contain the <data>, <orig_hash> and <orig_text> tags but with <languageKey> tags inside
only for the specific language they used.
When the include file is read the information for the selected language key is read from each of the three tags and merged into the internal array.
Element
130 of 145
Description
Child elements
3/17/2016 5:01 AM

Element
Description
Child elements
<data>
<T3locallangExt>
Document tag for the external include files of <T3locallang>
<orig_hash>
<orig_text>
<data>
See <data> element of <T3locallang> above.
<orig_hash>
<orig_text>
This example shows a standard locallang-XML file for a backend module. Notice how the <orig_hash> section is included which means that translators can spot if an original label
changes. However the <orig_text> section would have been needed if translators were supposed to also see the dierence. But typically that is not enabled since it takes a lot of space
up.
<T3locallang>
<meta type="array">
<description>Standard Module labels for Extension Development Evaluator</description>
<type>module</type>
<csh_table/>
<labelContext type="array"/>
</meta>
<data type="array">
<languageKey index="default" type="array">
<label index="mlang_tabs_tab">ExtDevEval</label>
<label index="mlang_labels_tabdescr">The Extension Development Evaluator tool.</label>
</languageKey>
<languageKey index="dk" type="array">
<label index="mlang_tabs_tab">ExtDevEval</label>
<label index="mlang_labels_tabdescr">Evalueringsvrktj til udvikling af extensions.</label>
</languageKey>
....
</data>
<orig_hash type="array">
<label index="mlang_tabs_tab" type="integer">114927868</label>
<label index="mlang_labels_tabdescr" type="integer">187879914</label>
</languageKey>
</orig_hash>
</T3locallang>
The main XML file looks like this. Notice the tag csh_table has a value which is important for CSH content so it can be positioned in the right category.
In the <data> section you can see all default labels. But notice how the value for the dk translation is a reference to an external file! The contents of that file is shown below this listing.
<T3locallang>
<meta type="array">
<description>CSH for Web>Info module(s) (General Framework)</description>
<type>CSH</type>
<csh_table>_MOD_web_info</csh_table>
<labelContext type="array"/>
</meta>
<data type="array">
<languageKey index="default" type="array">
<label index=".alttitle">Web > Info module</label>
<label index=".description">The idea of the Web>Info ...</label>
<label index=".details">Conceptually the Web>Info mod...functionality.</label>
<label index="_.seeAlso">_MOD_web_func,</label>
<label index="_.image">EXT:lang/cshimages/pagetree_overview_10.png</label>
<label index=".image_descr">The Web>Info module a.... "info_pagetsconfig".</label>
</languageKey>
<languageKey index="dk">EXT:csh_dk/lang/dk.locallang_csh_web_info.xml</languageKey>
</data>
</T3locallang>
The include file (for dk) looks like below.
131 of 145
3/17/2016 5:01 AM
<T3locallangExt>
<data type="array">
<label index="pagetree_overview.alttitle">Sidetr overblik</label>
</languageKey>
</data>
<orig_hash type="array">
<label index="pagetree_overview.alttitle" type="integer">92312309</label>
</languageKey>
</orig_hash>
<orig_text type="array">
<label index="pagetree_overview.alttitle">Pagetree Overview</label>
</languageKey>
</orig_text>
</T3locallangExt>
This manual covers many dierent APIs of the TYPO3 CMS Core, but some other manuals exist which cover more specific aspects. They are listed below:
TCA Reference
Detailed description of the Table Control Array (TCA) which is used to fully describe database tables used in TYPO3.
TYPO3 CMS Skinning Reference
All things related to skinning, CSS and icons, for the TYPO3 backend.
TYPO3 CMS Services
Services are libraries which can be loaded flexibly based on various conditions.
File Abstraction Layer
The complete reference for the File Abstraction Layer introduced in TYPO3 CMS 6.0.
Inside TYPO3 CMS
The sister manual to this one. Describes the general principles underlying the TYPO3 CMS Core.
This section contains material which is generally more detailed and was removed from the main text to improve its readability. It may also be historical material which was le for those
who like to have a perspective on why some choices were made or why some things work the way they do in TYPO3 CMS.
The next sections describe in more details the necessity of RTE transformations. The text was written at the birth of transformations and might therefore be somewhat old-fashioned.
However it checked out generally OK and may help you to further understand why these issues exist. The argumentation is still valid.
The RTE applications typically expect to be fed with content formatted as HTML. In eect an RTE will discard content it doesnt like, for instance fictitious HTML tags and line breaks. Also
the HTML content created by the RTE editor is not necessarily as clean as you might like.
The editor has the ability to paste in formatted content copied/cut from other websites (in which case images are included!) or from text processing applications like MS Word or Star Oice.
This is a great feature and may solve the issue of transferring formatted content from e.g. Word into TYPO3.
However these inherent features - good or bad - raises the issue how to handle content in a field which we do not wish to pollute with unnecessary HTML-junk. One perspective is the fact
that we might like to edit the content with Netscape later (for which the RTE cannot be used, see above) and therefore would like it to be human readable. Another perspective is if we
might like to use only Bold and Italics but not the alignment options. Although you can configure the editor to display only the bold and italics buttons, this does not prevent users from
pasting in HTML-content copied from other websites or from Microso Word which does contain tables, images, headlines etc.
The answer to this problem is a so called transformation which you can configure in the $TCA (global, authoritative configuration) and which you may further customize through Page
TSconfig (local configuration for specific branches of the website). The issue of transformations is best explained by the following example from the table, tt_content (the content
elements).
The RTE is used in the bodytext field of the content elements, configured for the types Text and Text & Images.
132 of 145
3/17/2016 5:01 AM
The configuration of the two Text-types are the same: The toolbar includes only a subset of the total available buttons. The reason is that the text content of these types, Text and Text &
Images is traditionally not meant to be filled up with HTML-codes. But more important is the fact that the content is usually (by the standard TypoScript content rendering used on the vast
majority of TYPO3 websites!) parsed through a number of routines.
In order to understand this, here is an outline of what typically happens with the content of the two Text-types when rendered by TypoScript for frontend display:
1. All line breaks are converted to <br /> codes.
(Doing this enables us to edit the text in the field rather naturally in the backend because line breaks in the edit field comes out as line breaks on the page!)
2. All instances of http://... and mailto:.... are converted to links.
(This is a quick way to insert links to URLs and email address)
3. The text is parsed for special tags, so called typotags, configured in TypoScript. The default typotags tags are <LINK> (making links), <TYPOLIST> (making bulletlists),
<TYPOHEAD> (making headlines) and <TYPOCODE> (making monospaced formatting).
(The <LINK> tag is used to create links between pages inside TYPO3. Target and additional parameters are automatically added which makes it a very easy way to make sure, links are
correct. <TYPOLIST> renders each line between the start and end tag as a line in a bulletlist, formatted like the content element type Bulletlist would be. This would typically result
in a bulletlist placed in a table and not using the bullet-list tags from HTML. <TYPOHEAD> would display the tag content as a headline. The type-parameter allows to select between the
five default layout types of content element headlines. This might include graphical headers. <TYPOCODE> is not converted).
4. All other tags found in the content are converted to regular text (with htmlspecialchars) unless the tag is found in the allowTags list.
(This list includes tags like b (bold) and i (italics) and so these tags may be used and will be outputted. However tags like table, tr and td is not in this list by default, so table-html
code inserted will be outputted as text and not as a table!)
5. Constants and search-words - if set - will be highlighted or inserted.
(This feature will mark up any found search words on the pages if the page is linked to from a search result page.)
6. And finally the result of this processing may be wrapped in <font> -tags, <p> -tags or whatever is configured. This depends on whether a stylesheet is used or not. If a stylesheet is
used the individual sections between the typotags are usually wrapped separately.
Now lets see how this behaviour challenges the use of the RTE. This describes how the situation is handled regarding the two Text-types as mentioned above. (Numbers refer to the
previous bulletlist):
1. Line breaks: The RTE removes all line breaks and makes line breaks itself by either inserting a <P>...</P> section or <DIV>...</DIV> . This means well have to convert existing
lines to <P>...</P> before passing the content to the RTE and further we need to revert the <DIV> and <P> sections in addition to the <BR> -tagsto line breaks when the content
is returned to the database from the RTE.
The greatest challenge here is however what to do if a <DIV> or <P> tag has parameters like class or align. In that case we cant just discard the tag. So the tag is preserved.
2. The substitution of http:// and mailto: does not represent any problems here.
3. Typotags: The typotags are not real HTML tags so they would be removed by the RTE. Therefore those tags must be converted into something else. This is actually an opportunity and
the solution to the problem is that all <LINK> -tags are converted into regular <A> -tags, all <TYPOLIST> tags are converted into <OL> or <UL> sections (ordered/unordered lists,
type depends on the type set for the <TYPOLIST> tag!), <TYPOHEAD> -tags are converted to <Hx> tags where the number is determined by the type-parameter set for the
<TYPOHEAD> -tag. The align/class-parameter - if set - is also preserved. When the HTML- tags are returned to the database they need to be reverted to the specific typotags.
Other typotags (non-standard) can be preserved by being converted to a <SPAN> -section and back. This must be configured through Page TSconfig.
(Update: With css_styled_content and the transformation ts_css only the <link> typotag is le . The <typolist> and <typohead> tags are obsolete and regular HTML is used
instead)
4. Allowed tags: As not all tags are allowed in the display on the webpage, the RTE should also reflect this situation. The greatest problem is tables which are (currently) not allowed with
the Text- types. The reason for this goes back to the philosophy that the field content should be human readable and tables are not very readable.
(Update: With css_styled_content and the transformation ts_css tables are allowed)
5. Constants and search words are no problem.
133 of 145
3/17/2016 5:01 AM
6. Global wrapping does not represent a problem either. But this issue is related more closely to the line break-issue in bullet 1.
Finally images inserted are processed very intelligently because the magic type images are automatically post-processed to the correct size and proportions a er being changed by the
RTE in size.
Also if images are inserted by a copy/paste operation from another website, the image inserted will be automatically transferred to the server when saved.
In addition all URLs for images and links are inserted as absolute URLs and must be converted to relative URLs if they are within the current domain.
These actions are done by so called transformations which are configured in the $TCA . Basically these transformations are admittedly very customized to the default behavior of the
TYPO3 frontend. And they are by nature fragile constructions because the content is transformed back and forth for each interaction between the RTE and the database and may so be
erroneously processed. However they serve to keep the content stored in the database clean and human readable so it may continuously be edited by non-RTE browsers and users. And
furthermore it allows us to insert TYPO3-bulletlists and headers (especially graphical headers) visually by the editor while still having TYPO3 controlling the output.
Index
[0019] :ref:`start`
References
[0026] :ref:`next-steps`
Sitemap
[0023] :ref:`sitemap`
Targets
[0019] :ref:`... <targets-for-crossreferencing>`
[0020] :ref:`... <labels-for-crossreferencing>`
ApiOverview/Index
[0021] :ref:àpi-overview`
ApiOverview/Autoloading/Index
[0021] :ref:àutoload`
[0045] :ref:àutoload-autoloader`
[0071] :ref:àutoload-examples`
[0080] :ref:àutoload-examples-extbase`
[0107] :ref:àutoload-examples-no-conventions`
ApiOverview/BackendUserObject/Index
[0029] :ref:`be-user`
[0044] :ref:`be-user-check`
[0054] :ref:`be-user-access-current`
[0067] :ref:`be-user-access-any`
[0080] :ref:`be-user-access-tables`
[0102] :ref:`be-user-admin`
[0113] :ref:`be-user-page`
[0129] :ref:`be-user-mount`
[0141] :ref:`be-user-pageperms`
[0159] :ref:`be-user-module-save`
[0171] :ref:`be-user-module-get`
[0182] :ref:`be-user-tsconfig`
[0193] :ref:`be-user-name`
[0204] :ref:`be-user-configuration`
ApiOverview/Bootstrapping/Index
134 of 145
[0029] :ref:`bootstrapping`
[0095] :ref:`bootstrapping-context`
[0135] :ref:`bootstrapping-context-custom`
[0165] :ref:`bootstrapping-context-example`
3/17/2016 5:01 AM
ApiOverview/Categories/Index
[0029] :ref:`categories`
[0042] :ref:`categories-using`
[0048] :ref:`categories-managing`
[0066] :ref:`categories-activating`
[0140] :ref:`categories-flexforms`
[0186] :ref:`categories-api`
[0200] :ref:`categories-collections`
[0244] :ref:`categories-typoscript`
ApiOverview/Collections/Index
[0029] :ref:`collections`
[0039] :ref:`collections-records`
[0066] :ref:`collections-files`
[0093] :ref:`collections-api`
[0127] :ref:`collections-example`
ApiOverview/Examples/Index
[0029] :ref:èxamples`
[0043] :ref:èxamples-debug`
[0079] :ref:èxamples-examples`
ApiOverview/Examples/Clipboard/Index
[0025] :ref:èxamples-clipboard`
[0092] :ref:èxamples-clipboard-put`
ApiOverview/Examples/ContentElementWizard/Index
[0025] :ref:`content-element-wizard`
ApiOverview/Examples/ContextualMenu/Index
[0025] :ref:`csm`
[0036] :ref:`csm-adding`
[0145] :ref:`csm-implementation`
ApiOverview/Examples/CustomPermissions/Index
[0025] :ref:`custom-permissions`
[0038] :ref:`custom-permissions-registration`
[0079] :ref:`custom-permissions-evaluation`
[0099] :ref:`custom-permissions-keys`
ApiOverview/Examples/EditLinks/Index
[0025] :ref:èdit-links`
[0093] :ref:èdit-links-edit`
[0114] :ref:èdit-links-edit-restricted`
[0131] :ref:èdit-links-new`
ApiOverview/Examples/PageTrees/Index
[0025] :ref:èxamples-page-tree`
ApiOverview/Examples/ParsingHtml/Index
[0025] :ref:`parsing-html`
[0035] :ref:`parsing-html-extraction-blocks`
[0093] :ref:`parsing-html-extraction-single`
[0114] :ref:`parsing-html-cleanup`
[0174] :ref:`parsing-html-advanced`
ApiOverview/Examples/TablesInPageModule/Index
[0025] :ref:`page-module-tables`
ApiOverview/FlashMessages/Index
135 of 145
[0022] :ref:`flash-messages`
3/17/2016 5:01 AM
[0055] :ref:`flash-messages-api`
[0124] :ref:`flash-messages-extbase`
[0161] :ref:`flash-messages-javascript`
ApiOverview/FormProtection/Index
[0029] :ref:`csrf`
[0038] :ref:`csrf-backend`
[0099] :ref:`csrf-install`
ApiOverview/GlobalValues/Index
[0029] :ref:`globals`
ApiOverview/GlobalValues/Constants/Index
[0025] :ref:`globals-constants`
ApiOverview/GlobalValues/GlobalVariables/Index
[0029] :ref:`globals-variables`
[0257] :ref:`globals-exploring`
ApiOverview/Hooks/Index
[0029] :ref:`hooks`
ApiOverview/Hooks/Concept/Index
[0029] :ref:`hooks-concept`
[0040] :ref:`hooks-xclass`
[0054] :ref:`hooks-proposing`
[0064] :ref:`hooks-basics`
ApiOverview/Hooks/Configuration/Index
[0026] :ref:`hooks-configuration`
[0043] :ref:`hooks-extensions`
[0091] :ref:`hooks-core`
[0172] :ref:`hooks-modules`
ApiOverview/Hooks/Creation/Index
[0029] :ref:`hooks-creation`
[0063] :ref:`hooks-creation-object`
[0079] :ref:`hooks-creation-function`
ApiOverview/Http/Index
[0029] :ref:`http`
[0040] :ref:`http-basic`
[0060] :ref:`http-basic-example`
ApiOverview/Logging/Index
[0025] :ref:`logging`
[0040] :ref:`logging-quickstart`
ApiOverview/Logging/Configuration/Index
[0025] :ref:`logging-configuration`
[0053] :ref:`logging-configuration-writer`
[0116] :ref:`logging-configuration-processor`
ApiOverview/Logging/Logger/Index
[0025] :ref:`logging-logger`
[0031] :ref:`logging-logger-instantiation`
[0050] :ref:`logging-logger-log`
[0111] :ref:`logging-logger-shortcuts`
ApiOverview/Logging/Model/Index
[0025] :ref:`logging-model`
ApiOverview/Logging/Processors/Index
136 of 145
[0025] :ref:`logging-processors`
3/17/2016 5:01 AM
[0039] :ref:`logging-processors-builtin`
[0049] :ref:`logging-processors-introspection`
[0077] :ref:`logging-processors-memory`
[0097] :ref:`logging-processors-memory-peak`
[0117] :ref:`logging-processors-web`
[0126] :ref:`logging-processors-custom`
ApiOverview/Logging/Writers/Index
[0025] :ref:`logging-writers`
[0037] :ref:`logging-writers-builtin`
[0047] :ref:`logging-writers-database`
[0069] :ref:`logging-writers-file`
[0090] :ref:`logging-writers-php`
[0099] :ref:`logging-writers-syslog`
[0117] :ref:`logging-writers-custom`
ApiOverview/Mail/Index
[0021] :ref:`mail`
[0032] :ref:`mail-configuration`
[0042] :ref:`mail-configuration-mail`
[0051] :ref:`mail-configuration-smtp`
[0083] :ref:`mail-configuration-sendmail`
[0102] :ref:`mail-configuration-mbox`
[0116] :ref:`mail-configuration-classname`
[0127] :ref:`mail-create`
[0176] :ref:`mail-attachments`
[0194] :ref:`mail-inline`
[0215] :ref:`mail-sender`
[0237] :ref:`mail-swi `
ApiOverview/MainClasses/Index
[0029] :ref:`main-classes`
ApiOverview/MainClasses/HighPriorityFunctions/Index
[0028] :ref:`high-priority-functions`
[0044] :ref:`high-priority-functions-general-utility`
[0346] :ref:`high-priority-functions-backend-utility`
[0515] :ref:`high-priority-functions-extension-management-utility`
[0584] :ref:`high-priority-functions-icon-utility`
[0628] :ref:`high-priority-functions-database-connection`
[0742] :ref:`high-priority-functions-beuser`
[0780] :ref:`coding-guidelines`
ApiOverview/MainClasses/UsefulFunctions/Index
[0029] :ref:ùseful-functions`
[0043] :ref:ùseful-general-utility`
[0352] :ref:ùseful-math-utility`
[0380] :ref:ùseful-backend-utility`
[0588] :ref:ùseful-extension-management-utility`
ApiOverview/Namespaces/Index
137 of 145
[0025] :ref:`namespaces`
[0055] :ref:`namespaces-example`
[0068] :ref:`namespaces-extensions`
[0115] :ref:`namespaces-extbase`
3/17/2016 5:01 AM
[0143] :ref:`namespaces-test`
[0160] :ref:`namespaces-instances`
[0176] :ref:`namespaces-references`
ApiOverview/SystemLog/Index
[0029] :ref:`syslog`
[0293] :ref:`syslog-simplified`
ApiOverview/SystemRegistry/Index
[0029] :ref:`registry`
[0056] :ref:`registry-table`
[0114] :ref:`registry-api`
[0191] :ref:`registry-examples`
ApiOverview/Typo3CoreEngine/Index
[0024] :ref:`tce`
ApiOverview/Typo3CoreEngine/Database/Index
[0029] :ref:`tce-database-basics`
[0051] :ref:`tce-commands`
[0110] :ref:`tce-command-keywords`
[0258] :ref:`tce-command-examples`
[0270] :ref:`tce-data`
[0336] :ref:`tce-data-examples`
[0386] :ref:`tce-clear-cache`
[0435] :ref:`tce-cache-hook`
[0448] :ref:`tce-flags`
ApiOverview/Typo3CoreEngine/Files/Index
[0029] :ref:`file-functions`
[0041] :ref:`tce-files-array`
[0102] :ref:`tce-file-keywords`
[0262] :ref:`tce-file-extensions-control`
ApiOverview/Typo3CoreEngine/Introduction/Index
[0024] :ref:`tce-introduction`
[0030] :ref:`tce-database`
[0059] :ref:`tce-files`
ApiOverview/Typo3CoreEngine/TceDb/Index
[0029] :ref:`tce-db-api`
ApiOverview/Typo3CoreEngine/TceFile/Index
[0025] :ref:`tce-file-api`
ApiOverview/Typo3CoreEngine/UsingTcemain/Index
[0029] :ref:ùsing-tcemain`
[0050] :ref:`tcemain-examples`
[0055] :ref:`tcemain-submit-data`
[0076] :ref:`tcemain-execute-commands`
[0096] :ref:`tcemain-clear-cache`
[0122] :ref:`tcemain-complex-submission`
[0172] :ref:`tcemain-data-command-user`
ApiOverview/Workspaces/Index
138 of 145
[0029] :ref:`workspaces`
[0053] :ref:`workspaces-frontend`
[0091] :ref:`workspaces-frontend-summary`
[0105] :ref:`workspaces-frontend-guidelines`
[0189] :ref:`workspaces-frontend-problems`
3/17/2016 5:01 AM
[0236] :ref:`workspaces-backend`
[0250] :ref:`workspaces-backend-api`
[0398] :ref:`workspaces-backend-acess`
[0414] :ref:`workspaces-detection`
[0428] :ref:`workspaces-tcemain`
[0443] :ref:`workspaces-moving`
ApiOverview/Xclasses/Index
[0029] :ref:`xclasses`
[0035] :ref:`xclasses-intro`
[0053] :ref:`xclasses-mechanism`
[0066] :ref:`xclasses-limitations`
[0087] :ref:`xclasses-declaration`
[0121] :ref:`xclasses-coding`
Appendices/Index
[0024] :ref:àppendices`
Appendices/AppendixA/Index
[0025] :ref:àppendix-a`
Appendices/AppendixA/PropertiesAndTransformations/Index
[0025] :ref:àppendix-a-properties`
Appendices/AppendixA/RteTransformationsInContentElements/Index
[0025] :ref:àppendix-a-content-elements`
[0163] :ref:àppendix-a-content-elements-conclusion`
CachingFramework/Index
[0026] :ref:`caching`
CachingFramework/Architecture/Index
[0026] :ref:`caching-architecture`
[0032] :ref:`caching-architecture-base`
[0054] :ref:`caching-architecture-identifier`
[0096] :ref:`caching-architecture-tags`
[0126] :ref:`caching-architecture-core`
[0239] :ref:`caching-architecture-task`
[0251] :ref:`caching-architecture-api`
CachingFramework/Configuration/Index
[0026] :ref:`caching-configuration`
[0039] :ref:`caching-configuration-cache`
[0082] :ref:`caching-disable`
CachingFramework/Developer/Index
[0026] :ref:`caching-developer`
[0039] :ref:`caching-developer-usage`
[0090] :ref:`caching-developer-access`
CachingFramework/FrontendsBackends/Index
139 of 145
[0026] :ref:`caching-frontend`
[0032] :ref:`caching-frontend-api`
[0107] :ref:`caching-frontend-avalaible`
[0116] :ref:`caching-frontend-string`
[0124] :ref:`caching-frontend-variable`
[0144] :ref:`caching-frontend-php`
[0166] :ref:`caching-backend`
[0254] :ref:`caching-backend-options`
[0280] :ref:`caching-backend-db`
3/17/2016 5:01 AM
[0314] :ref:`caching-backend-db-innodb`
[0327] :ref:`caching-backend-db-options`
[0370] :ref:`caching-backend-memcached`
[0382] :ref:`caching-backend-memcache-warning`
[0430] :ref:`caching-backend-memcache-options`
[0476] :ref:`caching-backend-redis`
[0519] :ref:`caching-backend-redis-options`
[0613] :ref:`caching-backend-apc`
[0646] :ref:`caching-backend-xcache`
[0667] :ref:`caching-backend-wincache`
[0679] :ref:`caching-backend-file`
[0712] :ref:`caching-backend-file-options`
[0740] :ref:`caching-backend-simple-file`
[0752] :ref:`caching-backend-pdo`
[0769] :ref:`caching-backend-pdo-options`
[0818] :ref:`caching-backend-transient`
[0833] :ref:`caching-backend-null`
CachingFramework/QuickStart/Index
[0026] :ref:`caching-quickstart`
[0035] :ref:`caching-quickstart-tuning`
[0070] :ref:`caching-quickstart-garbage`
DataFormats/T3datastructure/Index
[0025] :ref:`t3ds`
DataFormats/T3datastructure/Elements/Index
[0025] :ref:`t3ds-elements`
[0033] :ref:`t3ds-elements-array`
[0169] :ref:`t3ds-elements-value`
[0223] :ref:`t3ds-elements-example`
DataFormats/T3datastructure/Highlighting/Index
[0025] :ref:`t3ds-highlighting`
DataFormats/T3datastructure/Parsing/Index
[0025] :ref:`t3ds-parsing`
DataFormats/T3datastructure/SheetReferences/Index
[0025] :ref:`t3ds-sheet-references`
[0036] :ref:`t3ds-sheet-references-example`
DataFormats/T3locallang/Index
[0025] :ref:`locallang`
DataFormats/T3locallang/Elements/Index
[0025] :ref:`locallang-elements`
[0033] :ref:`locallang-elements-nesting`
[0151] :ref:`locallang-elements-value`
[0269] :ref:`locallang-ext`
[0325] :ref:`locallang-example-backend`
[0364] :ref:`locallang-example-csh`
ErrorAndExceptionHandling/Index
[0025] :ref:èrror-handling`
ErrorAndExceptionHandling/Configuration/Index
[0025] :ref:èrror-handling-configuration`
ErrorAndExceptionHandling/Configuration/DebugExceptionHandler/Index
140 of 145
[0025] :ref:èrror-handling-debug-exception-handler`
3/17/2016 5:01 AM
ErrorAndExceptionHandling/Configuration/ErrorHandler/Index
[0025] :ref:èrror-handling-error-handler`
ErrorAndExceptionHandling/Configuration/Examples/Index
[0025] :ref:èrror-handling-configuration-examples`
[0030] :ref:èrror-handling-configuration-examples-debug`
[0062] :ref:èrror-handling-configuration-examples-production`
[0092] :ref:èrror-handling-configuration-examples-performance`
ErrorAndExceptionHandling/Configuration/Extending/Index
[0025] :ref:èrror-handling-extending`
ErrorAndExceptionHandling/Configuration/ProductionExceptionHandler/Index
[0025] :ref:èrror-handling-production-exception-handler`
ErrorAndExceptionHandling/Screenshots/Index
[0025] :ref:èrror-handling-screenshots`
ExtensionArchitecture/Index
[0025] :ref:èxtension-architecture`
[0031] :ref:èxtension-architecture-introduction`
[0067] :ref:èxtensions-and-core`
ExtensionArchitecture/ConfigurationFiles/Index
[0025] :ref:èxtension-configuration-files`
ExtensionArchitecture/ConfigurationOptions/Index
[0025] :ref:èxtension-options`
ExtensionArchitecture/CreateNewDistribution/Index
[0025] :ref:`distribution`
[0058] :ref:`distribution-kickstart`
[0073] :ref:`distribution-kickstart-image`
[0085] :ref:`distribution-kickstart-fileadmin`
[0100] :ref:`distribution-kickstart-database`
[0114] :ref:`distribution-kickstart-configuration`
[0127] :ref:`distribution-kickstart-custom-dependencies`
[0150] :ref:`distribution-testing`
[0168] :ref:`distribution-more-information`
ExtensionArchitecture/CreateNewExtension/Index
[0025] :ref:èxtension-create-new`
ExtensionArchitecture/DeclarationFile/Index
[0025] :ref:èxtension-declaration`
ExtensionArchitecture/Documentation/Index
[0024] :ref:èxtension-documentation`
[0041] :ref:èxtension-documentation-sphinx`
[0076] :ref:èxtension-documentation-readme`
[0090] :ref:èxtension-documentation-openoice`
ExtensionArchitecture/ExtensionKey/Index
[0025] :ref:èxtension-key`
[0073] :ref:èxtension-license`
[0093] :ref:èxtensions-security`
[0110] :ref:èxtension-key-registration`
ExtensionArchitecture/ExtensionManager/Index
[0025] :ref:èxtension-manager`
ExtensionArchitecture/FilesAndLocations/Index
141 of 145
[0025] :ref:èxtension-files-locations`
[0031] :ref:èxtension-files`
3/17/2016 5:01 AM
[0047] :ref:èxtension-reserved-filenames`
[0277] :ref:èxtension-reserved-folders`
[0347] :ref:èxtension-reserved-folders-legacy`
ExtensionArchitecture/Installation/Index
[0025] :ref:èxtension-install`
ExtensionArchitecture/NamingConventions/Index
[0025] :ref:èxtension-naming`
[0106] :ref:èxtension-old-extensions`
[0120] :ref:èxtension-extending`
ExtensionArchitecture/Resources/Index
[0025] :ref:èxtension-resources`
ExtensionArchitecture/SystemGlobalAndLocalExtensions/Index
[0025] :ref:èxtension-scope`
[0040] :ref:èxtension-local`
[0061] :ref:èxtension-global`
[0076] :ref:èxtension-system`
[0087] :ref:èxtension-loading-precedence`
Internationalization/Index
[0025] :ref:ìnternationalization`
Internationalization/Introduction/Index
[0025] :ref:`xli`
[0049] :ref:`xli-basics`
[0105] :ref:`xli-files`
Internationalization/Migration/Index
[0025] :ref:`xli-migration`
[0041] :ref:`xli-compatibility`
Internationalization/Translation/Index
[0025] :ref:`xli-translating`
[0033] :ref:`xli-translating-server`
[0048] :ref:`xli-translating-local`
[0066] :ref:`xli-translating-custom`
[0128] :ref:`xli-translating-languages`
[0188] :ref:`xli-translating-servers`
Introduction/Index
[0028] :ref:ìntroduction`
[0034] :ref:òverview`
[0063] :ref:`what-s-new`
[0100] :ref:`code-examples`
[0116] :ref:`feedback`
[0136] :ref:`credits`
[0145] :ref:`dedication`
JavaScript/Index
[0028] :ref:`javascript`
JavaScript/Ajax/Index
[0028] :ref:àjax`
JavaScript/Ajax/Backend/Index
142 of 145
[0029] :ref:àjax-backend`
[0044] :ref:àjax-backend-id`
[0079] :ref:àjax-backend-server`
[0131] :ref:àjax-backend-client`
3/17/2016 5:01 AM
JavaScript/Ajax/Presentation/Index
[0029] :ref:àjax-presentation`
[0035] :ref:àjax-client`
[0069] :ref:àjax-server`
[0103] :ref:àjax-formats`
[0127] :ref:àjax-formats-plain`
[0139] :ref:àjax-formats-xml`
[0148] :ref:àjax-formats-json`
JavaScript/UsingExtjs/Index
[0028] :ref:èxtjs`
JavaScript/UsingExtjs/ExtDirect/Index
[0029] :ref:èxtdirect`
[0034] :ref:èxtdirect-intro`
[0073] :ref:èxtdirect-how-to`
[0144] :ref:èxtdirect-debugging`
[0156] :ref:èxtdirect-api-generator`
JavaScript/UsingExtjs/Loading/Index
[0029] :ref:èxtjs-loading`
JavaScript/UsingExtjs/PageTree/Index
[0028] :ref:`pagetree`
[0056] :ref:`context-menu`
[0070] :ref:`context-menu-configuration`
[0148] :ref:`context-menu-custom`
[0166] :ref:`context-menu-custom-configuration`
[0267] :ref:`context-menu-custom-action`
[0320] :ref:`context-menu-custom-extdirect`
[0351] :ref:`context-menu-custom-callbacks`
[0375] :ref:`context-menu-diagram`
JavaScript/UsingExtjs/Viewport/Index
[0025] :ref:`viewport`
[0040] :ref:`viewport-structure`
[0060] :ref:`viewport-navigation`
[0141] :ref:`viewport-global-navigation`
[0157] :ref:`viewport-loading`
[0171] :ref:`viewport-extending`
[0208] :ref:`viewport-debug`
PageTypes/Index
[0025] :ref:`page-types`
[0109] :ref:`page-types-example`
Rte/Index
[0025] :ref:`rte`
Rte/InTheBackend/Index
[0025] :ref:`rte-backend`
[0031] :ref:`rte-backend-introduction`
Rte/InTheBackend/PlugRte/Index
[0025] :ref:`rte-plug`
[0048] :ref:`rte-api`
Rte/Transformations/Index
[0025] :ref:`transformations`
Rte/Transformations/CustomApi/Index
143 of 145
3/17/2016 5:01 AM
[0025] :ref:`transformations-custom`
[0037] :ref:`transformations-custom-key`
[0053] :ref:`transformations-custom-key-registration`
[0079] :ref:`transformations-custom-code`
[0162] :ref:`transformations-custom-usage`
Rte/Transformations/Introduction/Index
[0025] :ref:`transformations-introduction`
[0054] :ref:`transformations-hybrid-modes`
[0075] :ref:`transformations-hybrid-modes-db`
[0108] :ref:`transformations-hybrid-modes-rte`
[0132] :ref:`transformations-configuration`
[0144] :ref:`transformations-where`
Rte/Transformations/Overview/Index
[0025] :ref:`transformations-overview`
[0037] :ref:`transformations-overview-filters`
[0125] :ref:`transformations-overview-meta`
Rte/Transformations/Process/Index
[0025] :ref:`transformations-process`
[0039] :ref:`transformations-process-step1`
[0108] :ref:`transformations-process-examples`
Rte/Transformations/Tsconfig/Index
144 of 145
[0025] :ref:`transformations-tsconfig`
[0086] :ref:`transformations-tsconfig-examples`
[0112] :ref:`transformations-tsconfig-configuration`
[0123] :ref:`transformations-tsconfig-configuration-disabled`
[0143] :ref:`transformations-tsconfig-configuration-proc`
[0168] :ref:`transformations-tsconfig-configuration-specific`
[0186] :ref:`transformations-tsconfig-processing`
[0208] :ref:`transformations-tsconfig-processing-overrulemode`
[0230] :ref:`transformations-tsconfig-processing-preservetags`
[0268] :ref:`transformations-tsconfig-processing-dontconvbrtoparagraph`
[0292] :ref:`transformations-tsconfig-processing-allowtagsoutside`
[0321] :ref:`transformations-tsconfig-processing-allowtags`
[0348] :ref:`transformations-tsconfig-processing-denytags`
[0369] :ref:`transformations-tsconfig-processing-blockelementlist`
[0389] :ref:`transformations-tsconfig-processing-transformboldanditalictags`
[0414] :ref:`transformations-tsconfig-processing-htmlparser`
[0588] :ref:`transformations-tsconfig-processing-allowedfontcolors`
[0612] :ref:`transformations-tsconfig-processing-allowedclasses`
[0671] :ref:`transformations-tsconfig-processing-keeppdivattribs`
[0693] :ref:`transformations-tsconfig-processing-remapparagraphtag`
[0721] :ref:`transformations-tsconfig-processing-usedivasparagraphtagforrte`
[0744] :ref:`transformations-tsconfig-processing-preservedivsections`
[0765] :ref:`transformations-tsconfig-processing-preservetables`
3/17/2016 5:01 AM
[0785] :ref:`transformations-tsconfig-processing-dontfetchextpictures`
[0807] :ref:`transformations-tsconfig-processing-plainimagemode`
[0878] :ref:`transformations-tsconfig-processing-disableunifylinebreaks`
[0902] :ref:`transformations-tsconfig-processing-user`
UserSettingsConfiguration/Index
[0025] :ref:ùser-settings`
[0036] :ref:ùser-settings-reference`
UserSettingsConfiguration/Checking/Index
[0025] :ref:ùser-settings-checking`
UserSettingsConfiguration/Columns/Index
[0025] :ref:ùser-settings-columns`
UserSettingsConfiguration/Ctrl/Index
[0025] :ref:ùser-settings-ctrl`
UserSettingsConfiguration/Extending/Index
[0025] :ref:ùser-settings-extending`
UserSettingsConfiguration/Showitem/Index
[0025] :ref:ùser-settings-showitem`
Summary: 432 targets (430 with link text, 2 without).
145 of 145
3/17/2016 5:01 AM

Typo3 Core API

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Typo3 Core API

Загружено:

Авторское право:

Доступные форматы

TYPO3 Core APIs latest documentation

Docs TYPO3 Core APIs latest documentation

Previous Key: doc_core_api

tsref, typoscript, reference, forDevelopers, forAdvanced

Open Publication License available from www.opencontent.org/openpub/

This version is updated for TYPO3 CMS 6.2.

TYPO3 Core APIs latest documentation

usage of flash messages in Extbase has changed.

An extension consists of:

TYPO3 Core APIs latest documentation

TYPO3 Core APIs latest documentation

18x16 GIF, PNG or SVG icon for the extension.

Local Update tool class

TYPO3 Core APIs latest documentation

Typical folder for a frontend plugin class.

Typical folder for a backend module.

Typical folder for a service.

Local extensions are located in the typo3conf/ext/ directory.

Global extensions are located in the typo3/ext/ directory.

System extensions are located in the typo3/sysext/ directory.

TYPO3 Core APIs latest documentation

Assigned by the TYPO3 Extension Repository.

Determined by yourself, but prefixed user_

TYPO3 Core APIs latest documentation

Prefix with tx_[ key ]_ where key is without underscores!

Name: No underscores, prefixed u

(Names are always without underscores!)

TYPO3 Core APIs latest documentation

$TYPO3_LOADED_EXT[extension key] = array(

The name of the extension in English.

Miscellaneous stu (Where not easily placed elsewhere)

TYPO3 Core APIs latest documentation

'constraints' => array(

If set, then the folder named uploads/tx_[extKey-with-no- underscore] should be present!

Comma list of directories to create upon extension installation.

Author name (Use a-z)

Author email address

Author company (if any company sponsors the extension).

Not supported anymore

TYPO3 Core APIs latest documentation

TYPO3 Core APIs latest documentation

TYPO3 Core APIs latest documentation

TYPO3 Core APIs latest documentation

Create the following folder structure inside your extension:

TYPO3 Core APIs latest documentation

An example manual is available in the TYPO3 Git repository.

The source is the documentation! (General wisdom)

The good old t3lib_div class has been renamed to:

TYPO3 Core APIs latest documentation

Inside the class, the namespace is declared as:

For a frontend module:

TYPO3 Core APIs latest documentation

Consider the following:

TYPO3 Core APIs latest documentation

$extensionClassesPath = \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('news') . 'Classes/';

# run the TYPO3 CMS CLI commands in development context

TYPO3 Core APIs latest documentation

or be part of the web server configuration:

In certain situations, more specific contexts are desirable:

TYPO3 Core APIs latest documentation

// Making an instance of class "\\TYPO3\\CMS\\Core\\TypoScript\\Parser\\TypoScriptParser":

TYPO3 Core APIs latest documentation

Evaluate files and directories for security reasons

// Getting absolute path of a temporary file