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:

• ./typo3/cli_dispatch.phpsh extbase schema:generate <extension key> produces the XSD file for the ViewHelpers of one extension
• 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

Besides the TYPO3 Core, Extbase and Fluid, Schemaker requires the extension vhs. 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 captured as well, because Fluid reads them when preparing the arguments.

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 generates the schema per extension key and only finds ViewHelpers in that extension’s Classes/ViewHelpers/ folder. ViewHelpers of other extensions end up in their own schema. Solution: run a separate generation for each extension with its own ViewHelpers.

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 maintained up to TYPO3 7.6; the last version is 3.2.0. There are no forks for TYPO3 v10 and v11; the most recent one on GitHub reaches TYPO3 8.7. The Fluid template engine changed internally with v8 (standalone package typo3fluid/fluid) and v13 (Fluid 4), which affects schema generation.

For TYPO3 v13, the command vendor/bin/typo3 fluid:schema:generate, which the Core has shipped since version 13.2, is recommended as an alternative; it generates XSD files for all ViewHelpers of the project. 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. From TYPO3 13.2 on, PhpStorm automatically picks up the XSD files from vendor/bin/typo3 fluid:schema:generate and uses them to complete Core ViewHelpers as well as custom ones. For custom ViewHelpers, the command reads the same information as Schemaker, the argument definitions and the class DocBlock.

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.