Autoloader: Speed up Extension Development 

Rendered

Wed, 22 Jul 2026 20:01:31 +0000

Classification

autoloader

Keywords

forEditors, forAdmins, forBeginners, forIntermediates

Author

Tim Lochmüller, Carsten Biebricher, Tim Spiekerkötter

Email

tim.lochmueller@hdnet.de, carsten.biebricher@hdnet.de

Language

en

Introduction 

What does it do? 

This extension implements a framework for autoload mechanisms for 3rd party extension. There are different loader for different extension targets. The aim of the extension is a smart "Convention over configuration" pattern to reduce the amount of configurations in e.g. ext_tables, ext_localconf. To get more details for each loader, please read the technical general section first. After the general integration you are ready to learn something about the loaders.

Need help? 

Loader 

Here we describe the different implemented Loader.

Alternative Implementations 

The alternative implementations mechanism, works like the xclass mechanism. The loader reflect the original class and register the class as implementation to the ObjectContainer ("ObjectContainer->registerImplementation"). This is just a alternative handling for extending classes/interfaces.

Command Controller 

The "CommandController" autoloader register all command controller for the new handling of the scheduler in the extbase-way. The loader expect the command controller classes in the Classes/Command/ folder of the given extension. All classes will be analyzed and finally registered to the TYPO3_CONF_VARS.

Content Objects 

Content objects are a sub type of smart objects (the loader register the content object as smart objects, to get all smart object functions) and placed in this folder: "Classes/Domain/Model/Content/". Content objects always extends the tt_content table and need a "@TYPO3CMSExtbaseAnnotationDatabase tt_content" annotation (see smart objects). You can use existing fields on the one hand and create other custom fields on the other hand. Each content object is registered as CType in the TYPO3 content element handling. There is one central Controller that render the CTypes and take care, that the right domain model is selected and the right template ist rendered. The template location is "Resources/Private/Templates/Content/" and the template has the same name as the domain model (also upper camel case). There are two possibilities to get access to the data. You can access "data" and "object" in fluid. Data is the whole database row and object is the domain model with the mapped properties.

If you do not want to use the css_styled_content default header, please add the @noHeader annotation to the content object.

Summarize: Create a domain model, create a template, maybe run database compare, create and use the new content element.

Context Sensitive Helps 

This loader check the smart objects and create language files for the context sensitive help function of TYPO3. The XML files are generated based on the current state of the model. Use the loader, after you finish the modelling process is the right way.

The loader build a base structure. You have to insert the additional help text by yourself.

ExtensionId (eID) 

The ExtensionId loader loads the classes in from the folder "Resources/Private/Php/eID/" and register the PHP files in this folder as TYPO3 eID scripts. The identifier of the eID script is the file base name. If the script file is "Register.php" you can access the script via "/?eID=Register". Please use internally service classes to control the application.

Extension TypoScript 

This loader register additional TypoScript to the rendering process to describe the model in detail. All annotations are class annotations and no method annotations. Possible annotations and results are...

@db The annotation is also used by the smart object handling. If a model is tagged with @db this loader will add the following line the the TS: config.tx_extbase.persistence.classes.YOURCLASSName.mapping.tableName = target_table_with_db_annotation

@recordType The annotation is used, if the current model is part of a record type set. After the tag you have to define the record type field. The annotation generate and register in the following line of TS: config.tx_extbase.persistence.classes.YOURCLASSName.mapping.recordType = record_type_field

@parentClass The annotation is used, if the current model is part of a subclass set. After the tag you have to define the subclass name. The annotation generate and register the following TS: config.tx_extbase.persistence.classes.YOURCLASSName.subclasses.YOURClassSubclassName = YOURCLASSName

!!!Important!!!

This old Mapping via TypoScript is deprecated and old. Please use the more modern Mapping via Configuration/Extbase/Persistence/Classes.php and call the Utility function in the file like return HDNETAutoloaderUtilityExtbasePersistenceUtility::getClassMappingForExtension('your_extension_key');

FlexForms 

FlexForms are located in the "Configuration/FlexForms/" folder. All flex forms are XML files (please check TYPO3 core documentation) with the name of the plugin (upper camel case). The loader scans the folder and register the XML files to the TYPO3 core. So: Just use the same name for your Plugin and flex form file.

If there are FlexForms in the "Configuration/FlexForms/Content/" folder, the configuration XML files are related to Autoloader content objects and will be registered to the content element. In the content element, you can access the configuration values via settings, link in extbase.

Gridelements 

There are several places for the gridelements configuration. All labels are added automatically to your L10N files (xlf, xml). This are the important paths:

• Resources/Private/Grids/[xxx].[ts|txt|typoscript]

• Resources/Public/Icons/Grids/[xxx].[png|svg|gif|jpg]

• Configuration/FlexForms/Grids/[xxx].xml

Headless Json 

Headless Json is a sub type of content objects (the loader register the headless json as smart objects, to get all smart object functions) and generates the typoscript needed to serialize the content object into json into this directory: "Resources/Private/TypoScript/Content/ContentObjec.typoscript".

If the @noHeader annotation is present on the content object, no header will be included in the output. If an object or an object storage of an object is specified in the @databaseField annotation, it will be serialized with all of its properties. This is done recursively for all relations. The loader (in case of an object storage) identifies the foreign key from the domain model, to which the object storage points (property with type equal to the current type). Many to many relations are not correctly selected as of now.

Hooks 

Hooks are located in the folder "Classes/Hooks". The loader scan the directory and check the classes via PHP reflection against certain annotations. The keyword is "@hook" and the class or method (based on the target hook) have to be marked with this keyword. If the keyword ist part of the class PHPDoc, the hook register the class name and if the annotation is part of a method PHPDoc the autoloader will register the method (TYPO3 syntax class name -> method name) to the given hook.

To define the target of the hook (in TYPO3 normally a array path in TYPO3_CONF_VARS) you have to set the target after the @hook annotation, separated by pipes. Example:

/**
 * Description
 *
 * @hook TYPO3_CONF_VARS|SC_OPTIONS|recordlist/mod1/index.php|drawFooterHook
 */
function testFunction(){
	// do something
}

Language Override 

Use this loader to create "locallangXMLOverride" configurations for language files. Recreate the same folder structure of the extension whose language files you want to override within Resources/Private/Language/Overrides. The first level is the extension name (UpperCamelCase). For XLIFF files language prefixes like de.locallang_mod.xlf are supported to register overrides for translations.

For example to override EXT:foo_bar/mod1/locallang_mod.xlf just create the file Resources/Private/Language/Overrides/FooBar/mod1/locallang_mod.xlf and fill it with language entries. To override EXT:foo_bar/mod1/de.locallang_mod.xlf create Resources/Private/Language/Overrides/FooBar/mod1/de.locallang_mod.xlf.

Even if an extension follows the usual Resources/Private/Language structure, you still have to recreate that structure within Resources/Private/Language/Overrides, e.g. Resources/Private/Language/Overrides/BazQux/Resources/Private/Language/locallang.xlf.

Internally the following kind of configuration will be generated:

$TYPO3_CONF_VARS['SYS']['locallangXMLOverride']['default']['EXT:baz_qux/Resources/Private/Language/locallang.xlf'][] = 'EXT:my_ext/Resources/Private/Language/Overrides/BazQux/Resources/Private/Language/locallang.xlf';
$TYPO3_CONF_VARS['SYS']['locallangXMLOverride']['de']['EXT:baz_qux/Resources/Private/Language/locallang.xlf'][] = 'EXT:my_ext/Resources/Private/Language/Overrides/BazQux/Resources/Private/Language/de.locallang.xlf';

Plugins 

The "Plugins" Loader check all controller and search for actions with the "@plugin" annotation. The plugin annotation register plugins for the given controller in the ext_localconf and ext_tables process. It is possible to annotate actions in different controllers to build one plugin. But please take care, which action is the default action. If the specific action is a non cachable method, just add the "@noCache" to register this action as noCache action.

The plugin labels are translated via the extension localization mechanism.

Note: You can add a "!" after the Plugin name in the method comment to set this action to the default action.

Slots 

The "Slots" Loader scans the "Classes/Slots" folder, to connect the given class methods to specific signals. All class will be checked. The slot methods have to annotate with "@signalClass" and "@signalName" to point to the target signal. So it is possible to connect one slot class with many signals.

SmartObjects 

"SmartObjects" are the base for the content objects and help the developer to speed up the development, if there are persistent models. All smart objects have a "@db" annotation on the given class. If the model is mapped to a existing table, you have to add the table name like "@db tt_content". In this case, the create table statement is create without the TYPO3 default fields like e.g. tstamp, crdate, sorting.

In addition, it is possible to add one or more key / index definitions for the table with the @key annotation as follows: "@key key_name (column_name_1, column_name_2)" Caution: There is currently no validation of whether the key columns are present. Like any changes in the @db definitions, even @key needs to visit the installtool and start comparing the database. Alternatively, the typo3_console extension can do this on the command line.

Furthermore the properties should have also a "@db" annotation, if the property is stored in the database. The field definition determined by the variable type of the property. If the variable contains a complex data type, you have to add a proper field definition like "@db int(11) NOT NULL" on the right field.

return \HDNET\Autoloader\Utility\ExtbasePersistenceUtility::getClassMappingForExtension('extension_key');

Static TypoScript 

These loader loads all setup and/or constants text files, that are in the "Configuration/TypoScript" folder structure and add them as static TypoScript include to TYPO3. The search for this text files is recursively. If there are same files in a deeper folder structure, the folder name will also added to the registration to differ between the different TypoScripts.

TCA Files 

This loader check all smart objects and create the right TCA folder and file structure. The TCA is build on a smart object manager preset (dynamic). The developer can customize this configuration in the different TCA files.

TypeConverter 

The TypeConverter loads the recursively the type converter from the directory "Classes/Property/TypeConverter/" and register them as ExtBase type converter. All classes that are instantiable will be registered.

Xclass 

All Xclasses (Attention: This is the new TYPO3_CONF_VARS/SYS/Objects mechanism and not the old Xclass mechanism) in the folder "Classes/Xclass" will be registered. The classes are reflected and registered to the TYPO3 core. Just create a own class, extend an existing class and the loader will do the magic!

Technical Information 

General 

The autoloader has a simple API, that take care to trigger the different loaders of the autoloader extension. In the ext_localconf and ext_tables files of your extension, you have to trigger the static loader function. Furthermore you have to set autoloader in the dependencies of your extensions ext_emconf (so the extensions are load in the right order).

To trigger the autoloader, please add the following lines to your ext_localconf.php and ext_tables.php files:

// in ext_localconf.php
\HDNET\Autoloader\Loader::extLocalconf('VENDORNAME', 'extension_key');

// in ext_tables.php
\HDNET\Autoloader\Loader::extTables('VENDORNAME', 'extension_key');

In the basic configuration this lines will trigger all loader of the autoloader extension. The loader are always split into three parts:

• prepare Loader information: The loader prepare complex information (reflection, file listings, search and replace, prepare information) and store that information into an array. The autoloader extension take care, that the array is cached, so the next calls are smart and fast.
• ext_tables execute: The code that is execute in the ext_tables
• ext_localconf execute: The code that is execute in the ext_localconf

Furthermore you have the possibility to select only a few loaders to increase the performance of the auto loading process. This is possible by adding a array as third parameter including the names of the Loader that you need.

// Example in ext_localconf.php
\HDNET\Autoloader\Loader::extLocalconf('VENDORNAME', 'extension_key', array('Xclass', 'Slots'));

// Example in ext_tables.php
\HDNET\Autoloader\Loader::extTables('VENDORNAME', 'extension_key', array('Xclass', 'Slots'));

Folder and Tags 

NOTE: SINCE TYPO3 10 Check the Annotations classes for the right Annotations!!!!

Localization Strings 

There are different L10N strings, that are used by the autoloader and also created for the language file.

Note: words in upper case are placeholders.

Smart Object Management 

The smart object management is a important part of the autoloader. Smart objects are extbase domain model that have a @db annotation. Models with this annotations are smart objects for different processes.

Database definition (general):

The database definition is created automatic via a install tool hook. The target object will be reflected and the database definition is generated by the autoloader extension on the fly. This is no performance bottleneck because the database definition is only called in the extension install process and in the install tool itself. This mechanism take care, that all "@db"-properties of "@db" models exists in the persistence layer. All properties that have no @db-annotation are already in the database or do not need a field in the database layer.

TCA file generation (TcaFiles loader):

The TCA files of the given smart objects are generated automatic via the TcaFiles loader and build a base TCA on the fly (the TCA ist cached by the core). You have to modify the generated TCA if you need special fields in the backend. FileReferences, int, boolean and normal text are in the right format. Especially relation between different objects arn't in the automatic mapping of the properties.

Content Objects (ContentObjects loader):

Content objects are special domain model that are placed in the "Classes/Domain/Model/Content/" folder. All these models are registered as content elements. The content element is rendered by a generic Controller (you do not need a own controller) and load the Fluid Template from "Resources/Private/Templates/Content". In the fluid template you should use {object} to get access to your domain model or use {data} to get access to the whole database record.