Glossary
TCA (Table Configuration Array)
The configuration that decides how database fields appear and are validated in the TYPO3 backend.
What the TCA is good for
The Table Configuration Array describes, for every database table, how TYPO3 deals with it in the backend. It is the reason a new field does not merely exist in the database but also shows up as a labelled input in the right place.
Technically it is a large, nested PHP array. That sounds more unwieldy than it feels: in practice you work with manageable sections for individual fields.
Field types
The TCA knows a range of types that cover most of practice: single-line and multi-line text, selection fields with fixed values or values read from the database, date and time, references to files, relations to other records, and checks such as required or valid email address.
Anyone who wants a good editing interface spends more time here than anywhere else. A well-chosen field type with a clear label saves a great many follow-up questions later.
How it relates to Extbase
In Extbase extensions the model describes the data from the code’s point of view and the TCA from the backend’s. The two have to match: every property in the model needs a column in the table and, as a rule, an entry in the TCA.
Where they diverge, the errors are unpleasant to find, because something is missing in the backend without any message appearing anywhere.
Where the TCA sits in a project
For a table of your own, the configuration lives in Configuration/TCA/ under the table name. When an existing table only needs extending, an extra field on pages or on content elements for instance, that belongs in Configuration/TCA/Overrides/.
The separation matters because TYPO3 treats the two places differently. Redefine somebody else’s table completely instead of overriding it and you take away everything the core and other extensions have registered there.
The TCA is not the database schema
A common misunderstanding: the TCA does not create columns. The structure of the table sits in ext_tables.sql; the TCA only describes how TYPO3 deals with the columns that exist.
If the column is missing but the TCA is there, the backend shows a field whose content lands nowhere. The other way round, the column exists but is invisible in the backend. At first glance, both cases look like a fault somewhere else entirely.
Types and palettes
columns describes the individual fields, types defines which of them appear in a form and in what order. That is why a text content element looks different from an image element even though both live in the same table.
palettes groups several fields so they sit side by side on one line. This is not a question of looks: a form with thirty fields stacked one under the other does not get read, it gets scrolled past.
columnsOverrides lets a field be configured differently per type, for instance as required only where it is genuinely needed.
Showing and hiding fields
displayCond shows or hides a field depending on another value. Make a choice and you only see the fields that belong to that choice.
Used sparingly, it is one of the most effective tools for a tidy interface. Overused, it produces a form whose behaviour nobody can predict any more.
Why changes sometimes do not arrive
The TCA is cached. Change a file and see nothing in the backend and, in most cases, you are looking at the cache rather than at a fault in the configuration.
With approaches such as Content Blocks or Mask the TCA is generated from a more compact description. It does not disappear that way; it is simply no longer written by hand.