What does it do? 

The extension provides a full rendering environment for Handlebars templates within TYPO3 CMS. All core features of Handlebars.js are supported by the usage of the third-party library PHP Handlebars.

Its main use is to seamlessly integrate Handlebars templates into TYPO3 without the need to modify these templates again for output in TYPO3.

Features 

• Full rendering environment for Handlebars templates
• Native support for custom Handlebars helpers
• Easy to extend and customize
• Built on dependency injection for better performance and maintainability
• Integration with TYPO3's cache framework for compiled templates
• Compatible with TYPO3 13.4 LTS and 14.3 LTS

Support 

There are several ways to get support for this extension:

• Slack: https://typo3.slack.com/messages/ext-handlebars
• GitHub: https://github.com/CPS-IT/handlebars/issues

License 

This extension is licensed under GNU General Public License 2.0 (or later).

Requirements 

• PHP 8.2 - 8.5
• TYPO3 13.4 LTS - 14.3 LTS

Installation 

Require the extension via Composer (recommended):

composer require cpsit/typo3-handlebars

Or download it from the TYPO3 extension repository.

Site sets 

The extension provides two site sets that can be included in the site configuration or any other site set.

• cpsit/handlebars — Handlebars base

  • Wires plugin.tx_handlebars.view.templateRootPaths and plugin.tx_handlebars.view.partialRootPaths from the site settings handlebars.view.templateRootPath and handlebars.view.partialRootPath.
  • Include this set for every site that renders Handlebars templates.

• cpsit/handlebars-content-element — Handlebars content elements

  • Sets lib.contentElement = HANDLEBARSTEMPLATE, replacing the default Fluid base object used by EXT:fluid_styled_content.
  • Include this set when all content elements should use Handlebars rendering by default.

dependencies:
  - cpsit/handlebars
  - cpsit/handlebars-content-element

Priority order 

Per-content-object (priority 100) 

Template and partial root paths can be set directly inside a HANDLEBARSTEMPLATE content object. These paths apply only to that specific rendering, including any nested partial lookups triggered by it.

tt_content.textmedia = HANDLEBARSTEMPLATE
tt_content.textmedia {
    templateRootPaths {
        10 = EXT:my_extension/Resources/Private/Templates
    }
    partialRootPaths {
        10 = EXT:my_extension/Resources/Private/Partials
    }
}

TypoScript (priority 50) 

Global paths for all renderings on the current page can be configured under plugin.tx_handlebars.view:

plugin.tx_handlebars {
    view {
        templateRootPaths {
            10 = EXT:my_extension/Resources/Private/Templates
        }
        partialRootPaths {
            10 = EXT:my_extension/Resources/Private/Partials
        }
    }
}

The cpsit/handlebars site set also populates these paths from the site settings {$handlebars.view.templateRootPath} and {$handlebars.view.partialRootPath}.

Service container (priority 0) 

The lowest-priority source is the service container. Paths registered here apply instance-wide, regardless of the current page or content object, and serve as the global fallback.

handlebars:
  view:
    templateRootPaths:
      10: EXT:my_extension/Resources/Private/Templates
    partialRootPaths:
      10: EXT:my_extension/Resources/Private/Partials

The HandlebarsExtension DI extension merges all paths declared this way into the container parameters %handlebars.templateRootPaths% and %handlebars.partialRootPaths%.

Global variables 

Global variables are merged into every template rendering automatically. They can be defined through TypoScript or the service container.

plugin.tx_handlebars {
    variables {
        publicPath = /assets
        siteName = My Site
    }
}

handlebars:
  variables:
    publicPath: /assets
    apiEndpoint: https://api.example.com

Per-rendering variables 

Variables scoped to a single rendering are declared in the variables property of a HANDLEBARSTEMPLATE content object. Each entry is processed as a standard content object against the current record's data:

tt_content.header = HANDLEBARSTEMPLATE
tt_content.header {
    templateName = Header

    variables {
        header = TEXT
        header.field = header

        subheader = TEXT
        subheader.field = subheader

        link = TEXT
        link.typolink.parameter.field = header_link
    }
}

Entries with no sub-configuration are treated as simple variables and passed to the template as-is, without invoking ContentObjectRenderer:

variables {
    # Content object — field value is rendered via cObjGetSingle
    header = TEXT
    header.field = header

    # Simple variables — values are passed through directly
    cssClass = my-element
    theme = dark
}

Two variables are always injected automatically and cannot be overridden (this reflects the same behavior as in FLUIDTEMPLATE):

data

The full data array of the current content element record.

current

The value of the current field ( $cObj->currentValKey).

Via TypoScript 

# Enable debug mode
config.debug = 1

# Disable debug mode
config.debug = 0

Via system configuration 

// Enable debug mode
$GLOBALS['TYPO3_CONF_VARS']['FE']['debug'] = true;

// Disable debug mode
$GLOBALS['TYPO3_CONF_VARS']['FE']['debug'] = false;

Next steps 

• HANDLEBARSTEMPLATE content object — complete reference for all HANDLEBARSTEMPLATE properties
• Data processors — enrich templates with database queries, menus, and custom variable processing
• Custom helpers — expose custom PHP logic to templates

templateName 

Type

string / stdWrap

Description

Name of the template to render. The value is resolved as a filename (without the .hbs extension) relative to the configured template root paths. Exactly one of templateName, template, or file must be set.

Example

templateName = Header

# With stdWrap
templateName.field = tx_myext_template_name

Copied!

template 

Type

string / stdWrap

Description

Inline Handlebars source used directly as the template. Useful for short or dynamically constructed templates. Cannot be used together with templateName or file.

Example

template = <h1>{{header}}</h1>

Copied!

file 

Type

string / stdWrap

Description

Absolute or EXT:-relative path to a Handlebars template file. Cannot be used together with templateName or template.

Example

file = EXT:my_extension/Resources/Private/Templates/Special.hbs

Copied!

templateRootPaths 

Type

array (numeric keys)

Description

Template root paths for this content object. These are added to the content object path provider with the highest priority (100), overriding any TypoScript or service container paths for this rendering. Higher numeric keys take precedence over lower ones.

Example

templateRootPaths {
    10 = EXT:my_extension/Resources/Private/Templates
    20 = EXT:my_other_extension/Resources/Private/Templates
}

Copied!

partialRootPaths 

Type

array (numeric keys)

Description

Partial root paths for this content object. Same priority and override rules as templateRootPaths.

Example

partialRootPaths {
    10 = EXT:my_extension/Resources/Private/Partials
}

Copied!

variables 

Type

array

Description

Variables passed to the template. Each entry is processed as a content object against the current content element's data record. Simple string values are passed through as-is; entries with a sub-array are rendered via ContentObjectRenderer::cObjGetSingle().

Two variable names are reserved and always available automatically:

• data — the full content element data array
• current — the current field value

Example

variables {
    header = TEXT
    header.field = header

    bodytext = TEXT
    bodytext.field = bodytext
    bodytext.parseFunc < lib.parseFunc_RTE

    image = FILES
    image.references.fieldName = image
}

Copied!

settings 

Type

array

Description

Arbitrary key-value pairs passed to the template as the settings variable. Unlike variables, entries are not processed as content objects — values are used as plain strings.

Example

settings {
    showDate = 1
    dateFormat = d.m.Y
}

Copied!

In the template:

{{#if settings.showDate}}
    <time>{{formatDate date settings.dateFormat}}</time>
{{/if}}

Copied!

dataProcessing 

Type

array

Description

Standard data processors, executed after variables are resolved. Processors receive and return the $processedData array. Any key added by a processor is available as a template variable.

The extension provides three additional processors: process-variables, resolve-markers, and unflatten-variable-names.

Example

dataProcessing {
    10 = database-query
    10 {
        table = tx_myext_domain_model_item
        as = items
    }

    20 = process-variables
    20 {
        as = items
        merge = 1
        variables {
            label = TEXT
            label.field = title
        }
    }
}

Copied!

preProcessing 

Type

array

Description

Data source aware processors executed before variables are processed. These can read from multiple data sources (content element record, processed data, processor configuration) and modify the variable set before content object rendering begins.

postProcessing 

Type

array

Description

Data source aware processors executed after variables have been resolved and data processors have run, but before the template is rendered.

assets 

Type

array

Description

Registers JavaScript and CSS assets via TYPO3's AssetCollector API. Supports four sub-keys: javaScript, inlineJavaScript, css, inlineCss.

Example

assets {
    javaScript {
        my-ext-app {
            source = EXT:my_extension/Resources/Public/JavaScript/app.js
            attributes.defer = 1
            options.useNonce = 1
        }
    }
    css {
        my-ext-styles {
            source = EXT:my_extension/Resources/Public/Css/styles.css
        }
    }
}

Copied!

headerAssets 

Type

content object

Description

Adds arbitrary markup to the page <head>. The value is evaluated as a content object and the result is passed to PageRenderer::addHeaderData().

Example

headerAssets = TEXT
headerAssets.value = <link rel="stylesheet" href="/assets/styles.css">

Copied!

footerAssets 

Type

content object

Description

Adds arbitrary markup before the closing </body> tag. The value is evaluated as a content object and the result is passed to PageRenderer::addFooterData().

Example

footerAssets = TEXT
footerAssets.value = <script src="/assets/app.js"></script>

Copied!

stdWrap 

Type

stdWrap

Description

Standard TYPO3 stdWrap processing applied to the final rendered output.

Example

stdWrap.wrap = <div class="handlebars-content">|</div>

Copied!

process-variables 

Class: \CPSIT\Typo3Handlebars\DataProcessing\ProcessVariablesProcessor

Processes a variables configuration block — exactly like the top-level variables of HANDLEBARSTEMPLATE — within a data processor chain. This is most useful when combined with other processors such as database-query, allowing per-record variable processing.

tt_content.my_element = HANDLEBARSTEMPLATE
tt_content.my_element {
    templateName = MyElement

    dataProcessing {
        10 = process-variables
        10 {
            variables {
                header = TEXT
                header.field = header

                teaser = TEXT
                teaser.field = bodytext
                teaser.parseFunc < lib.parseFunc_RTE
            }
        }
    }
}

dataProcessing {
    10 = database-query
    10 {
        table = tx_myext_domain_model_item
        as = items

        dataProcessing {
            10 = process-variables
            10 {
                table = tx_myext_domain_model_item
                as = item
                variables {
                    title = TEXT
                    title.field = title

                    body = TEXT
                    body.field = bodytext
                    body.parseFunc < lib.parseFunc_RTE
                }
            }
        }
    }
}

resolve-markers 

Class: \CPSIT\Typo3Handlebars\DataProcessing\ResolveMarkersProcessor

Replaces marker-style keys (e.g., ###NAV_ITEMS###) in the processed data with the values stored under those keys. The typical pattern is to use a marker as a named placeholder early in the chain — either as the as target of a preceding processor or directly in a variables entry — and then resolve all markers to clean variable names in a final step. This keeps intermediate processors decoupled from the variable names the template expects.

tt_content.my_element = HANDLEBARSTEMPLATE
tt_content.my_element {
    templateName = MyElement

    dataProcessing {
        # Declare the expected output slots early using markers — these
        # names will become the final template variables
        10 = menu
        10 {
            as = ###mainNavigation###
            levels = 2
        }

        20 = menu
        20 {
            as = ###footerLinks###
            special = directory
            special.value = 42
        }

        # Resolve all markers to clean variable names in one final step
        90 = resolve-markers
        90.removeNonMatchingMarkers = 1
    }
}

After processing, the template receives mainNavigation and footerLinks as clean variable names. The markers at the top of the chain serve as upfront documentation of what the template expects, while the processors that follow fill those slots independently.

unflatten-variable-names 

Class: \CPSIT\Typo3Handlebars\DataProcessing\UnflattenVariableNamesProcessor

Converts dot-separated flat variable names into nested arrays. This is useful when other processors set their as key to a dotted path, representing the intended position in a nested data structure.

dataProcessing {
    10 = menu
    10 {
        as = page.nav.mainMenu
    }

    20 = menu
    20 {
        as = page.nav.footerLinks
        special = directory
        special.value = 42
    }

    90 = unflatten-variable-names
}

After processing, the template receives a nested page object:

{{#each page.nav.mainMenu}}
    <a href="{{link}}">{{title}}</a>
{{/each}}

The processor has no configuration properties and operates on the entire processed data array.

Implement a helper 

Implement the \CPSIT\Typo3Handlebars\Renderer\Helper\Helper interface and place the #[AsHelper] attribute on the class. Because the class implements the Helper interface, the attribute automatically resolves to the render method:

namespace Vendor\Extension\Renderer\Helper;

use CPSIT\Typo3Handlebars\Attribute\AsHelper;
use CPSIT\Typo3Handlebars\Renderer\Helper\Helper;
use DevTheorem\Handlebars\HelperOptions;

#[AsHelper('greet')]
final readonly class GreetHelper implements Helper
{
    public function render(HelperOptions $options): mixed
    {
        return sprintf('Hello, %s!', $options->hash['name'] ?? 'World');
    }
}

The attribute can also be placed directly on a method, in which case the method name is inferred automatically — no method parameter needed. Dependency injection works normally for all #[AsHelper]-annotated classes:

use CPSIT\Typo3Handlebars\Attribute\AsHelper;
use CPSIT\Typo3Handlebars\Renderer\Helper\Helper;
use DevTheorem\Handlebars\HelperOptions;
use Vendor\Extension\Domain\Model\Person;
use Vendor\Extension\Domain\Repository\PersonRepository;

#[AsHelper('greet')]
final readonly class GreetHelper implements Helper
{
    public function __construct(
        private PersonRepository $repository,
    ) {}

    public function render(HelperOptions $options): mixed
    {
        return sprintf('Hello, %s!', $options->hash['name'] ?? 'World');
    }

    #[AsHelper('greetAll')]
    public function greetAll(HelperOptions $options): mixed
    {
        return implode(PHP_EOL, array_map(
            static fn(Person $person) => sprintf('Hello, %s!', $person->getName()),
            $this->repository->findAll(),
        ));
    }
}

use CPSIT\Typo3Handlebars\Attribute\AsHelper;
use DevTheorem\Handlebars\HelperOptions;

#[AsHelper('greet')]
final readonly class GreetHelper
{
    public function __invoke(HelperOptions $options): mixed
    {
        return sprintf('Hello, %s!', $options->hash['name'] ?? 'World');
    }
}

Use the helper in a template 

Reference the helper by its identifier:

{{greet name="Alice"}}

{{greetAll}}

Alternative: Register via Services.yaml 

If you cannot use the attribute (e.g., for a third-party class), register the helper explicitly in Services.yaml. Both identifier and method are required:

services:
  Vendor\Extension\Renderer\Helper\GreetHelper:
    tags:
      - name: handlebars.helper
        identifier: 'greetAll'
        method: 'greetAll'

BeforeTemplateCompilationEvent 

Dispatched immediately before a template is compiled. The event provides read-only access to the rendering context and the renderer. Use it to inspect the context (e.g., to log which template is about to be rendered) or to trigger additional rendering via the renderer:

namespace Vendor\Extension\EventListener;

use CPSIT\Typo3Handlebars\Event\BeforeTemplateCompilationEvent;

final readonly class BeforeTemplateCompilationListener
{
    public function __invoke(BeforeTemplateCompilationEvent $event): void
    {
        $context = $event->getContext();   // RenderingContext
        $renderer = $event->getRenderer(); // Renderer
    }
}

BeforeRenderingEvent 

Dispatched after variables have been resolved and merged, immediately before the compiled template is executed. The full variable set can be read and modified:

namespace Vendor\Extension\EventListener;

use CPSIT\Typo3Handlebars\Event\BeforeRenderingEvent;

final readonly class BeforeRenderingListener
{
    public function __invoke(BeforeRenderingEvent $event): void
    {
        // Add a variable
        $event->addVariable('timestamp', time());

        // Replace the entire variable set
        $variables = $event->getVariables();
        $variables['title'] = strtoupper($variables['title'] ?? '');
        $event->setVariables($variables);

        // Remove a variable
        $event->removeVariable('internalFlag');
    }
}

Available methods:

• getVariables() / setVariables(array $variables) — get or replace the full variable set
• addVariable(string $name, mixed $value) — add or overwrite a single variable
• removeVariable(string $name) — remove a variable by name
• getContext() — the RenderingContext (read-only)
• getRenderer() — the Renderer (read-only)

AfterRenderingEvent 

Dispatched after the template has been fully rendered. The rendered HTML string can be read and replaced:

namespace Vendor\Extension\EventListener;

use CPSIT\Typo3Handlebars\Event\AfterRenderingEvent;

final readonly class AfterRenderingListener
{
    public function __invoke(AfterRenderingEvent $event): void
    {
        $content = $event->getContent();
        $event->setContent(trim($content));
    }
}

Available methods:

• getContent() / setContent(string $content) — get or replace the rendered output
• getContext() — the RenderingContext (read-only)
• getRenderer() — the Renderer (read-only)

Asset Types 

The AssetCollector API supports four distinct asset types, all fully supported by this extension:

1. External JavaScript files — link to external .js files
2. Inline JavaScript code — embed JavaScript directly in the page
3. External CSS files — link to external .css files
4. Inline CSS code — embed styles directly in the page

10 = HANDLEBARSTEMPLATE
10 {
    templateName = MyTemplate

    assets {
        javaScript {
            my-app-script {
                source = EXT:myext/Resources/Public/JavaScript/app.js
                attributes {
                    async = 1
                    defer = 1
                    crossorigin = anonymous
                }
                options {
                    priority = 1
                    csp = 1
                }
            }
        }
    }
}

assets {
    inlineJavaScript {
        my-inline-script {
            source = console.log('Hello from Handlebars'); initMyApp();
            attributes {
                type = module
            }
            options {
                priority = 1
            }
        }
    }
}

assets {
    css {
        my-styles {
            source = EXT:myext/Resources/Public/Css/styles.css
            attributes {
                media = screen and (max-width: 768px)
            }
            options {
                priority = 1
            }
        }
    }
}

assets {
    inlineCss {
        critical-css {
            source = body { margin: 0; padding: 0; } .container { max-width: 1200px; }
        }
    }
}

Configuration reference 

Wiring the implementation 

Register the custom renderer as the implementation of the Renderer interface in your extension's Services.yaml:

services:
  CPSIT\Typo3Handlebars\Renderer\Renderer:
    alias: Vendor\Extension\Renderer\MyRenderer

Example implementation 

namespace Vendor\Extension\Renderer\Template;

use CPSIT\Typo3Handlebars\Exception;
use CPSIT\Typo3Handlebars\Renderer\Template\BaseTemplateResolver;
use CPSIT\Typo3Handlebars\Renderer\Template\TemplatePaths;

final readonly class MyTemplateResolver extends BaseTemplateResolver
{
    public function __construct(
        private TemplatePaths $templatePaths,
    ) {}

    public function resolveTemplatePath(string $templatePath, ?string $format = null): string
    {
        [$templateRootPaths] = $this->resolveTemplatePaths($this->templatePaths);

        foreach (array_reverse($templateRootPaths) as $rootPath) {
            $filename = $this->resolveFilename($templatePath, $rootPath, $format ?? 'hbs');

            if (is_file($filename)) {
                return $filename;
            }
        }

        throw new Exception\TemplatePathIsNotResolvable($templatePath);
    }

    public function resolvePartialPath(string $partialPath, ?string $format = null): string
    {
        [, $partialRootPaths] = $this->resolveTemplatePaths($this->templatePaths);

        foreach (array_reverse($partialRootPaths) as $rootPath) {
            $filename = $this->resolveFilename($partialPath, $rootPath, $format ?? 'hbs');

            if (is_file($filename)) {
                return $filename;
            }
        }

        throw new Exception\PartialPathIsNotResolvable($partialPath);
    }
}

Wiring the implementation 

Register the custom resolver as the implementation of the TemplateResolver interface in your extension's Services.yaml:

services:
  CPSIT\Typo3Handlebars\Renderer\Template\TemplateResolver:
    alias: Vendor\Extension\Renderer\Template\MyTemplateResolver

Reading from DataSourceCollection 

DataSourceCollection::resolve() searches the data sources in priority order and returns the first match. Pass a specific DataSource case to restrict the lookup:

use CPSIT\Typo3Handlebars\DataProcessing\DataSource\DataSource;

// Search all sources (highest priority first)
$table = $collection->resolve('table');

// Search only the processor configuration
$table = $collection->resolve('table', DataSource::ProcessorConfiguration);

// Search two specific sources, in the given order
$table = $collection->resolve('table', [
    DataSource::ProcessorConfiguration,
    DataSource::ContentObjectConfiguration,
]);

The four DataSource cases are:

• DataSource::ProcessorConfiguration — this processor's own config block
• DataSource::ProcessedData — accumulated output from previous processors
• DataSource::ContentObjectRenderer — current record's field values
• DataSource::ContentObjectConfiguration — top-level HANDLEBARSTEMPLATE config

Example implementation 

namespace Vendor\Extension\DataProcessing;

use CPSIT\Typo3Handlebars\DataProcessing\DataSource\DataSource;
use CPSIT\Typo3Handlebars\DataProcessing\DataSource\DataSourceAwareProcessor;
use CPSIT\Typo3Handlebars\DataProcessing\DataSource\DataSourceCollection;
use TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer;

final readonly class MyPreProcessor implements DataSourceAwareProcessor
{
    public function process(
        array $variables,
        DataSourceCollection $collection,
        ContentObjectRenderer $contentObjectRenderer,
    ): array {
        $table = $collection->resolve('table', DataSource::ProcessorConfiguration, 'tt_content');
        $variables['tableName'] = $table;

        return $variables;
    }
}

Registering the processor 

Reference the processor class by its fully qualified class name in preProcessing or postProcessing:

10 = process-variables
10 {
    variables {
        header = TEXT
        header.field = header
    }

    preProcessing {
        10 = Vendor\Extension\DataProcessing\MyPreProcessor
    }
}

The numeric keys control execution order when multiple processors are registered. The class is instantiated via GeneralUtility::makeInstance(), so constructor injection works as normal.

PathProvider 

Implement the \CPSIT\Typo3Handlebars\Renderer\Template\Path\PathProvider interface to contribute template and partial root paths programmatically — for example when paths depend on the current site configuration or a value not available at container compile time.

Higher priority values are merged last and therefore take precedence over lower ones. The three built-in providers use 0 ( GlobalPathProvider), 50 ( TypoScriptPathProvider), and 100 ( ContentObjectPathProvider).

interface PathProvider

Fully qualified name

\CPSIT\Typo3Handlebars\Renderer\Template\Path\PathProvider

getTemplateRootPaths ( )

Return an array of template root paths, keyed by integer priority.

returntype

array

getPartialRootPaths ( )

Return an array of partial root paths, keyed by integer priority.

returntype

array

isCacheable ( )

Return true if the paths provided by this provider may be cached. Return false for request-dependent paths.

returntype

bool

getPriority ( )

Return the priority of this provider. Higher values win.

returntype

int

namespace Vendor\Extension\Renderer\Template\Path;

use CPSIT\Typo3Handlebars\Renderer\Template\Path\PathProvider;
use TYPO3\CMS\Core\Site\SiteFinder;

final readonly class SitePathProvider implements PathProvider
{
    public function __construct(
        private SiteFinder $siteFinder,
    ) {}

    public function getTemplateRootPaths(): array
    {
        return [];
    }

    public function getPartialRootPaths(): array
    {
        return [];
    }

    public function isCacheable(): bool
    {
        return false;
    }

    public static function getPriority(): int
    {
        return 25;
    }
}

The class is picked up automatically because PathProvider carries #[AutoconfigureTag('handlebars.template_path_provider')]. No extra Services.yaml entry is needed beyond standard autowiring.

VariableProvider 

Implement the \CPSIT\Typo3Handlebars\Renderer\Variables\VariableProvider interface to inject variables into every template rendering without repeating them in TypoScript. Common uses include a site-wide locale string, feature flags, or shared navigation data.

Providers are merged in ascending priority order; a higher-priority provider can overwrite keys from a lower-priority one. The built-in GlobalVariableProvider uses priority 0.

interface VariableProvider

Fully qualified name

\CPSIT\Typo3Handlebars\Renderer\Variables\VariableProvider

get ( )

Return the variables contributed by this provider.

returntype

array

getPriority ( )

Return the priority of this provider. Higher values win.

returntype

int

namespace Vendor\Extension\Renderer\Variables;

use CPSIT\Typo3Handlebars\Renderer\Variables\VariableProvider;
use TYPO3\CMS\Core\Site\SiteFinder;

final readonly class SiteVariableProvider implements VariableProvider
{
    public function __construct(
        private SiteFinder $siteFinder,
    ) {}

    public function get(): array
    {
        return [
            'siteName' => $this->siteFinder->getSiteByPageId(0)->getIdentifier(),
        ];
    }

    public function offsetExists(mixed $offset): bool
    {
        return array_key_exists($offset, $this->get());
    }

    public function offsetGet(mixed $offset): mixed
    {
        return $this->get()[$offset] ?? null;
    }

    public function offsetSet(mixed $offset, mixed $value): never
    {
        throw new \LogicException('Variables are read-only.', 1781693633);
    }

    public function offsetUnset(mixed $offset): never
    {
        throw new \LogicException('Variables are read-only.', 1781693639);
    }

    public static function getPriority(): int
    {
        return 10;
    }
}

Like PathProvider, the class is picked up automatically via #[AutoconfigureTag('handlebars.variable_provider')] on the interface.

Version 1.0.0 

Version 1.0.0 replaces the previous PHP-class rendering model (DataProcessor / DataProvider / Presenter) with the HANDLEBARSTEMPLATE content object. All rendering configuration moves to TypoScript; custom PHP classes are no longer the entry point.

tt_content.header = USER
tt_content.header.userFunc = Vendor\Extension\DataProcessing\HeaderProcessor->process

tt_content.header = HANDLEBARSTEMPLATE
tt_content.header {
    templateName = Header

    variables {
        header = TEXT
        header.field = header

        subheader = TEXT
        subheader.field = subheader
    }
}

tt_content.my_element {
    templateName = MyElement
}

tt_content.my_element {
    templateName = MyElement
    templateName.override.if {
        isTrue.field = tx_myext_variant
        value = special
    }
    templateName.override = MyElementSpecial
}

services:
  Vendor\Extension\Renderer\Helper\GreetHelper:
    tags:
      - name: handlebars.helper
        identifier: 'greet'
        method: 'greetById'

use CPSIT\Typo3Handlebars\Attribute\AsHelper;
use CPSIT\Typo3Handlebars\Renderer\Helper\Helper;
use DevTheorem\Handlebars\HelperOptions;

#[AsHelper('greet')]
final readonly class GreetHelper implements Helper
{
    public function render(HelperOptions $options): string { /* ... */ }
}

tt_content.textmedia = HANDLEBARSTEMPLATE
tt_content.textmedia {
    templateRootPaths.10 = EXT:my_extension/Resources/Private/Templates
    partialRootPaths.10 = EXT:my_extension/Resources/Private/Partials
}

Create an issue first 

Before you start working on the extension, please create an issue on GitHub: https://github.com/CPS-IT/handlebars/issues

Also, please check if there is already an issue on the topic you want to address.

Contribution workflow 

git clone https://github.com/CPS-IT/handlebars.git
cd handlebars

composer install

# All analyzers
composer analyze

# Specific analyzers
composer analyze:dependencies

# All linters
composer lint

# Specific linters
composer lint:composer
composer lint:editorconfig
composer lint:php
composer lint:typoscript

# Fix all CGL issues
composer fix

# Fix specific CGL issues
composer fix:composer
composer fix:editorconfig
composer fix:php
composer fix:typoscript

# All static code analyzers
composer sca

# Specific static code analyzers
composer sca:php

# All tests
composer test

# Specific tests
composer test:functional
composer test:unit

# All tests with code coverage
composer test:coverage

# Specific tests with code coverage
composer test:coverage:functional
composer test:coverage:unit

# Merge code coverage of all test suites
composer test:coverage:merge

open .Build/coverage/html/_merged/index.html

# Rebuild and open documentation
composer docs

# Build documentation (from cache)
composer docs:build

# Open rendered documentation
composer docs:open