Microtemplate for TYPO3

Fluid is sometimes overkill when all you need is a string filled with variables

Not every templating problem needs the full Fluid engine. When an email subject line should read “Hello {name}, your order #{orderNumber}”, or a footer snippet should show “Last updated: {date}”, Fluid with its ViewHelpers, layouts and partials is architectural overhead. A micro-template engine does nothing but replace variables in text snippets. No Fluid, no TypoScript object path, no template file. A string with placeholders, an array with values, done. Under the extension key microtemplate, however, the TER lists a different product: a one-page template by Brightside, currently version 6.0.0 for TYPO3 14. No micro-template engine by that name is published there.

Micro-templating is a niche tool for developers who need simple string substitution in extensions or TypoScript configurations without starting the Fluid rendering pipeline. Editors never see it directly; it works in the background as a utility. Its scope is deliberately narrow: Fluid remains the right choice for complex templates with loops, conditions and inheritance, while micro-templating covers the simple case of a finished string that needs a dynamic value in three places.

Typical use cases are email texts, dynamic snippets and configuration templates

The most common scenario is generating email texts in extensions. A custom extension sends confirmation emails, and subject and body should be configurable without the developer having to create Fluid templates. The extension reads the text from a TypoScript constant (“Order #{orderNumber} confirmed”) and replaces the placeholders with the current values.

The second scenario is dynamic text snippets in TypoScript configurations. A page title pattern such as “{siteName} - {pageTitle} | {category}” is resolved via micro-templating. That is simpler than a COA with several TEXT objects and stdWrap functions.

The third scenario is configuration templates for third-party integrations. When an extension makes an API endpoint configurable (https://api.example.com/{version}/users/{userId}), micro-templating can replace the placeholders before the API call. This is particularly useful for extensions that support several API environments, such as staging and production, and want to keep the endpoint structure in the TypoScript configuration rather than in the code.

A fourth scenario comes up occasionally in practice: log messages with a structured format. An extension writes “Import of {count} records from {source} completed at {time}” to the TYPO3 log. Micro-templating makes the log text configurable without the developer having to maintain sprintf calls with positional arguments.

Technically, a micro-template engine is a single PHP class doing string replacement

At its core, a micro-template engine consists of a single PHP class that runs str_replace or preg_replace on a template string. The placeholders follow a configurable syntax (default: {variableName}), and an associative array supplies the values. The class has no dependencies beyond PHP’s own string handling.

Integration into TYPO3 works through a service or a static method that is called from other extensions or from TypoScript configurations. There is no frontend plugin, no backend module and no content element. The engine is pure developer infrastructure.

The performance cost is negligible: a str_replace on a 500-character string with 5 variables takes less than 0.01 ms. By comparison, the Fluid engine starts a full rendering cycle for the same result, with template parsing, ViewHelper instantiation and caching, which takes 1 to 5 ms. In a typical page rendering process, the difference goes unnoticed, but in loops that generate 1,000 emails or 500 log entries, the performance advantage becomes measurable.

Such an engine needs no database tables, no backend modules and no frontend plugins; it can be placed as a single class in any extension of your own.

Common problems are missing escaping, syntax conflicts and thin documentation

Problem one: no automatic HTML escaping. A micro-template engine replaces placeholders one to one, without escaping the inserted value. If a user name contains HTML tags, such as <script>alert('XSS')</script>, that markup goes straight into the output. The fix: escape values manually before inserting them (htmlspecialchars), or use micro-templating only for internal data that is not user-generated.

Problem two: syntax conflicts with Fluid. If micro-template placeholders ({variable}) are used in a context where Fluid also renders, Fluid tries to resolve them and throws an error. The fix: use a different placeholder syntax (for example {{variable}} or %variable%) or make sure the substitution runs before Fluid.

Problem three: thin documentation and community support. A micro-template class that you build yourself or inherit from legacy projects has no user base: when problems arise, there is no community, no issue tracking and no Stack Overflow answers. Developers have to read the source code to understand how it behaves. In practice, every developer on the team ends up using it differently, because no conventions are documented.

One more topic: debugging. If a placeholder is not replaced because the array key does not exactly match the placeholder name (case, whitespace), a simple substitution issues no warning. The placeholder simply stays in place, and the developer looks for the error in the wrong spot. A debug mode that logs unresolved placeholders therefore belongs in every custom implementation.

Micro-templating needs no extension, because PHP has the tools built in

A micro-template engine uses only standard PHP functions and is therefore not tied to any TYPO3 version; which versions an extension by that name would be released for cannot be documented, because no such version has been published. The real question is whether you need one at all. Plain PHP delivers the same functionality without an extension through strtr() or str_replace() with a replacement array, which worked long before PHP 8.0; named arguments do not help here, because sprintf() only knows positional placeholders. For more complex templates, Fluid remains the better choice despite its overhead, because it brings caching, escaping and template inheritance. Gosign does not actively use micro-template extensions in existing projects and, for new implementations, recommends building the functionality directly into the project’s own extension or into TypoScript via stdWrap.