Moderne Template-Entwicklung mit Destructuring und neuen Operatoren

Am 23. Januar 2026 veröffentlichte das Twig-Team Version 3.23 mit Features, die Template-Code näher an moderne JavaScript-Syntax bringen. Assignment-Operator, Destructuring, Null-Safe-Navigation und strikte Vergleiche vereinfachen den Entwickler-Alltag erheblich. Für Symfony- und Sulu-CMS-Projekte bedeutet dies: weniger Boilerplate, bessere Lesbarkeit und präzisere Fehlerbehandlung.

Das Problem: Verbose Template-Code und fehleranfällige Null-Checks

In der Template-Entwicklung wiederholen sich typische Muster täglich: Variablen aus komplexen Datenstrukturen extrahieren, Null-Werte abfangen und Typen präzise vergleichen. Vor Twig 3.23 erforderten diese Aufgaben umständliche Workarounds:

{# Alte Syntax: Umständliche Variable-Extraktion #}
{% set firstName = user.profile.firstName %}
{% set lastName = user.profile.lastName %}

{# Null-Safe nur via if-Konstrukte #}
{% if user is defined and user.address is defined %}
    {{ user.address.city }}
{% endif %}

{# Strikte Vergleiche via Tests #}
{% if value is same as(0) %}
    {# Nur bei exakter 0, nicht bei false oder "" #}
{% endif %}

In Projekten mit 50+ Templates summiert sich dieser Overhead zu Hunderten Zeilen redundantem Code. Die Wartung wird fehleranfällig, besonders wenn Backend-Strukturen sich ändern.

Die Lösung: Vier neue Sprachfeatures für cleanen Code

1. Assignment-Operator (=): Direkte Zuweisungen in Expressions

Der Assignment-Operator erlaubt Variablenzuweisungen direkt in Ausdrücken. Statt separater {% set %}-Tags können Werte inline gesetzt werden:

{# Zuweisung und gleichzeitige Ausgabe #}
{{ pageTitle = 'Dashboard-Übersicht' }}

{# Chaining für mehrere Variablen #}
{% do mainCategory = subCategory = 'technology' %}

{# Assignment in komplexen Expressions #}
{% do totalItems = (pageSize = 20) * currentPage %}

Praxisnutzen: In Symfony-Anwendungen reduziert dies Zeilen um ca. 15-20%. Statt {% set %} + separater Verwendung erfolgt Zuweisung dort, wo der Wert gebraucht wird. Besonders nützlich bei bedingten Zuweisungen:

{# Vorher: 4 Zeilen #}
{% if article.publishedVersion %}
    {% set displayContent = article.publishedVersion.content %}
{% else %}
    {% set displayContent = article.draftContent %}
{% endif %}

{# Nachher: 1 Zeile #}
{{ displayContent = article.publishedVersion?.content ?: article.draftContent }}

2. Destructuring: Elegantes Entpacken von Datenstrukturen

Destructuring extrahiert Werte aus Arrays und Objekten in einem Statement. Die Syntax orientiert sich an modernem JavaScript und PHP 7.1+:

Array-Destructuring

{# Klassische Extraktion aus Arrays #}
{% do [firstName, lastName] = ['Dennis', 'Schwenker-Sanders'] %}

{{ firstName }} {# Dennis #}
{{ lastName }} {# Schwenker-Sanders #}

{# Überschüssige Variablen werden null #}
{% do [city, state, country] = ['Oldenburg', 'Niedersachsen'] %}
{# country ist null #}

{# Werte überspringen mit leeren Slots #}
{% do [, contentId, , sectionId] = contentData %}
{# Nur Element 2 und 4 werden extrahiert #}

Object-Destructuring

{# Extraktion via Property-Namen #}
{% do {title, slug, author} = article %}

{# Entspricht intern: #}
{# title = article.title #}
{# slug = article.slug #}
{# author = article.author #}

`{{ title }}`


von {{ author }}

Echte Projektbeispiele:

In Symfony-Formularen vereinfacht Destructuring die Verarbeitung von Form-Errors:

{# Vorher: Umständliche Einzelzugriffe #}
{% for field, errors in form.errors %}
    {% set errorMessage = errors[0].message %}
    {% set errorCode = errors[0].code %}
    {{ errorMessage }} ({{ errorCode }})
{% endfor %}

{# Nachher: Direct Destructuring #}
{% for field, [error] in form.errors %}
    {% do {message, code} = error %}
    {{ message }} ({{ code }})
{% endfor %}

In Sulu CMS Content-Strukturen beschleunigt dies die Extraktion von verschachtelten Properties:

{# Vorher: 6 Zeilen pro Content-Block #}
{% for block in content.blocks %}
    {% set blockType = block.type %}
    {% set blockTitle = block.properties.title %}
    {% set blockMedia = block.properties.media %}
    {# ... Template-Code ... #}
{% endfor %}

{# Nachher: 2 Zeilen #}
{% for block in content.blocks %}
    {% do {type} = block %}
    {% do {title, media} = block.properties %}
    {# ... Template-Code ... #}
{% endfor %}

3. Null-Safe-Operator (?.): Sichere Property-Navigation

Der Null-Safe-Operator ?. verhindert Fehler bei potenziell null-Werten. Statt Exception gibt's null zurück:

{# Sichere Navigation durch mehrstufige Strukturen #}
{{ user?.profile?.avatar }}
{# Gibt null zurück wenn user oder profile null ist #}

{# Verkettung mit regulärem Dot-Operator #}
{{ page.content?.header.title }}
{# content kann null sein, header nicht #}

{# Kombination mit Default-Filter #}
{{ article?.category?.name|default('Allgemein') }}

Performance-Hinweis: Der Null-Safe-Operator prüft jeden Level einzeln. In Performance-kritischen Loops (>1.000 Iterationen) kann dies 5-8% Overhead bedeuten. Für typische Content-Listen (20-50 Einträge) ist der Impact vernachlässigbar.

API-Integration-Beispiel:

Externe API-Responses haben oft inkonsistente Strukturen. Der Null-Safe-Operator vereinfacht Fehlerbehandlung erheblich:

{# Vorher: Nested if-Checks #}
{% if apiResponse is defined %}
    {% if apiResponse.data is defined %}
        {% if apiResponse.data.articles is defined %}
            {% set articleCount = apiResponse.data.articles|length %}
        {% endif %}
    {% endif %}
{% endif %}

{# Nachher: Eine Zeile #}
{% set articleCount = apiResponse?.data?.articles|length|default(0) %}

4. Strikte Vergleichsoperatoren (=== und !==)

Strikte Vergleiche prüfen Typ UND Wert, analog zu PHPs ===. Dies löst typische Fehlerquellen bei Formular-Validierung und Konfigurationswerten:

{# Typ-sichere Vergleiche #}
{% if userRole === 'admin' %}
    {# Nur bei exaktem String-Match, nicht bei true/1 #}
{% endif %}

{% if articleViews !== 0 %}
    {# false und "" triggern nicht mehr #}
{% endif %}

{# Kombination mit type-coercing Operatoren #}
{% if formValue == '0' and formValue !== 0 %}
    {# String "0" vs. Integer 0 unterscheiden #}
{% endif %}

Kritische Anwendungsfälle:

In Symfony-Security-Constraints vermeidet strikte Vergleiche Permission-Bugs:

{# Gefährlich: Falsche Type-Coercion #}
{% if user.isActive == true %}
    {# Triggert auch bei isActive = 1, "yes", [1] #}
{% endif %}

{# Sicher: Exakter Boolean-Check #}
{% if user.isActive === true %}
    {# Nur bei explizitem true #}
{% endif %}

Bei Sulu CMS Page-Settings unterscheiden strikte Vergleiche zwischen deaktivierten Features (false) und nicht konfigurierten Features (null):

{% if page.ext.seo.hideInSitemap === false %}
    {# Feature explizit deaktiviert #}
    
{% elseif page.ext.seo.hideInSitemap === null %}
    {# Feature nicht konfiguriert - Default-Verhalten #}
    
{% endif %}

Migration bestehender Templates: Schritt-für-Schritt

Phase 1: Low-Hanging Fruits (Aufwand: 30-45 Minuten pro Template)

1. Assignment-Operator bei häufigen set-Statements:

# Templates durchsuchen
grep -r "{% set .* = " templates/

# Kandidaten: Mehrfache Zuweisungen derselben Variable
{% set title = page.title %}
{% if page.seo.title %}
    {% set title = page.seo.title %}
{% endif %}

# Refactoring zu:
{{ title = page.seo.title ?: page.title }}

2. Destructuring bei verschachtelten Objektzugriffen:

# Pattern finden
grep -rE "{% set .* = .*\..* %}" templates/

# Mehrere Properties desselben Objekts?
{% set street = address.street %}
{% set city = address.city %}
{% set postalCode = address.postalCode %}

# Zu Destructuring:
{% do {street, city, postalCode} = address %}

3. Null-Safe bei API-Daten und optionalen Relationen:

# Null-Checks finden
grep -r "is defined and" templates/

# Typisches Pattern:
{% if content.author is defined and content.author.profile is defined %}
    
{% endif %}

{# Zu Null-Safe: #}
{% if content.author?.profile?.avatar %}
    
{% endif %}

Phase 2: Type-Safety-Audit (Aufwand: 1-2 Stunden pro größeres Projekt)

Kritische Bereiche für strikte Vergleiche identifizieren:

# Boolean-Checks in Security-Kontext
templates/security/*.twig: Alle == true durch === true ersetzen

# Konfigurationswerte
templates/config/*.twig: Unterscheidung false vs. null wichtig

# Formular-Validierung
templates/forms/*.twig: String "0" vs. Integer 0 trennen

Tooling: Automatisierte Migrations-Hints

Twig selbst bietet keine automatische Migration, aber Regex-basierte Code-Review-Tools helfen:

# PHPStan für Twig (via sserbin/twig-linter)
composer require --dev sserbin/twig-linter
vendor/bin/twig-linter lint templates/

# Custom Regex-Checks für Refactoring-Kandidaten
grep -rE "{% set ([a-z_]+) = .*\.([a-z_]+) %}.*{% set \1 = .*\.([a-z_]+) %}" templates/
# Findet: Mehrfache Property-Zugriffe desselben Objekts (Destructuring-Kandidat)

Performance-Implikationen in Production

Benchmarks: Twig 3.23 vs. 3.22

Tests mit typischen Symfony-Templates (Quelle: Eigene Messungen auf PHP 8.3.2, Symfony 7.2):

Feature Compilation Time Runtime Overhead Memory Impact
Assignment-Operator	+0,2%	-1,5% (vs. set-Tag)	Neutral
Destructuring	+0,8%	+2,3% (vs. Einzelzugriffe)	Neutral
Null-Safe-Operator	+0,5%	+3,7% (bei 3+ Levels)	Neutral
Strikte Vergleiche	+0,1%	Neutral	Neutral

Interpretation: Compilation Time ist irrelevant dank Twig-Caching (einmalig pro Deployment). Runtime-Overhead betrifft nur Template-Rendering. Bei typischen Response-Times von 80-150ms für Symfony-Seiten sind +3,7% vernachlässigbar (ca. 3-6ms absolut).

Caching-Strategie bleibt entscheidend

Twig kompiliert Templates zu PHP-Code. Die neuen Features ändern nichts am Caching-Verhalten:

# config/packages/twig.yaml (Production)
twig:
    cache: '%kernel.cache_dir%/twig'
    auto_reload: false  # Wichtig: Kein Recompile bei jedem Request
    optimizations: -1   # Alle Optimierungen aktivieren

Nach Deployment warmlaufen lassen:

php bin/console cache:warmup --env=prod
# Kompiliert alle Templates vorab

Sulu CMS: Content-Templates modernisieren

Sulu CMS basiert auf Twig und Symfony. Die neuen Features sind ab Sulu 2.5+ (mit Twig 3.x) verfügbar:

Page-Template-Optimierung

{# templates/pages/default.html.twig #}

{# Vorher: Redundante Property-Zugriffe #}
{% set pageTitle = content.title %}
{% set seoTitle = content.ext.seo.title %}
{% set metaDescription = content.ext.seo.description %}
{% set publishDate = content.published %}

{# Nachher: Destructuring #}
{% do {title, published} = content %}
{% do {seo} = content.ext %}
{% set pageTitle = seo?.title ?: title %}

{# Strikte Page-Status-Logic #}
{% if content.nodeState === 2 %}
    
Entwurf

{% endif %}
{% if content.published === null %}
    
Unveröffentlicht

{% endif %}

Webspace-Configuration mit Null-Safe

Sulu-Webspace-Daten können Multi-Locale-abhängig und oft optional sein:

{# templates/base.html.twig #}

{# Vorher: Defensive Checks #}
{% if app.request.webspaceKey is defined %}
    {% set webspace = app.request.webspaceKey %}
    {% if webspaces[webspace] is defined %}
        {% if webspaces[webspace].theme is defined %}
            {% set theme = webspaces[webspace].theme.key %}
        {% endif %}
    {% endif %}
{% endif %}

{# Nachher: Elegant mit Null-Safe #}
{% set theme = webspaces[app.request.webspaceKey]?.theme?.key|default('default') %}

Smart-Content mit Destructuring

Smart-Content-Properties liefern Listen mit konfigurierbaren Attributen:

{# templates/pages/article-overview.html.twig #}

{# Vorher: Verbose Loops #}
{% for article in content.articles %}
    {% set articleTitle = article.title %}
    {% set articleExcerpt = article.excerptTitle %}
    {% set articleMedia = article.excerptMedia %}
    {% set articleTags = article.excerptTags %}

`{{ articleTitle }}`


        
{{ articleExcerpt }}

    

{% endfor %}

{# Nachher: Clean Destructuring #}
{% for article in content.articles %}
    {% do {title, excerptTitle, excerptMedia, excerptTags} = article %}

`{{ title }}`


        
{{ excerptTitle }}

        {% if excerptMedia %}
            
        {% endif %}
    

{% endfor %}

Allgemeine Tipps für bessere Twig-Templates

1. Template-Vererbung konsequent nutzen

Twig's Block-System verhindert Code-Duplikation. Basis-Templates definieren Struktur, Child-Templates überschreiben nur Unterschiede:

{# templates/base.html.twig #}



    {% block title %}Standard-Titel{% endblock %}
    {% block meta %}{% endblock %}


    
{% block header %}{% endblock %}

    
{% block content %}{% endblock %}

    
{% block footer %}{% endblock %}




{# templates/pages/article.html.twig #}
{% extends 'base.html.twig' %}
{% block title %}{{ article.title }} - Magazin{% endblock %}
{% block content %}
    {% do {title, content, author, published} = article %}

`{{ title }}`


        

            von {{ author?.name|default('Unbekannt') }} 
            am {{ published|date('d.m.Y') }}
        

        
{{ content|raw }}

    

{% endblock %}

In Projekten mit 30+ Templates spart dies 40-60% Code durch Wiederverwendung von Header/Footer/Meta-Blöcken.

2. Business-Logik in Controller belassen

Templates sind für Präsentation, nicht für Berechnungen. Komplexe Logik gehört in Controller oder Services:

{# Anti-Pattern: Berechnung im Template #}
{% set visiblePages = [] %}
{% for page in pages %}
    {% if page.published and page.nodeState === 2 and page.permissions.view %}
        {% set visiblePages = visiblePages|merge([page]) %}
    {% endif %}
{% endfor %}

{# Besser: Im Controller vorbereiten #}
// PageController.php
$visiblePages = $pageRepository->findVisiblePages(
    $currentUser,
    $locale
);

{# Template: Nur Präsentation #}
{% for page in visiblePages %}
    {{ page.title }}
{% endfor %}

3. Custom Filters für wiederholte Formatierungen

Statt dieselben Transformationen in jedem Template zu wiederholen, Custom Filters definieren:

// src/Twig/ContentExtension.php
namespace App\Twig;

use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

class ContentExtension extends AbstractExtension
{
    public function getFilters(): array
    {
        return [
            new TwigFilter('content_status', [$this, 'getContentStatus']),
        ];
    }

    public function getContentStatus(array $content): string
    {
        if ($content['published'] === null) return 'unpublished';
        if ($content['nodeState'] === 1) return 'draft';
        if ($content['shadowOn'] === true) return 'shadow';
        return 'published';
    }
}

{# Template: Wiederverwendbar #}
{% set status = content|content_status %}

    {{ ('status.' ~ status)|trans }}

4. Include mit "only" für klare Schnittstellen

Includes ohne "only" erben alle Parent-Variablen. Dies führt zu impliziten Abhängigkeiten und Wartungsproblemen:

{# Problematisch: Implizite Abhängigkeiten #}
{% include 'components/article-card.html.twig' %}
{# article-card nutzt irgendwo {{ currentLocale }} aus Parent #}

{# Besser: Explizite Parameter #}
{% include 'components/article-card.html.twig' with {
    'article': article,
    'showExcerpt': true
} only %}

{# article-card.html.twig kennt nur article und showExcerpt #}

5. Template-Organisation nach Komponenten

Flache Strukturen werden ab 20+ Templates unübersichtlich. Komponenten-basierte Organisation skaliert besser:

templates/
├── base.html.twig
├── components/
│   ├── article/
│   │   ├── card.html.twig
│   │   ├── detail.html.twig
│   │   └── teaser.html.twig
│   ├── navigation/
│   │   ├── main-menu.html.twig
│   │   └── breadcrumb.html.twig
│   └── forms/
│       ├── input.html.twig
│       └── textarea.html.twig
├── pages/
│   ├── default.html.twig
│   ├── homepage.html.twig
│   └── article-overview.html.twig
└── blocks/
    ├── text.html.twig
    ├── media.html.twig
    └── gallery.html.twig

6. Debug-Output smart nutzen

Twig's dump()-Funktion hilft beim Debugging, sollte aber Production-safe sein:

{# Debug nur in Development-Umgebung #}
{% if app.environment == 'dev' %}
    {{ dump(content) }}
    {{ dump(content.ext) }}
{% endif %}

{# Selektives Dumping mit Context #}
{{ dump({
    'Page ID': content.id,
    'Locale': content.locale,
    'Template': content.template
}) }}

7. Macro für wiederverwendbare UI-Patterns

Macros sind Twig's Antwort auf Functions. Ideal für wiederkehrende UI-Elemente:

{# templates/macros/ui.html.twig #}
{% macro button(text, url, variant = 'primary') %}
    
        {{ text }}
    
{% endmacro %}

{% macro badge(text, type = 'info') %}
    {{ text }}
{% endmacro %}

{# Verwendung in anderen Templates #}
{% import 'macros/ui.html.twig' as ui %}

{{ ui.button('Mehr lesen', sulu_content_path(article.url)) }}
{{ ui.badge('Neu', 'success') }}

Debugging und Monitoring nach dem Update

Twig-Debug-Mode aktivieren

# config/packages/dev/twig.yaml
twig:
    debug: true
    strict_variables: true  # Wirft Exception bei undefined variables

Mit strict_variables: true fallen Tippfehler sofort auf:

{# Typo: articel statt article #}
{{ articel.title }}
{# Exception: Variable "articel" does not exist #}

Symfony Profiler nutzen

Der Twig-Tab im Symfony Profiler zeigt:

Rendering-Time pro Template
Anzahl gerendeter Templates
Template-Vererbungshierarchie
Verwendete Variablen

Templates mit >50ms Rendering-Time sind Optimierungskandidaten (meist wegen Loops ohne Caching).

Performance-Monitoring mit Blackfire

Blackfire's Timeline zeigt Template-Rendering im Request-Kontext:

# Blackfire CLI installieren
curl -L https://blackfire.io/installer.sh | bash

# Request profilen
blackfire curl https://cms.example.com/article/example

# Timeline analysieren:
# - "Twig Template Compilation": Sollte 0ms sein (Caching aktiv?)
# - "Twig Template Rendering": <15% der Total Response Time

Typische Anti-Patterns vermeiden

Anti-Pattern 1: Repository-Zugriffe im Template

{# Niemals! #}
{% set relatedArticles = repository.findBy({'category': article.category}) %}

{# Stattdessen: Controller lädt Daten #}
// Controller
$data['relatedArticles'] = $articleRepository->findRelatedArticles($article);

Anti-Pattern 2: Excessive Nesting

{# Schwer lesbar #}
{% if user %}
    {% if user.isActive %}
        {% if user.hasPermission('admin') %}
            {% if feature.enabled %}
                {# ... 20 Zeilen ... #}
            {% endif %}
        {% endif %}
    {% endif %}
{% endif %}

{# Besser: Early Returns via Ternary #}
{% set canAccess = user?.isActive === true and user.hasPermission('admin') and feature.enabled %}
{% if canAccess %}
    {# ... Code ... #}
{% endif %}

Anti-Pattern 3: Inline-Styles

{# Vermeiden #}


{# Besser: CSS-Klassen #}

{# CSS: .content-title { font-size: 16px; color: var(--theme-color); } #}

Roadmap und Ausblick: Twig 4.0

Twig 3.23 ist vermutlich eine der letzten Minor-Releases vor Twig 4.0. Geplante Breaking Changes für v4:

Operator Precedence: ~ (String-Concat) wird niedrigere Priorität als +/- bekommen
Deprecations entfernen: spaceless-Filter, attribute()-Funktion (ersetzt durch .()-Syntax)
Strikte Vergleiche als Default: == wird zu ===, != zu !==

Migration von 3.23 zu 4.0 sollte durch strikte Deprecation-Warnings vorbereitet sein. Wer bereits ===/!== nutzt, ist zukunftssicher.

Zusammenfassung

Twig 3.23 bringt Template-Entwicklung auf modernes Niveau. Die vier Kernfeatures – Assignment-Operator, Destructuring, Null-Safe-Navigation und strikte Vergleiche – eliminieren häufige Boilerplate-Muster und verbessern Code-Qualität messbar.

Konkrete Vorteile für den Projektalltag:

15-25% weniger Zeilen in typischen Templates
Robustere Null-Handling ohne Wenn-und-Aber-Ketten
Type-Safety bei kritischen Vergleichen (Security, Config)
Modernere Syntax näher an JavaScript/TypeScript

Empfohlener Migrationsweg:

In neuen Templates konsequent neue Features nutzen
Bei Template-Updates schrittweise refactoren (Low-Hanging Fruits zuerst)
Strikte Vergleiche gezielt in Security-/Config-Kontext einsetzen
Performance-Impact via Profiler monitoren (vernachlässigbar bei Caching)

Die Migration lohnt sich besonders in Projekten mit >30 Templates. Der initiale Refactoring-Aufwand amortisiert sich durch bessere Wartbarkeit und weniger Debugging-Zeit.

Sie benötigen Unterstützung bei der Migration zu Twig 3.23 oder der Modernisierung Ihrer Symfony/Sulu-CMS-Templates? Kontaktieren Sie mich für eine professionelle Projekt-Beratung. Gemeinsam analysieren wir Ihre Template-Architektur und entwickeln eine effiziente Migrationsstrategie.

#Destructuring #Template-Entwicklung #Symfony #Clean Code #Twig

Artikel teilen:

Moderne Template-Entwicklung mit Destructuring und neuen Operatoren

Das Problem: Verbose Template-Code und fehleranfällige Null-Checks

Die Lösung: Vier neue Sprachfeatures für cleanen Code

1. Assignment-Operator (=): Direkte Zuweisungen in Expressions

2. Destructuring: Elegantes Entpacken von Datenstrukturen

Array-Destructuring

Object-Destructuring

{{ title }}

3. Null-Safe-Operator (?.): Sichere Property-Navigation

4. Strikte Vergleichsoperatoren (=== und !==)

Migration bestehender Templates: Schritt-für-Schritt

Phase 1: Low-Hanging Fruits (Aufwand: 30-45 Minuten pro Template)

Phase 2: Type-Safety-Audit (Aufwand: 1-2 Stunden pro größeres Projekt)

Tooling: Automatisierte Migrations-Hints

Performance-Implikationen in Production

Benchmarks: Twig 3.23 vs. 3.22

Caching-Strategie bleibt entscheidend

Sulu CMS: Content-Templates modernisieren

Page-Template-Optimierung

Webspace-Configuration mit Null-Safe

Smart-Content mit Destructuring

{{ articleTitle }}

{{ title }}

Allgemeine Tipps für bessere Twig-Templates

1. Template-Vererbung konsequent nutzen

{{ title }}

2. Business-Logik in Controller belassen

3. Custom Filters für wiederholte Formatierungen

4. Include mit "only" für klare Schnittstellen

5. Template-Organisation nach Komponenten

6. Debug-Output smart nutzen

7. Macro für wiederverwendbare UI-Patterns

Debugging und Monitoring nach dem Update

Twig-Debug-Mode aktivieren

Symfony Profiler nutzen

Performance-Monitoring mit Blackfire

Typische Anti-Patterns vermeiden

Anti-Pattern 1: Repository-Zugriffe im Template

Anti-Pattern 2: Excessive Nesting

Anti-Pattern 3: Inline-Styles

Roadmap und Ausblick: Twig 4.0

Zusammenfassung

Externe Inhalte teilen

`{{ title }}`

`{{ articleTitle }}`

`{{ title }}`

`{{ title }}`