What does it do? 

It provides a graphical modeler to define domain objects and their relations as well as associated controllers with basic actions. It also provides a properties form to define extension metadata, frontend plugins and backend modules that use the previously defined controllers and actions.

Finally, it generates a basic extension with that can be installed and further developed:

.
└── ebt_blog/
    ├── composer.json
    ├── ext_emconf.php
    ├── ext_localconf.php
    ├── ext_tables.php
    ├── ext_tables.sql
    ├── ExtensionBuilder.json
    ├── Classes/..
    ├── Configuration/
        ├── Backend/
            └── Modules.php
        └── ..
    ├── Documentation/..
    ├── Resources/..
    └── Tests/..

In addition to the kickstart mode, the Extension Builder also provides a roundtrip mode that allows you to use the graphical editor even after you have started making manual changes to the files. In this mode, the Extension Builder retains the manual changes, such as new methods, changed method bodies, comments and annotations, even if you change the extension in the graphical editor.

What does it not do? 

Composer mode 

If your TYPO3 installation uses Composer, install the latest Extension Builder through:

composer require friendsoftypo3/extension-builder

If you are not using the latest version of the Extension Builder, you need to add a version constraint, for example:

composer require friendsoftypo3/extension-builder:"^12.0"

"repositories": [
    "local": {
        "type": "path",
        "url": "Packages/*"
    }
]

Legacy mode 

If you are working with a TYPO3 installation that does not use Composer, install the extension in the Extension Manager:

• Navigate to Admin Tools > Extensions > Get Extensions.
• Click on Update now
• Search for extension_builder
• Click Import and install on the side of the extension entry

and activate it:

• Navigate to Admin Tools > Extensions > Installed Extensions
• Search for extension_builder
• Activate the extension by clicking on the Activate button in the A/D column

1. Open the graphical editor 

Go to the backend module of the Extension Builder, switch to the graphical editor by selecting the Domain Modelling view (1) and ensure that the properties form (2) is expanded, located on the left side of the graphical modeler (3).

Please note that some configuration options are only available if the advanced options are enabled by clicking the Show advanced options button in the upper right corner (4). These options are mainly intended for experienced TYPO3 developers.

2. Insert meta data of extension 

Enter meaningful meta data of your extension in the properties form (2) on the left side.

Once you have filled in the required Name, Vendor name and Key fields, you can click the Save button at the top to create the extension skeleton in your file system based on your configuration. Feel encouraged to save frequently.

3. Create a domain object 

If you want to extend the extension skeleton to implement business logic, create at least one domain object by dragging the gray New Model Object tile onto the canvas. Give it a meaningful name, which must be an UpperCamelCase, alphanumeric string, for example "Blog".

4. Create a frontend plugin 

If you want to create an extension that generates output in the TYPO3 frontend, add a plugin in the Frontend plugins subsection of the properties form. It will then be available for selection in the type field of the TYPO3 content element "General Plugin".

5. Create a backend module 

If your extension should provide a TYPO3 backend module, add a module in the Backend modules subsection of the properties form. It will then be available in the module menu on the left side of the TYPO3 backend.

6. Save the extension 

If your model represents the domain you wanted to implement you can hit the Save button at the top. The Extension Builder generates all required files for you in a location that depends on your local setup:

{
    "repositories": {
        "packages": {
            "type": "path",
            "url": "packages/*"
        }
    }
}

composer require <extension-package-name>:@dev

composer require ebt/ebt-blog:@dev

7. Continue developing 

Now you can start modifying the generated files in your IDE. If you still want to be able to modify the domain model in the graphical editor you have to make sure that the roundtrip mode is activated in the configuration, before loading the extension in the Extension Builder again.

Extension skeleton 

This is the minimum set of extension files generated when only the required metadata has been entered into the properties form and no domain modeling has been performed:

.
└── ebt_blog/
    ├── composer.json
    ├── ext_emconf.php
    ├── ExtensionBuilder.json
    ├── Configuration/
        └── ExtensionBuilder/..
    ├── Documentation/..
    └── Resources/
        └── Public/
            └── Icons/
                └── Extension.svg

The extension metadata is stored in the composer.json and ext_emconf.php files and is used for installations in Composer mode and Legacy mode respectively. The extension icon Extension.svg is displayed in the list of extensions of the Extension Manager module. The Documentation/ folder contains a basic set of documentation files. Read the section "Documentation" how to proceed with the documentation.

The Extension Builder stores some internal data in the ExtensionBuilder.json file and in the Configuration/ExtensionBuilder/ folder which should be kept as long as the extension is edited in the Extension Builder.

Domain modeling files 

Most of the extension files are created for modeling the domain and configuring frontend plugins and backend modules:

.
└── ebt_blog/
    ├── ext_localconf.php
    ├── ext_tables.php
    ├── ext_tables.sql
    ├── Classes/
        ├── Controller/..
        └── Domain/
            ├── Model/..
            └── Repository/..
    ├── Configuration/
        ├── Backend/
            └── Modules.php
        ├── TCA/..
        └── TypoScript/..
    ├── Resources/
        ├── Private/
            ├── Language/..
            ├── Layouts/..
            ├── Partials/..
            └── Templates/..
        └── Public/
            └── Icons/..
    └── Tests/
        ├── Functional/..
        └── Unit/..

The frontend plugins are registered in the ext_localconf.php file and the backend modules are registered in the Configuration/Backend/Modules.php file. The associated views are configured in the Configuration/TypoScript/ folder and the Fluid view templates are bundled in the Resources/Private/ folder.

The database schema of the domain model is defined in the ext_tables.sql file. The controller classes are provided in the folder Classes/Controller/, the classes that define the domain model are provided in the folder Classes/Domain/ and their representation in the TYPO3 backend is configured in the folder Configuration/TCA/. Last but not least, the tests of the classes are located in the folder Tests/.

For more information on tests, see the section "Tests" and for everything else, please refer to the Extbase & Fluid book of the official TYPO3 documentation.

Documentation 

The Extension Builder has already created sample documentation for your extension if you have Generate documentation enabled in the properties form.

cd <path-to-extension>
source <(docker run --rm t3docs/render-documentation show-shell-commands)
dockrun_t3rd makehtml
xdg-open "Documentation-GENERATED-temp/Result/project/0.0.0/Index.html"

Tests 

The TYPO3 Core is covered by thousands of tests of varying complexity: Unit tests (testing part of a class), functional tests (testing multiple classes in combination) and acceptance tests (testing the entire website user experience). To simplify testing, the general functionality for writing tests is bundled in the TYPO3 Testing Framework, and all custom tests should use it by inheriting from its base classes.

The Extension Builder generates a set of unit tests and a dummy functional test that easily cover the generated classes of your extension. The generated tests should encourage you to write your own tests once you start customizing the code.

If you are new to testing, we recommend that you invest some time to learn the benefits of software testing. It will certainly improve the quality of your software, but it will also boost your programming skills. Moreover, it will allow you to refactor without fear of breaking anything: Code that is covered by tests shows less unexpected behavior after refactoring.

/**
 * @test
 */
public function setTitleForStringSetsTitle(): void
{
   $this->subject->setTitle('Conceived at T3CON10');

   self::assertEquals('Conceived at T3CON10', $this->subject->_get('title'));
}

/**
 * @test
 */
public function deleteActionRemovesTheGivenBlogFromBlogRepository(): void
{
    $blog = new \Ebt\EbtBlog\Domain\Model\Blog();

    $blogRepository = $this->getMockBuilder(\Ebt\EbtBlog\Domain\Repository\BlogRepository::class)
        ->onlyMethods(['remove'])
        ->disableOriginalConstructor()
        ->getMock();

    $blogRepository->expects(self::once())->method('remove')->with($blog);
    $this->subject->_set('blogRepository', $blogRepository);

    $this->subject->deleteAction($blog);
}

Global configuration 

In the TYPO3 backend go to Settings > Extension Configuration and open the configuration of the Extension Builder. Here are several settings configurable:

Local configuration 

After the initial creation of an extension, you will find the file Configuration/ExtensionBuilder/settings.yaml in the extension which contains the following extension specific settings:

overwriteSettings:
  Classes:
    Controller: merge
    Domain:
      Model: merge
      Repository: merge

  Configuration:
    #TCA: merge
    #TypoScript: keep

  Resources:
    Private:
      Language: merge
      #Templates: keep

  Documentation: skip

classBuilder:
  Controller:
    parentClass: \Ebt\Blog\Controller\ActionController

  Model:
    AbstractEntity:
      parentClass: \Ebt\Blog\DomainObject\AbstractEntity

    AbstractValueObject:
      parentClass: \Ebt\Blog\DomainObject\AbstractValueObject

  Repository:
    parentClass: \Ebt\Blog\Persistence\Repository

  setDefaultValuesForClassProperties: true

ignoreWarnings:
  503

Check access of controller actions 

Be aware that any controller action can be called just by appending a parameter to the URL where the frontend plugin or backend module is included:

?tx_<extensionkey>_<pluginkey>[action]=<action>

For example, if a controller provides an edit and a delete action, the edit action URL could look like this:

https://example.org/diary/?tx_blog_blogs[action]={edit}&tx_blog_blogs[blog]=2

This will load the edit view with a form to edit the blog and load the blog data into it.

By default there is no access control. If someone manipulates this URL and replaces the edit action with the delete action:

https://example.org/diary/?tx_blog_blogs[action]={delete}&tx_blog_blogs[blog]=2

the blog would be deleted instead of being edited.

You have to make sure in your receiving controller to only allow context-specific actions and generally restrict access to critical actions.

Editing an existing extension 

The roundtrip mode is enabled by default. To disable it, see the Extension Builder configuration Configuration.

The general rule is: All configurations that can be edited in the graphical editor should be applied in the graphical editor. For example, if your extension depends on another extension, you should add it in the properties form of the graphical editor and not directly in the ext_emconf.php and composer.json.

Make sure you configure the Overwrite settings.

Overview of the roundtrip features 

Consequences of various actions:

If you change the extension key:

• the extension will be copied to a folder named like the new extension key
• all classes and tables are renamed
• your code should be adapted to the new names (not just overridden with the default code)

If you change the vendor name:

• namespaces in all class files are updated
• use/import statements referencing the old vendor namespace are updated
• type hints, var types, and return types in methods and parameters are updated
• TypoScript files are regenerated with the new vendor name automatically

If you rename a property:

• the corresponding class property is renamed
• the corresponding getter and setter methods are updated
• TCA files and SQL definitions are newly generated, modifications will be LOST
• existing data in the corresponding table field will be LOST, except you RENAME the field in the database manually

If you rename a relation property:

• the corresponding class property is renamed
• the corresponding getter/setter or add/remove methods are updated
• the new SQL definition and default TCA configuration will be generated
• existing data in the corresponding table field will be LOST, except you RENAME the field in the database manually
• existing data in many-to-many database tables will be LOST, except you RENAME the table manually

If you change a property type:

• the var type doc comment tags are updated
• the type hint for the parameter in getter and setter methods are updated
• the SQL type is updated if necessary
• existing data in the corresponding table field might get LOST, except you ALTER the field type in the database manually

If you change a relation type:

• if you switch the type from 1:1 to 1:n or n:m or vice versa the getter/setter or add/remove methods will be lost (!)
• the required new getter/setter/ or add/remove methods are generated with the default method body
• existing data in many-to-many database tables will be LOST, except you RENAME the table manually

If you rename a domain object:

• the corresponding classes (domain object, controller, repository) will be renamed
• all methods, properties and constants are preserved
• relations to this domain object are updated
• references to the renamed classes in OTHER classes are NOT updated (!)
• TCA files and SQL definitions are new generated, modifications will be LOST

Extending domain objects 

The Extension Builder supports single table inheritance. This means you can extend domain object classes, either from your current extension or from other extensions. You must enter the fully qualified class name of the domain object you want to extend in the Extend existing model class field in the domain object settings form. The class must be loadable, i.e. you can only extend classes of extensions that are installed. After saving and updating the database (if necessary), you should find a drop-down list Record Type and a new tab with the new properties in the backend record form.

In this example, the frontend user domain object was extended:

Mapping to tables 

If you want to store a domain object in an existing table, for example if there is no domain object class for that table yet (like tt_address), then you can enter the table name in the Map to existing table field in the domain object settings form. The Extension Builder will then add fields to this table for each property you added to your domain object. If you name the properties according to the existing field names, you can access the existing fields with the getters and setters of your domain object class, and no new fields are created.

In this example the domain object is mapped to table tt_address:

and these are the resulting database updates:

and this is the backend form of the extended frontend user:

Relations to domain objects of other extensions 

If you want to add a relation to a domain object that is not part of your current extension, you must enter the fully qualified class name of that object in the relation settings form. The related class must be loadable, so you can only add domain objects from installed extensions.

System Requirements 

Generated Code Changes 

The Extension Builder 13.x branch generates code that is compatible with TYPO3 13 and PHP 8.3. If you have previously generated an extension with an older version, you need to update the following patterns manually or regenerate the affected files.

class ArticleRepository
{
    protected $defaultOrderings = ['sorting' => QueryInterface::ORDER_ASCENDING];
}

use TYPO3\CMS\Extbase\Persistence\Repository;

class ArticleRepository extends Repository
{
    protected array $defaultOrderings = ['sorting' => QueryInterface::ORDER_ASCENDING];
}

class Article extends AbstractEntity
{
    /**
     * @var string
     */
    protected $title;

    /**
     * @var ObjectStorage<Tag>
     */
    protected $tags;
}

use TYPO3\CMS\Extbase\DomainObject\AbstractEntity;
use TYPO3\CMS\Extbase\Persistence\ObjectStorage;

class Article extends AbstractEntity
{
    protected string $title = '';
    protected ObjectStorage $tags;

    public function __construct()
    {
        $this->initializeObject();
    }

    public function initializeObject(): void
    {
        $this->tags ??= new ObjectStorage();
    }
}

class ArticleController extends ActionController
{
    /**
     * @var ArticleRepository
     */
    protected $articleRepository;

    public function injectArticleRepository(ArticleRepository $articleRepository): void
    {
        $this->articleRepository = $articleRepository;
    }
}

use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class ArticleController extends ActionController
{
    public function __construct(
        private readonly ArticleRepository $articleRepository,
    ) {}

    public function listAction(): ResponseInterface
    {
        $articles = $this->articleRepository->findAll();
        $this->view->assign('articles', $articles);
        return $this->htmlResponse();
    }
}

'columns' => [
    'sys_language_uid' => [
        'config' => [
            'type' => 'language',   // native type since TYPO3 12
        ],
    ],
    'crdate' => [
        'config' => [
            'type' => 'datetime',   // replaces 'input' with eval=>'datetime'
        ],
    ],
],

// ext_tables.php
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule(
    'MyExt',
    'web',
    'mymodule',
    '',
    [MyController::class => 'list,show'],
    ['access' => 'user,group', ...]
);

return [
    'web_myextmymodule' => [
        'parent' => 'web',
        'access' => 'user,group',
        'iconIdentifier' => 'my-ext-module',
        'labels' => 'LLL:EXT:my_ext/Resources/Private/Language/locallang_mod.xlf',
        'extensionName' => 'MyExt',
        'controllerActions' => [
            MyController::class => ['list', 'show'],
        ],
    ],
];

services:
  _defaults:
    autowire: true
    autoconfigure: true
    public: false

  Vendor\MyExt\:
    resource: '../Classes/*'

Migration Checklist 

Use this checklist when migrating a previously generated extension:

PHP / Backend
[ ] All repository classes extend TYPO3\CMS\Extbase\Persistence\Repository
[ ] All model properties have native PHP type declarations
[ ] Controllers use constructor injection (not injectX() methods)
[ ] All action methods return ResponseInterface
[ ] declare(strict_types=1) at top of every PHP file

TCA
[ ] sys_language_uid uses type = 'language'
[ ] Date/time fields use type = 'datetime'
[ ] No deprecated type = 'input' with eval for dates

Module / Routing
[ ] Module registered in Configuration/Backend/Modules.php (not ext_tables.php)
[ ] No TBE_MODULES array manipulation

Dependency Injection
[ ] Configuration/Services.yaml present with autowire: true
[ ] ext_localconf.php does not use makeInstance for services

Version 13.2.0 

• [FEATURE] TCA select properties can now have custom items configured directly in the domain modeling editor — each item has a label and a value.
• [TASK] locallang_csh_*.xlf files are no longer generated. CSH (Context Sensitive Help) was removed in TYPO3 v12; field descriptions are now written exclusively to locallang_db.xlf and referenced via the TCA description key. When a domain object is removed via RoundTrip, any leftover locallang_csh_*.xml and locallang_csh_*.xlf files are cleaned up automatically. Existing generated extensions may have orphaned CSH files that can be deleted manually.
• [BUGFIX] Renaming a domain object no longer corrupts the controller constructor and action parameter names.
• [BUGFIX] Property settings panel now correctly shows and hides fields based on the selected property type.
• [BUGFIX] Boolean properties no longer always appear as checked after loading an existing extension.
• [BUGFIX] Saving an extension no longer fails after a relation has been deleted.
• [BUGFIX] Opening old ExtensionBuilder.json files that are missing the renderType key no longer causes an error — the field is silently ignored.
• [BUGFIX] Indentation of nested method calls is preserved correctly during RoundTrip.
• [BUGFIX] Field descriptions are now preserved with their original casing in generated XLF files.
• [BUGFIX] SelectProperty type is now stored as a string instead of an integer, fixing issues when loading extensions that use select fields.
• [BUGFIX] Fixed undefined array key excludeField warning in ObjectSchemaBuilder.

Version 13.1.0 

• [BUGFIX] ext_tables.sql now includes a CREATE TABLE statement for models that have no own properties but are the target of a ZeroToMany inline relation — previously the FK column was silently dropped, leaving the database table uncreated.
• [BUGFIX] A validation warning is now shown when a domain object has no properties, informing the user that no CREATE TABLE statement will be generated in ext_tables.sql.
• [BUGFIX] Generated controller actions now declare ResponseInterface as their return type, matching the TYPO3 v13 standard.
• [BUGFIX] f:image ViewHelper calls in generated templates now use the image attribute instead of src, fixing rendering of filenames with Umlauts or special characters.
• [FEATURE] XLF files are no longer rewritten when only the date= attribute changed — avoids VCS noise on every regeneration. The staticDateInXliffFiles setting is removed as it is no longer needed.
• [FEATURE] Generated backend module extensions now include a user.tsconfig file that makes the backend module accessible without manual TSconfig setup.
• [FEATURE] extbase is now automatically added as a dependency to generated extensions that use Extbase controllers or domain objects.

Version 13.0.0 

Breaking changes and migrations (v12 → v13):

• [TASK] Update dependencies to TYPO3 ^13.4, PHP ^8.3.
• [TASK] Frontend plugins are now registered as CType content elements using PLUGIN_TYPE_CONTENT_ELEMENT — the deprecated list_type approach is no longer used. page.tsconfig wizard entries are no longer generated because registerPlugin() with CType automatically adds the plugin to the content element wizard. Existing generated extensions using list_type must be regenerated to adopt the new registration.
• [TASK] TypoScript is no longer loaded via ext_typoscript_setup.typoscript (which was dropped in TYPO3 v13) — the extension now registers its TypoScript paths via addTypoScriptSetup() in ext_localconf.php.
• [FEATURE] Extensions with frontend plugins can now optionally generate a Site Set (Configuration/Sets/). When the Generate Site Set option is enabled in the editor, the generator creates config.yaml, setup.typoscript, and constants.typoscript instead of the classic addStaticFile approach. The classic behavior is unchanged when the option is not enabled.
• [BUGFIX] Constructor property promotion flags (readonly, visibility modifiers) are now preserved correctly during RoundTrip code generation.
• [TASK] Generated TypoScript setup templates no longer include a storagePid setting — the line is commented out so integrators can enable it deliberately.

Version 12.0.0 

Breaking changes and migrations (v11 → v12):

• [TASK] Update dependencies to TYPO3 ^12.4, PHP ^8.3, PHPUnit ^10, testing-framework ^7, add Rector
• [TASK] Migrate backend module registration from ext_tables.php to Configuration/Backend/Modules.php
• [TASK] Rename TypoScript setup file extension from .txt to .typoscript
• [TASK] Replace GeneralUtility::makeInstance() with Dependency Injection throughout
• [TASK] Migrate setter injection to constructor injection in all controller and service classes
• [TASK] Replace YUI/WireIt/InputEx with Lit Web Components and TYPO3 v12 CSS variables
• [TASK] Replace yarn/SCSS build pipeline with Vite and ESM module bundling (npm)
• [TASK] Add Playwright E2E test infrastructure
• [TASK] Migrate TCA: type=number (was type=input/eval=int), type=link (was renderType=inputLink)
• [TASK] Migrate TCA items arrays to associative format (label/value keys)

Version 11.0.13 

• [DOCS] Adds information about a possible missing storage path when using composer mode
• Bugfixes

Version 11.0.12 

• [TASK] Switch documentation rendering to PHP (thanks to Sandra Erbel)
• [BUGFIX] fix issue with default value for nodefactory
• [BUGFIX] Enables scroll view of extension save dialog confirmations (thanks to warki)

Version 11.0.11 

• [TASK] Use current standard for web-dir (thanks to Sybille Peters)
• [BUGFIX] - Undefined array key $parentClass

Version 11.0.10 

• [BUGFIX] Allow null for native date and time
• [TASK] one controller action pair per line
• [FEATURE] add tca field description
• [BUGFIX] resolve nullable types correctly

Version 11.0.9 

• [BUGFIX] Generate correct TCA for images and files
• [TASK] Corrected CSS-Default-Styles
• [DOCS] Small changes in Documentation

Version 11.0.8 

• [BUGFIX] fixes links in extension module
• [TASK] Set the description field of backend module to textarea
• [BUGFIX] Fix issue in JS - "Relations"

Version 11.0.4 

• [BUGFIX] Fix warning if setDefaultValuesForClassProperties does not exist
• [DOCS] Add sponsoring page
• [BUGFIX] fixes title for advanced option button
• [BUGFIX] Generate correct .xlf files
• [BUGFIX] Language file not merged
• [BUGFIX] issue 599 missing property settings

Version 11.0.3 

• [TASK] Add support for typo3/cms-composer-installers v4

Version 11.0.2 

• [DOCS] Checkbox was renamed to "Generate documentation"
• [DOCS] Fix controller action names in blog example
• [DOCS] Small fixes derived from backport of documentation
• [DOCS] Small fixes derived from backport of documentation v11
• [TASK] Make Extension Builder compatible with PHP 8.0
• [TASK] Add allowed composer plugins
• [TASK] Update return type hint for model getters
• [BUGFIX] Strip trailing spaces after comma
• [DOCS] Rename slack channel to #extension-builder
• [TASK] Align with new TYPO3 documentation standards
• [TASK] Align with new TYPO3 documentation standards (follow-up)
• [BUGFIX] Fix PHP8 warning because overwriteSettings not found in empty settings

Build tooling 

The JavaScript sources are bundled with Vite. To install dependencies and build the frontend assets, run:

npm install
npm run build

The compiled output is written to Resources/Public/JavaScript/.

npm run lint

npm run lint:js       # ESLint
npm run lint:scss     # Stylelint
npm run lint:format   # Prettier (check only)

npm run format

E2E tests 

End-to-end tests are written with Playwright and require the ddev environment to be running:

ddev start
npm run test:e2e

To open the interactive Playwright UI:

npm run test:e2e:ui

To run tests in a headed browser:

npm run test:e2e:headed

PHP tests 

PHP unit and functional tests use PHPUnit 10 and TYPO3 Testing Framework ^7.

Run unit tests:

composer unit-tests

Run functional tests (uses SQLite, no database setup required):

composer functional-tests

Run all checks (PHP CS Fixer, unit tests, functional tests):

composer test

Rector 

For automated code migrations, TYPO3 Rector is integrated. Run it with:

vendor/bin/rector

– The TYPO3 project - Inspiring people to share