CP Registry
Vision / Demo

TYPO3-Bridge

Wie der Maintenance-Mode der Werkstatt aussehen soll: bestehende TYPO3-Seiten laden, in der Werkstatt ändern, zurueckschreiben. Diese Seite zeigt die Idee mit Mock-Daten — die echte Bridge braucht eine TYPO3-API.

1

Liste aller TYPO3-Seiten

Die Werkstatt fragt eine TYPO3-API: GET /api/cms/pages — bekommt alle pflegbaren Seiten mit Titel, ID, Kategorie. Im Maintenance-Mode-Dialog der Werkstatt waehlst du eine.

Tarifseite Oekostrom/tarife/oekostrom · 7 CEs · zuletzt: 14.04.2026
Energieberatung/service/beratung · 9 CEs · zuletzt: 02.04.2026
Aktuelles aus der Region/aktuelles · 12 CEs · zuletzt: 22.04.2026
Kontakt & Hotline/kontakt · 4 CEs · zuletzt: 28.03.2026
2

TYPO3-CEs in Werkstatt-Blöcke übersetzen

Die TYPO3-API gibt pro Seite eine Liste von Content-Elementen zurück. Ein Mapping-Layer wandelt sie in Werkstatt-Block-Nodes um — basierend auf dem CType-Feld:

// CE-Typ → Werkstatt-Block-Typ Mapping
const CTYPE_TO_BLOCK = {
  'cp_hero': 'hero',
  'cp_cards': 'cards',
  'cp_teaser': 'teaser',
  'cp_quote': 'quote',
  'cp_faq': 'faq',
  'cp_text': 'text',
  'cp_alert': 'alert',
  // …
};

// Felder lesen aus tt_content / Custom-Tabellen
function ceToBlock(ce) {
  return {
    id: 'tt_content_' + ce.uid,
    type: CTYPE_TO_BLOCK[ce.CType],
    controls: { spacing: ce.tx_cp_spacing, width: ce.tx_cp_width },
    content: extractContent(ce),
  };
}
3

In der Werkstatt ändern

Editor sieht den aktuellen Stand der TYPO3-Seite als Werkstatt-Konfig. Ändert Texte, verschiebt Blöcke, prüft Mobile. Status-Anzeige im Toolbar: "Verbunden mit TYPO3-Seite #42".

4

Zurück nach TYPO3 schreiben

Klick auf "Änderungen veröffentlichen" → die Werkstatt-Konfig wird zurück-gemappt zu CE-Datensätzen. Die TYPO3-API erhält: hinzufügen, ändern, löschen, neu sortieren. Pro CE ein Datenbank-Update.

POST /api/cms/pages/42/sync
{
  "blocks": [
    { "type": "hero", "tt_content_uid": 1234, "content": {...} },
    { "type": "cards", "tt_content_uid": 1235, "content": {...} },
    { "type": "quote", "tt_content_uid": null, "content": {...} }, // neu
  ],
  "removed": [1240]  // Quelle gibt mit, welche CEs zu löschen sind
}
5

TYPO3-seitig: Endpoint + Mapper

Damit die Bridge läuft, braucht TYPO3 zwei Bausteine — beides ist überschaubar (~1-2 Tage Backend-Arbeit):

  • REST-API-Extension — z.B. typo3/cms-extbase mit Routen /api/cms/pages, /api/cms/pages/{id} (GET/POST/PUT). JWT-Auth für Editor-Login.
  • CType-zu-Werkstatt-Mapper — pro Custom-Content-Element ein Mapping-Layer in PHP. Für Standard-CEs (Text, Bild) gibt es Default-Mapper.
  • Optional: Webhook — wenn TYPO3-Seite extern geändert wurde, soll die Werkstatt das wissen ("Seite wurde inzwischen veraendert — neu laden?").

Was müsste passieren, damit das produktiv geht?

  • TYPO3-Extension entwickeln — REST-API-Endpoints + JWT-Auth. (~2 Tage)
  • CType-Mapping pflegen — pro Custom-CE ein PHP-Mapper. Initial für ~10 CEs. (~1 Tag pro 10 CEs)
  • Werkstatt-Maintenance-UI — Dialog mit Seiten-Liste, Status "verbunden mit", Sync-Button. (~1 Tag)
  • Konflikt-Behandlung — wenn jemand parallel im TYPO3-Backend ändert (Last-modified-Header prüfen, Konflikt-Dialog). (~1 Tag)
  • Berechtigungen — nicht jeder darf alles. TYPO3-Berechtigungs-Modell durchreichen. (~1 Tag)

Vorsicht — Risiken

  • Datenverlust bei fehlgeschlagenem Mapping: wenn ein TYPO3-Custom-CE keinen Mapper hat, darf die Werkstatt den NICHT löschen. Pflicht: Whitelist-Modus, alles unbekannte bleibt unangetastet.
  • Versionierung kollidiert: Werkstatt-Snapshots vs. TYPO3-Versions-Historie. Idee: TYPO3-Workspaces nutzen, dort Werkstatt-Änderungen ablegen, Editor publisht aus dem Workspace.
  • Berechtigungen: Nur Editoren mit den richtigen Rechten dürfen die Bridge nutzen. Token nicht in den Browser local-storage — Cookies + Server-Session.