Directory structure of a content block¶
Although the classic structure of a TYPO3 extension is easier to understand for TYPO3 developers, we chose to use the Symfony compliant src/dist structure instead. As TYPO3 uses more and more of Symfony it could be beneficial, especially for people new to TYPO3, to get used to these structures. Also, src/dist is more easy to understand by frontend developers as this kind of naming is also common there.
| Directory / File | Mandatory? | Could be created by a generator |
|---|---|---|
| composer.json | x | x |
| ContentBlockIcon.(svg/png/gif) | x | x |
| EditorInterface.yaml | x | x |
| src/Language/Default.xlf | x | x |
| src/EditorPreview.html | x | |
| src/Frontend.html | x | |
| dist/EditorPreview.css | x | |
| dist/Frontend.css | x | |
| dist/Frontend.js | x |
Content block package files explained¶
composer.json¶
refers to: Composer schema
The content block ID (CType) derives from the package name. Therefore one composer package represents exactly one content block.
You must
- provide this file
- set the type property to: typo3-cms-contentblock
You may
- use the full composer.json config and define autoloading for ViewHelpers etc.
EditorInterface.yaml¶
refers to: YAML RFC
The content block ID (CType) derives from the package name. Therefore one composer package represents exactly one content block.
You must
- provide this file
- define the editor interface of exactly one content block
- define all the fields and their position in the editing interface
ContentBlockIcon.(svg|png|gif)¶
This is the icon for the content block. There is no fallback by intention, but it is easy to generate an SVG with the content block name as a graphical representation.
You must
- provide this file
- provide that file in the format svg or png or gif
- provide a file with 1:1 dimensions
src/Language/Default.xlf¶
You may
- provide that file
- define your labels with the XLF links in the configuration file