Storing the changes
There are various ways to store changes to $GLOBALS
. They
depend - partly - on what you are trying to achieve and - a lot -
on the version of TYPO3 CMS which you are targeting. The TCA can only be
changed from within an extension.
Changed in version 14.0
There are two changes for \TYPO3\
.
The second argument $type
and the third argument $extension
have been dropped.
Storing in extensions
The advantage of putting your changes inside an extension is that they are nicely packaged in a self-contained entity which can be easily deployed on multiple servers.
The drawback is that the extension loading order must be finely controlled. However, in case you are modifying Core TCA, you usually don't have to worry about that. Since custom extensions are always loaded after the Core's TCA, changes from custom extensions will usually take effect without any special measures.
In case your extension modifies another extension, you actively need to make sure your extension is loaded after the extension you are modifying. This can be achieved by registering that other extension as a dependency (or suggestion) of yours. See the description of constraints in Core APIs.
The loading order also matters if you have multiple extensions overriding the same field, probably even contradicting each other.
Files within Configuration/
files are loaded
within a dedicated scope. This means that variables defined in those files
cannot leak into the following files.
For more information about an extension's structure, please refer to the extension architecture chapter.
Storing in the Overrides/
folder
Changes to $GLOBALS
must be stored inside a folder called Configuration/
.
For clarity files should be named along the pattern
<tablename>.
.
Thus, if you want to customize the TCA of tx_
,
you need to create the file Configuration/
.
The advantage of this method is that all such changes are incorporated into
$GLOBALS
before it is cached. This is thus far more efficient.
Note
All files within Configuration/
will be loaded, you are not forced
to have a single file for table "tt_content" for instance. When dealing with custom
content elements this file can get 1000+ lines very quickly and maintainability can get
hard quickly as well.
Also names don't matter in that folder, at least not to TYPO3. They only might influence
loading order. Proper naming is only relevant for the real definition of tables one
folder up in Configuration/
Attention
Be aware that you cannot extend the TCA of extensions if it was configured within
its ext_
file, usually containing the "ctrl" section
referencing a "dynamicConfigFile". Please ask the extension author to switch
to the Configuration/
setup.
Attention
Only TCA-related changes should go into Configuration/
files. Some API calls may be okay as long as they also manipulate only
$GLOBALS
. For example, it is fine to register a plugin with
\TYPO3\
in
Configuration/
because that API call only
modifies $GLOBALS
for table tt_
.
Changing the TCA "on the fly"
It is also possible to perform some special manipulations on
$GLOBALS
right before it is stored into cache, thanks to the
PSR-14 event AfterTcaCompilationEvent.