Glossary
Content Blocks
An approach for defining custom content elements compactly, instead of spreading the configuration across several files.
What the approach solves
Custom content elements are needed in almost every TYPO3 project. The classic route spreads their definition across several files, which works but means hunting in several places for one small change.
Content Blocks gather what belongs together: fields, labels and template sit side by side. An element is recognisable as a unit and can be moved or removed as a whole.
What it changes for editors
From the editorial point of view, nothing changes. A content element looks the same in the backend regardless of how it was defined.
The difference lies in maintainability on the development side, and therefore indirectly in how quickly a change request can be carried out.
When the classic route stays
There are cases where the more verbose configuration through the TCA still fits better, for instance with very specific field types or when an element is closely interlocked with an existing extension.
Using both side by side is possible. What matters is picking one line for the project and documenting it, so half the elements are not built one way and half the other.
How a Content Block is put together
A Content Block is a directory. Inside sits a description of the fields, the labels for the interface, the Fluid template for the output, and everything else that belongs to it, such as a preview image for the selection list in the backend.
From that description the extension generates what TYPO3 expects anyway: the entries in the TCA, the necessary database column, and the connection to the template. The classic route is not abolished, it is simply no longer written by hand.
Not only content elements
The same approach covers page types. A custom page type with fields of its own, for a press release with a date and a contact person say, is created the same way as a content element.
That is the practical advantage over the notion that this is only about a few form fields: what is held together is a structure, not a collection of inputs.
The identifier is the real decision
Every block carries an identifier, and table values, field names and language keys are derived from it. It ends up in the editors’ data.
Changing it afterwards is therefore not a rename but a data migration. Spend ten minutes on naming at the start and you reliably save that later. The same goes for the field names inside a block.
How it relates to Mask
Mask pursues a similar goal by a different route: there, elements are clicked together through an interface in the backend; here they are described in files in the sitepackage.
The difference is less about features than about how you work. What sits in files sits in Git, can be reviewed and travels with a deployment. What is created in the backend is there faster but has to be moved between environments some other way.
Limits
For the great majority of content elements the approach is enough. It reaches its limits where an element is closely interlocked with logic of its own: custom database queries, form processing, a connection to an interface.
An Extbase extension is the better home then, and the Content Block stays with what it is meant for: structured content that editors maintain.