Schemaker for TYPO3

Why missing ViewHelper documentation slows TYPO3 projects down

Fluid ViewHelpers are the backbone of every TYPO3 template development. But once a project includes custom ViewHelpers, the problem begins: no developer knows all parameters, no IDE offers autocompletion, and documentation exists at best as a comment in the PHP code. Schemaker solves this problem by automatically generating XSD schema files from PHP classes. These schemas provide IDEs with the information needed for autocompletion, validation and inline documentation directly in the Fluid template.

For teams with more than one TYPO3 developer, this is not a comfort question but a productivity question. Without schema files, every developer spends 15 to 30 minutes daily looking up ViewHelper parameters in source code.

Typical use cases

Enterprise projects with 20+ custom ViewHelpers. Large TYPO3 installations frequently include specialized ViewHelpers - for price formatting, permission checks, API calls or industry-specific logic. Without Schemaker, every new developer on the project must read source code to understand the available parameters. With Schemaker, they open the Fluid template in PhpStorm or VS Code and immediately receive suggestions. For a project with 25 custom ViewHelpers and an average of 4 parameters per ViewHelper, this saves an estimated 30 to 45 minutes of source code searching per developer day.

Extension development for the TYPO3 Extension Repository (TER). Extension publishers that include custom ViewHelpers can ship XSD files generated by Schemaker. This significantly reduces support requests and improves the developer experience for every extension user. In the TER as well as on Packagist, an included XSD file signals professional extension development.

Onboarding new developers. In a TYPO3 agency, developers regularly switch between projects. Schemaker-generated schemas function as living documentation: they are always current because they are generated directly from the code. No wiki that becomes outdated. No Confluence that nobody maintains. A new developer installs the project, opens a Fluid template and immediately sees which ViewHelpers with which parameters are available. Instead of 2 days of familiarization, it is 2 hours.

Technical architecture

Schemaker analyzes PHP classes that extend AbstractViewHelper. It reads the @param annotations, the registerArgument() calls and the class DocBlocks. From this, it generates XSD schema files (XML Schema Definition) that are assigned to the Fluid namespace.

Integration works through the TYPO3 CLI:

• vendor/bin/typo3 schemaker:generate produces XSD files for all registered ViewHelper namespaces
• The generated XSD files are placed in the project (typically: Resources/Private/Schemas/)
• In every Fluid template, the namespace is declared with a schema location
• The IDE (PhpStorm, VS Code with the appropriate extension) reads the XSD and offers autocompletion

Schemaker has only the TYPO3 Core and the Fluid template engine package as dependencies. It does not intervene in the rendering process and has no performance impact on the live website - schema generation runs exclusively on the CLI in the development context. In production environments, Schemaker does not even need to be installed; the generated XSD files are distributed via version control (Git) and function independently of the extension.

Important: Schemaker only analyzes ViewHelpers that are correctly registered. ViewHelpers that work via $this->registerArgument() in the initializeArguments() method are fully recognized. Older ViewHelpers that define parameters through render() method signatures (pre-TYPO3 v8 pattern) are partially not captured correctly.

Common problems and solutions

IDE shows no autocompletion despite XSD. Most common cause: the namespace in the Fluid template does not match the XSD namespace. Schemaker generates schemas based on the PHP namespace of the ViewHelper classes. If a different alias is used in the Fluid template, the IDE finds no mapping. Solution: xmlns:custom="http://typo3.org/ns/Vendor/Extension/ViewHelpers" must exactly match the generated schema.

Generated XSD does not contain all ViewHelpers. Schemaker only finds ViewHelpers reachable through Composer autoloading. Extensions installed only via classic mode directory (without Composer) are not fully scanned. Solution: switch to Composer-based installation or manually configure the autoload path.

Schema outdated after code changes. XSD files are not automatically updated when ViewHelper parameters change. Solution: integrate schema generation into the CI/CD pipeline. A composer post-install-cmd hook or a build step in GitLab CI ensures schemas are regenerated after every dependency update. This automatic update prevents developers from working with outdated schemas and discovering errors only at runtime.

Migration and version compatibility

Schemaker was originally developed by Claus Due (FluidTYPO3 team) and was actively maintained through TYPO3 v9. For TYPO3 v10 and v11, community forks exist with limited functionality. The Fluid template engine changed internally in v11 and v12 (new ExpressionParser, changed argument handling), which partially affects schema generation.

For TYPO3 v12 and v13, the PhpStorm-integrated TYPO3 plugin support is recommended as an alternative - it reads ViewHelper information directly from the PHP code without requiring separate XSD files. The TYPO3 Core team also provides official XSD schemas for the Core ViewHelpers.

Those with Schemaker in production who are migrating to TYPO3 v12 should evaluate whether the existing workflow can be replaced by IDE-native functions. The PhpStorm plugin for TYPO3 (as of 2026) offers ViewHelper autocompletion for Core ViewHelpers and extensions that use correct DocBlocks. For custom ViewHelpers, the plugin accesses the same PHP information that Schemaker uses - just without the detour through XSD files.

Gosign supports the evaluation and migrates existing schema workflows to modern toolchains. Typical effort for the migration: 4 to 8 hours per project, including IDE configuration for all developers on the team and documentation of available ViewHelper namespaces.