TYPO3 v7 has reached its end-of-life November 30th, 2018 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

There is no further ELTS support. It is recommended that you upgrade your project and use a supported version of TYPO3.

Files and locations


An extension consists of:

  1. a directory named by the extension key (which is a worldwide unique identification string for the extension)

  2. standard files with reserved names for configuration related to TYPO3 (of which most are optional, see list below)

  3. any number of additional files for the extension itself.

Reserved filenames

This list of filenames are all reserved filenames in the root directory of extensions. None of them are required but for example you cannot have a TYPO3 extension recognized by TYPO3 without the "ext_emconf.php" file etc. You can read more details like that in the table below.

In general, do not introduce your own files in the root directory of extensions with the name prefix "ext_".




Definition of extension properties.

Name, category, status etc. Used by the EM. The content of this file is described in more details below. Note that it is auto-written by EM when extensions are imported from the repository.


If this file is not present the EM will not find the extension.


Addition to LocalConfiguration.php which is included if found. Should contain additional configuration of $TYPO3_CONF_VARS and may include additional PHP class files.

All ext_localconf.php files of included extensions are included right after the typo3conf/LocalConfiguration.php file has been included and database constants defined. Therefore you cannot setup database name, username, password though, because database constants are defined already at this point.


Observe rules for content of these files. See section on caching below.


Included if found. Contains extensions of existing tables, declaration of modules, backend styles etc. All code in such files is included after all the default definitions provided by the Core.

Since TYPO3 CMS 6.1, definition of new database tables should be done entirely in Configuration/TCA/(name of the table).php. These files are expected to contain the full TCA of the given table (as an array) and simply return it (with a return statement).

Since TYPO3 CMS 6.2, customizations of existing tables should be done entirely in Configuration/TCA/Overrides/(name of the table).php. This way the TCA changes are cached.


SQL definition of database tables.

This file should contain a table-structure dump of the tables used by the extension. It is used for evaluation of the database structure and is therefore important to check and update the database when an extension is enabled.If you add additional fields (or depend on certain fields) to existing tables you can also put them here. In that case insert a CREATE TABLE structure for that table, but remove all lines except the ones defining the fields you need.

The ext_tables.sql file may not necessarily be "dumpable" directly to MySQL (because of the semi-complete table definitions allowed defining only required fields, see above). But the EM or Install Tool can handle this. The only very important thing is that the syntax of the content is exactly like MySQL made it so that the parsing and analysis of the file is done correctly by the EM.


Static SQL tables and their data.

If the extension requires static data you can dump it into a sql-file by this name.Example for dumping mysql data from bash (being in the extension directory):

mysqldump --password=[password] [database name] [tablename] --add-drop-table > ./ext_tables_static.sql

--add-drop-table will make sure to include a DROP TABLE statement so any data is inserted in a fresh table.

You can also drop the table content using the EM in the backend.


The table structure of static tables needs to be in the ext_tables.sql file as well - otherwise an installed static table will be reported as being in excess in the EM!


Preset TypoScript constants. Will be included in the constants section of all TypoScript templates.


Use such a file if you absolutely need to load some TS (because you would get serious errors without it). Otherwise static templates or usage of the Extension Management API (ExtensionManagementUtility) are preferred.


Preset TypoScript setup. Will be included in the setup section of all TypoScript templates.


Use such a file if you absolutely need to load some TS (because you would get serious errors without it). Otherwise static templates or usage of the Extension Management API (ExtensionManagementUtility) are preferred.


Extension Configuration template.

Configuration code in TypoScript syntax setting up a series of values which can be configured for the extension in the EM.

If this file is present the EM provides you with an interface for editing the configuration values defined in the file. The result is written as a serialized array to LocalConfiguration.php in the variable $TYPO3_CONF_VARS['EXT']['extConf'][ *extension_key* ]

If you want to do user processing before the content from the configuration form is saved (or shown for that sake) there is a hook in the EM which is configurable with $TYPO3_CONF_VARS ['SC_OPTIONS']['typo3/mod/tools/em/index.php']['tsStyleConfigForm'][] = " *function reference* "

ext_icon.gif, ext_icon.png or ext_icon.svg

Extension Icon

18x16 GIF, PNG or SVG icon for the extension.


Extension icon will look nicer when provided as vector graphics (SVG) rather than bitmaps (GIF or PNG).


Local Update tool class

If this file is found it will install a new menu item, "UPDATE", in the EM when looking at details for the extension. When this menu item is selected the class inside of this file (named "ext_update") will be instantiated and the method "main()" will be called and expected to return HTML content.

Also you must add the function "access()" and make it return a boolean value whether or not the menu item should be shown. This feature is meant to let you disable the update tool if you can somehow detect that it has already been run and doesn't need to run again.The point of this file is to give extension developers the possibility to provide an update tool if their extensions in newer versions require some updates to be done.


Since TYPO3 CMS 4.3, it is possible to declare classes in this file so that they will be automatically detected by the TYPO3 autoloader. This means that it is not necessary to require the related class files anymore. See the Autoloading chapter for more details.

Not needed anymore since TYPO3 CMS 6.1, when using namespaces.


PHP API data

A file containing a serialized PHP array with API information for the PHP classes in the extension. The file is created - and viewed! - with tools found in the extension "extdeveval" (Extension Development Evaluator)

Reserved folders

The current standard for files location - except for the special files mentioned above - is inspired by TYPO3 Flow. It is necessary to use such structure in Extbase-based extensions and recommended for all extensions anyway.

In order to use Namespaces, class files must be located in a Classes folder.

Refer to the Extbase and Fluid book for more information on extension structure. Also look at the "examples" extension.

The Extension Builder will create the right structure for you. It is described below:


Contains MVC Controller classes.


Contains MVC Domain model classes.


Contains data repository classes.


Helper classes used in the views.


TypoScript static setup (setup.txt) and constants (constants.txt). Use subfolders if your have several static templates.


One file per database table, using the name of the table for the file, plus ".php". Only for new tables.


For extending existing tables, one file per database table, using the name of the table for the file, plus ".php".


Contains the manual in reStructuredText format (read more on the topic).


XLIFF files for localized labels.


Main layouts for the views.


Partial templates for repetitive use.


One template per action, stored in a folder named after each Controller.


Any CSS file used by the extension.


Any images used by the extension.


Any JS file used by the extension.


Contains unit testing classes.

Legacy structure

The structure of older extensions was not so clearly defined, but it generally adhered to the following conventions:




Typical folder for a frontend plugin class.


Typical folder for a backend module.


Typical folder for a service.


Extensions normally consist of other files: Classes, images, html- files etc. Files not related to either a frontend plugin (pi/) or backend module (mod/) might be put in a subfolder of the extension directory named "res/" (for "resources") but you can do it as you like (inside of the extension directory that is).The "res/" folder content will be listed as files you can select in the configuration interface.

Files in this folder can also be selected in a selector box if you set up Extension configuration in a "ext_conf_template.txt" file.