Ein neuer TYPO3 Content Block beginnt selten mit dem Schreiben einer YAML-Datei. In der Praxis kommen Anforderungen aus Tickets, Slack-Nachrichten, Formularen oder Abstimmungen mit Kundinnen und Kunden. Genau hier kann n8n seine Stärke ausspielen: als Workflow-Automation-Plattform, die Systeme verbindet und wiederkehrende Abläufe orchestriert.
Wichtig ist die Abgrenzung: n8n ersetzt nicht die TYPO3-Entwicklung. Der Content Block selbst wird in TYPO3 beziehungsweise in einer TYPO3-Extension definiert. n8n kann jedoch den Weg von der Anforderung bis zum geprüften Deployment strukturieren und automatisieren.
In diesem Artikel zeigen wir dir eine belastbare Architektur für die Kombination aus TYPO3 Content Blocks und n8n – inklusive Beispiel, CLI-Befehl, Qualitätskontrollen und wichtigen Sicherheitsaspekten.
Was ist ein TYPO3 Content Block?
Ein Content Block ist ein eigenständiger, wiederverwendbarer Content Type für TYPO3. Bei einem Content Element definierst du beispielsweise Felder, Backend-Beschriftungen und Fluid-Templates für ein neues Inhaltselement.
Die offizielle Dokumentation beschreibt config.yaml als zentrale Datei eines Content Blocks. Dort werden unter anderem der Name und die verfügbaren Felder festgelegt. Die zugehörigen Ressourcen liegen typischerweise in den Bereichen assets, templates und language. Weitere Details findest du in der TYPO3-Dokumentation zur Definition von Content Blocks.
Für ein einfaches Content Element kann die Struktur zum Beispiel so aussehen:
my_extension/
└── ContentBlocks/
└── ContentElements/
└── cta/
├── config.yaml
├── templates/
│ ├── frontend.html
│ └── backend-preview.html
├── language/
│ └── labels.xlf
└── assets/
└── icon.svg
Welche Rolle übernimmt n8n?
n8n verbindet Anwendungen über Workflows und APIs. Die Plattform kann Daten aus verschiedenen Quellen verarbeiten, Bedingungen auswerten und anschließend Aktionen auslösen. Für den TYPO3-Kontext ist n8n deshalb vor allem als Orchestrierungsschicht interessant.
Ein sinnvoller Workflow kann zum Beispiel folgende Schritte abbilden:
- Eine Anforderung für einen neuen Content Block geht über ein Formular, ein Ticketsystem oder einen Webhook ein.
- n8n prüft Pflichtangaben wie Blockname, Felder, Ziel-Extension und gewünschte Sprache.
- Die Anforderungen werden in ein definiertes Datenformat überführt.
- Ein Entwicklungs- oder Deployment-System erzeugt daraus das Grundgerüst.
- TYPO3 führt Prüfungen wie Cache-Leerung, Extension-Setup oder Content-Block-Linting aus.
- Ein Pull Request oder ein Freigabeprozess wird erstellt.
n8n sollte dabei nicht unkontrolliert direkt auf die Produktivinstallation schreiben. Besser ist ein nachvollziehbarer Prozess über Versionsverwaltung, Review und Deployment. Für die Verbindung zu nicht nativ unterstützten Diensten sieht die n8n-Dokumentation den HTTP Request Node und API-basierte Integrationen als zentralen Ansatz vor.
Content Block in TYPO3 vorbereiten
1. Anforderungen eindeutig beschreiben
Bevor n8n einen Workflow startet, sollte die Anforderung strukturiert sein. Für einen Call-to-Action-Block könnten die Daten beispielsweise so aussehen:
{
"vendor": "acme",
"name": "cta",
"title": "Call to Action",
"extension": "site_package",
"fields": [
{
"identifier": "headline",
"type": "Text"
},
{
"identifier": "text",
"type": "Textarea"
}
]
}
Diese Struktur ist kein allgemeines TYPO3-Format für jede denkbare Umsetzung. Sie dient als internes Übergabeformat zwischen n8n und deinem Entwicklungsprozess. Entscheidend ist, dass Namen, Feldtypen und Ziel-Extension vor der Code-Generierung validiert werden.
2. Grundgerüst mit dem TYPO3-CLI erzeugen
Die Content-Blocks-Dokumentation stellt einen CLI-Befehl zum Erzeugen eines Grundgerüsts bereit. Ein Beispiel für ein Content Element lautet:
vendor/bin/typo3 make:content-block \
--content-type="content-element" \
--vendor="acme" \
--name="cta" \
--title="Call to Action" \
--extension="site_package"
Der Befehl erzeugt ein minimales Grundgerüst. Die verfügbaren Optionen und die alternative Schreibweise content-blocks:create sind in der offiziellen Dokumentation zum Content-Blocks-Kickstart beschrieben.
n8n kann diesen Schritt auslösen, sollte den Befehl aber nicht mit unkontrollierten Benutzereingaben zusammensetzen. Werte wie Vendor, Name und Extension gehören in eine Whitelist oder müssen vorab gegen ein festes Schema geprüft werden.
Ein n8n-Workflow für die Content-Block-Erstellung
Webhook oder Formular als Startpunkt
Der Workflow kann mit einem Webhook beginnen. Ein internes Formular übergibt beispielsweise die Anforderungen für den neuen Block an n8n. Alternativ kann ein bestehendes Ticketsystem oder ein Projektmanagement-Tool als Auslöser dienen.
Im nächsten Schritt sollte ein Validierungs-Node prüfen, ob alle erforderlichen Werte vorhanden sind. Dazu gehören mindestens:
- ein eindeutiger technischer Name,
- ein gültiger Vendor- beziehungsweise Namensraum,
- eine bekannte TYPO3-Extension,
- zulässige Feldtypen,
- eine verantwortliche Person für die Freigabe.
Daten normalisieren und Regeln anwenden
Ein Function- oder Code-Node kann die Eingaben normalisieren. Leerzeichen werden entfernt, technische Namen vereinheitlicht und nicht erlaubte Zeichen abgewiesen. Außerdem kann der Workflow unterscheiden, ob ein Content Element, ein Page Type oder ein Record Type angelegt werden soll.
Diese Unterscheidung ist relevant, weil TYPO3 Content Blocks verschiedene Content Types unterstützen. Die YAML-Referenz der TYPO3 Content Blocks beschreibt dafür unterschiedliche Konfigurationsmöglichkeiten.
Repository oder Deployment-System aufrufen
Statt den Produktionsserver direkt zu verändern, kann n8n einen kontrollierten technischen Prozess anstoßen. Denkbar sind zum Beispiel:
- das Anlegen eines Branches in einem Git-Repository,
- das Erzeugen eines Pull Requests,
- das Starten einer CI/CD-Pipeline,
- das Aufrufen eines abgesicherten internen Build-Services,
- oder – in einer kontrollierten Entwicklungsumgebung – die Ausführung des TYPO3-CLI-Befehls.
Welche Variante geeignet ist, hängt von eurer Infrastruktur, den Zugriffsrechten und dem gewünschten Freigabeprozess ab. Für Agenturen und Whitelabel-Partner ist ein Repository-basierter Ablauf meist besonders gut nachvollziehbar, weil Änderungen versioniert und gemeinsam geprüft werden können.
Beispiel für die technische Übergabe
Ein n8n-Workflow kann aus den validierten Eingangsdaten einen Auftrag für einen internen Build-Service erzeugen. Die Übergabe könnte beispielsweise so aussehen:
POST /internal/typo3/content-blocks
Content-Type: application/json
{
"vendor": "acme",
"name": "cta",
"title": "Call to Action",
"extension": "site_package",
"repository": "customer-website",
"branch": "feature/content-block-acme-cta"
}
Der Service würde anschließend den Auftrag prüfen, das Grundgerüst erzeugen und das Ergebnis als Branch oder Artefakt bereitstellen. Die konkrete API ist projektspezifisch und muss selbst entwickelt beziehungsweise durch eure CI/CD-Plattform bereitgestellt werden. Sie gehört nicht automatisch zum TYPO3-Core oder zur n8n-Standardintegration.
Diese Trennung hat einen wichtigen Vorteil: n8n bleibt für die Prozesslogik zuständig, während die TYPO3-Umgebung nur über klar definierte und abgesicherte Schnittstellen angesprochen wird.
Nach der Generierung: TYPO3 prüfen und einrichten
Ein erzeugter Content Block ist noch nicht automatisch produktionsbereit. Je nach Definition können zusätzliche Datenbankfelder oder Tabellen erforderlich sein. Die TYPO3-Dokumentation weist deshalb darauf hin, nach Änderungen die Caches zu leeren und das Extension-Setup beziehungsweise den Datenbankvergleich auszuführen.
Ein möglicher Prüfablauf sieht so aus:
vendor/bin/typo3 cache:flush -g system
vendor/bin/typo3 extension:setup --extension=site_package
vendor/bin/typo3 content-blocks:lint
Der Lint-Befehl gehört zu den dokumentierten Content-Blocks-Kommandos und kann Konfigurationen gegen das vorgesehene Schema prüfen. Die verfügbaren Befehle findest du in der TYPO3-Übersicht der Console Commands.
Zusätzlich solltest du den Frontend-Output, die Backend-Vorschau, Sprachlabels, Berechtigungen und – falls relevant – die Darstellung in Workspaces testen. Ein automatisierter Workflow kann diese Prüfungen anstoßen, aber nicht vollständig fachlich ersetzen.
Sicherheit und Governance bei n8n und TYPO3
Ein Workflow, der Quellcode erzeugt oder TYPO3-Kommandos ausführt, benötigt besondere Schutzmaßnahmen. Achte mindestens auf folgende Punkte:
- Minimale Rechte: Verwende getrennte technische Konten und erteile nur die notwendigen Berechtigungen.
- Keine freien Shell-Befehle: Übergib keine ungeprüften Eingaben direkt an eine Shell.
- Allowlisting: Begrenze erlaubte Extensions, Feldtypen und Namenskonventionen.
- Review vor Deployment: Produktionsänderungen sollten über einen nachvollziehbaren Freigabeprozess laufen.
- Secrets schützen: API-Schlüssel, SSH-Zugangsdaten und Repository-Tokens gehören in die Credential-Verwaltung und nicht in Workflow-Text oder Code.
- Protokollierung: Speichere Auftrag, Ergebnis und Freigabestatus so, dass Änderungen später nachvollzogen werden können.
Gerade bei Kundenprojekten und Whitelabel-Setups ist außerdem wichtig, Mandanten, Umgebungen und Repositories sauber voneinander zu trennen.
Wann lohnt sich die Automatisierung?
n8n lohnt sich besonders dann, wenn Content Blocks regelmäßig nach einem ähnlichen Muster entstehen oder viele Beteiligte in den Prozess eingebunden sind. Beispiele sind standardisierte Landingpage-Module, Kampagnenbausteine, Produktteaser oder wiederkehrende Komponenten für mehrere Kundenprojekte.
Bei einem einzelnen, stark individuellen Block ist eine manuelle Entwicklung oft schneller. Der größte Nutzen entsteht, wenn n8n nicht nur Dateien erzeugt, sondern den gesamten Ablauf verbessert: von der strukturierten Anforderung über technische Prüfungen bis zur dokumentierten Freigabe.
Fazit: TYPO3 entwickelt die Struktur, n8n automatisiert den Prozess
Ein TYPO3 Content Block ist eine technische Komponente aus Konfiguration, Templates, Sprachdateien und gegebenenfalls Assets. n8n ist die passende Ergänzung, wenn du die Abläufe rund um diese Komponente automatisieren möchtest.
Die robuste Lösung besteht deshalb nicht darin, n8n direkt auf die Produktivdatenbank loszulassen. Besser ist eine kontrollierte Kette aus strukturierten Anforderungen, Validierung, Content-Block-Generierung, Versionsverwaltung, automatisierten Prüfungen und menschlicher Freigabe.
So entsteht ein skalierbarer Workflow, der für interne TYPO3-Teams ebenso geeignet ist wie für Agenturen, technische Partner und Whitelabel-Projekte.
Du möchtest TYPO3 Content Blocks standardisieren oder n8n in eure Entwicklungsprozesse integrieren? Wir unterstützen dich bei Architektur, Umsetzung und sicherem Deployment.
