This document describes the global array called $GLOBALS['TCA'] . This
array is a layer on top of the database tables that TYPO3 can operate on. It is a
very central element of the TYPO3 architecture.
Almost all code examples used in this manual come either from the TYPO3
source code itself, from the extension examples,
or from extension styleguide. Extension styleguide comes with
a huge list of TCA examples and field combinations. Installing it locally in some test environment is a good
idea since the extension is great as a "show-off" on what can be done with TCA. Even experienced developers
will find things they did not know before.
What is $GLOBALS['TCA']?
The Table Configuration Array (or $GLOBALS['TCA'], TCA) is a global array in TYPO3
which extends the definition of database tables beyond what can be done strictly with SQL.
First and foremost $GLOBALS['TCA'] defines which tables are editable in the TYPO3 backend.
Database tables with no corresponding entry in $GLOBALS['TCA'] are "invisible" to the TYPO3 backend.
The $GLOBALS['TCA'] definition of a table also covers the following:
Relations between that table and other tables
What fields should be displayed in the backend and with which layout
How should a field be validated (e.g. required, integer, etc.)
How a field is used in the frontend by Extbase and any extension that may refer to this information
TCA can be seen as the glue between the DataHandler which takes care of persisting data into
the database, and the FormEngine which renders table rows in the Backend. TCA tells both of
these main core constructs how they should behave for specific tables, fields and relations. Additionally, some
parts of the Frontend rendering process also utilize TCA information, for instance the extbase MVC relies on it.
This array is highly extendable using extensions. Extensions can add fields
to existing tables and add new tables. Several required extensions that are
always loaded, already deliver some TCA files in their
Configuration/TCA directories.
Most importantly, the extension "core" comes with a definition of pages,
be_users and further tables needed by the whole system.
The extension "frontend" comes with the tables tt_content, fe_users, sys_template and more.
See the directories typo3/sysext/core/Configuration/TCA/ and
typo3/sysext/frontend/Configuration/TCA/ for the complete list of the TYPO3 CMS tables.
The TCA definition of a new table with the name "database-table-name" must be done in the
extension directory Configuration/TCA/ with database-table-name.php as filename.
An example is EXT:sys_note/Configuration/TCA/sys_note.php for table "sys_note". This file will be
found by the bootstrap code (if starting a TYPO3 request). It must return an
array with the content of the TCA setting or NULL if the table
should not be defined (depending on the extension's internal logic).
The return value of any loaded file will be cached, so there must either be no dynamic PHP code in it or
care must be taken to clear the system cache after each change in such files.
See the t3api docs for more information on how extensions can add and change TCA.
The TYPO3 core bootstrap compiles the final TCA on first call by loading all files from the
different locations, and caches the result. On subsequent calls this relatively huge array is then rather quickly loaded
from cache and is made available as $GLOBALS['TCA'] in almost all normal access patterns like Frontend, Backend and CLI requests.
TCA main array structure
Table entries (first level)
The "first level" of the $GLOBALS['TCA'] array is made of the table names (as
they appear in the database):
Here three tables, pages, tt_content and tx_examples_haiku are shown as examples.
Inside tables (second level)
Each table is further defined by an array which configures how the
system handles the table, both for the display and the processing in the
backend. The various parts on this second level are called "sections".
The general structure (looking at a single table) is as follows:
The following table provides a brief description of the various
sections of $GLOBALS['TCA']['some_table'] . Each section is covered in more details in its own
chapter.
['ctrl'] The table
The "ctrl" section contains properties for the table in general.
These are basically divided in two main categories:
properties which affect how the table is displayed and handled in
the backend interface . This includes which icon, what name, which
columns contains the title value, which column defines the type value
etc.
properties which determine how it is processed by the system
(TCE). This includes publishing control, "deleted" flag, whether the table
can only be edited by admin-users, may only exist in the tree root
etc.
For all tables configured in $GLOBALS['TCA'] this section must exist.
The "columns" section contains configuration for each table field
(also called "column") which can be edited in the backend.
The configuration includes both properties for the display in the
backend as well as the processing of the submitted data.
Each field can be configured as a certain "type" (e.g. checkbox,
selector, input field, text area, file or db-relation field, user
defined etc.) and for each type a separate set of additional
properties applies. These properties are clearly explained for each
type.
The "types" section defines how the fields in the table (configured in
the "columns" section) should be arranged inside the editing form; in
which order, with which "palettes" (see below) and with which possible
additional features applied.
All properties on the second level either have their own properties or
contain a further hierarchy.
In the case of the [columns] section, this will be the fields
themselves. For the [types] and [palettes] section this will be the list
of all possible types and palettes.
Properties scope
In the detail reference one or more scopes are given for each
property. They indicate which area is affected by a given
property. The various scopes are explained below:
Display
A "display" property will only affect the backend forms themselves.
They have no impact on the values, nor on the database.
Proc.
This stands for "processing". Such properties have an impact
on the values entered (for example, filtering them) or how they
are written to the database (for example, dates transformed to
time stamps).
Database
Such a property influences only the data type with regards
to the database structure (for example, dates kept as
datetime fields).
Search
Search properties are related to the general search feature
provided by the TYPO3 backend.
Because some things never fit in precise categories, there may be
properties with a special scope. The meaning will be explained in
the description of the property itself.
Glossary
Before you read on, let's just refresh the meaning of a few concepts
mentioned on the next pages:
TCE
Short for TYPO3 Core Engine. Also referred to as "DataHandler".
The corresponding class
\TYPO3\CMS\Core\DataHandling\DataHandler
should ideally handle all updates to records made in the backend of TYPO3. The class will handle all the
rules which may be applied to each table correctly. It will also handle logging, versioning, history and undo features,
and copying, moving, deleting etc.
"list of"
Typically used like "list of field names". Whenever
"list of" is used it means a list of strings separated by comma and
with NO space between the values.
field name
The name of a field from a database table. Another
word for the same is "column" but it is used more rarely, however the
meaning is exactly the same.
record type
A record can have different types, determined by the
value of a certain field in the record. This field is defined by the
type property of the [ctrl] section.
It affects which fields are displayed in backend form
(see the "types" configuration).
The record type can be considered as a switch in the interpretation
of the whole record.
LLL reference
A localized string fetched from a locallang file
by prefixing the string with LLL:.
Many of the examples are part of the TYPO3 extension styleguide. This
extension offers numbered examples for any field type. Furthermore there
are examples with different properties set to different values.
Some examples can also be found in the TYPO3 extension examples. This
extension contains special configurations that have not been used in the
extension stylguide nor in the TYPO3 Core.
The extension examples can be installed via composer:
Some examples are taken from the TYPO3 Core and some come from
different system extensions. You can open their TCA definitions in the
corresponding file in the system extension.
Common examples are taken from the following tables:
Go to the Help menu (?) > Styleguide. In the styleguide
choose tab TCA / Records and then the button
Create styleguide page tree with data. After you are done
you can delete the example page tree by clicking the other button
Delete styleguide page tree and all styleguide data records
Have a look at the examples
Navigate to the new page tree called styleguide TCA demo, using
the List module. Choose a page, for example
elements basic, and open the English record. The records in the
other languages can be used to see examples of localization and the relation
between languages.
Hint
If you turn on the backend debugging you can see the names of all fields as
used in the database. Furthermore, in fields that hide the real database
value (such as checkboxes) you can see the value hidden behind the label.
To activate backend debugging go to: Admin Tools > Settings
> Configuration Presets > Debug Settings > BE/debug.
Find the corresponding TCA definition
All TCA examples are called after their type and then numbered. The tables
carry the same name as the entry in the page tree, prefixed with
tx_styleguide_ therefore you would find the examples from elements_basic at:
public/typo3conf/ext/styleguide/Configuration/TCA/tx_styleguide_elements_basic.php.
Open the file with an editor of your choice. Then search for the name of the
field, in this example checkbox_9. You can then have a look at the TCA
definition in a working example.
Best practices
Some configuration settings are applied to almost all tables in TYPO3. See the following
sections about best practises and conventions.
If the table has a TCA definition, TYPO3 will automatically create the following fields:
uid
An auto-incrementing unique identifier. This field is used as table key
and as a reference in relationships between records.
pid
The uid field of the parent page. The record is situated on this page.
If this value is 0 the record is not connected to any page.
There is no separate TCA definition of these fields in the TCA configuration. It is
not possible to use other names for these fields.
Fields used by convention
Warning
It is possible to change the names of the following fields, however this is
strongly discouraged as it breaks convention and may lead to compatibility
issues with third party extensions.
All fields mentioned below get added to the database automatically. It is
not recommended to define them in the ext_tables.sql. Doing so
with incompatible SQL settings can lead to problems later on.
Soft delete
deleted
This field is used to enable soft delete in records. In can be configured
by setting ctrl->delete:
If no deleted field is configured, records will be hard deleted.
The DataHandler in the backend and Extbase will automatically execute
DELETE statements.
The deleted field is never directly visible in backend forms. It is
handled separately by the DataHandler. Therefore it
needs no definition in the columns section.
These enable fields are only respected in the frontend if you
use proper queries or Extbase repository settings in your extensions code.
See Enablecolumns / enablefields usage for more information.
Manual sorting in the backend
sorting
This field is used to manually sort records in the backend. In can be configured
by ctrl->sortby:
The sortby field contains an integer and is managed by the DataHandler. It
therefore should have no definition in the Field definitions (columns) section. Any value in this
field can be changed at any time by the DataHandler.
Use default_sortby if you want to
sort by an existing field of the domain instead.
Fields managed by the DataHandler
The following fields are automatically set when a record is written by the
DataHandler. They should never be
displayed in backend forms or explicitly set, therefore they need no entry in
the Field definitions (columns) section of the TCA.
It is possible to change the names of the following fields, however this is
strongly discouraged as it breaks convention and may lead to compatibility
issues with third party extensions.
All columns mentioned below get auto-created
in the TCA and added to the database automatically. It is
not recommended to define them in the TCA overrides or ext_tables.sql. Doing so
with incompatible settings can lead to problems later on.
Language fields in detail
sys_language_uid
This field gets defined in
ctrl->languageField. If this field is
defined a record in this table can be translated into another language.
If this value is found being set together with
languageField then
FormEngine will show the default translation value under the fields in
the main form.
Note
Sometimes l18n_parent is used for this field in Core tables. This
is for historic reasons.
This field contains the uid of the record the translation was created from.
For example if your default language is English and you already translated a
record into German you can base the Suisse-German translation on the German
record. In this case l10n_parent would contain the uid of the English
record while l10n_source contains the uid of the German record.
This
information is used later on to compare the current values of the default
record with those stored in this field. If they differ, there will
be a display in the form of the difference visually:
Note
Sometimes l18n_diffsource is used for this field in Core tables. This
has historic reasons.
Example: Enable table for localization and translation:
The ['columns'] section contains configuration for each table field (also called "column") which can
be edited or shown in the backend. This is typically the biggest part of a TCA definition.
The configuration includes both properties for the display in the backend as well as the processing of the
submitted data.
Each field can be configured as a certain "type" (required!), for instance a checkbox, an input field, or a
database relation selector box. Each type allows a set of additional "renderType"s (sometimes required!). Each "type" and "renderType" combination comes with a set of additional properties.
Properties on the level parallel to label
are valid for all "type" and "renderType" combinations.
They are listed below. The list of properties within the "config" section depend on the specific "type" and "renderType"
combination and are explained in detail in the ['columns']['config'] section.
For some type definitions there are additional
render types available that mainly influence rendering. For example
Select fields and
Text areas provide different render types.
The property can be used to display an additional help text between the field label and
the user input when editing records. As an example, the Core uses the description property
in the site configuration module when editing a site on some properties like identifier.
The property is available on all common TCA types like input and select and so on.
The field can be used with a string that will be directly output or with a
language reference.
If set, all backend users are prevented from editing the field unless they
are members of a backend user group with this field added as an
"Allowed Excludefield" (or "admin" user).
This option can be used to define the language related field
rendering. This has nothing to do with the processing of language
overlays and data storage but the display of form fields.
Keywords are:
hideDiff
The differences to the default language field will not be displayed.
defaultAsReadonly
This renders the field as read only field with the content of the default
language record. The field will be rendered even if
l10n_mode is set to
'exclude'. While exclude defines the field not to be
translatable, this option activates the display of the default data.
The main relevance is when a record is localized by an API call in DataHandler that makes a copy of the default
language record. You can think of this process as copying all fields from the source record. By default, the given
value from the default language record is copied to the localization overlay and the field is editable in the
overlay record. This behaviour can be changed:
exclude
Field will not be shown in FormEngine if this record is a localization of the default language. Works basically
like a display condition. Internally, the field value of the default language record is copied over to the
field of the localized record. The DataHandler keeps the values of localized records in sync and actively copies
a changed value from the default language record into the localized overlays if changed.
You can force the field to be displayed as readonly (with default language value)
by setting "l10n_display" to defaultAsReadonly.
prefixLangTitle
The field value from the default language record gets copied when a localization overlay is created, but the
content is prefixed with the title of the target language. The field stays editable in the localized record.
It only works for field types like "text" and "input". The text will be prepended and can be configured by
the page TSconfig property TCEMAIN.translateToMessage
If this property is not set for a given field, the value of the default language record is copied over to the
localized record on creation, the field value is then distinct from the default language record, can be edited
at will and will never be overwritten by the DataHandler if the value of the default language record changes.
If set to reload, it triggers a form reload once the value of this field
is changed. This is automatically set for fields specified as
record type in the control section.
A rule is a string divided into several parts by ":" (colons). The first part is
the rule-type and the subsequent parts depend on the rule type.
The following rules are available:
FIELD
This evaluates based on another field's value in the record.
Part 1 is the field name
Part 2 is the evaluation type. These are the possible options:
REQ
Requires the field to have a "true" value. False values are "" (blank string) and 0 (zero).
Everything else is true. For the REQ evaluation type Part 3 of the rules string must be the string "true"
or "false". If "true" then the rule returns "true" if the evaluation is true. If "false" then the rule
returns "true" if the evaluation is false.
> / < / >= / <=
Evaluates if the field value is greater than, less than the value in "Part 3"
= / !=
Evaluates if the field value is equal to value in "Part 3"
IN / !IN
Evaluates if the field value is in the comma list equal to value in "Part 3"
- / !-
Evaluates if the field value is in the range specified by value in "Part 3" ([min] - [max])
BIT / !BIT
Evaluates if the bit specified by the value in "Part 3" is set in the field's value
(considered as an integer)
Part 3 is a comma separated list of string or numeric values
REC:NEW:true
This will show the field for new records which have not been saved yet.
REC:NEW:false
This will show the field for existing records which have already been saved.
HIDE_FOR_NON_ADMINS
This will hide the field for all non-admin users while admins can see it.
Useful for FlexForm container fields which are not supposed to be edited directly via the FlexForm but
rather through some other interface.
USER
userFunc call with a fully qualified class name.
Additional parameters can be passed separated by colon:
USER:Evoweb\\Example\\User\\MyConditionMatcher->checkHeader:some:more:info
The following arguments are passed as array to the userFunc:
record: the currently edited record
flexContext: details about the FlexForm if the condition is used in one
flexformValueKey: vDEF
conditionParameters: additional parameters
The called method is expected to return a bool value: true if the field should be displayed, false otherwise.
VERSION:IS
Evaluate if a record is a "versioned" record from workspaces.
Part 1 is the type:
IS
Part 2 is "true" or "false": If true, the field is shown only if the record is a version (pid == -1).
Example to show a field in "Live" workspace only: VERSION:IS:false
In FlexForm, display conditions can be attached to single fields in sheets, to sheets itself, to flex section fields
and to flex section container element fields. FIELD references can be prefixed with a sheet name to
reference a field from a neighbor sheet, see examples below.
Tip
Fields used in a conditions should have the column option
onChange set to reload.
Examples for display conditions
Basic display condition
This example will require the field named "tx_templavoila_ds" to be true, otherwise the field for which this rule
is set will not be displayed:
Going further the next example defines the following conditions: for the
"example_field" field to be displayed, the content element must be in the
default language. Furthermore it must be a text-type element or have the
headline "Example" defined:
Flex form fields can access field values from various different sources:
<!-- Hide field if value of record field "header" is not "true" --><displayCond>FIELD:parentRec.header:REQ:true</displayCond><!-- Hide field if value of parent record field "field_1" is not "foo" --><displayCond>FIELD:parentRec.field_1:!=:foo</displayCond><!-- Hide field if value of neighbour field "flexField_1 on same sheet is not "foo" --><displayCond>FIELD:flexField_1:!=:foo</displayCond><!-- Hide field if value of field "flexField_1" from sheet "sheet_1" is not "foo" --><displayCond>FIELD:sheet_1.flexField_1:!=:foo</displayCond>
Some examples from extension styleguide to get an idea on what the
field definition is capable of: An input field
with slider, a select drop-down for images, an inline relation spanning multiple tables.
The following example can be found in the extension styleguide. On translating a record in a new language the content of the
field gets copied to the target language. It get prefixed with
[Translate to <language name>:].
The field types get defined in the TCA of a field in ['config']['type'].
The field type influences the rendering of the form field in the backend. It
also influences the processing of data on saving the values. Those behaviour can
be influenced by further properties.
Section ['columns'][*]['config'] (where * stands for a table column) is the main workhorse when it comes to single field configuration.
The main property is type, it specifies the DataHandler processing and database value. Additionally,
property renderType specifies how a field is rendered. The renderType is sometimes optional. Both properties
together specify the set of properties that are valid for one field.
This section of the documentation is first split by type to give an overview of what can be done
with a type, then lists all possible renderType's with all possible properties. Since some type's
can do useful stuff without a specific renderType too, those properties are listed below renderType "default",
which equals to "not set".
Show information between an element label and the main element input area. Configuration
works identical to the "fieldWizard" property, no default configuration in the core exists (yet).
In contrast to "fieldWizard", HTML returned by fieldInformation is limited, see
FormEngine docs for more details.
Hint
fieldInformation is not implemented by default. Use
to display general information below a fields title.
This becomes handy when using an IDE and doing operations like renaming classes.
The provided method will have an array of parameters passed to it. The items array is passed by reference
in the key items. By modifying the array of items, you alter the list of items. A method may throw an
exception which will be displayed as a proper error message to the user.
The referenced itemsProcFunc method should populate the items by filling $params['items']:
/**
* A user function used in select_2
*/classTypeSelect2ItemsProcFunc{
/**
* Add two items to existing ones
*
* @param array $params
*/publicfunctionitemsProcFunc(&$params): void{
$params['items'][] = ['label' => 'item 1 from itemProcFunc()', 'value' => 'val1'];
$params['items'][] = ['label' => 'item 2 from itemProcFunc()', 'value' => 'val2'];
}
}
Copied!
This results in the rendered select dropdown having four items. This is a really simple example. In the real world
you would use the other passed parameters to dynamically generate the items.
The field for which an MM configuration exists stores the number of records
in the relation on each update, so the field should be an integer.
Note
Using MM relations you can only store the relations for foreign tables
in the list. You cannot add properties like string values for the relation
itself.
MM relations and FlexForms
MM relations has been tested to work with FlexForms if not in a repeated
element in a section.
Related configurations
MM_match_fields
MM_match_fields
Type
array
Scope
Display / Proc.
Array of field=>value pairs to both insert and match against when writing/reading MM relations.
MM_opposite_field
MM_opposite_field
Type
string (field name)
Scope
Proc.
If you want to make a MM relation editable from the foreign side (bidirectional) of the relation as well, you need
to set MM_opposite_field on the foreign side to the field name on the local side.
E.g. if the field "companies.employees" is your local side and you want to make the same relation editable from
the foreign side of the relation in a field called persons.employers, you would need to set the MM_opposite_field
value of the TCA configuration of the persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in "sys_refindex".
MM_oppositeUsage
MM_oppositeUsage
Type
array
Scope
Proc.
In a MM bidirectional relation using select match fields
/ group match fields the opposite side needs to know about
the match fields for certain operations (for example, when a copy is created in a workspace) so that relations
are carried over with the correct information.
MM_oppositeUsage is an array which references which fields contain the
references to the opposite side, so that they can be queried for match
field configuration.
MM_table_where
MM_table_where
Type
string (SQL WHERE)
Scope
Proc.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...} around
identifiers to be as DBAL-compatible as possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
Auto creation of intermediate MM tables from TCA
Note
The intermediate mm tables defined in ['config']['MM']
are created automatically.
TCA table column fields that define ['config']['MM'] can
drop specification of the intermediate mm table layout in:
ext_tables.sql. The TYPO3 database analyzer
takes care of proper schema definition.
Extensions are strongly encouraged to drop ext_tables.sqlCREATE TABLE definitions for those intermediate tables referenced by
TCA table columns. Dropping these definitions allows the Core to adapt
and migrate definitions if needed.
The mm tables are automatically created if:
A table column TCA config defines MM with type='select',
type='group' or type='inline'.
The "MM" intermediate table has no TCA table definition (!).
A table of the resulting name is not defined in ext_tables.sql.
The schema analyzer takes care of further possible fields apart from
uid_local and uid_foreign, like tablenames,
fieldname and uid if necessary, depending on local side of the
TCA definition.
The fields used for sorting sorting and sorting_foreign are
always created, they do not need to be defined in TCA.
Example
The "local" side of a mm table is defined as such in TCA:
The intermediate table may have the following fields:
uid_local, uid_foreign
Storing uids of both sides. If done right, this is reflected in the table
name - tx_foo_local_foreign_mm
sorting, sorting_foreign
Are required fields used for ordering the items.
tablenames
Is used if multiple tables are allowed in the relation.
uid (auto-incremented and PRIMARY KEY)
May be used if you need the "multiple" feature (which allows the same record to be references multiple times
in the box. See MM_hasUidField for type='group' fields.
Show action buttons next to the element. This is used in various type's to
add control buttons right next to the main element. They can open popups,
switch the entire view and other things. All must provide a "button" icon
to click on, see FormEngine docs for more details.
See type=group for examples.
Control button to directly add a related record. Leaves the current view and opens a new form to add
a new record. On 'Save and close', the record is directly selected as referenced element
in the type='group' field. If multiple tables are allowed, the
first table from the allowed list is selected, if no specific table option is given.
Note
The add record control is disabled by default, enable it if needed. It
is shown below the edit popup control if not changed by below or
after settings.
Add a record to this table, falls back to first table from
allowed list if not set for
type='group' fields and to foreign_table for type='select' fields.
Can be one of 'set', 'prepend' or 'append'. With 'set' the given selection
is substituted with the new record, 'prepend' adds the new record on top of
the list, 'append' adds it at the bottom.
The edit popup field control shows a pencil icon to edit an element directly in a popup window.
When a record is selected and the edit button is clicked, that record opens in a new window for modification.
Note
The edit popup control is pre-configured, but disabled by default. Enable it if you need it, the button
is by default shown below element browser and insert clipboard.
The list module control button opens the Web > List module for only one table and allows the user to manipulate
stuff there.
Note
The list module control is disabled by default, enable it if needed. It is shown below the add record
control if not changed by below or after settings.
List records of this table only, falls back to first table from
allowed list if not set for
type='group' fields and to foreign_table for type='select' fields.
Specifies wizards rendered below the main input area of an element. Single type / renderType elements
can register default wizards which are merged with this property.
For example, type='check' comes with this default wizards configuration:
It is possible to add own wizards by adding them to the TCA of the according field and pointing to a registered
renderType, to resort wizards by overriding the before and after keys, to hand over additional
options in the optional options array to specific wizards, and to disable single wizards using the
disabled key. Developers should have a look at the
FormEngine docs for details.
Show a "diff-view" if the content of the default language record has been changed after the
translation overlay has been created. The ['ctrl'] section property
transOrigDiffSourceField has to be specified
to enable this wizard in a translated record.
This wizard is important for editors who maintain translated records: They can see what has been
changed in their localization parent between the last save operation of the overlay.
The localization state selector wizard displays two or three radio buttons in localized records
saying: "This field has an own value distinct from my default language or source record", "This field
has the same value as the default language record" or "This field has the same value as my source record".
This wizard is especially useful for the tt_content table. It will only render, if:
The record is a localized record (not default language)
The record is in "translated" (connected), but not in "copy" (free) mode
The table is localization aware using the ['ctrl'] properties languageField,
transOrigPointerField. If the optional property
translationSource is also set, and if the record is a translation
from another localized record, the third radio appears.
The property ['config']['behaviour']['allowLanguageSynchronization'] is set to true
Show values from the default language record and other localized records if the edited row is a
localized record. Often used in tt_content fields. By default, only the value of the default
language record is shown, values from further translations can be shown by setting the
user TSconfig property additionalPreviewLanguages.
The wizard shows content only for "simple" fields. For instance, it does not work for database relation fields,
and if the field is set to readOnly. Additionally, the table has to be language aware by setting up the
according fields in ['ctrl'] section.
TCA column type category
While using the type category, TYPO3 takes care of generating the
necessary TCA configuration.
Developers only have to define the TCA column and add category as the
desired TCA type in the tables's TCA file (inside or outside of the Overrides folder).
It is still possible to configure a category tree with type=select
and renderType=selectTree when you want to override specific fields,
but in most cases the simplified category TCA type is sufficient.
Contains an array of key-value pairs. The key contains the id of the item
group, the value contains the label of the item group or its language
reference.
Only groups containing items will be displayed. In the select field first all
items with no group defined are listed then the item groups in the order of
their definition, each group with the corresponding items.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
This value contains the name of the table in which to store a MM relation.
It is used together with
foreign_table.
The database field with a MM property only stores the number of records
in the relation.
Renders the field in a way that the user can see the values but cannot edit them. The rendering is as similar
as possible to the normal rendering but may differ in layout and size.
Warning
This property affects only the display. It is still possible to write to those fields when using
the DataHandler.
Stores the uid of the selected category. When using this
relationship, maxitems=1 will automatically be added to
the column configuration. While one record can only have a
relation to one category, each category can
still have a relationship to more then one record.
oneToMany
Stores the uids of selected categories in a comma-separated list.
manyToMany (default):
Uses the intermediate table sys_category_record_mm
and only stores the categories count on the local side. This is the use
case, which was previously accomplished using
ExtensionManagementUtility->makeCategorizable().
In the following example a category tree is displayed, but only one
category can be selected.
Either childrenField or parentField has to be set - childrenField takes precedence. Keywords:
dataProvider
Allows to define a custom data provider class for usecases where special data preparation
is necessary. By default \TYPO3\CMS\Core\Tree\TableConfiguration\DatabaseTreeDataProvider is used.
childrenField (string)
Field name of the foreign_table that references the uid of the child records.
parentField (string)
Field name of the foreign_table that references the uid of the parent record
startingPoints (string, comma separated values)
allows to set multiple records as roots for tree records.
The setting takes a CSV value, e.g. 2,3,4711, which takes records of the uids
2, 3 and 4711 into account and creates a tree of these records.
Additionally, each value used in startingPoints may be fed from a
site configuration
by using the ###SITE:### syntax.
Example:
# Site configbase:/rootPageId:1categories:root:123
It is possible to use the type category in FlexForm data structures.
Due to some limitations in FlexForm, the manyToMany relationship is not
supported. Therefore, the default relationship - used if none is defined -
is oneToMany.
An example of the "oneToMany" use case is EXT:news,
which allows to only display news of specific categories in the list view:
When using the check type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
Introduction
This type creates checkbox(es).
There can be between 1 and 31 checkboxes. The corresponding database field must be of type integer.
Each checkbox corresponds to a single bit of the integer value, even if there is only one checkbox.
Tip
This means that you should check the bits of values from single-checkbox
fields and not just whether it is true or false.
Resorting the 'items' of a type='check' config results in single items moving to different bit positions.
It might be required to migrate existing field data if doing so.
checkboxToggle: Instead of checkboxes,
a toggle item is displayed.
checkboxLabeledToggle: A toggle
switch where both states can be labelled (ON/OFF, Visible / Hidden or alike).
Its state can be inverted via invertStateDisplay
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
In how many columns the checkboxes will be shown. Makes sense only if the 'items' property is defining multiple
checkboxes.
Allowed values are 1, 2, 3, ..., 31 or inline, 1 being default. If set to inline the checkboxes are
"floating" and there will be as many in one row as fits to browser width.
Note checkboxes will still wrap if browser width is not sufficient.
Each bit of the decimal value corresponds to a checkbox. As an example, the
value 5 enables the first and third checkbox.
This is true even if there is only one checkbox, which then maps to the first
bit (reading from right to left).
decimal value
binary representation
selected checkboxes
0
0000 0000
none
1
0000 0001
first
2
0000 0010
second
5
0000 0101
first, third
127
0111 1111
the first seven
To find out the right default decimal value, first start off by writing down
the binary representation and set the desired bits at the appropriate
position to 1. Then convert the binary number to decimal. You can either use
a calculator with programmer mode or search online for "binary to decimal".
If this evaluation is defined, the maximum number of records from the same table that can have this box
checked will be limited. If someone tries to check the box of a record beyond the allowed maximum, the
box will be unchecked automatically upon saving.
The actual limit is defined with the validation property validation.
maximumRecordsCheckedInPid
Similar to maximumRecordsChecked but with the validation scope limited to records stored in the same page.
If set, this array will create an array of checkboxes instead of just a single "on/off" checkbox.
Note
You can have a maximum of 31 checkboxes in such an array and each element is represented by a single bit
in the integer value which ultimately goes into the database.
In this array each entry is itself an associative array.
The value sent to the database will be an integer representing a bit mask based on the position of the checkbox
in this array.
A basic item looks like this:
'items' => [
['label' => 'Green tomatoes'], // Note these should be LLL references
['label' => 'Red peppers'],
],
Copied!
Use the label key, instead of the numerical
index 0 which was done in previous versions.
Further properties can be set per item, but not all of them apply to all renderTypes:
label (string or LLL reference)
The displayed title.
invertStateDisplay (boolean)
All renderTypes. If set to true, checked / unchecked state are swapped in view: A checkbox is marked checked if
the database bit is not set and vice versa.
iconIdentifierChecked (string)
Only if renderType is not set (default): An optional icon shown is selected / on. If not set, a check mark
icon is used.
iconIdentifierUnchecked (string)
Only if renderType is not set (default): An optional icon shown selected / on. If not set, no icon is
show (check mark icon not displayed).
labelChecked (string)
Mandatory property for renderType checkboxLabeledToggle: Text shown if element is selected / on.
labelUnchecked (string)
Mandatory property for renderType checkboxLabeledToggle: Text shown if element is not selected.
This becomes handy when using an IDE and doing operations like renaming classes.
The provided method will have an array of parameters passed to it. The items array is passed by reference
in the key items. By modifying the array of items, you alter the list of items. A method may throw an
exception which will be displayed as a proper error message to the user.
Renders the field in a way that the user can see the values but cannot edit them. The rendering is as similar
as possible to the normal rendering but may differ in layout and size.
Warning
This property affects only the display. It is still possible to write to those fields when using
the DataHandler.
Values for the eval rules. The keys of the array must correspond to the
keyword of the related evaluation rule. For maximumRecordsChecked and maximumRecordsCheckedInPid
the value is expected to be an integer.
Default checkbox
The checkbox with renderType check
is typically a single checkbox or a group of checkboxes.
invertedStateDisplay: A checkbox is marked checked if the database bit is
not set and vice versa.
Labeled toggle checkbox
The checkbox type with the
renderType checkboxLabeledToggle is
displayed as a toggle switch where both states can be labelled
(ON / OFF, Visible / Hidden or alike).
When using the color type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type color should be used to render a JavaScript-based color picker.
The according database field
is generated automatically.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, the DB column must be allowed
to be NULL, and property nullable must be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be
saved and not a NULL.
.. _columns-color-properties-nullable:
.. confval:: nullable
:name: color-nullable
:Path: $GLOBALS['TCA'][$table]['columns'][$field]['config']
:type: boolean
:Default: false
:Scope: Proc
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as :sql:`NULL` in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be
saved and not a :sql:`NULL`.
The database field must allow the :sql:`NULL` value.
Example:
.. literalinclude:: _Properties/_Nullable.rst.txt
:caption: EXT:some_extension/Configuration/TCA/tx_sometable.php
Abstract value for the width of the <input> field. To set the
field to the full width of the form area, use the value 50. Minimum is 10.
Default is 30.
Renders a select box with static values next to the input field. When a
value is selected in the box, the value is transferred to the field. Keys:
items (array)
An array with selectable items. Each item is an array with the first value being the label in the select
drop-down (LLL reference possible) the second being the hex-value transferred to the input field.
The value should have exactly 7 characters, as this is the maximum for a hex-value.
The database type has changed from int signed to bigint signed
when the field is auto-generated (with the exception of the columns
tstamp, crdate, starttime, endtime that
still use int signed).
This allows to store dates from some million years ago to far into the
future.
The TCA type datetime should be used to input values representing a
date time or datetime. The according database field
is generated automatically as bigint signed.
Note
TYPO3 does not handle the following dates properly:
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
If set, the date or time will not be stored as timestamp, but as native
date, time or datetime field in the database. Keep in mind that no
timezone conversion will happen.
Note
When this property is not set the datetime value is automatically
converted to an int.
Example: Date and time picker stored in a datetime field
Sets the output format if the field is set to read-only. Read-only fields
with format set to "date" will be formatted as "date", "datetime"
as "datetime", "time" as "time" and "timesec" as "timesec".
Note
The format option defines how the field value will be displayed,
for example, in FormEngine. The storage format is defined via
dbType and falls back to
eval=integer.
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, the DB column must be allowed
to be NULL, and property nullable must be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved and not a NULL.
This means that the "some_date" field of the "tt_content" table will
be searched in only for elements of type X and Y. This helps making any
search more relevant.
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
When using the email type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type email should be used to input values representing email
addresses. The according database field
is generated automatically.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Some of these evaluation keywords will trigger a JavaScript pre- evaluation in the form. Other evaluations will be
performed in the backend. The evaluation functions will be executed in the list-order. Keywords:
unique
Requires the field to be unique for the whole table. Evaluated on the server only.
Note
When selecting on unique-fields, make sure to select using AND pid>=0 since the field can contain
duplicate values in other versions of records (always having PID = -1). This also means that if you are using
versioning on a table where the unique-feature is used you cannot set the field to be truly unique
in the database either!
uniqueInPid
Requires the field to be unique for the current PID among other records on the same page.
Evaluated on the server only.
Example: Email field unique on the storage page
Require an email address to be unique for this record type in this folder
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, option nullablemust be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved and not a NULL.
When the eval option is set to unique
or uniqueInPid multiple null values are still possible.
Renders the field in a way that the user can see the values but cannot edit them. The rendering is as similar
as possible to the normal rendering but may differ in layout and size.
Warning
This property affects only the display. It is still possible to write to those fields when using
the DataHandler.
Abstract value for the width of the <input> field. To set the email
field to the full width of the form area, use the value 50. Minimum is 10.
Default is 30.
Note
The softref definition 'softref' => 'email[subst]' is automatically applied
to all email fields.
File
New in version 13.0
When using the file type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type file creates a field where files can be attached to
the record. The according database field
is generated automatically.
Has information about the appearance of child-records, namely:
collapseAll (boolean)
Show all child-records collapsed (if false, all are expanded)
expandSingle (boolean)
Show only one child-record expanded each time. If a collapsed record is
clicked, the currently open one collapses and the clicked one expands.
createNewRelationLinkTitle (string or LLL reference)
Overrides the link text and title of the "Create new relation" button
with a localized string. Only useful, if the element browser is enabled.
addMediaLinkTitle (string or LLL reference)
Overrides the link text and title of the "Add media by URL" button
with a localized string. Only useful, if the element browser is enabled.
uploadFilesLinkTitle (string or LLL reference)
Overrides the link text and title of the "Select & upload files" button
with a localized string. Only useful, if the element browser is enabled.
useSortable (boolean)
Activate drag & drop.
showPossibleLocalizationRecords (boolean)
Show unlocalized files which are in the original language, but not
yet localized.
showAllLocalizationLink (boolean)
Defines whether to show the "localize all records" link to fetch
untranslated records from the original language.
showSynchronizationLink (boolean)
Defines whether to show a "synchronize" link to update to a
1:1 translation with the original language.
enabledControls (array)
Associative array with the keys 'info', 'new', 'dragdrop', 'sort',
'hide', 'delete', 'localize'. If the accordant values are set to a
boolean value (true or false), the control is shown or hidden in the
header of each record.
headerThumbnail (array)
Defines whether a thumbnail should be rendered in the inline element's
header. This is used by the file abstraction layer to render a preview
of the related image. Can contain image processing instructions
like width and height.
field (required)
The table column name, which contains the uid of the image reference. Usually this is uid_local.
width
The width of the thumbnail.
height
The height of the thumbnail.
fileUploadAllowed (boolean)
Defines whether the button "Select & upload file" should be rendered. This can be used for file fields to directly
upload files and create a reference to the file. The button is limited to file fields using File Abstraction Layer.
It will only appear to backend users which have write access to the user upload folder. By default this folder is
fileadmin/user_upload but it can be changed in User TSconfig using options.defaultUploadFolder.
See the TSconfig reference.
The button is shown by default unless this option is set to false.
fileByUrlAllowed (boolean)
Defines whether the button "Add media by URL" should be rendered. This button is used to include media
URLs from, for example, Vimeo or YouTube.
elementBrowserEnabled (boolean)
Hides or displays the element browser button in inline records
This property can also be overridden by page TSconfig.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
This property can also be overridden by page TSconfig.
Default false. Disables that child records get moved along with their parent records. Usually if in a parent-child
relation a parent record is moved to a different page (eg. via cut+paste from clipboard), the children are relocated
along with the parent. This flag disables the child move.
This property can also be overridden by page TSconfig.
Show information between an element label and the main element input area. Configuration
works identical to the "fieldWizard" property, no default configuration in the core exists (yet).
In contrast to "fieldWizard", HTML returned by fieldInformation is limited, see
FormEngine docs for more details.
Maximum number of files that can be attached. Defaults to a high value.
JavaScript record validation prevents the record from being saved if the
limit is not satisfied.
This property can also be overridden by page TSconfig.
The files attached to this record are displayed but cannot be changed
in the backend form.
This property can also be overridden by page TSconfig.
Warning
This property affects only the display. It is still possible to write
to those fields when using the DataHandler.
FlexForm field
New in version 13.0
When using the flex type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
Renders a FlexForm element. Essentially, this consists in a
hierarchically organized set of fields which will have their values saved into a
single field in the database, stored as XML.
The general idea is: There is a data structure that defines which and how single
fields should be displayed, re-using all the TCA column type possibilities. The
actual values of single fields are then stored in an XML representation within
this "flex" field.
The configuration options ds_tableField, ds_pointerField_searchParent_subField
and ds_pointerField_searchParent are not handled anymore. Use the
Events to replace their logic if needed.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Each key is a value that can be pointed to by ds_pointerField.
Default key is "default" which is what you should use if you do not have a ds_pointerField value of course.
If you specified more than one ds_pointerField, the keys in this "ds" array should contain comma-separated
value pairs where the asterisk * matches all values (see the example below). If you don't need to switch for the
second ds_pointerField, it's also possible to use only the first ds_pointerField's value as a key in
the "ds" array without necessarily suffixing it with ",*" for a catch-all on the second ds_pointerField.
For each value in the array there are two options:
Renders the field in a way that the user can see the value but cannot edit it.
Warning
This property affects only the display. It is still possible to
write to those fields when using the DataHandler.
Defining multiple data structures for different records
There can be multiple data structures defined in TCA and it depends on the
configuration and the record which one is chosen. If the ds
and ds_pointerField are not sufficient, you can use the
Events to manipulate with data structure should be
displayed.
Note
It is not possible to override these properties in
TCA type columnsOverrides or to manipulate
them in an inline parent-child relation from the parent TCA.
Events to manipulate the FlexForm data structure
There are appropriate events that allow the manipulation of the data structure
lookup logic:
Basically, the configuration for a FlexForm field is all about pointing
to the data structure which contains form rendering information.
For general information about the backbone of a Data Structure, please
refer to the "<T3DataStructure>" chapter in the
Core API manual.
The mixture of the different "ds" properties can be puzzling at first,
but they allow powerful combinations to specify which data structure should be
used in different scenarios.
Straight and simple: Whenever a record is handled that has a column field
definition with this TCA, the data structure defined in
FILE:EXT:my_extension/Configuration/FlexForms/Main.xml
is parsed and the flex form defined in there is displayed.
There are now multiple data structures registered for this "flex" field. It
depends on the value of the field "selector" which one is chosen: If
"selector" value is "foo", "Foo.xml" is parsed and displayed, "Bar.xml" is
chosen for the value "bar", and if none of the two matches, it falls back
to "Default.xml".
FlexForm syntax
Note
This section is still messy, should be merged with the section from Core API
and FlexForms and should be much easier to understand.
FlexForms create a form-in-a-form. The content coming from this form
is still stored in the associated database field - but as an XML
structure, stored by \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array().
The "TCA" information needed to generate the FlexForm fields are found
inside a <T3DataStructure> XML document. When you configure a FlexForm
field in a Data Structure (DS) you can use basically all column types
documented here for TCA. The limitations are:
"unique" and "uniqueInPid" evaluation is not available
You cannot nest FlexForm configurations inside of FlexForms.
You cannot add, change or remove fields in FlexForms without copying the data structure and changing the configuration accordingly.
Charset follows that of the current backend UTF-8. When storing FlexForm information in external files,
make sure that they are using UTF-8 too.
type='inline' and other types that point to different tables are not allowed in FlexForm section containers.
Changed in version 13.0
Since TYPO3 13.0, also type='select' (when using
foreign_table) is not allowed and will raise an exception
when used. Note this only applies to FlexForm sections, not general
FlexForm usage. For details and migration see
Breaking: #102970 - No database relations in FlexForm container sections.
The tables below documents the extension elements:
Array Elements
<meta>
Element
<meta>
Can contain application specific meta settings. For FlexForms this means a definition of how languages
are handled in the form.
<[application tag]>
Element
A direct reflection of a ['columns']['field name']['config'] PHP array configuring a field in TCA. As XML,
this is expressed by array2xml()'s output.
<ROOT>
Element
<ROOT>
For <ROOT> elements in the DS you can add application specific information about the
sheet that the <ROOT> element represents.
Child elements
<sheetTitle>
<sheetDescription>
<sheetShortDescr>
Value Elements
<sheetTitle>
Element
<sheetTitle>
Format
string or LLL reference
Specifies the title of the sheet.
<sheetDescription>
Element
<sheetDescription>
Format
string or LLL reference
Specifies a description for the sheet shown in the flexform.
<sheetShortDescr>
Element
<sheetShortDescr>
Format
string or LLL reference
Specifies a short description of the sheet used in the tab-menu.
Sheets and FlexForms
FlexForms always resolve sheet definitions in a Data Structure. If only one sheet is defined that must be
the "sDEF" sheet (default). In that case no tab-menu for sheets will appear (see examples below).
FlexForm data format, <T3FlexForms>
When saving FlexForm elements the content is stored as XML using
\TYPO3\CMS\Core\Utility\GeneralUtility::array2xml() to convert the internal PHP array to XML
format. The structure is as follows:
<T3FlexForms>
Element
<T3FlexForms>
Document tag
Child elements
<meta>
<data>
<meta>
Element
<meta>
Meta data for the content. For instance information about which sheet is active etc.
<data>
Element
<data>
Contains the data: sheets, language sections, field and values
Child elements
<sheet>
<sheets>
Element
<sheets>
Contains the data for each sheet in the form. If there are no sheets, the default sheet "<sDEF>" is always used.
Child elements
<sDEF>
<s_[sheet keys]>
<sDEF>
Element
<sDEF>
For each sheet it contains elements for each language. only the <lDEF> tag is used.
Child elements
<lDEF>
<lDEF>
Element
<lDEF>
For each language the fields in the form will be available on this level.
Child elements
<[field name]>
<[field name]>
Element
<[field name]>
For each field name there is at least one element with the value, <vDEF>.
Child elements
<vDEF>
<vDEF>
Element
<vDEF>
Format
string
Content of the field in default or localized versions.
Examples
Simple FlexForm
The extension styleguide provides some sample FlexForms.
The "simple FlexForm" field provides a very basic
configuration with just a select-type field to choose a page from the
table pages.
The corresponding TCA column loads the DataStructure (ds) form an
external XML file:
It's clear that the contents of <input_1> is a direct reflection of
the field configurations we normally set up in the $GLOBALS['TCA'] array.
FlexForm in a plugin
The data structure for a FlexForm can also be loaded in the pi_flexform
field of the tt_content table by adding the following in the
TCA Overrides of an extension, see this example from the extension
t3docs/blog-example
:
<?phpdeclare(strict_types=1);useTYPO3\CMS\Core\Utility\ExtensionManagementUtility;useTYPO3\CMS\Extbase\Utility\ExtensionUtility;defined('TYPO3') ordie();$pluginKey = ExtensionUtility::registerPlugin('blog_example','BlogList','List of Blogs (BlogExample)','blog_example_icon','plugins','Display a list of blogs',);ExtensionManagementUtility::addToAllTCAtypes('tt_content','--div--;Configuration,pi_flexform', $pluginKey,'after:subheader',);ExtensionManagementUtility::addPiFlexFormValue('*','FILE:EXT:blog_example/Configuration/FlexForms/PluginSettings.xml', $pluginKey,);
Copied!
In line 18ff the field pi_flexform is added to the display
of fields when the record type of the plugin is selected.
In line 25ff the method addPiFlexFormValue() from class
ExtensionManagementUtility is used to
register the FlexForm.
Example: FlexForm with two sheets
This example provides a FlexForm field with two "sheets". Each sheet
can contain a separate FlexForm structure. Each sheet can also have a
sheet descriptions:
In this example the FlexForm data structure is saved directly into the TCA
field:
[
'columns' => [
'flex_1' => [
'label' => 'flex_1 sheet description',
'description' => 'field description',
'config' => [
'type' => 'flex',
'ds' => [
'default' => '
<T3DataStructure>
<sheets>
<sSheetdescription_1>
<ROOT>
<sheetTitle>sheet description 1</sheetTitle>
<sheetDescription>
sheetDescription: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Nam id ante ornare, iaculis elit a, malesuada augue. Etiam neque odio,
condimentum sed dolor vitae, sollicitudin varius lacus. Pellentesque sit amet aliquam arcu.
Phasellus ut euismod felis. Fusce at tempor turpis.
Nam eu arcu id lorem vestibulum tristique vel in erat. Phasellus maximus, arcu nec
condimentum venenatis, mauris nisl venenatis tellus, eget suscipit arcu nunc et purus.
Nunc luctus congue vulputate. Donec placerat, lorem vitae rhoncus euismod, ipsum ligula
tempor sapien, ac sodales metus mauris et lacus. Donec in ante a lectus semper rutrum nec
ut orci. Quisque id mi ultrices lacus fermentum consequat quis sed odio. Sed quis turpis
rutrum, convallis sem vitae, cursus enim. Maecenas sit amet sem nisi.
</sheetDescription>
<sheetShortDescr>
sheetShortDescr: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Nam id ante ornare, iaculis elit a, malesuada augue. Etiam neque odio,
condimentum sed dolor vitae, sollicitudin varius lacus. Pellentesque sit amet aliquam arcu.
Phasellus ut euismod felis. Fusce at tempor turpis.
</sheetShortDescr>
<type>array</type>
<el>
<input_1>
<label>input_1</label>
<config>
<type>input</type>
</config>
</input_1>
</el>
</ROOT>
</sSheetdescription_1>
<sSheetdescription_2>
<ROOT>
<sheetTitle>sheet description 2</sheetTitle>
<sheetDescription>
foo
</sheetDescription>
<sheetShortDescr>
bar
</sheetShortDescr>
<type>array</type>
<el>
<input_2>
<label>input_2</label>
<config>
<type>input</type>
</config>
</input_2>
</el>
</ROOT>
</sSheetdescription_2>
</sheets>
</T3DataStructure>
',
],
],
],
],
]
Copied!
Notice how the data of the two sheets are separated.
A flex form field with two flex section containers
In this example the FlexForm data structure is saved directly into the TCA
field:
When using the folder type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type folder creates a field where folders can be attached to
the record. The values are stored as a combined identifier in a
comma-separated list (csv).
The according database field
is generated automatically.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
In case an allowed table has no entry point defined, the _default is used.
In case _default is also not set or elementBrowserEntryPoints is not
used at all, the previous behaviour applies.
fieldControl
fieldControl
The field of type folder can enable all common
field control options. Furthermore the
following are available:
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
Group fields
New in version 13.0
When using the group type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The group element (type' => 'group') in TYPO3 makes it possible to create references from a record of one table to many records from multiple tables in the system. The foreign tables can be the table itself (thus a self-reference) or any other table.
This is especially useful (compared to the "select" type) when records are scattered over the page tree and require
the Element Browser to select records for adding them to the group field.
For database relations however, the group field is the right and powerful choice, especially if dealing
with lots of re-usable child records, and if type='inline' is not suitable.
This type is very flexible in its display options with all its different
fieldControl and
fieldWizard options. A lot of them are available by default, however they must be enabled: 'disabled' => 'false'
Most common usage is to model database relations (n:1 or n:m).
The property allowed is required, to
define allowed relation tables.
The group field uses either the CSV format to store uids of related records or an intermediate mm table
(in this case MM property is required).
You can read more on how data is structured in Stored data values chapter.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
A comma list of tables from $GLOBALS['TCA'] , for example "pages,be_users".
Note
If the field is the foreign side of a bidirectional MM relation, only the first table is used and that
must be the table of the records on the native side of the relation.
Note
When using Extbase, you also need to fill
foreign_table
property with the same table name as used in
allowed property
(but with just one table name).
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
By default, the last selected page is used when opening the element browser.
Setting this configuration value changes this behaviour.
This configuration value is a PHP array, containing table => id
pairs. When opening the element browser for a specific table (buttons below
the group field), the defined page is then always selected by default. There
is also the special _default key, used for the general element browser
button (on the right side of the group field), which is not dedicated to a
specific table.
This configuration value also supports the known
markers ###SITEROOT###, ###CURRENT_PID### and ###PAGE_TSCONFIG_<key>###.
Each table => id pair can also be overridden via page TSconfig.
Example: Open the element browser on page 123 for tt_content elements
Control button to directly add a related record. Leaves the current view and opens a new form to add
a new record. On 'Save and close', the record is directly selected as referenced element
in the type='group' field. If multiple tables are allowed, the
first table from the allowed list is selected, if no specific table option is given.
Note
The add record control is disabled by default, enable it if needed. It
is shown below the edit popup control if not changed by below or
after settings.
The edit popup field control shows a pencil icon to edit an element directly in a popup window.
When a record is selected and the edit button is clicked, that record opens in a new window for modification.
The edit popup control is pre-configured, but disabled by default. Enable it if you need it, the button
is by default shown below element browser and insert clipboard.
The list module control is disabled by default, enable it if needed. It is shown below the add record
control if not changed by below or after settings.
The element browser field control used in type='group' renders a
button to open an element browser. It is enabled by default if rendering a
group element.
Use a render type from core or your own. Custom render types can be
registered with the NodeFactory.
The clipboard control adds a control button for type='group' to paste records from
a users clipboard into the selection. It is enabled by default for type='group' and
shown below the element browser if the
order has not been changed using the before and after keywords. It can be turned off by
setting disabled to true, just like any other fieldControl.
Render an overview of the selected records with correct icon and click menu and title. Allows to
perform actions on the selected records directly. Links the record title to a direct editing form.
Render a list of allowed tables and link to element browser. This field wizard is enabled by default.
This wizard allows to easily select records from a popup.
Define filters for item values. Doesn't work in combination with a wizard.
This is useful when only foreign records matching certain criteria should be allowed to be used as values in the
group field. The values are filtered in the Element Browser as well as during processing in DataHandler. Filter
userFuncs should have two input arguments ($parameters and $parentObject). The first argument ($parameters) is an
array with the parameters of the filter as configured in the TCA, but with the additional parameter "values", which
contains the array of values which should be filtered by the userFunc. The function must return the filtered
array of values.
Note
Do not confuse the filter values with the page tree selector on the left side. To change the entry page in the navigation
use elementBrowserEntryPoints instead.
Multiple filters can be defined, and an array of configuration data for each of the filters can be supplied:
'filter' => [
[
'userFunc' => \Vendor\Extension\MyClass::class . '->doFilter',
'parameters' => [
// optional parameters for the filter go here
],
],
[
'userFunc' => \Vendor\Extension\OtherClass::class . '->myFilter',
'parameters' => [
// optional parameters for the filter go here
],
],
],
Copied!
Example:
Say you have a "person" table with fields "gender" (radio buttons) as well as "mother" and "father", both group
fields with relations to the same table.
Now, in the field "mother" it should certainly only be possible to create relations to female persons. In that
case, you could use the filter functionality to make sure only females can be selected in that field.
The field configuration for the "mother" field could look like:
This property does not really exist for group-type fields. It is needed as
a workaround for an Extbase limitation. It is used to resolve dependencies
during Extbase persistence. It should hold the same values as property
allowed. Notice that only one
table name is allowed here in contrast to the property
allowed itself.
The "suggest wizard" is added by default to all database relation group fields. After a couple of characters have
been typed into this field, an ajax based search starts and shows a list of records matching the search word.
The syntax for the search is: "multiple words" something, so you can enclose words you want to find next to each other in double quotes.
A set of options is available to configure search details.
Setting this property to true disables the suggest wizard.
Defines whether referenced records should be localized when the current
record gets localized. This only applies if references are not stored using
MM tables. foreign_table
has to reference the same table in allowed.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
This value contains the name of the table in which to store a MM relation.
It is used together with
allowed (group). If you use
Extbase,
foreign_table has to contain
the same table name additionally.
The database field with a MM property only stores the number of records
in the relation.
The table name used in the field MM should be unique. It must be a
valid SQL table name. It is best practise to use the name of both
referenced tables and of the field in which the reference is saved on local
side. See also naming conventions for mm tables.
This way uniqueness can be ensured and it is possible to find the field
where the table is used quickly.
Array of field => value pairs to both insert and match against when
writing/reading MM relations.
MM_opposite_field
MM_opposite_field
Type
string (field name)
Scope
Proc.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
MM_oppositeUsage
MM_oppositeUsage
Type
array
Scope
Proc.
In a MM bidirectional relation using
group match fields
the opposite side needs to know about the match fields for certain operations
(for example, when a copy is created in a
workspace) so that relations are carried over
with the correct information.
MM_oppositeUsage is an array which references which fields contain
the references to the opposite side, so that they can be queried for match
field configuration.
MM_table_where
MM_table_where
Type
string (SQL WHERE)
Scope
Proc.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
Will prepend the table name to the stored relations (so instead of storing "23" you will
store e.g. "tt_content_23"). This is automatically turned on if multiple different tables are
allowed for one relation.
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
Optional, additional suggest options used if the suggest wizard is not
hidden. The suggest wizard options can also be overriden
on a page TSconfig level.
Suggestions can be configured differently for each table. Settings in "default" are applied to all tables.
In the example below, there is a special setting for the "pages" table to search only standard pages.
Comma-separated list of fields the suggest wizard should also search in. By default the wizard looks only in the
fields listed in the label and label_alt
of TCA ctrl properties.
addWhere (string)
Allows to define an additional where clause for the searchquery. It supplies a marker for ###THIS_UID###
which is useful to exclude the current record.
Note
Basically identical to 'searchCondition' - one will vanish sooner or later.
cssClass (string)
Add a CSS class to every list item of the result list.
maxItemsInResultList (integer)
Maximum number of results to display, default is 10.
maxPathTitleLength (integer)
Maximum number of characters to display when a path element is too long.
minimumCharacters (integer)
Minimum number of characters needed to start the search. Works only in "default" configuration array.
orderBy (string)
Allows to add an ORDER BY part to the search query.
pidList (list of values)
Limit the search to certain pages (and their sub pages). When pidList is empty all pages will be included in the
search (as long as the be_user is allowed to see them).
PHP class alternative receiver class, default is TYPO3\\CMS\\Backend\\Form\\Wizard\\SuggestWizardDefaultReceiver.
Can be used to implement an own search strategy.
renderFunc (string)
User function to manipulate the displayed records in the results.
searchCondition (string)
Additional WHERE clause (not prepended with AND).
Note
Basically identical to 'addWhere' - one will vanish sooner or later.
Example
'storage_pid' => [
'config' => [
'suggestOptions' => [
// configures the suggest wizard for the field "storage_pid"// in table "pages" to search only for pages with doktype=1'pages' => [
'searchCondition' => 'doktype=1',
],
],
],
],
Copied!
searchWholePhrase (boolean)
Whether to do a LIKE=%mystring% (searchWholePhrase = 1) or a LIKE=mystring%
(to do a real find as you type), default is 0.
The default and most wide spread method is the comma list.
Reserved tokens
In the comma list the token "," is used to separate the values. In addition the pipe sign "|" is used to separate
value from label value when delivered to the interface. Therefore these tokens are not allowed in reference
values, not even if the MM method is used.
The "Comma list" method (default)
When storing references as a comma list the values are simply stored one after another, separated by a comma in between
(with no space around!). The database field type is normally a varchar, text or blob field in order to handle this.
From the examples above the four Content Elements will be stored as "26,45,49,1" which is the UID values of the records.
Since "db" references can be stored for multiple tables the rule is that uid numbers without a table name prefixed
are implicitly from the first table in the allowed table list! Thus the list "26,45,49,1" is implicitly understood as
"tt_content_26,tt_content_45,tt_content_49,tt_content_1". That would be equally good for storage, but by default
the "default" table name is not prefixed in the stored string. As an example, lets say you wanted a relation to a
Content Element and a Page in the same list. That would look like "tt_content_26,pages_123" or alternatively
"26,pages_123" where "26" implicitly points to a "tt_content" record given that the list of allowed tables
were "tt_content,pages".
The "MM" method
Note
The intermediate mm tables defined in ['config']['MM']
are created automatically.
Using the MM method the Database Analyzer creates an intermediate MM table to
store the relation data. The database fields in the affected tables only contain
the number of records in the relation. You can read more about it here:
Auto creation of intermediate MM tables from TCA
Lets take the examples from before and see how they would be stored in an MM table:
uid_local
uid_foreign
tablename
sorting
[uid of the record you are editing]
26
tt_content
1
[uid of the record you are editing]
45
tt_content
2
[uid of the record you are editing]
49
tt_content
3
[uid of the record you are editing]
1
tt_content
4
Or for "tt_content_26,pages_123":
uid_local
uid_foreign
tablename
sorting
[uid of the record you are editing]
26
tt_content
1
[uid of the record you are editing]
123
pages
2
API for getting the reference list
Class \TYPO3\CMS\Core\Database\RelationHandler is designed to transform the stored reference list
values into an array where all uids are paired with the right table name. Also, this class will automatically
retrieve the list of MM relations. In other words, it provides an API for getting the references
from "group" elements into a PHP array regardless of storage method.
Image manipulation
New in version 13.0
When using the imageManipulation type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The type "imageManipulation" generates a button showing an image cropper in the backend for image files.
It is typically only used in FAL relations. The crop information is stored as an JSON array into the field.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
List of image types (by file extension) which can be cropped. Defaults to
$GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] which is usually gif,jpg,jpeg,png.
It is possible to define multiple crop variants. The array key is used as identifier for the ratio and the label
is specified with the "title" and the actual (floating point) ratio with the "value" key. The value must be of
PHP type float, not only a string.
It is also possible to define an initial crop area. If no initial crop area is defined, the default selected
crop area will cover the complete image. Crop areas are defined relatively with floating point numbers. The x and y
coordinates and width and height must be specified for that. The below example has an initial crop area in the size
the previous image cropper provided by default.
Users can also select a focus area, when configured. The focus area is always inside the crop area and marks the
area in the image which must be visible for the image to transport its meaning. The selected area is persisted to
the database but will have no effect on image processing. The data points are however made available as data
attribute when using the <f:image /> view helper.
The below example adds a focus area, which is initially one third of the size of the image and centered.
Very often images are used in a context, where they are overlaid with other DOM elements, like a headline. To give
editors a hint which area of the image is affected, when selecting a crop area, it is possible to define multiple
so called cover areas. These areas are shown inside the crop area. The focus area cannot intersect with any of
the cover areas.
The above configuration examples are basically meant to add one single cropping configuration
to sys_file_reference, which will then apply in every record, which reference images.
Configuration per content element
It is however also possible to provide a configuration per content element. If you for example want a different
cropping configuration for tt_content images, then you can add the following to your image field configuration of tt_content records:
Please note, that you need to specify the target column name as array key. Most of the time this will be crop
as this is the default field name for image manipulation in sys_file_reference
Define a cropping configuration for a specific content element
It is also possible to set the cropping configuration only for a specific tt_content element type by using the
columnsOverrides feature:
Please note, that the array for overrideChildTca is merged with the child TCA, so are the crop variants that are defined
in the child TCA (most likely sys_file_reference). Because you cannot remove crop variants easily, it is possible to disable them
for certain field types by setting the array key for a crop variant disabled to the value true
Disable an aspect ratio
Not only cropVariants but also aspect ratios can be disabled by adding a
"disabled" key to the array.
When using the inline type, TYPO3
generates the correct database fields.
Developers do not need to define this field in an extension's
ext_tables.sql file.
Inline Relational Record Editing (IRRE) is a way of editing parent-child-relations in the backend view.
Instead of child records already having to exist, new child records are created
using AJAX calls (to prevent reloading the complete backend view).
Inline fields should not be used anymore to handle files. Use the TCA
column type file instead.
The type='inline' is a powerful element that can handle many types of relation,
including simple 1:n and nested 1:n-1:n relations, aswell as m:n
relations with different view aspects and localization setups. When combined with
'ctrl' and 'types' properties in the TCA a huge amount of different views are possible.
The inline type was mainly designed to handle 1:n relations,
where one parent record has many children and each child has only one
parent. Children can not be transferred from one parent to another.
However, m:n relations can be setup using intermediate tables. An m:n
relation is where a child has many parents. In addition to the main parent-child
relation fields in the intermediate table, fields can be added to attach
additional information to the parent-child relation. One example of this is
"FAL" / resource handling in the Core. A parent record
(for instance table "tt_content") is connected via table "sys_file_reference" to
a media resource in "sys_file". A sys_file record has table "sys_file_metadata"
as a child record which holds meta information about the file (for instance a
description). This information can be overwritten for the specific file resource used in
"tt_content" by adding a new description in "sys_file_reference". There are inline
and field properties in the TCA such as "placeholder" to set this up.
Hint
The inline type does not have fieldInformation,
fieldControl or fieldWizard properties like other types. This is
due to the fact that it is a container and not an element. You can
still add fieldInformation or fieldWizard, but they must be configured
in the ctrl. Please see the
example.
Has information about the appearance of child records, namely:
collapseAll (boolean)
Show all child records collapsed (if false, all are expanded)
expandSingle (boolean)
Show only one child record expanded each time. If a collapsed record is clicked, the currently
open one collapses and the clicked one expands.
showNewRecordLink (boolean)
Disables the New record link in TCA inline elements without simultaneously disabling
the + button in the header of each inline record (using
['appearance']['enabledControls']['new']).
newRecordLinkAddTitle (boolean)
Adds the title of the foreign_table to the "New record" link.
false
"Create new"
true
"Create new <title of foreign_table>", e.g. "Create new address"
newRecordLinkTitle (string or LLL reference)
Overrides the title of the "New record" link with a localized string. This will work only if
newRecordLinkAddTitle is not set to true.
createNewRelationLinkTitle (string or LLL reference)
Overrides the link text and title of the "Create new relation" button with a localised string.
Only useful, if the element browser is enabled. This is usually used together with FAL relations to change it to "Add file" or similar.
levelLinksPosition (string)
Values: 'top' (default), 'bottom', 'both'. Defines where to show the "New record" link in relation
to the child records. Value 'none' is no longer supported, use showAllLocalizationLink,
showSynchronizationLink and showNewRecordLink with value false instead.
useCombination (boolean)
This is only useful on bidirectional relations using an intermediate table with attributes. In a "combination" it
is possible to edit the attributes AND the related child record itself. If using a
foreign_selector in such a case, the
foreign_unique property must be set to the same field as
the foreign_selector.
suppressCombinationWarning (boolean)
Suppresses the warning flash message that will be displayed when using useCombination.
You can also override the message with your own message using the example below.
Show unlocalized records which are in the original language, but not yet localized.
showAllLocalizationLink (boolean)
Defines whether to show the "localize all records" link to fetch untranslated records from the original language.
showSynchronizationLink (boolean)
Defines whether to show a "synchronize" link to update to a 1:1 translation with the original language.
enabledControls (array)
Associative array with the keys 'info', 'new', 'dragdrop', 'sort', 'hide', 'delete', 'localize'. If the accordant
values are set to a boolean value (true or false), the control is shown or hidden in the header of each record.
showPossibleRecordsSelector (boolean)
Can be used to hide the foreign record selector from the interface, even if you have a
foreign_selector configured. This can be used to keep the
technical functionality of the foreign_selector but is useful
if you want to replace it with your own implementation using a custom control,
see customControls.
elementBrowserEnabled (boolean)
Hides or displays the element browser button in inline records
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Default false. Disables that child records get moved along with their parent records. Usually if in a parent-child
relation a parent record is moved to a different page (eg. via cut+paste from clipboard), the children are relocated
along with the parent. This flag disables the child move.
This property can be especially useful if all child records should be gathered in one storage folder and their
parents are spread out at different places in the page tree. In combination with the
Tsconfig settingTCAdefaults.<table>.pid = <page id> children
can be forced to be created in this folder and stay there.
Default true. Usually in inline relations, if a parent is deleted, all children are deleted along with the parent.
This flag can be used to disable that cascading delete. Example usage: A frontend user (parent) has assigned
invoices (children). If a frontend user is deleted, it could be useful to keep the invoices.
Numerical array containing definitions of custom header controls for IRRE fields. This makes it possible to create
special controls by calling user-defined functions (userFuncs). Each item in the array item must be an array itself,
with at least on key "userFunc" pointing to the user function to call.
The userFunc string is defined as usual in TYPO3 as ['class']->['method'], e.g.:
If a field name for foreign_sortby is defined, then
this is ignored. Otherwise, this is used as the "ORDER BY" statement to sort the records in the table when listed.
Insert the fieldname of the inline element, that you want to have as the title of the inline element. E.g. 'header'. If set, it overrides the label set in $GLOBALS['TCA'][<foreign_table>]['ctrl']['label'] for the inline-view.
Array of field-value pairs to both insert and match against when writing/reading IRRE relations. Using the match
fields, it is possible to re-use the same child table in more than one field of the parent table by using a match
field with different values for each of the use cases.
Examples
Imagine you have a parent table called "company" and a child table called "persons". Now, if you want the company
table to have two fields of type "inline", one called "employees" and one called "customers", both containing
"persons". Then you could use a (hidden) field called "role" on the child (person) table to keep them apart.
The match TCA configuration of the parent table would then look like this:
If the match field is made editable, for instance as a select drop-down of two values, the the relation would
switch between the two parent fields after change an save. Imagine a user record having "open" and "closed" issues
assigned, both pointing to the same table. The user then switches the status of an issue from "open" to "closed".
On save, the issue would "move over" to the "closed" section in his view.
A selector is used to show all possible child records that could be used to create a relation with the parent record.
It will be rendered as a multi-select-box. On clicking on an item inside the selector a new relation is created.
The foreign_selector points to a field of the foreign_table
that is responsible for providing a selector-box – this field on the foreign_table usually
is of type select and also has a foreign_table defined.
In most cases you must assign the field uid_local to the foreign_selector.
This field name is used as a convention for the child record of the intermediate table.
The automatic generation of MM tables also uses this field name.
It depends whether uid_local of the MM table points to the opposite table (of the perspective of your inline field).
In case of the opposite direction the field name uid_foreign is usually used.
Define a field on the child record that stores the manual sorting
information. It is possible to have a different sorting, depending from
which side of the relation we look at parent or child.
Attention
Do not confuse this property with foreign_default_sortby.
The foreign_sortby field contains an integer and is managed by the DataHandler. If by accident a content column
like "title" is set as foreign_sortby, the DataHandler will write these integers into that field, which is most
likely not what you want. Use foreign_default_sortby in this case.
This property requires that the
foreign_field approach is
used.
When using MM relations the field used
on the intermediate table is hardcoded to sorting_foreign. Setting
this property has no effect combined with an MM table.
Warning
If you use the table only as an inline element, do not put the sortby field
in the ctrl section, otherwise TYPO3 CMS will sort the entire table with every update.
For example, if you have 10000 records, each with 4 inline elements, TYPO3 CMS will sort 40000 records even
if only 4 must be sorted.
The foreign_table_field is the field of the child record pointing to the parent record. This defines where
to store the table name of the parent record. On setting this configuration key together with
foreign_field, the child record knows what its parent record is –
so the child record could also be used on other parent tables. This issue is also known as "weak entity". Do not
confuse with foreign_table or
foreign_field. It has its own behavior.
Field which must be unique for all children of a parent record.
Example
Say you have two tables, products, your parent table, and prices, your child table (products) can have
multiple prices. The prices table has a field called customer_group, which is a selector box. Now you want to be
able to specify prices for each customer group when you edit a product, but of course you don't want to specify
contradicting prices for one product (i.e. two different prices for the same customer_group). That's why you
would set foreign_unique to the field name "customer_group", to prevent that two prices for the
same customer group can be created for one product.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
This value contains the name of the table in which to store an MM
relation. It is used together with
foreign_table. The
database field with a MM property only stores the number of records
in the relation.
Copying with MM relations will not create a copy of the value. Thus
copying the record Org with Org->orgA and Org->orgB as
New results in New->orgA and New->orgB instead of New->newA
and New->newB. Deleting the relation New->orgA will result in a
broken relation Org->orgA.
MM_opposite_field
MM_opposite_field
Type
string (field name)
Scope
Proc.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
This property can be used to override certain aspects of the child's TCA if that child record is
opened inline of the given parent. Display related TCA properties of the child table can be
overridden in types and columns section.
This works like foreign_field, but in case of using
bidirectional symmetric relations. symmetric_field defines in which field on
the foreign_table the uid of the "other" parent is stored.
This works like foreign_sortby, but in case of using bidirectional
symmetric relations. Each side of a symmetric relation could have its own sorting, so symmetric_sortby
defines a field on the foreign_table where the sorting of the
"other" side is stored. This property requires that the
foreign_field approach is used.
Examples
Note
Inline fields should not be used to handle files. Use the TCA
column type file instead.
Simple 1:n relation
This combines a table (for example companies) with a child table (for example
employees).
The record has two child records displayed inline.
This example combines records from a parent table
tx_styleguide_inline_mn with records from the child table
tx_styleguide_inline_mn_child using the intermediate table
tx_styleguide_inline_mn_mm. It is also possible to add
attributes to every relation – in this example a checkbox.
The parent table tx_styleguide_inline_mn contains the following column:
Record 1 is related to records 6 and 11 of the same table
This example combines records of the same table with each other. Image we want
to store relationships between hotels. Symmetric relations combine records of
one table with each other. If record A is related to record B then record B is
also related to record A. However, the records are not stored in groups. If
record A is related to B and C, B doesn't have to be related to C.
Record 11 is symmetrically related to record 1 but not to 6
The main table tx_styleguide_inline_mnsymmetric has a field storing the
inline relation, here: branches.
Records of the main table can than have a symmetric relationship to each other
using the intermediate table tx_styleguide_inline_mnsymmetric_mm.
The intermediate table stores the uids of both sides of the relation in
hotelid and branchid. Furthermore custom sorting can be defined in
both directions.
TCAdefaults.<table>.pid = <page id> can be used to define the pid of new child records. Thus, it's possible to
have special storage folders on a per-table-basis. See the TSconfig reference.
With a combination box
The combination box shows available records. On clicking one entry it gets
added to the parent record.
<?php
$tempFields = [
'my_new_field2' => [
'label' => 'inline field with field information',
'config' => [
'type' => 'inline',
// further configuration can be found in the examples above// ....
],
],
];
type='input' generates a html <input> field with the type
attribute set to text. It is possible to apply additional features such
as the valuePicker.
The according database field
is generated automatically. For short input fields allowing less
than 255 chars VARCHAR() is used, TEXT for larger input fields.
Extension authors who need or want to override default
TCA schema details for whatever reason, can of course
do so by defining something specific in ext_tables.sql.
Changed in version 13.2
Tables with TCA columns set to type="input" do not
need an ext_tables.sql entry anymore. The Core now
creates this column automatically.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Controls the autocomplete attribute of a given input field. If set to true (default false),
adds attribute autocomplete="on" to the input field allowing browser auto filling the field:
Some of these evaluation keywords will trigger a JavaScript pre- evaluation in the form. Other evaluations will be
performed in the backend. The evaluation functions will be executed in the list-order. Keywords:
alpha
Allows only a-zA-Z characters.
alphanum
Same as "alpha" but allows also "0-9"
alphanum_x
Same as "alphanum" but allows also "_" and "-" chars.
domainname
Allows a domain name such as example.org and automatically transforms
the value to punicode if needed.
is_in
Will filter out any character in the input string which is not found in the string entered in the
property is_in.
lower
Converts the string to lowercase (only A-Z plus a selected set of Western European special chars).
md5
Will convert the input value to its md5-hash using a JavaScript function.
nospace
Removes all occurrences of space characters (chr(32))
num
Allows only 0-9 characters in the field.
trim
The value in the field will have white spaces around it trimmed away.
unique
Requires the field to be unique for the whole table. Evaluated on the server only.
Note
When selecting on unique-fields, make sure to select using AND pid>=0 since the field can contain
duplicate values in other versions of records (always having PID = -1). This also means that if you are using
versioning on a table where the unique-feature is used you cannot set the field to be truly unique
in the database either!
uniqueInPid
Requires the field to be unique for the current PID among other records on the same page.
Evaluated on the server only.
upper
Converts to uppercase (only A-Z plus a selected set of Western European special chars).
year
Evaluates the input to a year between 1970 and 2038. If you need any year, then use "int" evaluation instead.
If the evaluation type "is_in" (see eval) is used for evaluation, then
the characters in the input string should be found in this string as well. This value is also passed
as argument to the evaluation function if a user-defined evaluation function is registered.
Note
The "is_in" value is trimmed during processing, leading and trailing whitespaces are removed. If
whitespaces should be allowed, it should be in between other characters, example a b.
This option allows to define a minimum number of characters for the
<input> field and adds a minlength attribute to the field.
If at least one character is typed in and the number of characters is less
than min, the FormEngine marks the field as invalid, preventing the
user to save the element. DataHandler will also take care for server-side
validation and reset the value to an empty string, if min is not
reached.
When using min in combination with ,
one has to make sure, the min value is less than or equal max.
Otherwise the option is ignored.
Empty fields are not validated. If one needs to have non-empty values, it is
recommended to use required => true in combination with min.
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, the DB column must be allowed
to be NULL, and property nullable must be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved and not a NULL.
This means that the "some_date" field of the "tt_content" table will
be searched in only for elements of type X and Y. This helps making any
search more relevant.
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
Abstract value for the width of the <input> field. To set the input field to the full width
of the form area, use the value 50. Minimum is 10. Default is 30.
Renders a select box with static values next to the input field. When a value is selected in the box,
the value is transferred to the field. Keys:
mode (keyword)
blank (or not set)
The selected value substitutes the value in the input field
append
The selected value is appended to an existing value of the input field
prepend
The selected value is prepended to an existing value of the input field
items (array)
An array with selectable items. Each item is an array with the first value being the label in the select
drop-down (LLL reference possible) the second being the value transferred to the input field.
By this configuration the field will be stripped for any space characters, converted to lowercase, only accepted
if filled in and on the server the value is required to be unique for all records from this table:
'eval' => 'nospace,lower,unique'
Copied!
Custom eval rules
You can supply own form evaluations in an extension by creating a class with three functions, one which returns
the JavaScript code for client side validation called returnFieldJS() and two for the server side:
deevaluateFieldValue() called when opening the record and evaluateFieldValue() called for validation when
saving the record:
<?phpnamespaceMVendor\MyExtension\Evaluation;
/**
* Class for field value validation/evaluation to be used in 'eval' of TCA
*/classExampleEvaluation{
/**
* JavaScript code for client side validation/evaluation
*
* @return string JavaScript code for client side validation/evaluation
*/publicfunctionreturnFieldJS(){
return'return value + " [added by JavaScript on field blur]";';
}
/**
* Server-side validation/evaluation on saving the record
*
* @param string $value The field value to be evaluated
* @param string $is_in The "is_in" value of the field configuration from TCA
* @param bool $set Boolean defining if the value is written to the database or not.
* @return string Evaluated field value
*/publicfunctionevaluateFieldValue($value, $is_in, &$set){
return $value . ' [added by PHP on saving the record]';
}
/**
* Server-side validation/evaluation on opening the record
*
* @param array $parameters Array with key 'value' containing the field value from the database
* @return string Evaluated field value
*/publicfunctiondeevaluateFieldValue(array $parameters){
return $parameters['value'] . ' [added by PHP on opening the record]';
}
}
Copied!
EXT:my_extension/ext_localconf.php
<?phpuseVendor\Extension\Evaluation\ExampleEvaluation;
// ....// Register the class to be available in 'eval' of TCA
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tce']['formevals'][ExampleEvaluation::class] = '';
When using the json type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
Example: Simple JSON field
The system extension
typo3/cms-webhooks
uses a TCA field of type
JSON for the input of additional HTTP request header data:
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Abstract value for the width of the <textarea> field in which the
JSON is displayed. To set the textarea to the full width
of the form area, use the value 50.
In case enableCodeEditor is set to true, which is the default and the
system extension
typo3/cms-t3editor
is installed and active,
the JSON value is rendered in the corresponding code editor.
Otherwise it is rendered in a standard textarea HTML element.
Renders the field in a way that the user can see the values but cannot edit
them. The rendering is as similar as possible to the normal rendering but
may differ in layout and size.
Warning
This property affects only the display. It is still possible to write to those fields when using
the DataHandler.
The number of rows in the JSON editor. May be corrected for harmonization
between browsers. Will also automatically be increased if the content in
the field is found to be of a certain length, thus the
field will automatically fit the content. Default is 5. Max value is 20.
This value can be overridden by page TSconfig.
Language fields
New in version 13.0
When using the language type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
This field type displays all languages available in the current site context.
Outside of the site context it displays all languages available in the
installation.
A special language All languages is automatically added.
The main purpose of the TCA language configuration is to simplify the TCA
language configuration. It therefore supersedes
the special=languages option of TCA columns with type=select.
Formerly foreign_table relations to the table sys_language had also
been used. This became deprecated with the introduction of site
configurations with TYPO3 v9.
This field type decouples the actually available site
languages from the sys_language table.
This TCA type automatically displays all available languages for the
current context (the corresponding site configuration) and also automatically
adds the special -1 language (meaning all languages) for all record
types, except pages.
In records on root level (pid=0) or on a page, outside of a site context,
all languages from all site configurations are displayed in the new field.
Since the TCA type language is mostly based on the type=select internally, most
of the associated TCA and TSconfig options can still be applied. This includes
for example the selectIcons field wizard, as well as the keepItems
and removeItems page TSconfig options.
Migration
An automatic TCA migration is performed on the fly, migrating all occurrences
to the new TCA type and adding a deprecation message to the deprecation log
where code adaption has to take place. Occurrences are all columns, defined as
$TCA['ctrl']['languageField'], as well as all columns, using the
special=languages option in combination with type=select.
Note
The migration resets the whole config array to use the new TCA
type. Custom setting such as field wizards are not evaluated until the TCA
configuration is adapted.
A new TCA field type called language was added to TYPO3 Core with v11.2.
Its main purpose is to simplify the TCA language configuration. It therefore
supersedes the special=languages option of TCA columns with type=select as
well as the now mis-use of the foreign_table option, being set to
sys_language.
Since the introduction of site configurations and the corresponding site
languages back in v9, the sys_language table was not longer the only source
of truth regarding available languages. Actually, the languages, available for
a record, are defined by the associated site configuration.
The language field type therefore allows to finally decouple the actually
available site languages from the sys_language table. This effectively reduces
quite an amount of code and complexity, since no relations have to be fetched
and processed anymore. This also makes the sys_refindex table a bit smaller,
since no entries have to be added for this relation anymore. To clean up your
exisiting reference index, you might use the CLI command
bin/typo3 referenceindex:update.
Another pain point was the special -1 language which always had to be added
to each TCA configuration manually. Thus, a lot of different implementations
of this special case could be found in one and the same TYPO3 installation.
The new TCA type now automatically displays all available languages for the
current context (the corresponding site configuration) and also automatically
adds the special -1 language for all record types, except pages.
Link
New in version 13.0
When using the link type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type link should be used to input values representing typolinks.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field link. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Enables any record link handler that is defined in the LinkHandler API.
To enable only a specific custom LinkHandler, add the defined identifier instead.
// 'record' will match any custom link handler'allowedTypes' => ['page', 'url', 'record']
Copied!
// 'tx_news' and 'custom_identifier' are both custom link handlers'allowedTypes' => ['page', 'url', 'tx_news', 'custom_identifier']
Copied!
// Allow all types (or skip this option).'allowedTypes' => ['*']
Display certain options in the link browser.
To allow all options in the Link Browser, skip this configuration or set
it to ['*']. To deny all options in the Link Browser, set this
configuration to [] (empty array).
class
Custom CSS classes for the link
params
Additional link parameters
target
Either empty, _top or _blank
title
The title attribute of the link
rel
The link relationship. Only available for RTE enabled fields and if buttons.link.relAttribute.enabled
is enabled in the RTE YAML configuration.
// Display only 'class' and 'params''appearance' => [
'allowedOptions' => ['class', 'params'],
],
Copied!
// Allow all options (or skip this option).'appearance' => [
'allowedOptions' => ['*'],
],
Copied!
// Deny all options'appearance' => [
'allowedOptions' => [],
],
Copied!
For custom email links, the options can be restricted:
An array of allowed file extensions. To allow all extensions, skip this
configuration or set it to ['*']. It's not possible to deny all
extensions.
// Allow only jpg and png file extensions'appearance' => [
'allowedExtensions' => ['jpg', 'png'],
],
Copied!
// Allow all file extensions (or skip this option).'appearance' => [
'allowedExtensions' => ['*'],
],
Copied!
browserTitle (string, LLL)
Allows to set a different title attribute for the Link Browser icon, defaults to Link.
// Either provide a LLL-reference (recommended)'appearance' => [
'browserTitle' => 'LLL:EXT:Resources/Private/Language/locallang.xlf:my_custom_title',
],
Copied!
// Or a simple string value'appearance' => [
'browserTitle' => 'My custom title',
],
Copied!
enableBrowser (boolean)
The Link Browser is enabled by default.
To disable the Link Browser altogether, set this option to false.
// Disable the link browser'appearance' => [
'enableBrowser' => false,
],
Controls the autocomplete attribute of a given link field. If set to true (default false),
adds attribute autocomplete="on" to the email input field allowing browser auto filling the field:
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, the DB column must be allowed
to be NULL, and property nullable must be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved and not a NULL.
This means that the "some_date" field of the "tt_content" table will
be searched in only for elements of type X and Y. This helps making any
search more relevant.
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
Abstract value for the width of the <input> field. To set the link
field to the full width of the form area, use the value 50. Minimum is 10.
Default is 30.
Renders a select box with static values next to the input field. When a value is selected in the box,
the value is transferred to the field. Keys:
mode (keyword)
blank (or not set)
The selected value substitutes the value in the input field
append
The selected value is appended to an existing value of the input field
prepend
The selected value is prepended to an existing value of the input field
items (array)
An array with selectable items. Each item is an array with the first value being the label in the select
drop-down (LLL reference possible) the second being the value transferred to the input field.
There are three columns config types that do similar things but still have subtle differences between them.
These are the none type, the passthrough type and the
user type.
Characteristics of none:
The DataHandler discards values send for type none and never
persists or updates them in the database.
Type none is the only type that does not necessarily need a database field.
Type none fields does have a default renderType in FormEngine that displays the value as readonly
if a database field exists and the value can be formatted.
If no database field exists for none fields, an empty readonly input field is rendered by default.
Type none fields are designed to be not rendered at other places in the backend, for instance they can
not be selected to be displayed in the list module "single table view" if everything has been configured
correctly.
The none field can be useful, if:
A "virtual" field that has no database representation is needed. A simple example could be a rendered
map that receives values from latitude and longitude fields but that needs to database representation
itself.
A third party feeds the database field with a value and the value should be formatted and displayed
in FormEngine. However, a input type with readOnly=true is usually better
suited to do that.
Since the formatting part of none fields can be done with input type as well, most useful usage
of type none fields is a "virtual" field that is combined with a custom
renderType by an extension.
The TYPO3 core makes little or no use of none fields itself.
The value of a none-type fields is normally displayed as is. It is however possible to format it using this property.
The following keywords are available, some having sub-properties. Sub-properties are called with the format.
keyword (note the trailing dot), which in itself is an array.
date
Formats the value of the field as a date. The default formatting uses PHP's date() function
and d-m-Y as a format.
Possible options are:
strftime
(boolean) If true, strftime() is used instead date() for formatting.
option
(string) Format string (i.e. Y-m-d or %x, etc.).
appendAge
(boolean) If true, the age of the value is appended is appended to the formatted output.
datetime
Formats the values using PHP's date() function and H:i d-m-Y as a format.
time
Formats the values using PHP's date() function and H:i as a format.
timesec
Formats the values using PHP's date() function and H:i:s as a format.
year
Formats the values using PHP's date() function and Y as a format.
int
Formats the values as an integer using PHP's sprintf() in various bases. The default base is
decimal (dec). The base is defined as an option:
base
(string) Defines the base of the value. Possible bases are "dec", "hex", "HEX", "oct" and "bin".
float
Formats the values as an real number using PHP's sprintf() and the %f marker. The number of
decimals is an option:
precision
(integer) Defines the number of decimals to use (maximum is 10, default is 2).
number
Formats the values as a number using PHP's sprintf(). The format to use is an option:
option
(string) A format definition according to PHP's sprintf()
function (see the reference).
md5
Returns the md5 hash of the values.
filesize
Formats the values as file size using \TYPO3\CMS\Core\Utility\GeneralUtility::formatSize().
One option exists:
appendByteSize
(boolean) If true, the original value is appended to the formatted string (between brackets).
user
Calls a user-defined function to format the values. The only option is the reference to the function:
userFunc
(string) Reference to the user-defined function. The function receives the field configuration and the
field's value as parameters.
When using the number type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type number should be used to input values representing numbers.
The slider option allows to define
a visual slider element, next to the input field. The steps can be
defined with the slider[step]
option. The minimum and maximum value can be configured with the
range[lower] and
range[upper] options.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Controls the autocomplete attribute of a given number field. If set to true,
adds attribute autocomplete="on" to the number input field allowing
browser auto filling the field:
The format property defines, which type of number should be handled. The
integer format is a simple number, whereas the decimal format
is a float value with two decimal places.
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, the DB column must be allowed
to be NULL, and property nullable must be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved
and not a NULL.
The if database field is created automatically, it allow the NULL
value.
Abstract value for the width of the <input> field. To set the number
field to the full width of the form area, use the value 50. Minimum is 10.
Default is 30.
Renders a select box with static values next to the input field. When a value is selected in the box,
the value is transferred to the field. Keys:
mode (keyword)
blank (or not set)
The selected value substitutes the value in the input field
append
The selected value is appended to an existing value of the input field
prepend
The selected value is prepended to an existing value of the input field
items (array)
An array with selectable items. Each item is an array with the first value being the label in the select
drop-down (LLL reference possible) the second being the value transferred to the input field.
There are three columns config types that do similar things but still have subtle differences between them.
These are the none type, the passthrough type and the
user type.
Characteristics of passthrough:
A value sent to the DataHandler is kept as is and put into the database field. However, the default TYPO3 backend forms never send data for a passthrough field.
Unlike the field type none, the field type passthrough must have a database field.
The TYPO3 backend forms do not render anything for passthrough fields by default. But they can be combined with a custom
renderType to display something. A field of type user is better suited for such use cases, though.
Values of passthrough fields are usually not rendered at other places in the backend.
Field updates by the DataHandler get logged and the history/undo function will work with such values.
The passthrough field can be useful, if:
A field needs no rendering, but some data handling using hooks of the DataHandler.
The passthrough type is used by TYPO3 core to handle meta data on records rows that are not shown as fields
if editing records and only have data logic attached to it. An example is the l10n_diffsource field whose
data is rendered differently in FormEngine at other places if editing a record but still updated and handled
by the DataHandler.
Typical usages of the field type passthrough is a field that only needs data evaluation on the DataHandler side, but
no rendering definition. The DataHandler does not evaluate the value in any way by default.
Since there is no rendering mode for this field type it is specifically fitted for direct API usage with the DataHandler.
Examples
This field is found in a number of tables, for instance the "pages" table. It is used by the system extension
"impexp" to store some information.
When using the password type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The TCA type password should be used for input values that represent
passwords.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
By default, the autocomplete=new-password attribute will be added to the
resulting input field. If autocomplete=true is configured in TCA, a
autocomplete=current-password attribute will be added to the element.
If hashed is set to false, if the field value will be saved as
plaintext to the database.
Note
The configuration 'hashed' => false has no effect for all fields in
the tables be_users and fe_users. In general it is not
recommended to save passwords as plain text to the database.
Example: The password will be saved as plain text:
This property is related to the placeholder property. When defined, a
checkbox will appear above the field. If that box is checked, the field can
be used to enter whatever the user wants as usual. If the box is not
checked, the field becomes read-only and the value saved to the database
will be NULL.
Warning
In order for this property to apply properly, the DB column must be allowed
to be NULL, and property nullable must be set to true.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved and not a NULL.
The control
renders a button next to the password field allowing the user to generate
a random password based on defined rules.
Using the control adds the generated password to the corresponding field.
The password is visible to the backend user only once and stored encrypted
in the database. Integrators are also able to define whether the user
is allowed to edit the generated password before saving.
This option assigns a password policy to fields
of the type password. For configured fields, the password policy validator
will be used in DataHandler to ensure,
that the new password complies with the configured password policy.
Password policy requirements are shown below the password field, when the
focus is changed to the password field.
Abstract value for the width of the <input> field. To set the
password field to the full width of the form area, use the value 50. Minimum
is 10. Default is 30.
Examples for using different password policies in TCA
Defines the encoding of random bytes. Overrules character definitions.
"hex"
Generates a random password in hexadecimal format. Example:
d0f4030d568ab483b8442735e9e3a7.
"base64"
Generates a random password in base64 format. Example:
dtbpykd4vf1hda_Ag9kG983y-_N2zyLZzof.
Note
Defining the passwordRules.random
password rule takes precedence over any character definition, which
should therefore be omitted as soon as
passwordRules.random is set to one
of the available encodings: hex or base64.
If set to true, the generated password also contains special
characters (!"#$%&\'()*+,-./:;<=>?@[\]^_{|} `).
Radio buttons
New in version 13.0
When using the radio type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
This type creates a set of radio buttons. The value is typically
stored as integer value, each radio item has one assigned number,
but it can be a string, too.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
This becomes handy when using an IDE and doing operations like renaming classes.
The provided method will have an array of parameters passed to it. The items array is passed by reference
in the key items. By modifying the array of items, you alter the list of items. A method may throw an
exception which will be displayed as a proper error message to the user.
Renders the field in a way that the user can see the value but cannot edit it.
Warning
This property affects only the display. It is still possible to
write to those fields when using the DataHandler.
Select fields
New in version 13.0
When using the select type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file. The field length can be adjusted with the
option .
The according database field
for all render types of select boxes fields are generated automatically.
Introduction
Selector boxes are very common elements in forms. By the "select" type you can create selector boxes. In
the most simple form this is a list of values among which you can choose only one.
There are various shapes of the select type, the images below give an overview. The basic idea is that all
possible child elements are always listed. This is in contrast to the group type which lists only selected
elements and helps with selecting others via element browser and other tools.
The select type is pretty powerful, there are a lot of options to steer both rendering and database handling.
Select TCA type is used to model a static selection of items or a n:1 database relation or a n:m database relation. For database relations the foreign_table TCA option is required.
In case of static items the values of the selected items are stored as CSV content.
In case of n:1 (e.g. Organization has one Administrator) the uid of Administrator is stored in the select column of the Organization.
In case of the n:m (e.g. Organization has multiple categories) the uid of the selected categories are stored either in CSV style inside the select column of the organization or as records in an MM-table, if specified in TCA.
The chosen renderType influences the behaviour of the element and how it will
be displayed.
The following renderTypes are available:
selectSingle: Select one
element from a list of elements
selectSingleBox: Select
one or more elements from a list of elements
selectCheckBox: One or
more checkboxes are displayed instead of a select list.
selectMultipleSideBySide:
Two select fields, items can be selected from the right field, selected
items are displayed in the left select.
selectTree: A tree for
selecting hierarchical data items.
selectSingle
Single select fields display a select field from which only one value can be
chosen.
The renderType selectSingle creates a drop-down box with items to select a
single value. Only if size is set to a
value greater than one, a box is rendered containing all selectable elements
from which one can be chosen.
If set, then values which are not integer ids will be allowed. May be needed
if you use itemsProcFunc or just enter additional items in the items array
to produce some string-value elements for the list.
Note
If you mix non-database relations with database relations like this, DO
NOT use integers for values and DO NOT use "_" (underscore) in values
either! Will not work if you also use "MM" relations!
Authorization mode for the selector box. The only possible option is:
explicitAllow
All static values from the "items" array of the selector box will be added to a matrix in the backend user
configuration where a value must be explicitly selected if a user (other than admin) is allowed to use it!)
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
As TYPO3 takes care of
generating the according database field
for select fields since TYPO3 v13, a developer can adjust the length
of the database field with this option in TCA directly.
The TCA config option dbFieldLength contains an integer value
that is applied to varchar fields (not text) and defines the
length of the database field. It will not be respected for fields that
resolve to an integer type. Developers who wish to optimize field length can
use dbFieldLength for type=select fields to increase or
decrease the default length.
Example: Increase the dbFieldLength for a select field
Excerpt from EXT:my_extension/Configuration/TCA/myextension_domain_model_mytable.php
If set, then no element is inserted if the current value does not match
any of the existing elements. A corresponding options is also found in Page
TSconfig.
Depth of directory recursions. Default is 99. Specify in range from 0-99. 0
(zero) means no recursion into subdirectories. Only useful in combination
with property folder.
This configuration can be overridden by Page
TSconfig.
Specifying a folder from where files are added to the item array.
Specify the folder relative to the
\TYPO3\CMS\Core\Core\Environment::getPublicPath(). See getPublicPath() .
Alternatively use the prefix "EXT:" to point to an extension folder.
Files from the folder are selected recursively to the level specified by
depth
and only files of the extensions defined by
allowedExtensions
are listed in the select box.
Only the file reference relative to the folder is stored.
If the files are images (gif,png,jpg) they will be configured as icons
(third parameter in items array).
This configuration can be overridden by Page
TSconfig.
The items from foreign_table
are selected with this WHERE clause. The WHERE clause is effectively
appended to the existing WHERE clause (which contains default constraints,
such as NOT deleted) and must begin with AND.
Field quoting
The example below uses the special field quoting syntax {#...} around
identifiers to be as DBAL-compatible as possible.
Note that ORDER BY and GROUP BY
should NOT be quoted, since they always receive proper quoting automatically
through the API.
Markers inside the WHERE statement
It is possible to use markers in the WHERE clause:
###REC_FIELD_[field name]###
Any field of the current record.
Note
The field name part of the marker is not in upper case letters.
It must match the exact case used in the database.
So for example sys_language_uid must be referenced using
###REC_FIELD_sys_language_uid###
A value you can set from Page TSconfig dynamically.
###SITE:<KEY>.<SUBKEY>###
A value from the site configuration, for example: ###SITE:mySetting.categoryPid### or ###SITE:rootPageId###.
The markers are preprocessed so that the value of CURRENT_PID and PAGE_TSCONFIG_ID are always integers
(default is zero), PAGE_TSCONFIG_IDLIST will always be a comma-separated list of integers (default is zero)
and PAGE_TSCONFIG_STR will be quoted before substitution (default is blank string).
More information about markers set by Page TSconfig can be found in
the TSconfig reference.
Example: Select single field with foreign_prefix and foreign_where
Contains an array of key-value pairs. The key contains the id of the item
group, the value contains the label of the item group or its language
reference.
Only groups containing items will be displayed. In the select field first all
items with no group defined are listed then the item groups in the order of
their definition, each group with the corresponding items.
Item groups are rendered as <optgroup>.
Item groups can also be defined for items in
foreign tables.
Contains the elements for the selector box unless the property
foreign_table or special has been set in which case
automated values are set in addition to any values listed in this array.
Changed in version 13.0
Auto-registration of New content element wizard via TCA introduced.
If your extension supports both TYPO3 v12 and v13, keep the page TSconfig
option newContentElement.wizardItems
until dropping TYPO3 v12 support.
Items registered for the field CType of table tt_content get
automatically added to the New content element wizard. Settings
from the items property can be overridden via page TSconfig
newContentElement.wizardItems.
Each element in this array is in itself an associative array.
label (string or LLL reference)
The displayed title.
value (integer or string)
The value stored in the database.
The special value --div-- was used to insert a non-selectable
value that appears as a divider label in the selector box. It is kept
for backwards-compatible reasons. Use item groups for custom selects instead.
Values must not contain , (comma) and | (vertical bar). If you want to use authMode, you should
also refrain from using : (colon).
icon (EXT: path or icon identifier)
Optional icon. For custom icons use a path prepended with EXT: to refer to an image
file found inside an extension or use an registered icon identifier. If configured on the foreign_table,
selicon-field is respected.
Fifth value is an optional description text. This is only shown when the list is shown
with renderType='selectCheckBox'.
Note
When having a zero as value and the field is of type int(10) in the database, make sure to define
the default value as well in TCA: 'default' => 0. Otherwise
issues may arise, e.g. with MySQL strict mode.
Example: Simple items definition with label and value
[
'columns' => [
'select_single_1' => [
'label' => 'select_single_1 two items, long text description',
'description' => 'field description',
'config' => [
'type' => 'select',
'renderType' => 'selectSingle',
'items' => [
[
'label' => 'foo and this here is very long text that maybe does not really fit into the form in one line. Ok let us add even more text to see how this looks like if wrapped. Is this enough now? No? Then let us add some even more useless text here!',
'value' => 1,
],
[
'label' => 'bar',
'value' => 'bar',
],
],
],
],
],
]
Copied!
Example: Items definition with label, value and icon
A more complex example could be this (includes icons):
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
In a MM bidirectional relation using
match fields
the opposite side needs to know about the match fields for certain operations
(for example, when a copy is created in a
workspace) so that relations are carried over
with the correct information.
MM_oppositeUsage is an array which references which fields contain
the references to the opposite side, so that they can be queried for match
field configuration.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
The property sortItems allows
sorting of static select items by their values or labels.
Built-in orderings are to sort items by their labels or values.
It is also possible to define custom sorting via PHP code.
When using grouped select fields with
itemGroups, sorting happens
on a per-group basis - all items within one group are sorted - as the
group ordering is preserved.
<?phpdeclare(strict_types=1);
/*
* This file is part of the TYPO3 CMS project.
*
* It is free software; you can redistribute it and/or modify it under
* the terms of the GNU General Public License, either version 2
* of the License, or any later version.
*
* For the full copyright and license information, please read the
* LICENSE.txt file that was distributed with this source code.
*
* The TYPO3 project - inspiring people to share!
*/namespaceTYPO3\CMS\Styleguide\UserFunctions\FormEngine;
/**
* A user function to sort ites
*
* @internal
*/finalclassSelectItemSorter{
/**
* Sort items by their reverse titles
*
* @param array $items
*/publicfunctionsortReverseTitles(&$items): void{
@usort(
$items,
function($item1, $item2){
return strcasecmp(strrev((string)$item1[0]), strrev((string)$item2[0]));
}
);
}
}
Copied!
Select multiple values (selectSingleBox)
This page describes the select type with
renderType='selectSingleBox'.
If set, then values which are not integer ids will be allowed. May be needed
if you use itemsProcFunc or just enter additional items in the items array
to produce some string-value elements for the list.
Note
If you mix non-database relations with database relations like this, DO
NOT use integers for values and DO NOT use "_" (underscore) in values
either! Will not work if you also use "MM" relations!
Authorization mode for the selector box. The only possible option is:
explicitAllow
All static values from the "items" array of the selector box will be added to a matrix in the backend user
configuration where a value must be explicitly selected if a user (other than admin) is allowed to use it!)
Migration: Using authMode='explicitDeny'
The "deny list" approach for single field values has been removed, the only allowed option
for authMode is explicitAllow. Extensions using config value explicitDeny
should be adapted to switch to explicitAllow instead. The upgrade wizard
"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
existing be_groups rows to the new format, drops any DENY fields and instructs
admins to not set new access rights of affected backend groups.
Migration: Using authMode='individual'
Handling of authMode being set to individual has been fully dropped.
The Core provides no alternative. This has been an obscure setting ever since and there is no
direct migration. Extensions that rely on this handling need to find a substitution based on
Core hooks, Core events or other existing Core API functionality.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
As TYPO3 takes care of
generating the according database field
for select fields since TYPO3 v13, a developer can adjust the length
of the database field with this option in TCA directly.
The TCA config option dbFieldLength contains an integer value
that is applied to varchar fields (not text) and defines the
length of the database field. It will not be respected for fields that
resolve to an integer type. Developers who wish to optimize field length can
use dbFieldLength for type=select fields to increase or
decrease the default length.
Example: Increase the dbFieldLength for a select field
Excerpt from EXT:my_extension/Configuration/TCA/myextension_domain_model_mytable.php
If set, then no element is inserted if the current value does not match
any of the existing elements. A corresponding options is also found in Page
TSconfig.
Depth of directory recursions. Default is 99. Specify in range from 0-99. 0
(zero) means no recursion into subdirectories. Only useful in combination
with property folder.
This configuration can be overridden by Page
TSconfig.
Specifying a folder from where files are added to the item array.
Specify the folder relative to the
\TYPO3\CMS\Core\Core\Environment::getPublicPath(). See getPublicPath() .
Alternatively use the prefix "EXT:" to point to an extension folder.
Files from the folder are selected recursively to the level specified by
depth
and only files of the extensions defined by
allowedExtensions
are listed in the select box.
Only the file reference relative to the folder is stored.
If the files are images (gif,png,jpg) they will be configured as icons
(third parameter in items array).
This configuration can be overridden by Page
TSconfig.
The items from foreign_table
are selected with this WHERE clause. The WHERE clause is effectively
appended to the existing WHERE clause (which contains default constraints,
such as NOT deleted) and must begin with AND.
Field quoting
The example below uses the special field quoting syntax {#...} around
identifiers to be as DBAL-compatible as possible.
Note that ORDER BY and GROUP BY
should NOT be quoted, since they always receive proper quoting automatically
through the API.
Markers inside the WHERE statement
It is possible to use markers in the WHERE clause:
###REC_FIELD_[field name]###
Any field of the current record.
Note
The field name part of the marker is not in upper case letters.
It must match the exact case used in the database.
So for example sys_language_uid must be referenced using
###REC_FIELD_sys_language_uid###
A value you can set from Page TSconfig dynamically.
###SITE:<KEY>.<SUBKEY>###
A value from the site configuration, for example: ###SITE:mySetting.categoryPid### or ###SITE:rootPageId###.
The markers are preprocessed so that the value of CURRENT_PID and PAGE_TSCONFIG_ID are always integers
(default is zero), PAGE_TSCONFIG_IDLIST will always be a comma-separated list of integers (default is zero)
and PAGE_TSCONFIG_STR will be quoted before substitution (default is blank string).
More information about markers set by Page TSconfig can be found in
the TSconfig reference.
Example: Select single field with foreign_prefix and foreign_where
Contains an array of key-value pairs. The key contains the id of the item
group, the value contains the label of the item group or its language
reference.
Only groups containing items will be displayed. In the select field first all
items with no group defined are listed then the item groups in the order of
their definition, each group with the corresponding items.
Item groups are rendered as <optgroup>.
Item groups can also be defined for items in
foreign tables.
Contains the elements for the selector box unless the property
foreign_table or special has been set in which case
automated values are set in addition to any values listed in this array.
Defines whether referenced records should be localized when the current
record gets localized. This only applies if references are not stored using
MM tables.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
In a MM bidirectional relation using
match fields
the opposite side needs to know about the match fields for certain operations
(for example, when a copy is created in a
workspace) so that relations are carried over
with the correct information.
MM_oppositeUsage is an array which references which fields contain
the references to the opposite side, so that they can be queried for match
field configuration.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
If set, then values which are not integer ids will be allowed. May be needed
if you use itemsProcFunc or just enter additional items in the items array
to produce some string-value elements for the list.
Note
If you mix non-database relations with database relations like this, DO
NOT use integers for values and DO NOT use "_" (underscore) in values
either! Will not work if you also use "MM" relations!
Authorization mode for the selector box. The only possible option is:
explicitAllow
All static values from the "items" array of the selector box will be added to a matrix in the backend user
configuration where a value must be explicitly selected if a user (other than admin) is allowed to use it!)
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
As TYPO3 takes care of
generating the according database field
for select fields since TYPO3 v13, a developer can adjust the length
of the database field with this option in TCA directly.
The TCA config option dbFieldLength contains an integer value
that is applied to varchar fields (not text) and defines the
length of the database field. It will not be respected for fields that
resolve to an integer type. Developers who wish to optimize field length can
use dbFieldLength for type=select fields to increase or
decrease the default length.
Example: Increase the dbFieldLength for a select field
Excerpt from EXT:my_extension/Configuration/TCA/myextension_domain_model_mytable.php
If set, then no element is inserted if the current value does not match
any of the existing elements. A corresponding options is also found in Page
TSconfig.
Depth of directory recursions. Default is 99. Specify in range from 0-99. 0
(zero) means no recursion into subdirectories. Only useful in combination
with property folder.
This configuration can be overridden by Page
TSconfig.
Specifying a folder from where files are added to the item array.
Specify the folder relative to the
\TYPO3\CMS\Core\Core\Environment::getPublicPath(). See getPublicPath() .
Alternatively use the prefix "EXT:" to point to an extension folder.
Files from the folder are selected recursively to the level specified by
depth
and only files of the extensions defined by
allowedExtensions
are listed in the select box.
Only the file reference relative to the folder is stored.
If the files are images (gif,png,jpg) they will be configured as icons
(third parameter in items array).
This configuration can be overridden by Page
TSconfig.
The items from foreign_table
are selected with this WHERE clause. The WHERE clause is effectively
appended to the existing WHERE clause (which contains default constraints,
such as NOT deleted) and must begin with AND.
Field quoting
The example below uses the special field quoting syntax {#...} around
identifiers to be as DBAL-compatible as possible.
Note that ORDER BY and GROUP BY
should NOT be quoted, since they always receive proper quoting automatically
through the API.
Markers inside the WHERE statement
It is possible to use markers in the WHERE clause:
###REC_FIELD_[field name]###
Any field of the current record.
Note
The field name part of the marker is not in upper case letters.
It must match the exact case used in the database.
So for example sys_language_uid must be referenced using
###REC_FIELD_sys_language_uid###
A value you can set from Page TSconfig dynamically.
###SITE:<KEY>.<SUBKEY>###
A value from the site configuration, for example: ###SITE:mySetting.categoryPid### or ###SITE:rootPageId###.
The markers are preprocessed so that the value of CURRENT_PID and PAGE_TSCONFIG_ID are always integers
(default is zero), PAGE_TSCONFIG_IDLIST will always be a comma-separated list of integers (default is zero)
and PAGE_TSCONFIG_STR will be quoted before substitution (default is blank string).
More information about markers set by Page TSconfig can be found in
the TSconfig reference.
Contains an array of key-value pairs. The key contains the id of the item
group, the value contains the label of the item group or its language
reference.
Only groups containing items will be displayed. In the select field first all
items with no group defined are listed then the item groups in the order of
their definition, each group with the corresponding items.
Item groups are rendered as <optgroup>.
Item groups can also be defined for items in
foreign tables.
Contains the elements for the selector box unless the property
foreign_table or special has been set in which case
automated values are set in addition to any values listed in this array.
Changed in version 13.0
Auto-registration of New content element wizard via TCA introduced.
If your extension supports both TYPO3 v12 and v13, keep the page TSconfig
option newContentElement.wizardItems
until dropping TYPO3 v12 support.
Items registered for the field CType of table tt_content get
automatically added to the New content element wizard. Settings
from the items property can be overridden via page TSconfig
newContentElement.wizardItems.
Each element in this array is in itself an associative array.
label (string or LLL reference)
The displayed title.
value (integer or string)
The value stored in the database.
The special value --div-- was used to insert a non-selectable
value that appears as a divider label in the selector box. It is kept
for backwards-compatible reasons. Use item groups for custom selects instead.
Values must not contain , (comma) and | (vertical bar). If you want to use authMode, you should
also refrain from using : (colon).
icon (EXT: path or icon identifier)
Optional icon. For custom icons use a path prepended with EXT: to refer to an image
file found inside an extension or use an registered icon identifier. If configured on the foreign_table,
selicon-field is respected.
When having a zero as value and the field is of type int(10) in the database, make sure to define
the default value as well in TCA: 'default' => 0. Otherwise
issues may arise, e.g. with MySQL strict mode.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
In a MM bidirectional relation using
match fields
the opposite side needs to know about the match fields for certain operations
(for example, when a copy is created in a
workspace) so that relations are carried over
with the correct information.
MM_oppositeUsage is an array which references which fields contain
the references to the opposite side, so that they can be queried for match
field configuration.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
The field in the database is of type text or varchar.
Select values from a checkbox list
On the contrary the type check saves multiple values
as bits. Therefore if the first value is chosen it stores 1, if only the
second is chosen it stores 2 and if both are chosen 3.
If set, then values which are not integer ids will be allowed. May be needed
if you use itemsProcFunc or just enter additional items in the items array
to produce some string-value elements for the list.
Note
If you mix non-database relations with database relations like this, DO
NOT use integers for values and DO NOT use "_" (underscore) in values
either! Will not work if you also use "MM" relations!
Authorization mode for the selector box. The only possible option is:
explicitAllow
All static values from the "items" array of the selector box will be added to a matrix in the backend user
configuration where a value must be explicitly selected if a user (other than admin) is allowed to use it!)
The size of the select field will be automatically adjusted based on
the number of selected items. The select field will never be smaller than
the specified size and never larger than
the value of autoSizeMax.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
As TYPO3 takes care of
generating the according database field
for select fields since TYPO3 v13, a developer can adjust the length
of the database field with this option in TCA directly.
The TCA config option dbFieldLength contains an integer value
that is applied to varchar fields (not text) and defines the
length of the database field. It will not be respected for fields that
resolve to an integer type. Developers who wish to optimize field length can
use dbFieldLength for type=select fields to increase or
decrease the default length.
Example: Increase the dbFieldLength for a select field
Excerpt from EXT:my_extension/Configuration/TCA/myextension_domain_model_mytable.php
If set, then no element is inserted if the current value does not match
any of the existing elements. A corresponding options is also found in Page
TSconfig.
Control button to directly add a related record. Leaves the current
view and opens a new form to add a new record. On 'Save and close', the
record is directly selected.
Note
The add record control is disabled by default, enable it with
disabled.
Can be one of 'set', 'prepend' or 'append'. With 'set' the given selection
is substituted with the new record, 'prepend' adds the new record on top of
the list, 'append' adds it at the bottom.
Example: Multiple sidebyside select field with "Add record" enabled
Depth of directory recursions. Default is 99. Specify in range from 0-99. 0
(zero) means no recursion into subdirectories. Only useful in combination
with property folder.
This configuration can be overridden by Page
TSconfig.
Specifying a folder from where files are added to the item array.
Specify the folder relative to the
\TYPO3\CMS\Core\Core\Environment::getPublicPath(). See getPublicPath() .
Alternatively use the prefix "EXT:" to point to an extension folder.
Files from the folder are selected recursively to the level specified by
depth
and only files of the extensions defined by
allowedExtensions
are listed in the select box.
Only the file reference relative to the folder is stored.
If the files are images (gif,png,jpg) they will be configured as icons
(third parameter in items array).
This configuration can be overridden by Page
TSconfig.
The items from foreign_table
are selected with this WHERE clause. The WHERE clause is effectively
appended to the existing WHERE clause (which contains default constraints,
such as NOT deleted) and must begin with AND.
Contains the elements for the selector box unless the property
foreign_table or special has been set in which case
automated values are set in addition to any values listed in this array.
Changed in version 13.0
Auto-registration of New content element wizard via TCA introduced.
If your extension supports both TYPO3 v12 and v13, keep the page TSconfig
option newContentElement.wizardItems
until dropping TYPO3 v12 support.
Items registered for the field CType of table tt_content get
automatically added to the New content element wizard. Settings
from the items property can be overridden via page TSconfig
newContentElement.wizardItems.
Each element in this array is in itself an associative array.
label (string or LLL reference)
The displayed title.
value (integer or string)
The value stored in the database.
Values must not contain , (comma) and | (vertical bar). If you want to use authMode, you should
also refrain from using : (colon).
icon (EXT: path or icon identifier)
Optional icon. For custom icons use a path prepended with EXT: to refer to an image
file found inside an extension or use an registered icon identifier. If configured on the foreign_table,
selicon-field is respected.
description (string or array)
Fifth value is an optional description text. This is only shown when the list is shown
with renderType='selectCheckBox'.
Note
When having a zero as value and the field is of type int(10) in the database, make sure to define
the default value as well in TCA: 'default' => 0. Otherwise
issues may arise, e.g. with MySQL strict mode.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
In a MM bidirectional relation using
match fields
the opposite side needs to know about the match fields for certain operations
(for example, when a copy is created in a
workspace) so that relations are carried over
with the correct information.
MM_oppositeUsage is an array which references which fields contain
the references to the opposite side, so that they can be queried for match
field configuration.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
A field with the selectTree render type allows you to represent data in
a hierarchical manner, similar to a tree. It is typically used when working
with database tables that have a hierarchical structure. The properties treeConfig and
foreign_table are mandatory and must be provided to establish the
connection to the relevant database table. Optionally, you can also use
items or itemsProcFunc to pass the values, but these are not
sufficient on their own. The top-level item in the tree will always represent
the descriptive name of the table.
Regarding joining several tables, the selectTree render type can handle multiple
tables through the configuration options.
If set, then values which are not integer ids will be allowed. May be needed
if you use itemsProcFunc or just enter additional items in the items array
to produce some string-value elements for the list.
Note
If you mix non-database relations with database relations like this, DO
NOT use integers for values and DO NOT use "_" (underscore) in values
either! Will not work if you also use "MM" relations!
Authorization mode for the selector box. The only possible option is:
explicitAllow
All static values from the "items" array of the selector box will be added to a matrix in the backend user
configuration where a value must be explicitly selected if a user (other than admin) is allowed to use it!)
Migration: Using authMode='explicitDeny'
The "deny list" approach for single field values has been removed, the only allowed option
for authMode is explicitAllow. Extensions using config value explicitDeny
should be adapted to switch to explicitAllow instead. The upgrade wizard
"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
existing be_groups rows to the new format, drops any DENY fields and instructs
admins to not set new access rights of affected backend groups.
Migration: Using authMode='individual'
Handling of authMode being set to individual has been fully dropped.
The Core provides no alternative. This has been an obscure setting ever since and there is no
direct migration. Extensions that rely on this handling need to find a substitution based on
Core hooks, Core events or other existing Core API functionality.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
As TYPO3 takes care of
generating the according database field
for select fields since TYPO3 v13, a developer can adjust the length
of the database field with this option in TCA directly.
The TCA config option dbFieldLength contains an integer value
that is applied to varchar fields (not text) and defines the
length of the database field. It will not be respected for fields that
resolve to an integer type. Developers who wish to optimize field length can
use dbFieldLength for type=select fields to increase or
decrease the default length.
Example: Increase the dbFieldLength for a select field
Excerpt from EXT:my_extension/Configuration/TCA/myextension_domain_model_mytable.php
If set, then no element is inserted if the current value does not match
any of the existing elements. A corresponding options is also found in Page
TSconfig.
Depth of directory recursions. Default is 99. Specify in range from 0-99. 0
(zero) means no recursion into subdirectories. Only useful in combination
with property folder.
This configuration can be overridden by Page
TSconfig.
Specifying a folder from where files are added to the item array.
Specify the folder relative to the
\TYPO3\CMS\Core\Core\Environment::getPublicPath(). See getPublicPath() .
Alternatively use the prefix "EXT:" to point to an extension folder.
Files from the folder are selected recursively to the level specified by
depth
and only files of the extensions defined by
allowedExtensions
are listed in the select box.
Only the file reference relative to the folder is stored.
If the files are images (gif,png,jpg) they will be configured as icons
(third parameter in items array).
This configuration can be overridden by Page
TSconfig.
The items from foreign_table
are selected with this WHERE clause. The WHERE clause is effectively
appended to the existing WHERE clause (which contains default constraints,
such as NOT deleted) and must begin with AND.
Field quoting
The example below uses the special field quoting syntax {#...} around
identifiers to be as DBAL-compatible as possible.
Note that ORDER BY and GROUP BY
should NOT be quoted, since they always receive proper quoting automatically
through the API.
Markers inside the WHERE statement
It is possible to use markers in the WHERE clause:
###REC_FIELD_[field name]###
Any field of the current record.
Note
The field name part of the marker is not in upper case letters.
It must match the exact case used in the database.
So for example sys_language_uid must be referenced using
###REC_FIELD_sys_language_uid###
A value you can set from Page TSconfig dynamically.
###SITE:<KEY>.<SUBKEY>###
A value from the site configuration, for example: ###SITE:mySetting.categoryPid### or ###SITE:rootPageId###.
The markers are preprocessed so that the value of CURRENT_PID and PAGE_TSCONFIG_ID are always integers
(default is zero), PAGE_TSCONFIG_IDLIST will always be a comma-separated list of integers (default is zero)
and PAGE_TSCONFIG_STR will be quoted before substitution (default is blank string).
More information about markers set by Page TSconfig can be found in
the TSconfig reference.
Example: Select single field with foreign_prefix and foreign_where
Contains the elements for the selector box unless the property
foreign_table or special has been set in which case
automated values are set in addition to any values listed in this array.
Maximum number of child items. Defaults to a high value. JavaScript record
validation prevents the record from being saved if the limit is not satisfied.
Minimum number of child items. Defaults to 0. JavaScript record validation
prevents the record from being saved if the limit is not satisfied.
Note
TCA table column fields that define ['config']['MM'] can omit the
specification of the intermediate MM table layout in
ext_tables.sql. The TYPO3 database
analyzer takes care of proper schema definition.
If you want to make a MM relation editable from the foreign side
(bidirectional) of the relation as well, you need to set
MM_opposite_field on the foreign side to the field name on
the local side.
For example, if the field companies.employees is your local side and
you want to make the same relation editable from the foreign side of the
relation in a field called persons.employers, you would need to set
the MM_opposite_field value of the TCA configuration of the
persons.employers field to the string "employees".
Note
Bidirectional references only get registered once on the native side in
sys_refindex.
In a MM bidirectional relation using
match fields
the opposite side needs to know about the match fields for certain operations
(for example, when a copy is created in a
workspace) so that relations are carried over
with the correct information.
MM_oppositeUsage is an array which references which fields contain
the references to the opposite side, so that they can be queried for match
field configuration.
Additional where clause used when reading MM relations.
Example:
{#uid_local} = ###THIS_UID###
Copied!
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL-compatible as
possible.
MM_hasUidField
MM_hasUidField
Changed in version 13.0
This setting is obsolete. Remove all occurrences of MM_hasUidField
from TCA. The uid column is added as primary key automatically,
if multiple = true is set, otherwise a combined primary key of
fields uid_local, uid_foreign plus eventually
tablenames and fieldname is used.
Registration of a select item group takes place in
Configuration/TCA/tx_mytable.php for new TCA tables, and in
Configuration/TCA/Overrides/a_random_core_table.php
for modifying an existing TCA definition.
For existing select fields additional item groups can be added via the
api method ExtensionManagementUtility::addTcaSelectItemGroup.
When adding a new select field, itemGroups should be added directly in the
original TCA definition without using the API method. Use the API within
TCA/Configuration/Overrides/ files to extend an existing TCA select
field with grouping.
Attaching select items to item groups
Using the API method ExtensionManagementUtility::addTcaSelectItem a
a fourth parameter in the array can be used to specify the id of the item
group.
With the introduction of the itemGroups the TCA column type select has a
clean API to group items for dropdowns in FormEngine. This was previously
handled via placeholder --div-- items,
which then rendered as <optgroup> HTML elements in a dropdown.
In larger installations or TYPO3 instances with lots of extensions, Plugins
or Content Types (tt_content.CType), or custom
Page Types (pages.doktype) drop down lists could grow large and
adding item groups caused tedious work for developers or integrators.
Grouping can now be configured on a per-item
basis. Custom groups can be added via an API or when defining TCA for a new
table.
Slugs / URL parts
The main purpose of this type is to define parts of a URL path to generate and
resolve URLs. The according database field
is generated automatically.
This example uses a custom slug prefix hook via
config['appearance']['prefix'] to adapt the displayed prefix. It takes
the two fields input_1 and input_2 into account for generating
the slug.
<?phpdeclare(strict_types=1);
/*
* This file is part of the TYPO3 CMS project.
*
* It is free software; you can redistribute it and/or modify it under
* the terms of the GNU General Public License, either version 2
* of the License, or any later version.
*
* For the full copyright and license information, please read the
* LICENSE.txt file that was distributed with this source code.
*
* The TYPO3 project - inspiring people to share!
*/namespaceTYPO3\CMS\Styleguide\UserFunctions\FormEngine;
/**
* A user function to compare two fields
*
* @internal
*/useTYPO3\CMS\Backend\Form\FormDataProvider\TcaSlug;
finalclassSlugPrefix{
publicfunctiongetPrefix(array $parameters, TcaSlug $reference): string{
return'custom slug prefix';
}
}
Evaluate if a record is unique in the whole TYPO3 installation (specific to a language).
This option is recommended as it allows to show any record stored inside other sites.
The only downside is that it is not possible to have the same slug on multiple sites.
uniqueInSite
Requires the field to be unique for the current site and language. This allows for multiple records of the same table to have the same slug as long as these records are separated by their sites. Consequently records of a foreign site are not accessible with uniqueInsite since slugs are looked up respecting the current site.
Warning
Be aware that using this option makes it impossible to show records stored inside other sites.
If this is required, unique should be used instead.
uniqueInPid
Requires the field to be unique for the current PID among other records on the same page.
No other eval setting is checked for. It is possible to set different eval options, however it is
recommended not to do so.
The slugs of parent pages will be prefixed to the slug for the page itself.
Disable it for shorter URLs, but take the higher chance of collision into
consideration.
Note
This option is exclusively for page records. It won't have an effect on any other records.
It allows to replace strings of a slug part. Add one of more array items
with the key being the string to replace and the value being the replacement
string.
The method then receives an parameter array with the following values
[
'slug', // ... the slug to be used
'workspaceId', // ... the workspace ID, "0" if in live workspace
'configuration', // ... the configuration of the TCA field
'record', // ... the full record to be used
'pid', // ... the resolved parent page ID
'prefix', // ... the prefix that was added
'tableName', // ... the table of the slug field
'fieldName', // ... the field name of the slug field
];
Defines whether a slug field should contain a prepending slash, for example
for nested categories with speaking segments.
If not set, this defaults to false. (Exception: for the
pages.slug field this defaults to true and cannot be
changed.)
Introduction
The main purpose of this type is to define parts of a URL path to generate and resolve URLs.
With a URL like https://www.typo3.org/ch/community/values/core-values/ a URL slug is typically a part like
/community or /community/values/core-values.
Within TYPO3, a slug is always part of the URL "path" - it does not contain scheme, host, HTTP verb, etc.
A slug is usually added to a TCA-based database table, for example pages. The TCA then contains rules for
evaluation and definition.
When applied to pages a hierarchy of pages is often represented by a combined slug: From each page the
characteristic last part of its slug is used as path segment. The segments are combined into one slug,
separated by slashes. The resulting URL's path is therefore similar to the file paths in common operating
systems.
However, slugs in TYPO3 are not limited to be separated by slashes. It is possible to use other separators.
Furthermore, a single path segment may contain any sign allowed in URLs, including slashes.
It is not required to build hierarchical paths. It is possible to assign a single, unique path segment to
each page in a deep page hierarchy. In TYPO3 the only requirement is that the slug for each
page in a domain must be unique.
If a TCA table contains a field called "slug", it needs to be filled for every existing record. It can
be shown and edited via regular backend forms, and is also evaluated during persistence via DataHandler.
The default behaviour of a slug is as follows:
A slug only contains characters which are allowed within URLs. Spaces, commas and other special characters are
converted to a fallback character.
A slug is always lower-cased.
A slug is unicode-aware.
It is possible to build a default value from the rootline (very helpful for pages, or categorized slugs),
but also to just generate a "speaking" segment from e.g. a news title.
Sanitation and Validation configuration options apply when persisting a record via DataHandler.
In the backend forms a validation happens by an AJAX call, which immediately checks any input and receives
a new proposal in case the slug is already used.
Text areas & RTE
New in version 13.0
When using the text type, TYPO3 takes care of
generating the according database field.
A developer does not need to define this field in an extension's
ext_tables.sql file.
The text type is for multi-line text input, in the database
ext_tables.sql files it is typically set to a TEXT column type.
In the backend, it is rendered in various shapes: It can be rendered as a simple
<textarea>, as a rich text editor (RTE), as a
code block with syntax highlighting, and others.
The following renderTypes are available:
default: A simple text area
or a rich text field is rendered, if no renderType is specified.
belayoutwizard: The backend
layout wizard is displayed in order to edit records of table
backend_layout in the backend.
codeEditor: This render type
triggers a code highlighter.
Changed in version 13.0
In previous TYPO3 versions, the code editor was available via the system
extension "t3editor". The functionality was moved into the system
extension "backend". The render type t3editor was renamed to
codeEditor. A TCA migration from the old value to the new one is
in place.
textTable: The
renderType = 'textTable' triggers a view to manage frontend table
display in the backend. It is used for the "table" tt_content content
element.
Simple text area
A simple text area or a rich text field is rendered, if no renderType is
specified.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
If set to true, the system renders a Rich Text Editor if that is enabled for the editor (default: yes),
and if a suitable editor extension is loaded (default: rteckeditor).
If either of these requirements is not met, the system falls back to a <textarea> field.
You can supply own form evaluations in an extension by creating a class with two functions:
deevaluateFieldValue() called when opening the record and evaluateFieldValue()
called for validation when saving the record:
<?phpnamespaceTYPO3\CMS\Styleguide\UserFunctions\FormEngine;
classTypeText9Eval{
/**
* Adds text "PHPfoo-evaluate" at end on saving
*/publicfunctionevaluateFieldValue(string $value, string $is_in, bool &$set): string{
return $value . 'PHPfoo-evaluate';
}
/**
* Adds text "PHPfoo-deevaluate" at end on opening
*/publicfunctiondeevaluateFieldValue(array $parameters): string{
$value = $parameters['value'];
return $value . 'PHPfoo-deevaluate';
}
}
Copied!
EXT:styleguide/ext_localconf.php
<?php// Register the class to be available in 'eval' of TCA
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tce']['formevals']
['TYPO3\\CMS\\Styleguide\\UserFunctions\\FormEngine\\TypeText9Eval'] = '';
Adds the HTML5 attribute "maxlength" to a textarea. Prevents the field from adding more than
specified number of characters. This is a client side restriction, no server side length restriction
is enforced.
This option allows to define a minimum number of characters for the
<input> field and adds a minlength attribute to the field.
If at least one character is typed in and the number of characters is less
than min, the FormEngine marks the field as invalid, preventing the
user to save the element. DataHandler will also take care for server-side
validation and reset the value to an empty string, if min is not
reached.
When using min in combination with ,
one has to make sure, the min value is less than or equal max.
Otherwise the option is ignored.
Empty fields are not validated. If one needs to have non-empty values, it is
recommended to use required => true in combination with min.
Note
This option does not work for text fields, if RTE is enabled.
If set to true, a checkbox will appear, which by default deactivates the
field. In the deactivated state the field is saved as NULL in the
database. By activating the checkbox it is possible to set a value.
If nothing is entered into the field, then an empty string will be saved and not a NULL.
Extension rte_ckeditor registers three presets: default, minimal and full and points to
YAML files with configuration details.
Integrators may override for instance the default key to point to an own YAML file which will affect
all core backend RTE instances to use that configuration.
If this property is not specified for an RTE field, the system will fall back to the default
configuration. The preset can be overridden with page TSconfig RTE.
The number of rows in the textarea. May be corrected for harmonization between browsers. Will also
automatically be increased if the content in the field is found to be of a certain length, thus the
field will automatically fit the content. Default is 5. Max value is 20.
Does not apply to RTE fields.
A simple text editor with 20 width
.. include:: /Images/Rst/Text4.rst.txt
This means that the "my_editor" field of the "tx_mytable" table will
be searched in only for elements of type X and Y. This helps making any
search more relevant.
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL compatible as
possible.
[
'columns' => [
'text_5' => [
'label' => 'text_5',
'description' => 'wrap=off, long default text',
'config' => [
'type' => 'text',
'wrap' => 'off',
'default' => 'This textbox has wrap set to "off", so these long paragraphs should appear in one line: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean non luctus elit. In sed nunc velit. Donec gravida eros sollicitudin ligula mollis id eleifend mauris laoreet. Donec turpis magna, pulvinar id pretium eu, blandit et nisi. Nulla facilisi. Vivamus pharetra orci sed nunc auctor condimentum. Aenean volutpat posuere scelerisque. Nullam sed dolor justo. Pellentesque id tellus nunc, id sodales diam. Sed rhoncus risus a enim lacinia tincidunt. Aliquam ut neque augue.',
],
],
],
]
[
'columns' => [
'text_6' => [
'label' => 'text_6',
'description' => 'wrap=virtual, long default text',
'config' => [
'type' => 'text',
'wrap' => 'virtual',
'default' => 'This textbox has wrap set to "virtual", so these long paragraphs should appear in multiple lines (wrapped at the end of the textbox): Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean non luctus elit. In sed nunc velit. Donec gravida eros sollicitudin ligula mollis id eleifend mauris laoreet. Donec turpis magna, pulvinar id pretium eu, blandit et nisi. Nulla facilisi. Vivamus pharetra orci sed nunc auctor condimentum. Aenean volutpat posuere scelerisque. Nullam sed dolor justo. Pellentesque id tellus nunc, id sodales diam. Sed rhoncus risus a enim lacinia tincidunt. Aliquam ut neque augue.',
],
],
],
]
The renderType = 'belayoutwizard' is a special renderType to
display the backend layout wizard when editing records of table
backend_layout in the backend. It is stored a custom
syntax representing the page layout in the database.
In previous TYPO3 versions, the code editor was available via the system
extension
typo3/cms-t3editor
. The functionality was moved into
the system extension
typo3/cms-backend
. The render type
t3editor was renamed to
codeEditor.
The code editor provides an enhanced textarea for
TypoScript input, with not only syntax highlighting, but
also autocomplete suggestions. Beyond that the code editor makes it possible to
add syntax highlighting to textarea fields for several languages.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
The number of rows in the textarea. May be corrected for harmonization
between browsers. Will also automatically be increased if the content in
the field is found to be of a certain length, thus the
field will automatically fit the content. Default is 5. Max value is 20.
This means that the "my_editor" field of the "tx_mytable" table will
be searched in only for elements of type X and Y. This helps making any
search more relevant.
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL compatible as
possible.
Migration from render type t3editor to render type codeEditor
The migration from render type t3editor to render type codeEditor is pretty
straight forward: Replace the render type. All other properties stayed the same.
The textTable render type triggers a view called "table wizard" to
manage the frontend table display in the backend. It is used for the "Table"
tt_content content element.
Allows an editor to select in a localized record whether the value is copied
over from default or source language record, or if the field has an own value
in the localization. If set to true and if the table supports localization
and if a localized record is edited, this setting enables FieldWizard
LocalizationStateSelector:
Two or three radio buttons shown below the field input. The state of this is
stored in a json encoded array in the database table called l10n_state.
It tells the DataHandler which fields of the localization records should be kept
in sync if the underlying default or source record changes.
Adds the HTML5 attribute "maxlength" to a textarea. Prevents the field from adding more than
specified number of characters. This is a client side restriction, no server side length restriction
is enforced.
The number of rows in the textarea. May be corrected for harmonization between browsers. Will also
automatically be increased if the content in the field is found to be of a certain length, thus the
field will automatically fit the content. Default is 5. Max value is 20.
This means that the "my_editor" field of the "tx_mytable" table will
be searched in only for elements of type X and Y. This helps making any
search more relevant.
The above example uses the special field quoting syntax {#...}
around identifiers to be as DBAL compatible as
possible.
[
'columns' => [
'text_5' => [
'label' => 'text_5',
'description' => 'wrap=off, long default text',
'config' => [
'type' => 'text',
'wrap' => 'off',
'default' => 'This textbox has wrap set to "off", so these long paragraphs should appear in one line: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean non luctus elit. In sed nunc velit. Donec gravida eros sollicitudin ligula mollis id eleifend mauris laoreet. Donec turpis magna, pulvinar id pretium eu, blandit et nisi. Nulla facilisi. Vivamus pharetra orci sed nunc auctor condimentum. Aenean volutpat posuere scelerisque. Nullam sed dolor justo. Pellentesque id tellus nunc, id sodales diam. Sed rhoncus risus a enim lacinia tincidunt. Aliquam ut neque augue.',
],
],
],
]
[
'columns' => [
'text_6' => [
'label' => 'text_6',
'description' => 'wrap=virtual, long default text',
'config' => [
'type' => 'text',
'wrap' => 'virtual',
'default' => 'This textbox has wrap set to "virtual", so these long paragraphs should appear in multiple lines (wrapped at the end of the textbox): Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean non luctus elit. In sed nunc velit. Donec gravida eros sollicitudin ligula mollis id eleifend mauris laoreet. Donec turpis magna, pulvinar id pretium eu, blandit et nisi. Nulla facilisi. Vivamus pharetra orci sed nunc auctor condimentum. Aenean volutpat posuere scelerisque. Nullam sed dolor justo. Pellentesque id tellus nunc, id sodales diam. Sed rhoncus risus a enim lacinia tincidunt. Aliquam ut neque augue.',
],
],
],
]
There are three columns config types that do similar things, but still have subtle differences between them.
These are the none type, the passthrough type and the
user type.
Characteristics of user:
A value sent to the DataHandler is just kept as is and put into the database field. Default FormEngine
however never sends values.
Unlike none, the type user must have a database field.
FormEngine only renders a dummy element for type user fields by default. It should be combined with a
custom renderType.
Type user field values are rendered as-is at other places in the backend. They for instance can be selected
to be displayed in the list module "single table view".
Field updates by the DataHandler get logged and the history/undo function will work with such values.
The user field can be useful, if:
A special rendering and evaluation is needed for a value when editing records via FormEngine.
Note
In previous versions of TYPO3 core, type='user' had a property userFunc to call an own class
method of some extension. This has been substituted with a custom element using a renderType.
See example below.
Examples
This example is part of the TYPO3 Documentation Team extension
t3docs/examples
.
The example registers an own node element, a TCA field using it and a class
implementing a rendering. See FormEngine docs for more details on this.
The label of a custom field does not get rendered automatically anymore
but must be rendered with $this->renderLabel($fieldId) or
$this->wrapWithFieldsetAndLegend().
Migration
If the custom field is used with TYPO3 v13, add $this->renderLabel($fieldId)
to the output. If your extension should be compatible with both TYPO3 v12.4
and v13 make a version check first and only add this for major versions
larger then 12.
The returned data in $resultArray['html'] will be output in the
TYPO3 Backend as it is passed. Therefore don't trust user input in
order to prevent cross-site scripting (XSS).
The array $this->data consists of the following parts:
The row of the currently edited record in
$this->data['databaseRow']
The configuration from the TCA in
$this->data['parameterArray']['fieldConf']['config']
The name of the input field in
$this->data['parameterArray']['itemFormElName']
The current value of the field in
$this->data['parameterArray']['itemFormElValue']
In order for the field to work, it is vital, that the corresponding
HTML input field has a unique id attribute, fills the
attributes name and data-formengine-input-name with the
correct name, as provided in the itemFormElName.
Note
The returned data in $resultArray['html'] must be valid HTML.
Invalid HTML (e.g. not closed elements) may result in unexpected
behaviour in TYPO3 (e.g. new inline elements not saved).
The field would then look like this in the backend:
The default renderType simply displays a dummy entry, indicating that a
custom renderType should be added. Additional render types can be defined
based on the requirements of the user type field. These render types
determine how the field is displayed and interacted with in the TYPO3
backend, allowing for specialized rendering and user interaction. Custom
render types provide a tailored experience for editing records
via the FormEngine.
Uuid
The main purpose of the TCA type uuid is to simplify the TCA
configuration when working with fields containing a UUID.
In case enableCopyToClipboard is set to true, which is the
default, a button is rendered next to the input field, which allows to copy
the UUID to the clipboard of the operating system.
This column configuration can be overwritten by
page TSconfig.
Abstract value for the width of the <input> field. To set the field
to the full width of the form area, use the value 50. Minimum is 10.
Default is 30.
This column configuration can be overwritten by
page TSconfig.
The version option defines the UUID version to be used. Allowed
values are 4, 6 or 7. The default is 4. For more information
about the different versions, have a look at the corresponding
Symfony documentation.
Table properties (ctrl)
The ctrl section contains properties for a database table in general.
These properties are basically divided into two main categories:
Properties which affect how a table is displayed and handled in
the backend. This includes which icon is shown and which name is given for a record. It defines which
column contains the title value, which column contains the type value etc.
Properties which determine how entries in the backend interface are processed by the system
(TCE). This includes the publishing control, the "deleted" flag, whether a table
can only be edited by admin-users, whether a table may only exist in the tree root etc.
Array to configure additional items in render containers of FormEngine,
see section Node expansion.
Next to single elements, some render container allow to be "enriched" with additional information via
the "node expansion" API. Currently, the OuterWrapContainer implements fieldWizard and
fieldInformation. InlineControlContainer implements fieldWizard and comes with
the default wizard localizationStateSelector. Custom containers may implement expansion nodes, too,
and if implemented correctly will automatically have their configuration merged with the definition
provided in this TCA array.
should be a defined container render type.
You can find more about the outerWrapContainer and
inlineControlContainer in the FormEngine documentation section on
rendering.
Valid types are for example:
outerWrapContainer type which corresponds to the
OuterWrapContainer (class).
inlineControlContainer type which corresponds to the
InlineControlContainer class
inline type which corresponds to the InlineControlContainer
class.
renderType
refers to a registered node name from NodeFactory
before, after
can be set to sort single wizards relative to each other.
disabled
can be used to disable built in default wizards.
options
Some wizards may support additional "options".
Note, next to "fieldWizard", some containers may also implement "fieldInformation", which can be
manipulated the same way.
The fields in this list will automatically have the value of the same field
from the "previous" record transferred when they are copied to the
position after another record from same table.
Example from tt_content table:
crdate
crdate
Type
string (field name)
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Proc.
Field name, which is automatically set to the current timestamp when
the record is created. Is never modified again.
By convention the name crdate is used for that field.
Note
The database field configured in this property is created automatically.
It does not have to be added to the ext_tables.sql.
Example
The following fields are set by the DataHandler automatically on creating or
updating records, if they are configured in the ctrl section of the TCA:
If a field name for sortby is defined, then this is ignored.
Otherwise this is used as the 'ORDER BY' statement to sort the records in the table when listed in the TYPO3 backend.
It is possible to have multiple field names in here, and each can have an ASC or DESC keyword. Note that the value
should not be prefixed with 'ORDER BY' in itself.
Do not confuse this property with sortby: default_sortby should be set only if there
is no sortby. The sortby field (typically set to sorting) contains an integer
for explicit sorting , the backend then shows "up" and "down" buttons to manage sorting of records relative
to each other. The default_sortby should only be set if that explicit sorting is not wanted or useful. For
instance, the list of frontend users is sorted by username and has no other explicit sorting field in the database.
delete
delete
Type
string (field name)
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Proc. / Display
Field name, which indicates if a record is considered deleted or not.
If this "soft delete" feature is used, then records are not really deleted, but just marked as 'deleted' by setting
the value of the field name to "1". In turn, the whole system must strictly respect the record as deleted. This
means that any SQL query must exclude records where this field is true.
This is a very common feature. Most tables use it throughout the TYPO3 Core. The core extension "recycler"
can be used to "revive" those deleted records again.
Example: Enable soft delete for the following table
Field name where description of a record is stored in. This description
is only displayed in the backend to guide editors and admins and should
never be shown in the frontend. If filled, the content of this column is
displayed in the Web > Page and Web > List module, and shown above the field list if
editing a record. It is meant as a note field to give editors important
additional information on single records. The TYPO3 Core sets this
property for a series of main tables like be_users, be_groups and tt_content.
Warning
Columns created automatically by being defined by this property
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like
Configuration/TCA/Overrides/something.php.
Example: Create a table that has a description column
Field name, which – if set – will prevent all editing of the record for non-admin users.
The field should be configured as a checkbox type. Non-admins could be allowed to edit the checkbox but if they
set it, they will effectively lock the record so they cannot edit it again – and they need an Admin-user
to remove the lock.
Note that this flag is cleared when a new copy or version of the record is created.
This feature is used on the pages table, where it also prevents editing of records on that page (except other pages)!
Also, no new records (including pages) can be created on the page.
Warning
Columns created automatically by being defined by this property
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like
Configuration/TCA/Overrides/something.php.
Example: A table with editlock
If the checkbox is set, the affected record can only be edited by admins.
The column definitions for these settings are auto-created.
Specifies which publishing control features are automatically implemented for the table.
This includes that records can be "disabled" or "hidden", have a starting and/or ending time and be access
controlled so only a certain front end user group can access them. This property is used by the
RestrictionBuilder to create SQL fragments.
These are the keys in the array you can use. Each of the values must be a field name in the table which
should be used for the feature:
disabled
Defines which field serves as hidden/disabled flag.
starttime
Defines which field contains the starting time.
endtime
Defines which field contains the ending time.
fe_group
Defines which field is used for access control via a selection of FE user groups.
Note
In general these fields do not affect the access or display in the backend! They are primarily
related to the frontend. However the icon of records having these features enabled will
normally change as these examples show:
Warning
Columns created automatically by being defined by this property
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like
Configuration/TCA/Overrides/something.php.
See also the delete and
features which are related,
but are active for both frontend and backend.
EXT
EXT
Type
array
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
(variable, depends on extension)
User-defined content for extensions. You can use this as you like.
Let's say that you have an extension with the key "myext", then it is ok to define properties for:
['ctrl']['EXT']['myext'] = ... (whatever you define)
Copied!
Note this is just a convention. You can use some other syntax but
with the risk that it conflicts with some other extension or future
changes in the TYPO3 Core.
formattedLabel_userFunc
formattedLabel_userFunc
Type
string
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Display
Similar to label_userFunc but allows
to return formatted HTML for the label and is used only for the labels of
inline (IRRE) records. The referenced user function may receive optional
arguments using the formattedLabel_userFunc_options property.
Options for formattedLabel_userFunc.
The array of options is passed to the user function in the parameters array
with key "options".
groupName
groupName
Type
string
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Special
This option can be used to group records in the new record wizard. If you define a new table and set
its "groupName" to the key of another extension, the table will appear in the list of records from that
other extension in the new record wizard.
We really appreciate you setting the ctrl property title to a localized value (LLL:EXT:), otherwise
it may happen that TYPO3 cannot extract the correct extension key from your table name, resulting in
wrong icons in list of new record wizard. This only happens if your extension key contains
underscores _, but the second part of your table name does not. For example: If your extension key
is my_extension the table names will normally start with tx_myextension. Since myextension does not
match the real extension key my_extension, the icon of your extension cannot be retrieved from your
extension. Instead of a localized title, you can also set groupName to your real extension
key: my_extension.
hideAtCopy
hideAtCopy
Type
boolean
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Proc.
If set, and the "disabled" field from enablecolumns is
specified, then records will be disabled/hidden when they are copied.
See also
It is possible to disable this feature on a page and user or group level using the Page
TSconfig option disableHideAtCopy.
hideTable
hideTable
Type
boolean
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Display
Hide this table in record listings, especially the list module.
iconfile
iconfile
Type
string
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Display
Pointing to the icon file to use for the table. Icons should be square SVGs. In case you cannot supply a SVG you
can still use a PNG file of 64x64 pixels in dimension.
A "static table" means that it should not be updated for individual
databases because it is meant to be centrally updated and distributed.
For instance static tables could contain country-codes used in many
systems.
The foremost property of a static table is that the uid's used are the
SAME across systems. Import/Export of records expect static records to
be common for two systems.
label
label
Type
string (field name)
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Display
Required!
Points to the field name of the table which should be used as the "title"
when the record is displayed in the system.
Note
label_userFunc overrides this
property (but it is still required).
Warning
For the label only regular input or text fields should be used. Otherwise
issues may occur and prevent from a working system if
TCEMAIN.table.tt_content.disablePrependAtCopy is not set or
set to 0.
Comma-separated list of field names, which are holding alternative
values to the value from the field pointed to by "label" (see above)
if that value is empty. May not be used consistently in the system,
but should apply in most cases.
Function or method reference. This can be used whenever the label or
label_alt options don't offer enough flexibility, e.g. when you want
to look up another table to create your label. The result of this
function overrules the label, label_alt
and label_alt_force settings.
When calling a method from a class, enter [classname]->[methodname]. The passed argument is an array
which contains the following information about the record for which to get the title:
$params['table'] = $table;
$params['row'] = $row;
Copied!
The resulting title must be written to $params['title'], which is passed by reference.
Warning
The title is passed later on through htmlspecialchars()
so it may not include any HTML formatting.
Example
Let's look at what is done for the "haiku" table of the "examples" extension. The call to the user function appears
in the EXT:examples/Configuration/TCA/tx_examples_haiku.php file:
This property contains the column name of the column which contains the identifier
language of the record. The column definition is auto-created.
If it is overridden it must still
be of type Language fields.
The column is called sys_language_uid by convention.
Backend users can be limited to have edit access for only certain of
these languages and if this option is set, edit access for languages
will be enforced for this table.
Also see the Frontend Localization Guide
for a discussion about the effects of
this property (and other TCA properties) on the localization process.
Warning
Columns created automatically by being defined by this property
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like
Configuration/TCA/Overrides/something.php.
Migration: Remove language column definitions from TCA
This string will be appended (not prepended, contrary to the name of this option) to the title of a record copy
when it is inserted on the same PID as the original record to distinguish them.
Usually the value is something like (copy %s) which signifies that it was a copy that was just
inserted (The token %s will be replaced by the copy number).
Note it is possible to disable this feature on a page and user or group level using the Page
TSconfig option disablePrependAtCopy.
previewRenderer
previewRenderer
Type
string
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Display
Configures a backend preview for a content element.
Records from this table may not be edited in the TYPO3 backend. Such tables are usually called "static".
If set, this property is often combined with a ext_tables_static+adt.sql file to automatically
populate the table with rows.
rootLevel
rootLevel
Type
[0, 1, -1]
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Proc. / Display
Determines where a record may exist in the page tree. There are three options depending on the value:
0 (false): Default. Can only exist in the page tree. Records from this table must belong to a page
(i.e. have a positive "pid" field value). Thus records cannot be created in the root of the page tree
(where "admin" users are the only ones allowed to create records anyways). This is the default behavior.
1 (true): Can only exist in the root. Records must have a "pid"-field value equal to zero. The consequence
is that only admin can edit this record.
-1: Can exist in both page tree and root. Records can belong either to a page (positive "pid" field value)
or exist in the root of the page tree (where the "pid" field value will be 0 (zero)). Note: the -1 value will
still select foreign_table records for selector boxes only from root (pid=0)
Note
The setting for "rootLevel" is ignored for records in the "pages" table (they are hardcoded to be allowed
anywhere, equal to a "-1" setting of rootLevel).
Warning
This property does not tell the whole story. If set to "0" or "-1", it allows records from the table in the
page tree, but not on any kind of page. By default records can be created only in "Folder"-type pages.
To enable the creation of records on any kind of page,
ignorePageTypeRestriction
must be used.
searchFields
searchFields
Type
string
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Search
Comma-separated list of fields from the table that will be included when searching for records in the TYPO3 backend.
No record from a table will ever be found if that table does not have searchFields defined. Only fields of the
following TCA types are searchable:
When searching as admin the fields uid and pid are automatically included.
For editors, uid and/or pid have to be added manually to the searchFields list.
Allows users to access records that are not in their defined web-mount,
thus bypassing this restriction.
ignoreRootLevelRestriction
Allows non-admin users to access records that are on the root-level
(page ID 0), thus bypassing this usual restriction.
ignorePageTypeRestriction
Allows to use a TCA table on any kind of page doktype unless a doktype
has a restriction set in the PageDoktypeRegistry API class.
selicon_field
selicon_field
Path
$GLOBALS['TCA'][$table]['ctrl']
type
string (field name)
Scope
Display
Field name, which contains the thumbnail image used to represent the record visually whenever it is shown
in FormEngine as a foreign reference selectable from a selector box.
This field must be a File field where icon files are selected. Since only the
first icon file will be used, the option should be used to allow only
selecting a single icon file.
You should consider this a feature where you can attach an "icon" to a record which is typically selected as a
reference in other records, for example a "category". In such a case this field points out the icon image which
will then be shown. This feature can thus enrich the visual experience of selecting the relation in other forms.
Example: Select foreign records from a drop-down using selicon
The table tx_styleguide_elements_select_single_12_foreign is defined as
follows:
Field name, which is used to manage the order of the records when displayed.
The field contains an integer value which positions it at the correct position between other records
from the same table on the current page. It should not be made editable by the user since the
DataHandler will manage the content automatically.
This feature is used by e.g. the "pages" table and "tt_content" table (Content Elements) in order to output the
pages or the content elements in the order expected by the editors. Extensions are expected to respect this field.
Typically the field name sorting is dedicated to
this feature.
Attention
Do not confuse this property with default_sortby. The sortby field contains
an integer and is managed by the DataHandler. If by accident a content column like "title" is set as sortby, the
DataHandler will write these integers into that field, which is most likely not what you want. Use default_sortby
in this case.
Contains the system name of the table. Is used for display in the
backend.
For instance the "tt_content" table is of course named "tt_content"
technically. However in the backend display it will be shown as
"Page Content" when the backend language is English. When another
language is chosen, like Danish, then the label "Sideindhold" is shown
instead. This value is managed by the "title" value.
You can insert plain text values, but the preferred way is to enter a
reference to a localized string. Refer to the Localization
section for more details.
In the above example the LLL: prefix tells the system to look up a
label from a localized file. The next prefix code:EXT:frontend will look for
the data in the extension with the key "frontend". In that extension the
file locallang_tca.xlf contains a XML structure inside of which one
label tag has an index attribute named "sys_template". This tag
contains the value to display in the default language. Other languages
are provided by the language packs.
Column name, by convention
l10n_diffsource, which will be updated with
the value of the original
language record whenever the translation record is updated. This
information is later used to compare the current values of the default
record with those stored in this field. If they differ, there will
be a display in the form of the difference visually. This is a big
help for translators so they can quickly grasp the changes that
happened to the default language text.
The column in the database is auto created. If you ever override it,
it should be at least a large text field (clob/blob). If
you do not define the field in the file ext_tables.sql it is
automatically created with the correct type.
Sometimes l18n_diffsource is used for this field in Core tables.
This has historic reasons.
Warning
Columns created automatically by being defined by this property
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like
Configuration/TCA/Overrides/something.php.
Example: Display changes in from the original language
Name of the column, by convention l10n_parent, used by
translations to point back to the original record, the record in the default
language of which they are a translation.
If this value is found being set together with the
languageField then the
FormEngine will show the default translation value under the fields in
the main form. This is very neat if translators are to see what they are
translating.
Sometimes l18n_parent is used for this field in Core tables. This
is for historic reasons.
Warning
Columns created automatically by being defined by this property
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like
Configuration/TCA/Overrides/something.php.
Name of the field, by convention
l10n_source is used by translations to point back to
the original record (i.e. the record in any language from which they are a
translated).
This property is similar to
transOrigPointerField. Both
fields only contain valid record uids (and not 0), if the record is a
translation (connected mode), and not a copy (free mode). In connected mode,
while transOrigPointerField always contains the uid of the default
language record, this field contains the uid of the record the
translation was created from.
For example, if a tt_content record in default language English with uid
13 exists, this record is translated to French with uid 17, and the
Danish translation is later created based on the French translation, then the
Danish translation has uid 13 set as l10n_parent and 17 as
l10n_source.
The column in the database is auto created. If you ever override it,
it should be at least a large text field (clob/blob). If
you do not define the field in the file ext_tables.sql it is
automatically created with the correct type.
Example: Keep track of the translation origin in connected mode translations
The value of this field determines which one of the types
configurations are used for displaying the fields in the FormEngine. It
will probably also affect how the record is used in the context where it belongs.
The most widely known usage of this feature is the case of Content Elements
where the Type: selector is defined as the "CType" field and when you
change that selector you will also get another rendering of the form:
It is used for example by the "doktype" field in the "pages" table.
On changing the value of the field defined in type the user gets prompted
to reload the record.
Only one type field can be defined. If you need to reload the record on
changing another field, see
property onchange.
It is also possible to make the type depend on the value of a related record,
for example to switch using the type field of a
foreign table. The syntax is relation_field:foreign_type_field.
For example the sys_file_metadata table takes its type from the
sys_file table.
Examples
the type stored in a field
--------------------------
The table tx_styleguide_type table from the "examples" extension defines different types. The field used for differentiating
the types is the "record_type" field. Hence we have the following in the ['ctrl'] section
of the tx_examples_dummy table:
The "record_type" field can take values ranging from 0 to 2. Accordingly we define types for the same values.
Each type defines which fields will be displayed in the BE form:
Array of icon identifiers to use for the records. The keys must correspond to the values found in the column
referenced in the typeicon_column property. The values correspond
to icons registered in the Icon API. With the key default, a default icon is
defined, which is used when no matching key is found. The default icon is also used in the
"Create new record" dialog from the List module. For using and configuring typeicon_classes
for custom page types, please see Create a new Page Type.
Field name, whose value decides alternative icons for the table records.
The values in the field referenced by this property must match entries
in the array defined in typeicon_classes
properties. If no match is found, the default icon is used. See example in the
related typeicon_classes property.
If used, the value of this property is often set to the same field name as type.
Note
The pages table has a special configuration and relies on the $GLOBALS['PAGES_TYPES'] array.
useColumnsForDefaultValues
useColumnsForDefaultValues
Type
string (list of field names)
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Proc.
When a new record is created, this defines the fields from the 'previous' record that should be used as default values.
What is considered the 'previous' record depends on how the record is created. For example, if
TSconfig options.saveDocNew is enabled, you can
create a new record from an existing one using the "New" button.
This may still get overridden by the default values for the record. When assigning values to a new
record the following are used (applied in that order, e.g. Page TSconfig will override User TSconfig):
User TSconfig
Page TSconfig
From 'previous' record
Default values
From 'inline' relations
See \TYPO3\CMS\Backend\Form\FormDataProvider\DatabaseRowInitializeNew->DatabaseRowInitializeNew()
Offline versions are identified by having a pid value = -1 and they
refer to their online version by the field t3ver_oid. Offline
versions of the "Page" and "Branch" types (contrary to "Element" type)
can have child records which points to the uid of their offline "root"
version with their pid fields (as usual). These children records are
typically copies of child elements of the online version of the
offline root version, but are not considered "versions" of them in a
technical sense, hence they don't point to them with their t3ver_oid
field (and shouldn't).
In the backend "Offline" is labeled "Draft" while "Online" is labeled "Live".
In order for versioning to work on a table there are certain requirements;
Tables supporting versioning must have these fields:
t3ver_oid
For offline versions; pointing back to online
version uid. For online: 0 (zero)
t3ver_wsid
For offline versions: Workspace ID of version.
For all workspace Ids apart from 0 (zero) there can be only one
version of an element per ID. For online: 0 (zero) unless t3ver_state
is set in which case it plays a role for previews in the backend (to
no de-select placeholders for workspaces, see
\TYPO3\CMS\Backend\Utility\BackendUtility::versioningPlaceholderClause())
and for publishing of move-to-actions (see
\TYPO3\CMS\Backend\Utility\BackendUtility::getMovePlaceholder()).
t3ver_state
Contains special states of a version used when new, deleted, moved content requires versioning.
For an online version:
"1" or "2" means that it is a temporary placeholder for a new
element (which is the offline version of this record)
If "t3ver_state" has a value >0 it should never be shown in Live workspace.
For an offline version:
"1" or "2" means that when published, the element must be deleted (placeholder for delete-action).
"-1" means it is just an indication that the online version has the flag set to "1" (is a placeholder for
new records.). This only affects display, not processing anywhere.
t3ver_stage
Contains the ID of the stage at which the record is. Special values are "0" which still refers to
"edit", "-10" refers to "ready to publish".
t3ver_count
0/offline=draft/never published, 0/online=current, 1/offline=archive, 1+=multiple online/offline
occurrences (incrementation happens when versions are swapped offline.)
t3ver_tstamp
Timestamp of last swap/publish action.
Changed in version 10.0
Field t3ver_move_id is not evaluated anymore. It can be safely dropped
after the upgrade wizard has been executed.
Corresponding SQL definitions:
t3ver_oid int(11) DEFAULT '0' NOT NULL,
t3ver_wsid int(11) DEFAULT '0' NOT NULL,
t3ver_state tinyint(4) DEFAULT '0' NOT NULL,
t3ver_stage int(11) DEFAULT '0' NOT NULL,
Copied!
Special `t3ver_swapmode` field for pages
When pages are versioned it is an option whether content and even the
branch of the page is versioned. This is determined by the parameter
treeLevels set when the page is versioned. -1 means swap only record,
0 means record and content and '> 0' means full branch. When the version is
later published the swapping will happen accordingly.
versioningWS_alwaysAllowLiveEdit
versioningWS_alwaysAllowLiveEdit
Type
boolean
Path
$GLOBALS['TCA'][$table]['ctrl']
Scope
Special
If set, this table can always be edited live even in a workspace and
even if "live editing" is not enabled in a custom workspace. For
instance this is set by default for Backend user and group records
since it is assumed that administrators like the flexibility of
editing backend users without having to go to the Live workspace.
Auto-created columns from 'ctrl'
New in version 13.3
Default definitions of Field definitions (columns) required by Table properties (ctrl) settings are
now automatically added to TCA if not manually
configured. Extension developers can now remove and avoid a significant amount
of boilerplate field definitions in Field definitions (columns) and rely on TYPO3 core to create
them automatically when dropping TYPO3 v12.4 support.
Certain ctrl settings, such as the enablecolumns and
languageField settings require TCA columns definitions.
Warning
Columns created automatically by being defined in the ctrl section of the TCA
still need to be added manually to the palettes and types definition.
Due to the TCA loading order
these columns are only created if the according ctrl property was added in
the original definition in Configuration/TCA/<tablename>.php, not
if they were defined in the overrides like Configuration/TCA/Overrides/something.php.
Load order when building TCA
To understand if and when TCA column auto-creation from ctrl definitions
kicks in, it is important to have an overview of the order of the single loading
steps:
Load single files from extension Configuration/TCA files
NEW - Enrich columns from ctrl settings
Load single files from extension Configuration/TCA/Overrides files
Apply TCA migrations
Apply TCA preparations
As a result of this strategy, columns fields are not auto-created, when
a ctrl capability is added in a Configuration/TCA/Overrides
file, and not in a Configuration/TCA "base" file. In general, such
capabilities should be set in base files only: Adding them at a later point - for
example in a different extension - is brittle and there is a risk the main
extension can not deal with such an added capability properly.
Overriding definitions from auto-created TCA columns
In most cases, developers do not need to change definitions of columns
auto-created by the Core. In general, it is advisable to not actively do this.
Developers who still want to change detail properties of such columns should
generally stick to "display" related details only.
There are two options to have own definitions: When a column is already defined
in a "base" TCA file (Configuration/TCA), the Core will not override it.
Alternatively, a developer can decide to let the Core auto-create a column, to
then override single properties in Configuration/TCA/Overrides files.
As example, "base" pages file defines this (step 1 above):
When an editor creates a new page, it should be "disabled" by default to
avoid having a new page online in the website before it is set up completely.
A Configuration/TCA/Overrides/pages.php file does this:
<?php// New pages are disabled by default
$GLOBALS['TCA']['pages']['columns']['disabled']['config']['default'] = 1;
Copied!
How to use enablecolumns in the ctrl section of TCA
Migration
Migration: Remove enable column definitions (hidden, starttime, endtime, fe_groups) from TCA
On dropping TYPO3 v12.4 support extensions authors can drop the column
definitions of the enable fields. They need to keep the Grouping fields (palettes) and
Fields to be displayed (types) definitions, however:
In Extbase repositories the records are hidden in the frontend by default,
however this behaviour can be disabled by setting
$querySettings->setIgnoreEnableFields(true) in the
repository.
Property label is a mandatory setting, but the above properties are a recommended
minimum. The list module shows an icon and a translated title of the table, and it uses the value of
field title as title for single rows. Single record administration however is limited with this setup: This
table does not implement soft delete, record rows can not be sorted between each other, record localization is not
possible, and much more. In the database, only columns uid, pid and title are needed
in ext_tables.sql with this setup.
Core table tt_content
Table tt_content makes much more excessive use of the ['ctrl'] section:
When tt_content records are displayed in the backend, the "label" property
indicates that you will see the content from the field named "header"
shown as the title of the record. If that field is empty, the content of field
subheader and if empty, of field bodytext is used as title.
The field called "sorting" will be used to determine the order in
which tt_content records are displayed within each branch of the page tree.
The title for the table as shown in the backend is defined as coming from a "locallang" file.
The "type" field will be the one named "CType". The value of this field determines the set of fields
shown in the edit forms in the backend, see the ['types'] section for details.
Of particular note is the "enablecolumns" property. It is quite extensive for this table since it is a
frontend-related table. Thus proper access rights, publications dates, etc. must be enforced.
Every type of content element has its own icon and its own class, used in conjunction with the
Icon API to visually represent that type in the TYPO3 backend.
In PHP, the node has to implement an interface, but can return any additional HTML which is rendered in the
"OuterWrapContainer" between the record title and the field body when editing a record:
Maximum number of items shown in the List module, if this table is listed
in extended mode (listing only a single table).
Grouping fields (palettes)
If editing records in the backend, all fields are usually displayed after each
other in single rows. Palettes provide a way to display multiple fields next
to each other if the browser window size allows this. They can be used to
group multiple related fields in one combined section.
Each palette has a name and can be referenced by name from within the
['types'] section.
To modify existing palettes you can use the utility functions
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addFieldsToPalette and
ExtensionManagementUtility::addFieldsToAllPalettesOfField.
It is also possible to define the label of a palette directly in the palette
definition. Declaring the label in an 'palettes' array can reduce boilerplate
declarations if a palette is used over and over again in multiple types. If a
label is defined for a palette this way, it is always displayed. Setting a
specific label in the 'types' array for a palette overrides the default label
that was defined within the 'palettes' array. There is no way to unset a label
that is set within the 'palettes' array. It will always be displayed.
If set to true, this palette will never be shown, but the fields of the palette are technically
rendered as hidden elements in FormEngine.
This is sometimes useful when you want to set a field's value by JavaScript from another user-defined field.
You can also use it along with the IRRE (TCA columns type inline)
foreign_selector feature if you don't want the relation
field to be displayed (it must be technically present and rendered though, that's why you should put it to
a hidden palette in that case).
Note
The "isHiddenPalette" concept is more a hack than a solution in current FormEngine code. It has been
introduced for the "FAL" file resource handling to have virtual fields which can be handled in JavaScript
but are not displayed to the editor. It comes with the price of a bunch of HTML that is disabled
via CSS if editing those records in the backend. The core will sooner or later reconsider this solution
and substitute it with something more appropriate. Extension authors should stay away from this property
if possible to not run into upgrade troubles if that happens.
label
label
Type
string
Path
$GLOBALS['TCA'][$table]['palettes']
Allows to display a localized label text as a dedicated entry into the palette declaration, instead as a part of
the types configuration.
By using the explicit label entry, code duplication upon reusing existing palettes can be reduced. The label is
always shown with the palette, no matter where it is referenced.
This string is a comma separated list of field names from ['columns'] section, each field can
optionally have a second, semicolon separated field to override the default label
property of the field.
Instead of a field name, the special keyword --linebreak-- can be used to place groups of fields on
single lines. Note this line grouping only works well if the browser window size allows multiple fields
next to each other, if the width is not sufficient the fields will wrap below each other anyways.
Caution
A field name must only appear once in the entire record. Do not reference
a single field within the showitem
list of a types section and again in a palette used in the same type.
Do not use a field in multiple palettes referenced in a type, or
multiple times in one palette.
The ['types'] section plays a crucial role in TCA to specify which fields from the ['columns'] section
are displayed if editing a table row in FormEngine. At least one type has to be configured before any field
will show up, the default type is 0.
Multiple types can be configured, which one is selected depends on the value of the field specified in
['ctrl']['type'] property. This approach is similar to what is often done with
Single Table Inheritance in Object-orientated
programming.
Creating content elements has been simplified by removing the need to
define the system fields for each element again and again. This shrinks
down a content element's showitem to just the element
specific fields. See also Automatically added system fields to content types (tt_content).
Introduction
The ['types'] system is powerful and allows differently shaped editing forms re-using fields, having own fields
for specific forms and arranging fields differently on top of a single database table. The tt_content with all
its different content elements is a good example on what can be done with ['types'].
So, the basic array has a key field with type names (here '0', and 'anotherType'), with a series of possible
properties each, most importantly the showitem property.
Changed or added ['columns'] field display definitions.
This allows to change the column definition of a field if a record of this type is edited. Currently, it only
affects the display of form fields, but not the data handling.
A typical property that can be changed here is renderType.
The core uses this property to override for instance the "bodytext" field config of table "tt_content": If a record
of type "text" is edited, it adds "enableRichtext = 1" to trigger an RTE to the default "bodytext" configuration,
and if a type "table" is edited, it adds "renderType = textTable" and "wrap = off" to "bodytext".
The FormEngine basically merges "columnsOverrides" over the default "columns" field after the record type
has been determined.
Attention
It is not possible to override any properties in "Proc." scope: The DataHandler does not take "columnsOverrides"
into account. Only pure "Display" related properties can be overridden. This especially means that
columns config 'type' must not be set to a different value.
Name of a palette to show. The label (string or LLL reference) is optional. If set, it is
shown above the single palette fields. The palette name is required and must reference a palette from
the palette section.
--palette--;;caching // Show palette "caching" without additional label
--palette--;Caching;caching // Show palette "caching" with label "Caching"
Copied!
--div--;tabLabel
Put all fields after this token onto a new tab and name the tab as given in "tabLabel" (string or LLL reference).
Note
It is good practice to add a comma in excess behind the very last field name
as shown in the examples above. The FormEngine code will ignore this, but it
helps developers to not forget about a comma when additional fields are
added, which can suppress an annoying "Why is my new field not
displayed?" bug hunt.
Field name, which holds a value being a key in the
subtypes_excludelist array.
This allows to add and hide fields found in the types configuration,
based on the value of another field in the row.
"[field value]" => "[comma-separated list of fields (from the main types-config) which are removed]"
Copied!
Changed in version 13.0
The properties bitmask_excludelist_bits and bitmask_excludelist_bits
been removed, it is not considered anymore when rendering
records in the backend record editing interface.
In case, extensions still use this setting, they should switch to casual
$GLOBALS['TCA']['someTable']['ctrl']['type'] fields instead, which
can be powered by columns based on string values.
Extended examples for using the types section of TCA
The above example shows three fields of the form. Since no further '--div--' are specified, there would be only
one tab. In this case FormEngine will suppress that single tab and just show all specified fields without
a tabbing indicator.
Put three fields on first tab "General" and the two fields "image1" and
"image2" on a second tab with the localized name found in
"EXT:examples/locallang_db.xml:tx_examples_haiku.images".
Similar to the example before, but rename the "General" tab to the string
specified in label "LLL:EXT:examples/locallang_db.xml:tx_examples_haiku.images".
Required type examples
Required type - minimal configuration
The type 0 is required to be defined. It has to have at least the
property showitem defined. A minimal
configuration can be seen here, for example:
The following configuration specifies two tabs: the first one labelled "general"
with three fields "category" "subject" and "message", and the second one
labelled "access" with the field "personal". Only the default type "0" is
specified. Opening such a record looks like this:
Optional additional types
The power of the "types" configuration becomes clear when you want the form
composition of a record to depend on a value from the record. Let's look at the
tx_styleguide_type table from the styleguide
extension. The ctrl section of its TCA contains a property called
:php: type:
This indicates that the field called record_type is to specify the type
of any given record of the table. Let's look at how this field is defined in
the property columns:
There's nothing unusual here. It's a pretty straightforward select field, with
three options. Finally, in the types section, we define what fields
should appear and in what order for every value of the type field:
Type withOverriddenColumns shows the fields and overrides
part of the configuration of the fields:
Note
It is a good idea to give all "types" speaking names, except the default
type 0. Therefore we named the other types withChangedFields
and withOverriddenColumns instead of 1, 2 etc. In a real life example
they should have names from the domain.
Example adding "nowrap" to a text type for type "text"
Migrate plugins with FlexForms added via subtypes_addlist
If you used plugins with the now deprecated subtypes, you probably used
subtypes_addlist to display a
FlexForm for configuration purposes.
Migrate by adding the field pi_flexform with the utility method
ExtensionManagementUtility addToAllTCAtypes() instead. You also have to change the parameters used for
method addPiFlexFormValue():
The fields pages and recursive used to be added
automatically to plugins when using the now outdated subtype "list_type".
Therefore they have to be added manually when doing the migration.
Migrate plugins with fields removed via subtypes_excludelist
Many extension author used the now deprecated option
subtypes_excludelist to hide these automatically added fields.
The same effect can now be used by simply not adding the fields in the first
place:
$pluginSignature = ExtensionUtility::registerPlugin(
'blog_example',
'Pi1',
'A Blog Example',
);
-$GLOBALS['TCA']['tt_content']['types']['list']['subtypes_excludelist'][$pluginSignature]- = 'pages,recursive';
Copied!
Migration: PreviewRenderer for subtypes
When migrating a plugin with a PreviewRenderer from list_type registration to
its own CType change the PreviewRenderer configuration to the record type as
well:
The fields are added to the showitem through their corresponding
palettes. In case such palette has been changed
by extensions, the required system fields are added individually to corresponding tabs.
In case one of those palettes has been changed to no longer
include the corresponding system fields, those fields are added individually
depending on their definition in the Table properties (ctrl) section.
By default, all custom fields - the ones still defined in showitem - are
added after the general palette and are therefore added to the
General tab, unless a custom tab (for example Plugin,
or Categories) is defined in between. It's also possible to start
with a custom tab by defining a --div-- as the first item in the
showitem. In this case, the General tab will be omitted.
All those system fields, which are added based on the ctrl section are
also automatically removed from any custom palette and from the customized
type's showitem definition.
If the content element defines the Extended tab, it will be
inserted at the end, including all fields added to the type via API methods,
without specifying a position, via
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTcaTypes(). See
Extended content element with custom fields for an example.
Examples for the showitems TCA section in content elements
Basic custom content element with header and bodytext
<?phpuseTYPO3\CMS\Core\Utility\ExtensionManagementUtility;
// Add the content element to the "Type" dropdown
ExtensionManagementUtility::addTcaSelectItem(
'tt_content',
'CType',
[
'label' => 'My extension basic text element',
'value' => 'my_extension_basic_text',
],
);
// Add the predefined fields to the "General" tab
$GLOBALS['TCA']['tt_content']['types']['my_extension_basic_text']['showitem'] =
'--palette--;;headers,bodytext,';
Copied!
The following tabs are shown, the header palette and bodytext field are shown
in palette general:
<?phpuseTYPO3\CMS\Core\Utility\ExtensionManagementUtility;
// Add the content element to the "Type" dropdown
ExtensionManagementUtility::addTcaSelectItem(
'tt_content',
'CType',
[
'label' => 'My extension custom text element with links',
'value' => 'my_extension_extended-text',
'icon' => 'my-extension-content-text',
'group' => 'default',
'description' => 'Some descripton',
],
'textmedia',
'after',
);
// Define some custom columns
$additionalColumns = [
'my_extension_link' => [
'label' => 'My link',
'config' => [
'type' => 'link',
],
],
'my_extension_link_text' => [
'label' => 'My link text',
'config' => [
'type' => 'input',
],
],
'my_extension_extra_text' => [
'label' => 'My extra text',
'config' => [
'type' => 'input',
],
],
];
// Add the custom columns to the TCA of tt_content
ExtensionManagementUtility::addTCAcolumns('tt_content', $additionalColumns);
// Add predefined and custom fields to the "General tab" and introduce a tab called "Extended"
$GLOBALS['TCA']['tt_content']['types']['my_extension_extended-text']['showitem'] = '
--palette--;;headers,
bodytext,
--div--;My tab,
my_extension_link,
my_extension_link_text,
--div--;LLL:EXT:core/Resources/Private/Language/Form/locallang_tabs.xlf:extended,';
// This field will be added in tab "Extended"
ExtensionManagementUtility::addToAllTCAtypes(
'tt_content',
'my_extension_extra_text',
'my_extension_extended-text'
);
Copied!
The following tabs are shown:
Additional fields that are subsequently added to the end of the table using
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTcaTypes()
will appear in the tab Extended.
Migration: Remove system fields from showitems on dropping TYPO3 v12.4 support
It is sufficient to apply changes to the showitem section
of content types once dropping TYPO3 v12.4 support in extensions.
In site packages or extensions only supporting TYPO3 v13.3 or above you can
migrate the showitem right away: