Ankündigungsleiste ohne Entwickler: mehrsprachige Hinweisbanner, die die Redaktion selbst steuert

Image Description
Christopher Zechendorf
24.08.2026
Share:

Ein Hinweisbanner über der Navigation, das die Redaktion selbst ein- und ausschaltet – pro Sprache und ohne Release. Und die drei Fallstricke darunter.

Hinweisbanner über der Navigation einer Website, redaktionell steuerbar

Ein Banner, das nach einer halben Stunde Arbeit aussieht

„Wir stehen Ende September auf einer Messe – kann oben auf der Website ein Hinweis dazu erscheinen?” Anfragen dieser Art klingen zunächst nach einem Streifen, einer Zeile Text und einer Farbe. Interessant werden sie erst durch den Teil des Satzes, der meistens ungesagt bleibt: Der Hinweis soll kurzfristig erscheinen, ebenso kurzfristig wieder verschwinden, zwischendurch anders formuliert werden – und all das, ohne dass jemand aus der Entwicklung eingreifen muss.

Genau das haben wir für Guuru umgesetzt: eine Ankündigungsleiste über der Navigation, die die Redaktion selbst ein- und ausschaltet, textlich und farblich anpasst und für jede Sprache getrennt pflegt. Die eigentliche Arbeit steckte dabei nicht in der Leiste. Sie steckte in drei Fallstricken darunter – und jeder einzelne davon hätte gereicht, damit die Funktion im entscheidenden Moment nicht tut, was sie soll.

Die Herausforderung

Gefordert war eine einzeilige Leiste ganz oben auf jeder Seite: Text, optionaler Link auf eine interne Seite oder eine externe Adresse, Schriftfarbe, Hintergrundfarbe, An/Aus-Schalter. Bedienbar von der Redaktion, jederzeit, ohne Release und ohne Rückfrage bei uns.

Dazu kamen zwei Randbedingungen, die den Zuschnitt bestimmt haben. Erstens ist die Website für neun Sprachen konfiguriert, von denen aktuell zwei live sind – die Lösung musste also von vornherein pro Sprache funktionieren, nicht „später auch mal”. Zweitens war der Termin gesetzt: Der Messeauftritt lag Wochen in der Zukunft, die Funktion musste deutlich vorher einsatzbereit und von der Redaktion erprobt sein.

Eine fertige Erweiterung aus dem TYPO3-Ökosystem haben wir bewusst nicht eingesetzt. Für fünf Eingabefelder und eine Zeile Markup handelt man sich sonst eine dauerhafte Abhängigkeit ein, die bei jedem Versionssprung mitgezogen werden will. Eine kleine, passgenaue Ergänzung im eigenen Site-Package bleibt update-sicher und macht das nächste TYPO3-Upgrade nicht komplizierter.

Unsere Lösung

1. Die Einstellungen dorthin legen, wo Mehrsprachigkeit schon funktioniert

Werte in einer Konfigurationsdatei scheiden aus: Eine Datei zu ändern bedeutet ein Deployment – genau das, was hier vermieden werden soll. Die Einstellungen mussten in die Datenbank.

Wir haben sie deshalb an den Seiten-Datensatz der Startseite gehängt. Seiten sind in TYPO3 von Haus aus übersetzbar, das heißt: Jede Sprachvariante bekommt ihre eigenen Werte über dieselbe Übersetzungsmaske, die die Redaktion ohnehin täglich benutzt. Kein Sonderweg, kein zusätzliches Modul, keine neue Bedienlogik.

Die fünf Felder liegen in einem eigenen Reiter, der nur an der Startseite auftaucht. Das ist keine Kosmetik: Ohne diese Einschränkung erscheinen die Felder in den Eigenschaften jeder einzelnen Seite und laden dazu ein, sie an der falschen Stelle zu pflegen. Beschriftungen und Erklärtexte gibt es auf Englisch und Deutsch, damit das Backend in beiden Sprachen verständlich bleibt.

2. Fallstrick Zwischenspeicher: Die Leiste ist an – und trotzdem nirgends zu sehen

TYPO3 hält für jede Seite eine fertig gerenderte Fassung im Zwischenspeicher. Wird die Startseite geändert, verwirft der Kern zunächst nur deren eigenen Eintrag. Alle anderen Seiten liefern weiterhin den alten Stand aus – also keine Leiste. Aus Sicht der Redaktion sieht das so aus: Schalter umgelegt, gespeichert, Website geöffnet, nichts passiert. Im ungünstigsten Fall wird der Schalter wieder ausgeschaltet und die Funktion als kaputt gemeldet.

Der übliche Weg wäre eine Regel im Seiten-TSconfig, die beim Speichern der Startseite den gesamten Seiten-Cache leert. Dieser Weg funktioniert an genau dieser Stelle nicht – und das ist der interessanteste Fund des ganzen Tickets: TYPO3 liest diese Regel beim Speichern nicht vom Datensatz selbst, sondern von dessen übergeordneter Seite. Die Startseite hat aber keine übergeordnete Seite. Eine auf sie zugeschnittene Regel greift damit prinzipiell nie. Wer das nicht weiß, sucht den Fehler stundenlang in der eigenen Konfiguration, obwohl die Konfiguration korrekt ist.

Wir haben es deshalb andersherum gelöst: Jede ausgelieferte Seite bekommt beim Rendern ein Cache-Etikett der Startseite mit. Speichert die Redaktion die Startseite, verwirft TYPO3 alle Seiten, die dieses Etikett tragen. Das Speichern einer Übersetzung löst dasselbe Etikett aus, weil der Kern Übersetzungen intern auf ihren Ursprungsdatensatz zurückführt. Nebenbei ist dieser Weg sparsamer als „alles leeren”: Betroffen sind nur die Seiten, die die Leiste tatsächlich lesen.

3. Fallstrick Sprachen: Ein bequemer Fallback am genau falschen Ort

Die Erwartung war klar formuliert: Eine Sprache ohne übersetzte Startseite zeigt keine Leiste. Die naheliegende Abfrage des Seiten-Datensatzes liefert in dieser Konfiguration aber nicht „nichts” zurück, sondern den Datensatz der Ausgangssprache. Für viele Felder ist dieses Verhalten gewollt und praktisch – ein fehlender Wert fällt eben auf die Hauptsprache zurück.

Für eine redaktionelle Ankündigung ist es das Gegenteil von praktisch. Auf einer französischen Seite stünde dann ein englischer Messehinweis: nie übersetzt, nie freigegeben, trotzdem sichtbar. Wir prüfen deshalb ausdrücklich, ob der gelesene Datensatz wirklich eine Übersetzung der aktuell angeforderten Sprache ist. Ist er es nicht, wird nichts ausgegeben – keine Leiste, kein leerer Farbstreifen, kein Fehler.

Bemerkenswert an diesem Punkt ist, wie er gefunden wurde: nicht im Test, sondern in der unabhängigen Codeprüfung vor der Freigabe. Die betroffenen Sprachen sind heute gar nicht erreichbar, der Effekt wäre also erst aufgetreten, wenn irgendwann in Zukunft die erste Seite in einer dieser Sprachen online geht – vermutlich Monate später, ohne erkennbaren Zusammenhang zu diesem Release.

4. Fallstrick Rechte: fertig gebaut und trotzdem unsichtbar

Neue Felder sind in TYPO3 standardmäßig gesperrt: Redaktionskonten ohne Administratorrechte sehen sie erst, wenn ein Administrator sie der Benutzergruppe freigibt. Dazu kommt der einmalige Abgleich der Datenbankstruktur, ohne den die neuen Felder schlicht nicht existieren.

Beides sind kleine Handgriffe – und beides sind Schritte, die man vergessen kann. Vergisst man sie, ist die Funktion entwickelt, geprüft, ausgeliefert und für genau die Person unsichtbar, die sie benutzen soll. Wir haben deshalb beide Punkte als ausdrückliche Release-Schritte festgehalten und ihre Erledigung bestätigt, bevor die Redaktion informiert wurde. Ein Feature gilt für uns nicht als fertig, wenn es im Code funktioniert, sondern wenn es im Konto des Kunden bedienbar ist.

5. Farben und Layout: die unterschätzten Kleinigkeiten

Zwei Details verdienen Aufmerksamkeit. Zum einen landen die beiden Farbwerte in einem Style-Attribut der Seite. Auch wenn der Farbwähler im Backend nur saubere Hexwerte erzeugt, prüfen wir jeden Wert gegen ein striktes Muster und fallen bei Abweichung auf die Standardfarben zurück; der Text selbst wird konsequent escaped. Ein Backend-Feld sollte nie ein Einfallstor sein – auch nicht für eigene Redakteure, die sich vertippen.

Zum anderen ist die Navigation fest am oberen Bildschirmrand verankert, der Seiteninhalt hält einen festen Abstand dazu. Eine Leiste, die einfach darüber gesetzt wird, verschwindet hinter der Navigation. Und ihre Höhe ist nicht konstant: neun Sprachen, frei formulierter Text, schmale Bildschirme – irgendwann bricht die Zeile um. Wir messen die tatsächliche Höhe im Browser und geben sie an Navigation, Inhaltsbereich, Mega-Menü und mobiles Overlay weiter. Solange die Leiste ausgeschaltet ist, gibt es weder zusätzliches Markup noch zusätzlich geladene Dateien.

Das Ergebnis

Die Redaktion schaltet die Leiste heute selbst ein und aus, formuliert den Text, setzt den Link und wählt die Farben – getrennt für Englisch und Deutsch, mit sofortiger Wirkung auf allen Seiten, ohne Entwicklerbeteiligung und ohne Release. Seiten, die bewusst ohne Navigation ausgeliefert werden, zeigen die Leiste nicht. Ist sie ausgeschaltet, verhält sich die Website exakt wie vorher.

Genauso wichtig wie die Funktion war der Zeitpunkt: Die Leiste stand Wochen vor der Messe bereit und konnte in Ruhe ausprobiert werden – statt am Tag davor unter Zeitdruck.

Fazit

Das Muster lässt sich weit über Messehinweise hinaus übertragen: Wartungsfenster, geänderte Öffnungszeiten, verlängerte Lieferfristen, Störungsmeldungen – überall dort, wo eine Information schneller draußen sein muss, als ein Deployment dauert.

Die Lehre aus diesem Ticket ist eine andere als erwartet. Selbstbedienung ist nicht das Eingabefeld im Backend. Sie ist die Summe dessen, was zwischen diesem Feld und der veröffentlichten Seite passieren muss: Der Zwischenspeicher muss die richtige Seite verwerfen, die Sprachlogik darf nichts durchreichen, was nie freigegeben wurde, und die Rechte müssen bei der Person liegen, die die Funktion benutzt. Wer nur das Feld baut, liefert eine Funktion, die genau dann versagt, wenn es darauf ankommt.

Möchten auch Sie Inhalte kurzfristig selbst steuern, ohne auf ein Deployment zu warten? Sprechen Sie uns an – wir schauen uns Ihre TYPO3-Installation an und bauen die Stellschrauben dorthin, wo Ihre Redaktion sie erreicht.

Interesse geweckt? Top-Stories direkt in Ihre Mailbox:

Share:

Über den Autor

Christopher Zechendorf

Christopher Zechendorf

Christopher Zechendorf leitet die ext.dev GmbH und bringt über 25 Jahre Erfahrung in Webentwicklung, CMS-Systemen und Infrastruktur mit.