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:

Was Sie sich konkret ersparen 

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

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

Content Blocks installieren 

Die Installation erfolgt 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, entstehen 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, wird die Struktur einer Codebase zum entscheidenden Erfolgsfaktor. 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 eignet sich nicht nur für 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

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) => $this->fullName = 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 leben 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 grundlegend wartbarer.