Beispiel
Hero korrekt gemappt
Du siehst in der Werkstatt einen Hero-Block. In TYPO3 wählt du "cp_hero" und befüllst Tag, Headline, Subline, Bild und CTA. Die Vorschau stimmt mit der Werkstatt überein.
Von der Werkstatt nach TYPO3
Was du in der Werkstatt geübt hast, sieht im TYPO3-Backend etwas anders aus — funktioniert aber gleich. Der Mapping-Guide für alle, die taeglich Inhalte pflegen.
- Verstehe, welcher Werkstatt-Block welchem TYPO3-CE entspricht
- Wisse, welche Felder im TYPO3-Backend was bewirken
- Vermeide die häufigsten Pflege-Anti-Patterns
Block ↔ Content-Element-Mapping
Problem: Wer in TYPO3 das falsche Content-Element wählt, befüllt Felder, die der gewünschte Block gar nicht liest — der Inhalt erscheint nicht oder verursacht Darstellungsfehler.
Lösung: Schlage in der Tabelle nach, welches CE zum Werkstatt-Block gehört. Stimmt der Name nicht genau: mit dem Backend-Team klären, ob es ein Alias gibt.
Jeder Werkstatt-Block hat ein TYPO3-Pendant. Der Backend-Editor in TYPO3 zeigt einen aehnlichen Wizard — andere UI, gleiche Felder.
| Werkstatt-Block | TYPO3-CE | Wichtigste Felder |
|---|---|---|
| Hero | cp_hero | Tag, Headline, Subline, Bild, CTA1+2 (Label + Link) |
| Karten-Grid | cp_cards | Spalten (Auswahl), Liste von Cards (Reihenfolge im Backend) |
| Card | (in Karten-Grid) | Titel, Beschreibung, Tag, Bild, Link |
| Teaser | cp_teaser | Layout (image-left/top/right), Tag, Titel, Text, Link, Bild |
| News-Grid | cp_news | Anzahl Einträge, Filter (Kategorie), Spalten |
| Quote | cp_quote | Zitat-Text, Autor, Rolle, Foto (optional) |
| FAQ (Accordion) | cp_faq | Frage + Antwort (Liste), Erstes-offen-Toggle |
| Tabs | cp_tabs | Tab-Liste mit Label + Inhalt |
| Bild + Text | cp_image_text | Layout, Bild, Text, Headline |
| Tabelle | cp_table | Spalten-Definition, Zeilen, Highlight-Zeile |
| Downloads | cp_downloads | Datei-Liste, Beschreibung pro Eintrag |
| Alert / Hinweis | cp_alert | Variant (info/warning/success/error), Titel, Body |
| CTA-Buttons | cp_cta_buttons | 1-2 Buttons (Label + Link) |
| CTA-Banner | cp_cta_banner | Tag, Headline, Subline, Button (Label + Link) |
| Text-Inhalt | cp_text oder Standard "Text" | Heading-Ebene (Auswahl H1-H6 oder ohne), Body |
| Navigation | (systemweit, nicht im CE) | Wird über Seitenstruktur gesteuert |
| Footer | (systemweit) | Spalten + Copyright im Globalen-Footer |
Keine Treffer.
Gegenbeispiel
Falsches CE gewählt
Du wählt "Text" statt "cp_hero". Das Bild-Feld fehlt, Headline erscheint als Fließtext. Vorschau sieht nichts wie die Werkstatt aus — und das Feld "Bild" ist nicht auffindbar.
Wann nicht anwenden: Navigation und Footer sind systemweit konfiguriert — die tauchen nicht in dieser Mapping-Tabelle auf und werden nicht per CE gepflegt. Änderungen dort gehen über Renana an das Backend-Team.
Abstand & Breite — was im Backend was bedeutet
Problem: Wer Abstand und Breite nach Auge setzt, ohne die Stufen zu kennen, produziert inkonsistente Seiten — und bemuehrt das Frontend-Team mit Korrekturen, die eigentlich im Backend lösbar waren.
Lösung: Die sechs Abstands-Stufen und fünf Breiten-Stufen kennen. Faustregel: md für Abstand, standard für Fließtext.
Im TYPO3 Backend gibt es zwei Auswahl-Felder pro Block: "Abstand oben" und "Breite". Hier die Werte:
"Abstand oben"
kein— Block schließt direkt am vorherigen ansehr eng (xs)— minimaler Trennereng (sm)— verwandte Inhalte, eng gefasstnormal (md)— Standard zwischen Blöckenweit (lg)— Section-Wechselsehr weit (xl)— vor wichtigen Highlight-Blöcken
Faustregel: md ist Standard. Verwende weit, wenn ein neues Thema beginnt.
"Breite"
standard (55rem)— Fließtext, optimale Lesebreitebreit (69rem)— Karten-Grids, Formularesehr breit (83rem)— Navigation, Galerienvoll (100%)— Hero-Bilder, Banner mit Hintergrundschmal (40rem)— fokussierter Text, Zitate
Faustregel: Lese-Inhalt → standard, Karten/Tabellen → breit, Hero/Banner → voll.
Beispiel
Blog-Artikel korrekt
Artikel-Page: Intro-Text in "standard", Karten-Grid darunter in "breit", abschliessender Hero-Banner in "voll". Jeder Block bekommt seine optimale Breite.
Gegenbeispiel
Alles auf "voll" gesetzt
Redakteur wählt für alle Blöcke "voll" — weil es "größer wirkt". Artikel-Absätze laufen über 120 Zeichen, werden auf Desktop kaum noch gelesen. Frontend-Ticket folgt.
Wann nicht anwenden: Wenn ein Block keines der sechs Abstandsfelder anbietet (z.B. systemweite Footer- oder Header-Blöcke) — das sind Backend-Konfigurationen, keine Redakteurs-Entscheidungen.
Anti-Patterns — typische Pflege-Fehler
Problem: Kleinere Entscheidungen im TYPO3-Backend — Breite, Heading-Ebene, Linktext, Alt-Text — summieren sich zu strukturellen Fehlern, die später Barrierefreiheits-Audits oder SEO-Prüfungen nicht bestehen.
Lösung: Diese sechs Anti-Patterns kennen und im Pflege-Alltag vermeiden. Bei Unsicherheit: erst mit Frontend abstimmen, nicht ausprobieren.
Volle Breite für Fließtext
Wenn ein Absatz über den ganzen Bildschirm läuft, ist er auf Desktops kaum noch lesbar (mehr als 90 Zeichen pro Zeile). Fix: Breite "standard" oder "schmal" wählen.
Mehrere H1 pro Seite
Manche Editoren setzen das "Headline-Feld" auf H1, weil es "wichtig" aussieht. Eine Seite hat genau eine H1 — das ist der Seitentitel. Subtitel sind H2.
"Hier klicken" als Button-Text
Funktioniert weder für Suchmaschinen noch Screenreader. Fix: Sag, was passiert: "Tarif berechnen", "PDF herunterladen".
Karten unterschiedlich lang
Eine Card mit 5 Worten neben einer mit 50 — wirkt unruhig. Fix: Aehnliche Längen anstreben (8–15 Worte). Wenn ein Thema mehr Platz braucht, gehört es nicht in eine Card.
Bilder ohne Alt-Text
Im TYPO3 gibt es ein "Alternativtext"-Feld — wird oft leer gelassen. Das verstößt gegen die Barrierefreiheits-Anforderungen. Fix: Beschreiben, was zu sehen ist (kein "Bild1.jpg").
Spacing nach Auge
Mit Margin-Klassen herumspielen, bis es "irgendwie passt". Fix: Die 6 Spacing-Stufen sind genug. Wenn eine fehlt, mit Frontend reden — keine Custom-CSS-Werte.
Wann nicht anwenden: Bei rein technischen Systembloecken (Navigation, Footer) gelten diese Regeln nicht — die haben keine frei befuellbaren Pflege-Felder. Dort ist das Backend-Team zuständig, nicht der Redakteur.
Workflow — von Werkstatt zu TYPO3
Problem: Wer direkt im TYPO3-Backend herumprobiert, ohne ein abgestimmtes Konzept, produziert Inhalte, die mit der Werkstatt-Vorlage nicht übereinstimmen — und zieht Korrekturrunden nach sich.
Lösung: Erst in der Werkstatt abstimmen, dann strukturiert übertragen. Die vier Schritte in dieser Reihenfolge.
- Schritt 1
Werkstatt: Konzept entwickeln
Blöcke kombinieren, Inhalte einkippen, Mobile prüfen, mit Kollegen abstimmen. Konfig speichern, Link teilen. - Schritt 2
TYPO3-Backend: Inhalte übernehmen
Pro Werkstatt-Block ein Content-Element in TYPO3 anlegen. Reihenfolge gleich. Felder gemäß Tabelle oben befüllen — mit den geuebten Texten. - Schritt 3
TYPO3 Live-Preview prüfen
TYPO3 hat eine eigene Vorschau. Prüfe: Sieht's aus wie in der Werkstatt? Falls nein: Felder kontrollieren (Spacing, Breite, Bilder). - Schritt 4
Veroeffentlichen
Wenn alle Felder gefüllt sind und die Preview stimmt: "Speichern und Schliessen" mit Sichtbarkeitsstatus auf "veröffentlicht".
Beispiel
Werkstatt-Link geteilt, dann übertragen
PM schickt Werkstatt-Link nach Freigabe. Redakteur öffnet TYPO3, legt CEs in gleicher Reihenfolge an, befüllt Felder. Preview stimmt beim ersten Vergleich — keine Rueckfrage.
Gegenbeispiel
Direkt im TYPO3 ausprobiert
Redakteur legt CEs an, bevor die Werkstatt-Version freigegeben ist. Drei Tage später ändert sich das Konzept. Alle CEs müssen neu angelegt werden.
Wann nicht anwenden: Bei kleinen Content-Updates (Wortlaut ändern, Bild tauschen) in bestehenden Seiten entfällt Schritt 1. Du arbeitest direkt in TYPO3 — aber nur in bereits freigegebenen Blöcken.
Hier übst du das
Drei Sätze für den Pflege-Alltag
- 1Erst Werkstatt, dann TYPO3. Konzept in der Werkstatt fertigstellen — abstimmen — übertragen. Nicht direkt im TYPO3 herumprobieren.
- 2Felder lesen, Werte kennen. "Breite: standard" heißt optimale Lesebreite. Wenn unsicher: Layout & Lesbarkeit-Schulungsseite konsultieren.
- 3Feld fehlt oder etwas sieht falsch aus: mit Frontend reden. Lieber kurz fragen, als ein eigenes Custom-CSS-Feld zu nutzen. Das System ist gewollt restriktiv.