content-distribution-source — TYPO3 pusht TYPO3, signiert, replay-sicher.

Warum ein eigenes Paket

moselwal/semantic-delivery verteilt Content an externe Kanäle — LinkedIn, Buffer, n8n, generische Webhooks. Es weiß nichts über:

• mehrere TYPO3-Instanzen als Peers
• Workspace-Publish-Trigger
• TYPO3-native Record-Snapshots (pages plus tt_content plus FAL)
• per-Sprache-lokale Edits auf der Receiver-Seite

content-distribution-source füllt genau diese Lücke. Es reused den SSRF-sicheren URL-Validator, die Ed25519-Key-Infrastruktur aus moselwal/content-provenance und die Rate-Limit- und Nonce-Patterns aus moselwal/webmcp.

Voraussetzungen

• TYPO3 14.x
• Composer-Paket moselwal/content-distribution-source
• Optional: moselwal/content-provenance für Vault-basierte Key-Provider, moselwal/structured-content für Relations und Annotationen

Transport, Authentifizierung und Scope

Transport — hybrid push plus pull

1. Push-Ping: Auf Workspace-zu-Live-Publish sendet die Source einen kleinen signierten Webhook an jeden abonnierten Target und kommuniziert, was sich geändert hat.
2. Pull-Fetch: Das Target authentifiziert sich zurück zum Source-Pull-Endpoint und lädt den vollständigen DAG-Snapshot.
3. Ack: Das Target bestätigt; die Source markiert den Outbox-Eintrag als acked.

Snapshots referenzieren alle Records per origin_uuid (UUIDv7) — nie per TYPO3-UID. Das lässt den Receiver Foreign-Keys gegen seinen eigenen ID-Space auflösen, ohne dass die UIDs zwischen den Instanzen kollidieren.

Workspace-Integration

Distribution wird nur getriggert, wenn ein Record im TYPO3-Workspace zu live gestaged wird. Drafts lecken nie. Der Trigger ist ein TYPO3-14-Event-Listener mit DataHandler-Hook als Fallback.

Authentifizierung

• Bearer-Token pro Target (preshared, verschlüsselt gespeichert)
• Ed25519-Signatur über Canonical-JSON (RFC 8785) des Payload-Headers. Keys werden vom KeyProviderInterface aus moselwal/content-provenance verwaltet — file-based oder Vault-backed, rotierbar.
• Replay-Protection über Nonce plus Timestamp; Receiver cachen Nonces für 600 s und lehnen Drift > ±300 s ab.

Scope — was out of the box distributiert wird

• pages mit allen tt_content-Kindern
• sys_file_reference plus sys_file (Binär-Inhalt per signierter URL nachgeladen, nie inline)
• sys_file_metadata, sys_category
• Custom-Tabellen — pro Site über settings.yaml registriert
• Optional: structured-content-Relations und -Annotationen

Installation, Quickstart und Commands

Installation

composer require moselwal/content-distribution-source
vendor/bin/typo3 extension:setup

Schema-Migrationen ergänzen origin_uuid-Spalten an pages, tt_content, sys_file* sowie die Package-Tabellen tx_cdsource_target und tx_cdsource_outbox.

Quickstart

# Ein Target registrieren
vendor/bin/typo3 cdsource:targets:add \
  --label="Production EN" \
  --base-url="https://en.example.com" \
  --subscribed-tables="pages,tt_content,sys_file_reference" \
  --subscribed-languages="0,1"

# Outbox abarbeiten (per cron oder scheduler)
vendor/bin/typo3 cdsource:outbox:process

CLI-Commands

Backend-Module

• Targets — CRUD für Target-Sites
• Outbox — Queue-Monitor, Replay-Button, Payload-Diff-Viewer

Architektur (DDD 4-Layer)

Strict DDD 4-Layer-Architektur, enforced via deptrac:

Lizenz GPL-2.0-or-later (siehe Repo). Codebase-Begleitdokumentation: CLAUDE.md im Paket.

Setzen wir ein bei …

Dieses Paket trägt die Multi-Site- und Multi-Region-Syndizierung in TYPO3 Kubernetes und ist Bestandteil souveräner Plattformen, die unter Open Source & Digitale Souveränität beschrieben sind. In der betreuten Variante: AI-Ready CMS as a Service.