TYPO3 Content Blocks und PHP 8.4 Property Hooks: Weniger Code, mehr Kontrolle

Wer TYPO3-Extensions entwickelt, kennt das Szenario: Ein neues Datenbankfeld bedeutet Änderungen an fünf verschiedenen Stellen – ext_tables.sql, TCA-Konfiguration, Domain-Model, Repository und Fluid-Template. Das kostet Zeit, provoziert Inkonsistenzen und macht Wartung zum Geduldspiel.

Die gute Nachricht: Zwei moderne Ansätze eliminieren diesen Overhead: Content Blocks für deklarative Datenstrukturen und PHP 8.4 Property Hooks für schlanke Domain-Models. Zusammen reduzieren sie Boilerplate um bis zu 80%.

Terminologie  

Bevor wir starten, eine kurze Begriffsklärung:

Inhaltsverzeichnis  

Was Sie sich konkret ersparen  

Zunächst ein Überblick: Was bringt Ihnen der Umstieg auf Content Blocks?

Relativer Aufwand in Prozent – 1% steht für vollständig automatisiert (kein manueller Aufwand). Kleiner ist besser.

Content Blocks installieren  

Installieren Sie in wenigen Schritten – je nach Setup über Composer oder den Extension Manager.

# Content Blocks Extension installieren
composer require friendsoftypo3/content-blocks

# Caches leeren und Datenbank aktualisieren
vendor/bin/typo3 cache:flush -g system
vendor/bin/typo3 extension:setup

Neue Content Types per CLI erstellen  

Das make:content-block-Kommando – inspiriert von der bewährten EXT:make Extension – generiert die komplette Grundstruktur für einen neuen Content Block in Sekunden.

Interaktiver Modus  

# Starten Sie den Wizard – er führt Sie durch alle Optionen
vendor/bin/typo3 make:content-block

Direkter Aufruf mit Parametern  

# Content-Element in einem Rutsch erstellen
vendor/bin/typo3 make:content-block \
  --content-type="content-element" \
  --vendor="webconsulting" \
  --name="team-member" \
  --title="Team Member" \
  --extension="my_sitepackage"

Verfügbare Optionen  

Nach der Erstellung  

# Caches leeren (wichtig!)
vendor/bin/typo3 cache:flush -g system

# Datenbank-Schema aktualisieren
vendor/bin/typo3 extension:setup --extension=my_sitepackage

Das Problem: Fragmentierte Wahrheit  

In klassischen TYPO3-Extensions verteilt sich die Definition eines einzelnen Feldes über mehrere Dateien:

Jede Änderung erfordert manuelle Synchronisation. Vergessen Sie eine Stelle, drohen Diskrepanzen zwischen Datenbankschema und Backend-Formular – ein klassischer Nährboden für Bugs.

Die Lösung: YAML als Single Point of Truth  

Mit der Content Blocks Extension definieren Sie Struktur, Typ und Validierung an einer einzigen Stelle. Die Extension generiert daraus automatisch:

Der zentrale Vorteil  

Warum Single Source of Truth in Zeiten von KI-Agents unverzichtbar ist  

In einer Ära, in der KI-gestützte Coding-Agents zunehmend Code analysieren, erweitern und refaktorieren, entscheidet die Codebase-Struktur über den Erfolg. Studien zeigen: 65% der Entwickler:innen erleben fehlenden Kontext beim Refactoring – ein Problem, das sich mit fragmentiertem Code potenziert.

"AI agents rely on the context provided by the codebase to generate relevant code. A poorly organized codebase can lead to 'context rot,' where the agent misses dependencies and produces suboptimal code."

— PropelCode: Structuring Codebases for AI Tools

Code-Beispiel: Team-Mitglied als Content Element  

Definieren Sie ein Content Element für Teammitglieder – eine YAML-Datei genügt:

# ContentBlocks/ContentElements/team-member/config.yaml
name: vendor/team-member
title: Team Member
description: Display a team member profile

fields:
  - identifier: full_name
    type: Text
    label: Full Name
    required: true
    
  - identifier: position
    type: Text
    label: Position / Role
    
  - identifier: email
    type: Email
    label: Email Address
    
  - identifier: biography
    type: Textarea
    label: Short Biography
    enableRichtext: true

Record Types: Eigene Datensätze definieren  

Die Content Blocks Extension beschränkt sich nicht auf Content Elements in tt_content. Mit Record Types erstellen Sie eigene Datenbanktabellen – ideal für News, Produkte, Events oder andere strukturierte Daten.

Content Elements vs. Record Types  

Extbase-kompatible Tabellenbenennung  

Wichtig: Für die nahtlose Integration mit Extbase-Repositories verwenden Sie die Namenskonvention tx_extensionkey_domain_model_*. Nur so funktionieren Model-Generatoren und Repositories korrekt.

# Extbase-kompatible Benennung
table: tx_mysitepackage_domain_model_news

Beispiel: News-Artikel als Record Type  

Ein vollständiges News-System in einer YAML-Datei:

# ContentBlocks/RecordTypes/news-article/config.yaml
name: myvendor/news-article
table: tx_mysitepackage_domain_model_news
labelField: title
languageAware: true
sortable: true
softDelete: true
trackCreationDate: true
trackUpdateDate: true
restriction:
  disabled: true
  startTime: true
  endTime: true
security:
  ignorePageTypeRestriction: true
fields:
  - identifier: title
    type: Text
    required: true
  - identifier: teaser
    type: Textarea
  - identifier: bodytext
    type: Textarea
    enableRichtext: true
  - identifier: image
    type: File
    allowed: common-image-types
    maxitems: 1
  - identifier: publish_date
    type: DateTime
  - identifier: author
    type: Text

Page Types: Eigene Seitentypen definieren  

Page Types erweitern die pages-Tabelle um eigene Seitentypen – ideal für Blog-Artikel, Landing Pages, News-Seiten oder andere Seitenarten mit speziellen Eigenschaften.

Wann Sie Page Types einsetzen  

Beispiel: Blog-Artikel als Page Type  

# ContentBlocks/PageTypes/blog-article/config.yaml
name: myvendor/blog-article
typeName: 1705234567   # Unix-Timestamp als eindeutige ID
group: default
fields:
  - identifier: author_name
    type: Text
    label: Autor:in
  - identifier: teaser_text
    type: Textarea
    label: Teaser
  - identifier: hero_image
    type: File
    allowed: common-image-types
    maxitems: 1
  - identifier: publish_date
    type: DateTime
    label: Veröffentlichungsdatum

Frontend-Template einbinden  

Page Types bieten kein automatisches Frontend-Rendering. Fügen Sie den ContentBlocksDataProcessor zu Ihrem TypoScript hinzu:

page.10 = FLUIDTEMPLATE
page.10 {
    dataProcessing {
        1 = content-blocks
    }
}

Danach stehen alle Felder im Template unter {data.author_name}, {data.hero_image} etc. zur Verfügung.

File Types: Erweiterte Datei-Metadaten  

File Types erweitern die sys_file_reference-Tabelle um eigene Felder – perfekt für Fotograf:in, Copyright-Hinweise oder zusätzliche Bildoptionen.

Verfügbare Dateitypen  

Beispiel: Erweiterte Bild-Metadaten  

# ContentBlocks/FileTypes/image-extended/config.yaml
name: myvendor/image-extended
typeName: image
prefixFields: false
fields:
  - identifier: image_overlay_palette
    type: Palette
    label: Erweiterte Bildoptionen
    fields:
      - identifier: alternative
        useExistingField: true
      - identifier: description
        useExistingField: true
      - type: Linebreak
      - identifier: photographer
        type: Text
        label: Fotograf:in
      - identifier: copyright
        type: Text
        label: Copyright-Hinweis
      - type: Linebreak
      - identifier: crop
        useExistingField: true

PHP 8.4: Property Hooks ersetzen Getter & Setter  

Ein erheblicher Teil klassischer Extbase-Models besteht aus repetitiven Getter- und Setter-Methoden. PHP 8.4 Property Hooks ändern das fundamental.

Der Paradigmenwechsel  

<?php
declare(strict_types=1);

namespace Vendor\TeamExtension\Domain\Model;

class TeamMember
{
    // Einfache Property ohne Logik – kein Hook nötig
    public string $position = '';
    
    // Property mit Transformations-Logik
    public string $fullName {
        get => strtoupper($this->fullName);
        set(string $value) => trim($value);
    }
    
    // Property mit Validierung
    public string $email {
        set(string $value) {
            if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
                throw new \InvalidArgumentException('Invalid email format');
            }
            $this->email = strtolower($value);
        }
    }
    
    // Virtuelle Property – keine Datenbank-Spalte
    public string $slug {
        get => str_replace(' ', '-', strtolower($this->fullName));
    }
}

Konkrete Vorteile von Property Hooks  

Was Property Hooks ermöglichen  

Die Synergie: Content Blocks + Property Hooks  

Die Kombination beider Technologien führt zu einer klaren Aufgabenteilung:

Das Ergebnis:

• YAML definiert die Datenstruktur (Single Point of Truth)
• PHP Models enthalten nur noch Geschäftslogik (Property Hooks)
• Kein Boilerplate mehr für TCA, SQL oder triviale Getter/Setter

Weitere CLI-Befehle im Überblick  

Content Blocks bietet neben make:content-block weitere nützliche Kommandos:

# Alle Content Blocks anzeigen
vendor/bin/typo3 content-blocks:list

# Sprachdateien generieren
vendor/bin/typo3 content-blocks:language:generate

# Assets publizieren
vendor/bin/typo3 content-blocks:assets:publish

Internationalisierung (i18n)  

Content Blocks vereinfacht die Mehrsprachigkeit erheblich. Labels und Übersetzungen verwalten Sie zentral in einer labels.xlf im Content Block-Ordner.

Ordnerstruktur  

ContentBlocks/ContentElements/hero-banner/
├── config.yaml
├── language/
│   ├── labels.xlf          # Standardsprache
│   └── de.labels.xlf       # Deutsche Übersetzung
└── templates/
    └── frontend.html

Labels in Templates verwenden  

<!-- Zugriff auf labels.xlf -->
<f:translate key="{cb:languagePath()}:my_label"/>

<!-- Label aus anderem Content Block -->
<f:translate key="{cb:languagePath(name: 'vendor/other-block')}:shared_label"/>

Record Types mehrsprachig machen  

Für Record Types aktivieren Sie languageAware in der config.yaml:

name: myvendor/news-article
table: tx_mysitepackage_domain_model_news
labelField: title
languageAware: true   # Aktiviert Übersetzungsfelder

Tooling und Ressourcen  

Fazit: Jetzt handeln, später profitieren  

Die Kombination aus TYPO3 Content Blocks und PHP 8.4 Property Hooks reduziert nicht nur den initialen Entwicklungsaufwand – sie macht Ihre Extensions deutlich wartbarer.