Extension Builder for TYPO3

The Extension Builder is the scaffolding tool without which no TYPO3 developer is truly productive

The Extension Builder has been the official tool for more than ten years for developers to create new extensions from scratch in TYPO3. Anyone who needs an Extbase extension with a domain model, repository, controller and backend module gets a visual editor that turns a UML-like domain diagram into the complete boilerplate: TCA configuration, SQL schema, ext_localconf, controller stubs, Fluid templates, language files. For agencies and product teams that regularly deliver their own extensions, the tool remains the fastest path from concept to first working prototype.

The audience are TYPO3 development teams at agencies and in-house that model business logic beyond sitepackages in TYPO3. Typical cases are extensions for product catalogues, event management, job portals, customer portals or industry-specific data structures. Without the Extension Builder, every one of these extensions would have to grow from an empty directory by hand, with the risk that the structure deviates from the TYPO3 core schema and breaks on the next upgrade.

Typical use cases

A first scenario is a prototype for a customer portal. A mechanical engineering company with 2,000 spare parts needs an extension that exposes product families, products and documentation as their own data structures in the backend. In under 30 minutes, the Extension Builder generates the complete scaffold: TCA, repositories, controllers, list and detail view. The team immediately starts with business logic instead of boilerplate.

A second scenario is training and onboarding. A developer building a TYPO3 extension for the first time learns the conventions of the framework through the generated scaffold without getting lost in documentation. The generated code is not perfect, but it is idiomatic and shows how Extbase is meant to be used.

A third scenario is the migration of existing data structures. Anyone who has to build a new TYPO3 extension from an old CSV export with ten entities can click together the domain model in the Extension Builder, export it and fill the generated code afterwards with an import command. That saves several person days compared to a manual build.

A fourth scenario is standardisation inside an agency pool. A service provider with 15 TYPO3 developers wants to ensure that every new extension has the same base structure. The Extension Builder enforces that structure through generation, and custom templates for the code generator ensure that code style, licence header and directory structure remain identical across projects.

Technical architecture

The Extension Builder is a classic TYPO3 backend extension with its own user interface. In the backend, a module appears in which the domain model is built through a drag-and-drop surface: entities as boxes, properties as fields, relations as lines. On export, a JSON schema is persisted, from which the generator writes the complete extension code.

Installation runs through Composer (friendsoftypo3/extension-builder). The extension has no production relevance and belongs in the development environment; it should not be activated in production at all. On generation, the Builder uses Twig-like templates that can be adapted per project if needed, for example to enforce custom code styles or a specific licence header.

What matters is that the Extension Builder does not support a roundtrip: anyone who generates once and then extends the code by hand can still open the extension in the Builder but must not regenerate, otherwise the Builder overwrites parts of the manually added logic. In practice, the Builder is used as a one-time scaffold step, after which the extension lives in the Git repository.

Common problems and solutions

The first problem is the overwrite trap after the first generation run. Teams that start the Builder a second time to add a field lose their own code changes. The solution is a clear rule in the team: the Extension Builder is used once, the rest is hand work. Later field changes are made manually in TCA, SQL and model.

The second problem is compatibility with modern PHP conventions. The generator still produces code that leans towards older PHP versions and older Extbase conventions. The solution is a cleanup pass directly after generation: add type declarations, set return types, introduce readonly properties, replace outdated annotation comments with native attributes.

The third problem is uncritical use as a code miracle. Some teams expect the Extension Builder to deliver a production-ready application. It does not: it delivers a scaffold. Every piece of business logic, every validation and every security concept remains the responsibility of the developer.

A fourth problem are outdated backend patterns in the generated code. The shipped controllers sometimes still use deprecated Extbase patterns that generate deprecation warnings in current TYPO3. The solution is a lint step directly after generation that checks the code against current coding standards and flags missing type declarations or outdated annotations. Modern pipelines combine this step with automatic code rewriting via Rector to keep the cleanup effort as low as possible.

Migration and version compatibility

The Extension Builder is officially available for TYPO3 v11 and v12 and is maintained by the Friends of TYPO3. For TYPO3 v13 there is an updated version that follows the new Extbase conventions. Teams upgrading existing extensions usually do not need the Builder for that, the upgrade runs through upgrade wizards in the install tool and manual adjustments.

More interesting is the strategic view: at a time when generative AI can produce complete extension scaffolds including business logic from a single prompt, the visual builder loses part of its original advantage. Gosign combines both worlds: for standard scaffolds with many entities, the Builder remains efficient; for demanding extensions with domain-specific logic, we generate the code directly from a functional briefing with AI support and save up to 80 percent of development time compared to a classic hand-build, while improving code quality at the same time.