Ein TYPO3-Upgrade gilt gemeinhin als geschafft, wenn das Frontend wieder sauber ausgeliefert wird und die Tests grün sind. Der unangenehmste Teil kommt aber manchmal erst danach – im Backend, im ganz normalen Redaktionsalltag. In zwei von uns betreuten TYPO3-Installationen zeigte sich nach dem Sprung von Version 12 auf 13 dasselbe Bild: Ein Klick auf „Neuer Datensatz” öffnete kein Eingabeformular mehr, sondern einen Ladespinner, der sich endlos weiterdrehte. Keine Fehlermeldung, kein Hinweis, kein Abbruch – nur eine Seite, die nie fertig wird.
Betroffen waren die TYPO3-Website von Profenster sowie eine weitere von uns betreute Installation. Die Ursache war am Ende eine einzige Feldkonfiguration, die noch aus deutlich älteren TYPO3-Zeiten stammte. Dieser Artikel zeigt, warum ein einzelnes Altlast-Feld ein komplettes Formular lahmlegen kann, warum genau dieser Fehler so schwer zu finden ist – und warum das Aufräumen solcher Altlasten in jede Upgrade-Vorbereitung gehört.
Das Fehlerbild war denkbar unkomfortabel für die Fehlersuche, denn es fehlte schlicht jeder Anhaltspunkt:
Genau diese Kombination macht solche Regressionen teuer: Man sucht zwangsläufig zuerst dort, wo man Fehler gewohnt ist – in den Logfiles, in der Datenbank, in den eigenen PHP-Klassen. Und findet dort nichts, weil der Fehler gar nicht auf dem Server passiert.
Wenn der Server einen fehlerfreien HTTP-200 liefert und trotzdem nichts erscheint, ist die Arbeit im Browser noch nicht abgeschlossen. Das TYPO3-Backend baut seine Eingabeformulare zu einem grossen Teil clientseitig auf: Die sogenannte FormEngine initialisiert nach dem Laden jedes einzelne Feld – Validierungsregeln, Datumsauswahl, Abhängigkeiten zwischen Feldern.
Der Blick in die Entwicklerkonsole des Browsers lieferte deshalb in Sekunden, was Stunden im Serverlog nicht hergegeben hätten: einen abgebrochenen JavaScript-Fehler aus der Datums-Bibliothek, mit der TYPO3 13 arbeitet. Der Spinner drehte sich nicht, weil etwas dauerte – er drehte sich, weil der Code, der ihn hätte ausblenden sollen, nie erreicht wurde.
Dahinter steckt eine Änderung, die mit dem Upgrade auf TYPO3 13 kam. Die clientseitige Formularvalidierung schickt jedes Feld, das in der Feldkonfiguration (dem TCA) als eval => 'datetime' markiert ist, durch die Datums-Bibliothek Luxon und deren Funktion DateTime.fromISO(). Erwartet wird also ein Datum im ISO-8601-Format.
In über Jahre gewachsenen Erweiterungen sind diese Felder aber häufig ganz anders angelegt: als reine Ganzzahl-Spalten mit dem Standardwert 0 – typischerweise die von älteren TYPO3-Vorlagen kopierten Sichtbarkeitsfelder starttime und endtime. Das Feld liefert der Validierung damit den Wert "0". Und "0" ist kein gültiges ISO-8601-Datum. Luxon wirft einen Fehler.
Der entscheidende Punkt ist, was dann passiert: Dieser Fehler wird nicht abgefangen. Er bricht nicht nur die Initialisierung des einen kaputten Feldes ab, sondern die gesamte Initialisierungsschleife – und damit den Aufbau des kompletten Formulars. Ein einziges Alt-Feld, das im Zweifel nicht einmal sichtbar ist, legt so ein Formular mit dreissig anderen, völlig intakten Feldern still. Das erklärt auch, warum der Fehler nur bestimmte Tabellen traf: genau jene, deren Konfiguration noch die alte Schreibweise enthielt.
Die naheliegende Schnellreparatur wäre gewesen, den Standardwert von 0 auf etwas „Datumsähnliches” zu ändern. Das hätte das Symptom kaschiert und die eigentliche Altlast konserviert. Wir haben stattdessen migriert.
TYPO3 kennt seit Version 12 einen eigenständigen Feldtyp type => 'datetime', der die frühere Konstruktion aus Texteingabefeld plus Render-Typ plus eval-Kette ersetzt. In den betroffenen Konfigurationsdateien haben wir konsequent darauf umgestellt und die obsoleten Angaben (renderType, eval, size, checkbox) entfernt. Zwei Eigenschaften blieben bewusst unverändert: der Standardwert und der zulässige Wertebereich, beide weiterhin als klassische Zeitstempel.
Das ist der wichtigste Punkt für den Betrieb: An der Datenhaltung ändert sich nichts. Die Spalten bleiben Ganzzahl-Spalten mit Unix-Zeitstempeln, es ist keine Datenmigration nötig, und bestehende Inhalte bleiben unangetastet. Der moderne Feldtyp interpretiert die 0 schlicht als „leer”, statt sie an eine Datumsbibliothek weiterzureichen, die daran scheitert. Damit ist die Fehlerquelle nicht umgangen, sondern beseitigt.
Ein Fix, der nur das gemeldete Formular repariert, ist bei diesem Fehlerbild wenig wert – denn jedes weitere Alt-Feld wartet nur darauf, beim nächsten Klick dasselbe zu tun. Deshalb gehört zu einem solchen Fix zwingend eine systematische Nachkontrolle: Wir haben die gesamte Erweiterung nach der alten Schreibweise durchsucht, alle Fundstellen migriert und anschliessend verifiziert, dass keine einzige Konfiguration mit dem alten Muster mehr übrig ist. Bei einem der beiden Projekte betraf das vier Konfigurationsdateien quer über Inhaltselemente und eigene Datenmodelle hinweg – gefunden wurden sie nur durch die vollständige Suche, gemeldet worden war ein einziges Formular.
Bei dieser Gelegenheit kam eine zweite, unauffälligere Altlast zum Vorschein: Verweise auf Beschriftungstexte, die auf Erweiterungen zeigten, die es im TYPO3-Core so gar nicht mehr gibt. Beim Umbau des Cores in einzelne Composer-Pakete sind diese Pfade umgezogen; die alten Referenzen laufen seither ins Leere.
Diese Verweise legen nichts lahm – sie sorgen nur dafür, dass Felder im Backend gar nicht oder mit kryptischen Platzhaltern beschriftet sind. Für die Redaktion ist das trotzdem täglich spürbar. Wir haben die Pfade auf ihre heutigen Entsprechungen im Core-Paket korrigiert und gegen die tatsächlich installierte Core-Version geprüft, statt sie aus dem Gedächtnis zu setzen.
Das Anlegen neuer Datensätze funktioniert in beiden Installationen wieder – und zwar nicht nur in dem gemeldeten Formular, sondern in allen, die dieselbe Altlast in sich trugen. Die Änderung blieb dabei bewusst klein und gut überprüfbar: reine Feldkonfiguration, kein Eingriff in Programmlogik, keine Datenmigration, kein sichtbarer Unterschied im Frontend. Die Umstellung wurde vor dem Ausrollen unabhängig gegengeprüft – auf Korrektheit der Migration, auf Datenkompatibilität der Zeitstempel und vor allem auf Vollständigkeit.
Der teuerste Teil dieses Fehlers war nicht die Reparatur, sondern die Suche. Ein Formular, das ohne jede Fehlermeldung im Ladespinner hängen bleibt, gibt von sich aus keinen einzigen Hinweis darauf, dass die Ursache eine unscheinbare Feldkonfiguration ist, die niemand mehr bewusst gepflegt hat.
Daraus lassen sich drei Dinge mitnehmen. Erstens: Ein Upgrade ist nicht mit dem grünen Frontend abgeschlossen – die Backend-Abläufe der Redaktion gehören genauso auf die Testliste, inklusive „Neuer Datensatz” für jede eigene Tabelle. Zweitens: Wenn der Server einen sauberen HTTP-200 liefert und trotzdem nichts erscheint, lohnt der Blick in die Browserkonsole mehr als jede weitere Runde im Serverlog. Und drittens, am wichtigsten: Veraltete Feldkonfigurationen sind keine Kosmetik, die man „irgendwann mal” angeht. Sie sind stille Blockaden, die genau dann zuschlagen, wenn eine neue Major-Version die Spielregeln ändert. Ein sauberes Upgrade räumt sie systematisch mit ab – nicht erst, wenn die Redaktion vor einem drehenden Spinner sitzt.
Steht bei Ihnen ein TYPO3-Upgrade an, oder verhält sich Ihr Backend seit dem letzten Versionssprung merkwürdig? Sprechen Sie uns an – wir prüfen Ihre Installation auf genau solche Altlasten, bevor sie im Alltag auffallen.
]]>An einem ganz normalen Morgen meldete unser täglicher, automatisierter Sicherheits-Scan für eine von uns betreute TYPO3-Website auf einen Schlag 22 bekannte Schwachstellen (CVEs) – und zwar nicht im selbst entwickelten Code, sondern in den quelloffenen Bibliotheken, auf denen die Seite aufbaut.
Das ist keine Ausnahme, sondern der Normalfall moderner Webentwicklung: Eine TYPO3-Anwendung besteht zu einem grossen Teil aus Dritt-Komponenten, die über den Paketmanager Composer eingebunden werden – vom TYPO3-Core selbst über HTTP-Clients bis zu spezialisierten Sicherheits-Bibliotheken. In genau diesen Komponenten werden fortlaufend neue Sicherheitslücken entdeckt und – verantwortungsvoll – veröffentlicht. Eine Website, die einmal live gegangen ist und danach „eingefroren” bleibt, sammelt deshalb mit jedem Tag stillschweigend Risiko an, ohne dass sich an ihrem sichtbaren Verhalten irgendetwas ändert.
Der erste Reflex bei 22 Meldungen ist oft Hektik: jede Lücke einzeln nachschlagen, einzeln patchen, einzeln testen. Das ist langsam, fehleranfällig und bringt den Abhängigkeitsbaum leicht in einen inkonsistenten Zustand. Wir gehen anders vor.
Am Anfang steht nicht der Fix, sondern die Sichtbarkeit. Für die von uns betreuten Projekte läuft täglich ein automatisierter Sicherheits-Scan, der die tatsächlich installierten Paketversionen mit den offiziellen Schwachstellen-Datenbanken abgleicht. So landet eine neu veröffentlichte Lücke bei uns auf dem Tisch, bevor sie in freier Wildbahn ausgenutzt werden kann – inklusive Einordnung, welche Pakete betroffen sind und welche Zielversion das Problem behebt.
Der entscheidende Punkt: In sauber gepflegten Projekten sind die Versions-Vorgaben (die sogenannten Constraints in der composer.json) bereits so gesetzt, dass die abgesicherten Patch-Versionen erlaubt sind – im konkreten Fall etwa ^13.4 für alle TYPO3-Pakete. Es musste also keine einzige Versionsvorgabe angefasst werden. Der Fix bestand darin, die bereits erlaubten, gepatchten Versionen tatsächlich zu ziehen – ein reiner Refresh der composer.lock:
composer update "typo3/cms-*" guzzlehttp/guzzle guzzlehttp/psr7 typo3/html-sanitizer --with-dependencies
Weil alle betroffenen Pakete in einem einzigen Lauf aktualisiert werden, bleibt der Abhängigkeitsbaum in sich konsistent – kein Flickenteppich aus 22 halb zusammenpassenden Einzelständen. Die composer.json bleibt dabei unangetastet; geändert wird ausschliesslich die Lock-Datei, die exakt festhält, welche Version wovon installiert ist.
In diesem einen Lauf wurden alle 22 gemeldeten Schwachstellen geschlossen:
Für die Redaktion und die Besucherinnen und Besucher der Seite war davon nichts zu spüren: keine Änderung an Inhalten, Funktionen oder Darstellung – nur intern deutlich sicherere Fundamente.
Ein Update gilt bei uns erst dann als erledigt, wenn nachweisbar ist, dass es wirkt. Der aktualisierte Stand wurde in einem sauberen PHP-8.4-Container gebaut und geprüft:
composer audit meldete anschliessend keine offenen Sicherheitshinweise mehr – alle 22 CVEs waren nachweislich ausgeräumt.composer validate bestätigte, dass Constraint-Datei und Lock-Datei zueinander passen.composer.lock – ein starkes Signal dafür, dass wirklich nur Versionen bewegt und keine Vorgaben verändert wurden.Der grösste Hebel gegen solche Sammelmeldungen ist, sie gar nicht erst gross werden zu lassen. Deshalb ist die Dependency-Pflege bei uns kein Feuerwehreinsatz, sondern Routine: Über mehrere Kundenprojekte hinweg heben wir TYPO3 planmässig auf die jeweils aktuelle Patch-Version im 13.4-LTS-Zweig (zuletzt auf 13.4.33) an. Wer regelmässig kleine, sichere Schritte geht, muss selten einen grossen, riskanten Sprung machen.
Alle 22 gemeldeten Schwachstellen wurden in einem einzigen, koordinierten Durchlauf geschlossen – ohne Änderung an Inhalten oder Funktionen, mit einem sauber begrenzten Diff und einem grünen Smoke-Test nach dem Deploy. Aus einer potenziell hektischen 22-fach-Baustelle wurde ein ruhiger, nachvollziehbarer und vollständig verifizierter Wartungsvorgang.
Sicherheit ist kein Zustand, den man einmal herstellt, sondern ein Prozess. Die Meldung von 22 CVEs an einem Tag klingt dramatisch – ist aber vollkommen beherrschbar, wenn drei Dinge zusammenkommen: kontinuierliche Überwachung, die Lücken früh sichtbar macht; sauber gepflegte Versionsvorgaben, die einen ruhigen Lockfile-Refresh statt hektischer Einzelfixes erlauben; und regelmässige Minor-Upgrades, die den Rückstand gar nicht erst entstehen lassen. So bleibt eine Website dauerhaft auf einem abgesicherten Fundament – unsichtbar für die Nutzer, aber entscheidend für den sicheren Betrieb.
Betreiben Sie eine TYPO3- oder PHP-Website und sind unsicher, wie es um die Aktualität Ihrer Abhängigkeiten steht? Sprechen Sie uns an – wir richten die kontinuierliche Überwachung ein und halten Ihre Seite planmässig auf einem sicheren Stand.
]]>Software wird umgebaut, Abläufe werden vereinfacht, alte Funktionen fliegen raus – das ist gesunde Weiterentwicklung. Was dabei gern übersehen wird: Die Links, die auf diese Funktionen zeigen, verschwinden nicht mit dem Code. Sie stecken in längst versendeten E-Mails, in Kalendereinträgen, in Lesezeichen und in den Indizes von Suchmaschinen – und sie bleiben dort, lange nachdem die dazugehörige Funktion entfernt wurde.
Genau dieses Muster haben wir auf der von uns betreuten Weinplattform VINUM beobachtet. Nach einem Umbau der Event-Anmeldung endete jeder Aufruf einer alten Anmelde-Aktion nicht etwa auf einer freundlichen Hinweisseite, sondern in einem harten Serverfehler. 41 solcher Fehler in nur sieben Tagen, verteilt über die deutsche und die französische Seite – ausgelöst von echten Nutzern, die auf einen völlig legitimen, korrekt signierten Link geklickt hatten. Dieser Artikel zeigt, wie man Funktionen abkündigt, ohne Besucher auf Fehlerseiten laufen zu lassen – ein Thema, das jede über Jahre gewachsene Website betrifft.
Die Event-Anmeldung von VINUM lief früher über einen Bestätigungslink per E-Mail: Nach der Anmeldung erhielten Interessenten eine Mail mit einem Link, der die Anmeldung abschloss. Bei einem Umbau wurde dieser Ablauf durch mehrstufige, serverseitige Anmeldeschritte ersetzt – die alte, mailbasierte Aktion wurde ersatzlos aus dem Code entfernt.
Was dabei nicht bedacht wurde: Diese Bestätigungslinks tragen in TYPO3 eine kryptografische Signatur (den sogenannten cHash), die sie gegen Manipulation absichert. Diese Signatur läuft nicht ab. Ein Link, der vor Monaten in einer Bestätigungsmail verschickt wurde, ist technisch bis heute gültig – er zeigt nur eben auf eine Aktion, die es nicht mehr gibt.
Und genau hier lag die Tücke im Detail:
InvalidActionNameException ab – noch bevor der Controller mit unserem eigenen Code aufgerufen wird. Ohne Auffangnetz wird daraus ein HTTP-500.Sichtbar wurde das Problem überhaupt erst durch unsere tägliche, automatisierte Auswertung der Produktions-Logs, die wiederkehrende Fehler clustert und als fertig recherchiertes Ticket aufbereitet – aus „einige 500er pro Tag” wurde so ein priorisierter Auftrag mit fertiger Ursachenanalyse.
Die naheliegende Reaktion – „die Funktion ist weg, dann sind die Links eben tot” – greift zu kurz. Solange gültige Links auf eine Adresse zeigen, ist diese Adresse Teil der öffentlichen Oberfläche und muss sich anständig verhalten. Unser Ziel war deshalb nicht, den Fehler zu unterdrücken, sondern die alten Links wieder an ein sinnvolles Ziel zu führen.
Statt die entfernten Aktionen ganz verschwinden zu lassen, haben wir sie in abgespeckter Form wieder eingeführt – nicht mit ihrer alten Logik, sondern als reine Weiterleitungen. Die frühere Bestätigungs-Aktion nimmt jetzt nur noch die Event-Kennung entgegen und leitet den Besucher direkt auf die zugehörige Event-Seite weiter. Wer also einen alten Anmeldelink anklickt, landet nicht auf einer Fehlerseite, sondern genau bei der Veranstaltung, um die es ging – inklusive des aktuellen, neuen Anmeldewegs.
Für die codebasierte Bestätigung, die statt einer Event-Kennung einen individuellen Anmeldecode trägt, geht die Weiterleitung einen Schritt weiter: Der Code wird nachgeschlagen, die zugehörige Anmeldung und deren Event ermittelt, und der Besucher landet auf der richtigen Event-Seite. Aus einem Serverfehler wird so eine saubere Weiterleitung mit erhaltenem Kontext.
Die eigentliche Ursache des 500ers – der Abbruch, noch bevor der Controller läuft – lässt sich nur an einer Stelle beheben: in der Konfiguration der Erweiterung, die festlegt, welche Aktionen ein Plugin ausführen darf. Wir haben die beiden alten Aktionsnamen dort wieder eingetragen, und zwar in beiden Varianten der Liste (der gecachten und der ungecachten). Erst dadurch reicht das Framework die Anfrage überhaupt an unseren Code weiter, statt sie vorzeitig mit einer InvalidActionNameException abzuweisen.
Alte Links kommen nicht immer sauber an. Manche tragen gar keine Kennung mehr, manche eine veraltete oder abgelaufene, manche eine durch mehrfaches Weiterleiten verstümmelte. Eine Weiterleitung, die stur mit einem gültigen Parameter rechnet, würde bei genau diesen Fällen wieder abstürzen – diesmal mit einem anderen Fehler.
Deshalb sind alle Parameter der neuen Aktionen bewusst optional. Fehlt eine Kennung, lässt sich ein Code nicht auflösen, oder ist ein Event längst vergangen, führt die Weiterleitung sauber auf die allgemeine Event-Übersicht zurück, statt einen Fehler zu werfen. Diese Nachsicht ist kein Beiwerk, sondern die Kernanforderung: Der Besucher soll immer auf einer funktionierenden Seite landen, egal in welchem Zustand sein alter Link ist.
Beim Aufräumen zeigte sich, dass im Code noch alte Vorlagen schlummerten, die weiterhin Links auf die entfernte Aktion erzeugten – eine potenzielle Quelle für immer neue tote Links. Diese Vorlagen haben wir entfernt. Damit gibt es keine lebende Stelle mehr, die frische Verweise auf eine nicht mehr existierende Funktion ausgibt; das Problem kann sich nicht aus sich selbst heraus nachbilden.
Aus jedem der bisher 41 Serverfehler pro Woche wird jetzt eine unauffällige Weiterleitung. Wer heute einen Monate alten Anmeldelink anklickt – aus einer archivierten Mail, einem Kalendereintrag oder einem Lesezeichen – landet direkt bei der gewünschten Veranstaltung oder, falls diese vorbei ist, auf der Event-Übersicht. Die InvalidActionNameException für die alten Aktionen ist aus den Logs verschwunden, und kein Besucher sieht mehr eine Fehlerseite, nur weil er einem völlig legitimen Link gefolgt ist.
Wichtiger als der einzelne Fix ist das Prinzip dahinter: Wir haben eine entfernte Funktion nicht wiederbelebt, sondern nur einen schmalen Migrationspfad für die noch kursierenden Links gebaut. Der neue Code ist bewusst minimal – er nimmt einen alten Aufruf entgegen und übergibt ihn an die aktuelle Oberfläche. So bleibt die Vereinfachung, die der Umbau gebracht hat, vollständig erhalten, ohne dass die Nutzer den Preis dafür zahlen.
Eine Funktion aus dem Code zu entfernen ist einfach. Die Spuren, die sie in der Aussenwelt hinterlassen hat, verschwinden aber nicht mit ihr: Signierte Links in E-Mails leben unbegrenzt weiter, Kalender und Lesezeichen sind ein Archiv, das man nicht kontrolliert, und Suchmaschinen halten alte Adressen hartnäckig fest. Wer eine Funktion abkündigt, braucht deshalb einen Plan für die URLs, die bereits im Umlauf sind – und in aller Regel heisst dieser Plan: weiterleiten statt ersatzlos streichen.
Das kostet wenig. Eine schlanke Weiterleitung, die einen alten Aufruf auf ein sinnvolles Ziel führt und mit fehlenden Parametern gnädig umgeht, ist in kurzer Zeit gebaut – und erspart realen Nutzern die Sackgasse einer Fehlerseite. Der teure Weg ist der, diese Altlasten erst dann zu bemerken, wenn sie sich als wiederkehrende 500er im Log stapeln.
Planen Sie einen Umbau, bei dem Funktionen oder ganze Seitenbereiche wegfallen? Sprechen Sie uns an – wir sorgen dafür, dass Ihre bestehenden Links den Übergang überstehen und Besucher weich aufgefangen werden, statt in Serverfehlern zu landen.
]]>Für ein Projekt im sozialen Bereich haben wir eine Plattform umgesetzt, auf der Menschen ihre wichtigsten Unterlagen sicher hinterlegen können: Notfallinformationen, Vorsorgewünsche, ein persönliches Tagebuch, Botschaften an Angehörige und ein handschriftliches Testament. Eine benannte Vertrauensperson darf genau definierte Teile davon einsehen – manches schon zu Lebzeiten, anderes erst nach einem bestätigten Ableben. Die Zielgruppe ist besonders schutzbedürftig, entsprechend hoch sind die Ansprüche an Datenschutz und Vertrauenswürdigkeit. Die Plattform beschreiben wir hier anonymisiert – ohne Kundennamen.
Eine digitale Nachlass- und Notfallvorsorge lebt von einem scheinbar einfachen Versprechen: Die richtigen Menschen sehen die richtigen Informationen – aber immer erst zum richtigen Zeitpunkt. Genau das ist technisch anspruchsvoll:
Statt eines einzelnen „verstorben ja/nein”-Schalters haben wir die Sichtbarkeit pro Inhalt konfigurierbar gemacht. Jede Rubrik trägt die Information, ob sie einer Vertrauensperson schon zu Lebzeiten oder erst nach einem bestätigten Ableben gezeigt wird.
Der sichere Standard ist dabei „erst nach dem Ableben” – neue Inhalte sind also im Zweifel geschützt und nicht versehentlich zu früh sichtbar. Das Modell lässt sich anpassen, ohne dass dafür programmiert werden muss, sollte sich der Bedarf einmal ändern.
Wichtig war uns: Einen Inhalt zu Lebzeiten schlicht „auszublenden” genügt nicht. Jeder Abruf wird serverseitig geprüft. Versucht jemand, einen noch gesperrten Inhalt direkt aufzurufen, wird der Zugriff aktiv verweigert – nicht nur in der Oberfläche versteckt. So gibt es keine Hintertür an der Ansicht vorbei.
Ist ein Ableben bestätigt, kann die Vertrauensperson innerhalb eines festen Aufbewahrungsfensters alle hinterlegten Daten in einem einzigen Paket herunterladen. Dieser Vorgang ist bewusst mehrstufig abgesichert:
So bleibt der Zugriff im Ernstfall praktikabel – und trotzdem lückenlos nachvollziehbar.
Handschriftliches Testament und Tagebuch werden der Vertrauensperson nach dem Ableben zusätzlich direkt im geschützten Bereich zur Ansicht bereitgestellt – ausschließlich lesend. Die zugehörigen Dateien liegen in einem privaten Speicher und sind nie über eine direkte Adresse abrufbar; sie werden nur über eine authentifizierte, auf die berechtigte Person geprüfte Ausgabe ausgeliefert.
Ergänzend haben wir einen geschützten Bereich für wichtige persönliche Dokumente umgesetzt – etwa Ausweis, Geburtsurkunde oder Versichertenkarte. Gerade bei Verlust oder Diebstahl bleiben die Unterlagen so digital verfügbar. Uploads werden serverseitig auf ihren tatsächlichen Dateityp geprüft (nicht nur anhand der Dateiendung), unter zufälligen Namen privat gespeichert und sind ebenfalls nur über die geprüfte, authentifizierte Ausgabe erreichbar.
Weil auf dieser Plattform besonders schützenswerte Daten liegen, haben wir das gesamte System einem gründlichen Sicherheits-Audit unterzogen und die bestätigten Befunde direkt behoben. Geprüft und gehärtet wurden unter anderem:
Datenschutz und Vertrauen waren hier kein nachträglicher Gedanke, sondern von Anfang an ein zentraler Bestandteil des Produkts.
Entstanden ist eine Plattform, die einem sensiblen Thema mit der nötigen Sorgfalt begegnet:
Das Projekt steht kurz vor dem Livegang. Es zeigt, wie sich hohe Datenschutz-Ansprüche und eine praxistaugliche Bedienung verbinden lassen – gerade dort, wo es um die persönlichsten Unterlagen eines Menschen geht.
Digitale Nachlass- und Notfallvorsorge ist Vertrauenssache. Ein durchdachtes, abgestuftes Berechtigungsmodell, konsequent serverseitig durchgesetzt und durch ein Sicherheits-Audit abgesichert, macht aus einem heiklen Thema ein belastbares Produkt.
Sie planen eine Anwendung, bei der Datenschutz und differenzierte Zugriffsrechte im Mittelpunkt stehen? Sprechen Sie mit uns – wir begleiten Sie von der Konzeption bis zum sicheren Livegang.
]]>Viele Websites führen ein Verzeichnis: Mitglieder, Anbieter, Standorte, Fachbetriebe. Oft ist es historisch als lange Liste mit einem einzelnen Filter gewachsen – funktional, aber mühsam zu durchsuchen. Diese Woche ist auf VINUM der komplett überarbeitete Weingüter-Kompass live gegangen: Aus einer simplen Regionsliste wurde ein vollwertiges, durchsuchbares Verzeichnis der Winzer – mit kombinierbarer Suche, synchroner Kartenansicht und eigenen Profilseiten pro Weingut.
Der Beitrag zeigt am echten Beispiel, wie man ein Verzeichnis in TYPO3 vom reinen Auflisten zu einem echten Rechercheinstrument entwickelt – und warum wir dabei bewusst nicht zu einer Suchmaschine wie Solr gegriffen haben.
Der bisherige Weingüter-Kompass zeigte die Weingüter nach Region gruppiert, mit genau einem Filter: der Region. Wer ein Weingut mit einem bestimmten Merkmal suchte – etwa Bio-Betriebe im Wallis, die eine bestimmte Rebsorte anbauen – musste sich durch die Liste scrollen. Jeder Treffer war zudem nur ein Stück Text: Der Klick auf einen Pin in der Karte führte auf die externe Website des Weinguts, eine eigene Profilseite im Portal gab es nicht.
Drei Dinge sollten sich ändern, ohne die bestehende Darstellung von heute auf morgen umzuwerfen:
Statt vieler einzelner Filterfelder gibt es jetzt ein zentrales Suchfeld mit Auswahlliste und Tippautomatik. Vier Dimensionen sind darin nach Gruppen sortiert kombinierbar: Region/Kanton, Angebote und Merkmale (etwa Degustation vor Ort, Bio, Übernachtung, Gastronomie), Rebsorten sowie Besonderheiten. Zusätzlich lässt sich frei nach Name, Ort oder Postleitzahl tippen.
Entscheidend ist die Logik dahinter: Mehrere Werte derselben Kategorie wirken als „oder” (Wallis oder Waadt), Werte unterschiedlicher Kategorien als „und” (Region Wallis und Rebsorte Pinot Noir). So lässt sich die Trefferliste präzise eingrenzen, ohne dass die Bedienung kompliziert wird. Umgesetzt haben wir das mit der bereits im Projekt vorhandenen Auswahlkomponente – ohne eine neue Abhängigkeit einzuführen.
Zwei Details aus den echten Daten waren dabei wichtig:
Die Liste aktualisiert sich sofort und ohne Neuladen der Seite; „Zurücksetzen” stellt die vollständige Liste wieder her.
Naheliegend wäre gewesen, für die Suche auf Solr zu setzen – die Suchmaschine, die auf VINUM die eigentliche Weinsuche mit über 100.000 Degustationsnotizen antreibt. Für den Weingüter-Kompass haben wir uns bewusst dagegen entschieden.
Der Grund ist die Datenmenge: Die vollständige Liste der Weingüter steht ohnehin bereits vollständig auf der Seite. In dieser Grössenordnung braucht es keine serverseitige Suchabfrage – die Filterung passiert direkt im Browser auf den bereits geladenen Daten. Das hat zwei handfeste Vorteile: Die Treffer erscheinen verzögerungsfrei (kein Server-Roundtrip, kein Neuladen), und es entsteht keine zusätzliche Infrastruktur, die betrieben, aktualisiert und indexiert werden müsste.
Die Faustregel, die wir dabei anlegen: Eine Suchmaschine wie Solr lohnt sich, wenn Datenmengen in die Tausende gehen, Volltextrelevanz und Rankings gefragt sind oder die Daten gar nicht erst vollständig in den Browser passen. Für ein überschaubares, kuratiertes Verzeichnis ist die schlanke, clientseitige Lösung schneller und günstiger im Betrieb. Das richtige Werkzeug hängt an der Datenmenge – nicht an der Frage, was technisch am meisten hermacht.
Jedes Weingut hat jetzt eine eigene Profilseite mit sprechender Adresse – aufgebaut wie die etablierten Mitgliederprofile im Portal: Kopfbereich, Beschreibung, Merkmale als Icons, Kontaktdaten, Öffnungszeiten und Kartenausschnitt. Damit diese Adressen sauber und suchmaschinenfreundlich sind, haben wir eine entsprechende Routing-Regel ergänzt, statt kryptische Parameter-URLs auszugeben.
Der zweite Schritt betrifft die Karte: Die Pins verweisen jetzt auf die Profilseite im Portal statt auf die externe Website des Weinguts. Karte und Liste ziehen dadurch am selben Strang – der Besucher bleibt im Verzeichnis und findet alle Informationen an einem Ort, statt auf verstreute externe Seiten geschickt zu werden.
Ein solcher Umbau darf die bestehende Seite nicht von einem Tag auf den anderen ersetzen. Deshalb steckt hinter dem Kompass ein Umschalter im Redaktionsbereich: In der Voreinstellung „Legacy” bleibt die klassische Listendarstellung Byte für Byte unverändert. Erst der Modus „Neu” aktiviert das überarbeitete Verzeichnis mit Facettensuche, Profilseiten und profilverlinkten Kartenpins.
So liessen sich die neuen Funktionen in Ruhe entwickeln und prüfen, während die Live-Seite unangetastet blieb. Ein Nebeneffekt der Überarbeitung: In der neuen Ansicht sind alle Regionen vollständig auswählbar – die 26 Schweizer Kantone und die 13 deutschen Anbaugebiete – und nicht nur jene, zu denen bereits ein Profil erfasst ist.
Ein Verzeichnis ist nur so gut wie seine Pflege. Damit die Inhalte aktuell bleiben, pflegen die Winzer ihre Angaben selbst – im bereits bestehenden, login-geschützten Bearbeitungsbereich. Im Zuge des Umbaus haben wir dort zwei neue Felder ergänzt: Instagram und Facebook. Sie funktionieren genau wie das bestehende Website-Feld und erscheinen anschliessend auf der Profilseite.
Der Clou liegt im Aufwand: Weil die Bearbeitung die Daten ohnehin schon direkt speichert, genügten das Datenmodell, das Formularfeld und die Datenbankspalte – kein Eingriff in die Ablauflogik. Neue Felder ohne Backend-Umbau, gepflegt von denen, die sie am besten kennen: den Weingütern selbst.
Aus einer statischen Regionsliste ist ein Verzeichnis geworden, mit dem Besucher tatsächlich arbeiten: Sie kombinieren Kriterien über mehrere Dimensionen, sehen Treffer sofort in Liste und Karte, und gelangen mit einem Klick auf eine vollständige Profilseite – alles ohne Wartezeiten und ohne den Umweg über externe Websites. Die Winzer halten ihre Profile selbst aktuell, und die vertraute Darstellung blieb während des gesamten Umbaus verfügbar.
Ein durchsuchbares Verzeichnis muss keine schwere Suchinfrastruktur bedeuten. Wer die Datenmenge realistisch einschätzt, das richtige Werkzeug wählt und den Umbau über einen Umschalter absichert, kommt schnell zu einer Lösung, die sich verzögerungsfrei bedient und günstig betreiben lässt. Facettensuche, Kartenanbindung und Self-Service-Pflege lassen sich so auch auf Mitglieder-, Anbieter- oder Standortverzeichnisse ganz unterschiedlicher Branchen übertragen.
Betreiben Sie ein Verzeichnis, das mehr sein soll als eine lange Liste? Sprechen Sie uns an – wir schauen uns Ihre Such- und Übersichtsseiten gerne an.
]]>In der ursprünglichen Struktur lag der Versand der Bestätigungsmail als Schritt innerhalb einer veröffentlichten Mautic-Kampagne. Das klingt naheliegend, hat aber eine unangenehme Nebenwirkung: Die Tabelle email_stats – die mit Abstand größte Tabelle der Mautic-Datenbank – wird dadurch load-bearing. Löscht man alte Versand-Statistiken, um Platz zu schaffen, „scharf” sich der Kampagnenschritt erneut und Mautic verschickt bereits zugestellte Bestätigungsmails ein zweites Mal. Ein einfaches Aufräumen war damit ausgeschlossen.
Betroffen waren die drei Kern-Newsletter für Deutschland, die Deutschschweiz und die französische Schweiz mit zusammen rund 120.000 „festverdrahteten” Statistikzeilen. Erschwerend kam die Mehrsprachigkeit hinzu: Jede Sprachvariante braucht ihre eigene Bestätigungsmail und ihren eigenen Bestätigungslink – und die französische Schweiz nutzt einen abweichenden französischen Bestätigungspfad.
Der Grundgedanke: Der Mailversand gehört nicht in die Kampagne, sondern ans Formular. Wenn die Bestätigungsmail direkt beim Absenden des Anmeldeformulars ausgelöst wird, ist sie von der Kampagnen-Statistik entkoppelt – und email_stats wird wieder frei aufräumbar.
Für jede Sprache haben wir ein eigenständiges Anmeldeformular aufgebaut, das die Bestätigungsmail selbst per Form-Action verschickt. Kein Kampagnenschritt hängt mehr am Mailversand, und die Statistiktabelle verliert ihre kritische Rolle.
Beim Absenden markiert das Formular den Kontakt als „ausstehend” – mit einem generischen und einem sprachspezifischen Tag. Erst der Klick in der Bestätigungsmail überführt ihn in den Status „bestätigt”. Diese Zustandsführung über Tags macht den gesamten Ablauf transparent und nachvollziehbar, ohne dass Kontakte vorschnell in die Verteiler geraten.
Ein einziges Trigger-Segment sammelt genau die Kontakte ein, die „ausstehend” sind und die Bestätigungsseite aufgerufen haben. Weil die französische Schweiz einen anderen Bestätigungspfad verwendet, matcht der URL-Filter beide Varianten per regulärem Ausdruck (REGEXP) statt über einen simplen Textvergleich. Das Segment startet leer und saugt so keine historischen Besucher ein – es reagiert ausschließlich auf frische Bestätigungen.
Eine schlanke Double-Opt-In-Kampagne ohne jeden Mailversand-Schritt schaltet die Kontakte anschließend anhand ihres Sprach-Tags in das richtige Empfänger-Segment – und räumt die „pending”-Tags gleich wieder auf.
Die Website läuft auf TYPO3. Der NewsletterHelper, der die Anmeldedaten an Mautic übergibt, zeigt jetzt pro Sprache auf die neuen Formulare statt auf die alten Kampagnen-Formulare. Weil die neuen Formulare feldidentische Klone sind, blieb der Rest der Integration – inklusive der Abmelde-Strecke – unverändert.
Auch den eigentlichen Newsletter-Versand haben wir von Kampagnen auf Segment-Mails (Broadcasts) umgestellt. Die zwei Fassungen jeder Ausgabe – mit und ohne Werbebanner – bilden wir über je zwei überschneidungsfreie Versand-Segmente pro Sprache ab. So bleibt auch der reguläre Versand frei von der email_stats-Kopplung, und die Auswahl der Empfänger ist über die Segmentdefinition sauber dokumentiert statt in Kampagnenlogik versteckt.
Die Statistiktabellen sind wieder aufräumbar (prune-bar), ohne dass jemals eine alte Bestätigungsmail erneut verschickt wird. Die gesamte Strecke wurde end-to-end über alle drei Sprachvarianten getestet – von der Anmeldung über die Bestätigungsmail und den Klick bis zur korrekten Einsortierung in das jeweilige Empfänger-Segment. Der rechtlich vorgeschriebene Double-Opt-In-Schritt bleibt dabei vollständig erhalten; entkoppelt haben wir nur die Technik dahinter.
Double-Opt-In ist kein Häkchen, das man einmal setzt – es ist eine Architekturentscheidung. Ob der Bestätigungsversand in der Kampagne oder am Formular hängt, klingt nach einem Detail, entscheidet aber darüber, ob die Datenbank in ein paar Jahren noch pflegbar ist. Wer solche Weichen früh richtig stellt, spart sich später aufwendige Migrationen und riskante Aufräumaktionen im laufenden Betrieb.
Sie planen eine mehrsprachige Newsletter-Strecke oder kämpfen mit einer Marketing-Datenbank, die sich nicht mehr aufräumen lässt? Sprechen Sie mit uns – wir schauen uns Ihre Double-Opt-In- und Segment-Architektur gerne an.
]]>Self-Service-Formulare im Frontend sind komfortabel: Statt jede Änderung über eine Agentur oder eine Redaktion laufen zu lassen, pflegen Verkoster, Winzer und Veranstalter ihre Inhalte selbst. Auf der von uns betreuten Weinplattform VINUM reichen sie so Verkostungsnotizen ein, legen Events an und aktualisieren ihre Profilangaben.
Genau diese Formulare sind aber auch ein Magnet für Eingaben, mit denen das Datenmodell nie gerechnet hat. Ein leer gelassenes Feld, eine zweistellige Jahreszahl, ein zu langer Freitext, ein Emoji – alltägliche Kleinigkeiten, die in Produktion einen harten Serverfehler auslösen, die Eingabe verwerfen und den Nutzer auf einer generischen Fehlerseite zurücklassen. Innerhalb einer Woche haben wir gleich mehrere solcher Abstürze aufgespürt und behoben. Dieser Artikel zeigt an echten Fällen, warum sie entstehen – und wie man sie systematisch verhindert, statt nur Symptome zu bekämpfen.
Die Fehler hatten alle dasselbe Grundmuster: Zwischen dem, was ein Formular zulässt, und dem, was die Datenbankspalte tatsächlich akzeptiert, klafft eine Lücke. TYPO3 mit seinem Extbase-Framework bildet ein abgeschicktes Formular auf ein Datenobjekt ab und schreibt es in die Datenbank. Passt der Wert nicht in die Spalte, wirft die Datenbank einen Fehler – und ohne sauberes Abfangen wird daraus ein HTTP-500, der beim Nutzer als Absturz ankommt.
Tückisch daran ist, dass diese Fehler unterhalb der Beschwerdeschwelle bleiben. Es sind keine spektakulären Ausfälle, sondern einzelne Nutzer, deren Eingabe „einfach nicht gespeichert” wird. Kaum jemand meldet das – es taucht nur als wiederkehrende Zeile im Produktions-Log auf. Vier Eingabemuster traten dabei besonders zuverlässig als Crash-Auslöser hervor:
NOT NULL-Verletzung ab.unsigned-Spalte rundheraus ablehnte.varchar(255)-Spalte – ab dem 256. Zeichen quittierte die Datenbank mit „Data too long”.So unterschiedlich die Auslöser wirken, die Verteidigung folgt demselben Prinzip: Man kann sich nicht auf eine einzelne Schutzschicht verlassen. Robuste Datenhaltung heisst, an mehreren Stellen gleichzeitig dafür zu sorgen, dass eine unerwartete Eingabe entweder sauber gespeichert oder freundlich abgewiesen wird – aber nie zu einem Absturz führt.
Lässt ein Nutzer ein Pflichtfeld leer, macht Extbase daraus nicht etwa eine 0, sondern ein null. Trifft dieses null auf eine Spalte, die per Definition keinen Leerwert erlaubt, schlägt die Datenbank-Bedingung zu. Im konkreten Fall existierte sogar bereits eine Absicherung – aber nur in einem von drei Speicherpfaden. Über die beiden ungesicherten Pfade rutschte das null weiterhin durch.
Die Lösung war, die Normalisierung nicht in jeder einzelnen Aktion zu wiederholen, sondern zentral im Datenmodell zu verankern: Ein fehlender Wert wird genau einmal – direkt beim Setzen der Eigenschaft – auf den etablierten Standardwert 0 zurückgeführt. Damit ist jeder heutige und jeder künftige Speicherpfad automatisch abgedeckt, ohne dass jemand daran denken muss.
Das Event-Formular liess freie Datumseingaben zu. Die zugrunde liegende Parsing-Funktion war dabei zu nachsichtig: Aus einer zweistelligen oder unplausiblen Jahreszahl erzeugte sie trotzdem ein gültiges Datum – bei einem Wert vor 1970 einen negativen Zeitstempel. Die zugehörige Datenbankspalte war jedoch unsigned, also auf positive Werte beschränkt, und wies den negativen Wert ab.
Hier haben wir auf zwei Ebenen angesetzt. Serverseitig parsen wir das Datum jetzt streng, prüfen es auf Plausibilität und lehnen Werte vor 1970 ab; statt eines Absturzes wird der Nutzer mit einem deutschen Hinweis zum Formular zurückgeführt, und es wird nichts Halbfertiges gespeichert. Zusätzlich erzwingen wir das Format TT.MM.JJJJ direkt im Browser: Die Datumsfelder prüfen die Eingabe noch vor dem Absenden, und der Kalender-Button trägt automatisch das richtige Format ein. So entsteht der Fehler gar nicht erst – und falls doch etwas durchkommt, fängt ihn die serverseitige Prüfung als Sicherheitsnetz ab.
Ein mehrzeiliges Textfeld ohne Längenbegrenzung, dahinter aber eine Spalte, die nur 255 Zeichen fasst – diese Diskrepanz war für „Data too long” verantwortlich. Bei mehrsprachigen Texten verschärft sich das noch, weil Umlaute und Akzente mehr als ein Byte belegen und die Grenze damit früher erreicht ist als bei reiner Zeichenzählung.
Die richtige Antwort war nicht, die Eingabe künstlich zu beschränken, sondern den Spaltentyp an die tatsächliche Nutzung anzupassen: Aus varchar(255) wurde ein text-Feld, das auch lange Beschreibungen vollständig aufnimmt – konsistent mit den benachbarten Freitextfeldern. Als zusätzliche Absicherung kürzen wir überlange Eingaben byte-genau auf die maximale Kapazität, falls jemand einen wirklich exzessiven Text einfügt. Bei der Gelegenheit haben wir die verwandten Felder desselben Formulars gleich mitgeprüft, um dieselbe Falle nicht an anderer Stelle offen zu lassen.
Emojis und Sonderzeichen aus dem erweiterten Unicode-Raum bestehen aus 4-Byte-Sequenzen. Der ältere Zeichensatz utf8 in MySQL/MariaDB kann pro Zeichen aber nur 3 Byte speichern und lehnt solche Eingaben mit „Incorrect string value” ab. Für Nutzer, die heute selbstverständlich ein Emoji in eine Beschreibung setzen, ist das eine alltägliche Eingabe – für die Datenbank ein Absturz.
Wir haben deshalb die Datenbankverbindung und die betroffenen Textspalten auf utf8mb4 umgestellt, den vollwertigen 4-Byte-Zeichensatz. Wichtig dabei: Die reine Schema-Migration von TYPO3 fasst die Kodierung bestehender Spalten nicht an – die bestehenden Daten mussten gezielt mit einem eigenen, wiederholbar ausführbaren Migrationsschritt nachgezogen werden. Erst danach werden Emojis verlustfrei gespeichert, statt die Eingabe abzuweisen.
Der eigentliche Hebel hinter all diesen Fixes ist, dass wir die Fehler überhaupt gesehen haben, bevor sich jemand beschwert hat. Möglich macht das eine tägliche, automatisierte Auswertung der Produktions-Logs, die wiederkehrende Fehler clustert, vom Rauschen trennt und als fertig recherchiertes Entwickler-Ticket aufbereitet. Aus „dreimal am Wochenende ein 500er” wird so ein priorisiertes Ticket mit Ursachenanalyse – nicht erst ein verärgerter Anruf Wochen später.
Innerhalb einer Woche wurden aus einer Handvoll unscheinbarer Logzeilen konkrete, behobene Fehler. Jeder einzelne hätte für sich genommen kaum jemandem auffallen müssen – in Summe waren es aber wiederkehrende Datenverluste für echte Nutzer, die ihre Eingaben verloren, ohne zu verstehen, warum.
Genauso wichtig wie die Einzelfixes ist das Muster dahinter: Statt das jeweils nächste defekte Feld zu flicken, haben wir die Schutzschichten dort verankert, wo sie alle Eingabewege abdecken – im Datenmodell, im Spaltentyp, im Zeichensatz und in der Validierung vor dem Absenden. Eine unerwartete Eingabe führt jetzt zu einem klaren Hinweis oder einer sauberen Speicherung, nicht mehr zu einer Fehlerseite.
Frontend-Self-Service ist ein Gewinn an Autonomie für die Nutzer – aber er verschiebt die Verantwortung für saubere Daten von der Redaktion zur Software. Jedes Feld, das ein Nutzer selbst befüllt, muss damit rechnen, dass das Modell auf eine Eingabe trifft, die es so nie erwartet hat. Robuste Datenhaltung bedeutet, diese Edge Cases nicht als Ausnahme, sondern als Normalfall zu behandeln: passende Spaltentypen, ein zeitgemässer Zeichensatz, serverseitige Validierung statt blossem Vertrauen auf den Browser – und ein Blick in die Produktions-Logs, der echte Probleme sichtbar macht, bevor sie eskalieren.
Häufen sich auf Ihrer Website unerklärliche Speicherfehler oder verlorene Formulareingaben? Sprechen Sie uns an – wir schauen uns Ihre Datenhaltung gerne systematisch an und härten sie gegen genau solche Edge Cases.
]]>Mehrsprachige Websites gelten als gelöstes Problem: Man legt die Sprachen an, übersetzt die Inhalte, fertig. In der Praxis steckt die Komplexität woanders – nämlich in der Frage, welche Inhalte überhaupt übersetzt gehören. Auf einer Plattform wie VINUM, die in drei Sprachräumen (Deutschland, Schweiz und französische Schweiz) ausgespielt wird, sind manche Daten echte Übersetzungen – ein Titel etwa lautet auf Französisch anders. Andere Daten sind dagegen sprachneutral: Eine Verkostungsnotiz zu einem bestimmten Wein ist dieselbe, egal in welcher Sprachversion sie erscheint.
Vermischt man beide Fälle im Datenmodell, entstehen Probleme, die zunächst nichts mit Sprache zu tun zu haben scheinen: Datensätze vermehren sich, Tabellen wachsen ins Uferlose, und die Suche zeigt veraltete Ergebnisse. Dieser Beitrag zeigt am echten Projekt, wie man die Sprach-Architektur von Anfang an sauber aufsetzt – und wie wir genau diese Wurzel bei einer bestehenden Plattform saniert haben.
Auf der Weinplattform waren mehrere Objekte als “übersetzbar” modelliert, die es inhaltlich gar nicht sind. Eine Degustation (ein Verkostungsereignis) etwa hat zahlreiche untergeordnete Verkostungsnotizen. Diese Notizen sind sprachneutral – und doch hingen sie an einem übersetzbaren Eltern-Objekt.
Das Tückische: TYPO3 nimmt eine solche Modellierung wörtlich. Sobald ein übersetztes Eltern-Objekt gespeichert wird, versucht das System, dessen untergeordnete Datensätze “mitzuübersetzen” – und legt dabei Kopien an. Bei jedem weiteren Speichern entstehen neue Kopien. Eine einzige grosse Degustation wuchs so von gut 800 auf rund 148.000 Notiz-Datensätze. Über alle Objekte hinweg sammelten sich Tausende Dubletten und verwaiste Verknüpfungen an.
Die Folgen waren konkret spürbar: Die öffentliche Weinsuche zeigte für eine aktuelle Verkostung keine frischen Treffer mehr, weil die Notizen mit der falschen Sprach-Kennung im Suchindex landeten. Und ein zuvor selbst gebauter “Aufräum-Mechanismus”, der die Klone nachträglich wieder löschte, kämpfte nur gegen das Symptom – nicht gegen die Ursache.
Der Kern des Problems steckte in einer einzigen Einstellung an den verschachtelten Beziehungen (Inline-Relationen) zwischen Eltern- und Kind-Datensätzen. Sie wies TYPO3 an, die Kind-Datensätze beim Lokalisieren gesondert zu behandeln. Der TYPO3-DataHandler – die zentrale Komponente, die alle Schreibvorgänge verarbeitet – interpretiert das so: Fehlt ein Kind-Datensatz in der Übersetzung, kopiere ihn. Diese Kopien tragen keine saubere Rückverknüpfung zum Original, weshalb das System sie bei der nächsten Prüfung erneut für “fehlend” hält und wieder kopiert – ein Aufschaukeln ohne Obergrenze.
Der erste Schritt war daher, diese Einstellung von den betroffenen Inline-Relationen zu entfernen. Damit endet die Vermehrung beim Speichern. Wichtig dabei: Das ist Vorbeugung, nicht Nachsorge. In der Verifikation haben wir reproduziert, dass dasselbe Speichern vorher Hunderte Kopien erzeugte und danach exakt null.
Die Vermeidung der Klone war nur die halbe Miete. Der eigentliche Designfehler war, sprachneutrale Objekte überhaupt als übersetzbar zu deklarieren. Also haben wir sie konsequent als das modelliert, was sie sind: sprachneutral.
TYPO3 kennt dafür eine eigene Sprach-Kennung – den Wert “alle Sprachen” (intern sys_language_uid = -1). Ein so markierter Datensatz gilt in jeder Sprachversion und wird nie übersetzt oder kopiert. Die Verkostungsnotizen tragen jetzt durchgängig diese Kennung; die übergeordneten Objekte sind nicht mehr übersetzbar.
Damit das auch dauerhaft hält, mussten wir alle Wege absichern, auf denen neue Datensätze entstehen – sowohl die Bearbeitung im Backend als auch die Erstellung über das Frontend. An jeder dieser Stellen wird die Sprach-Kennung “alle Sprachen” erzwungen. Zusätzlich haben wir die bereits falsch gespeicherten Datensätze – über 5.000 Stück – per Migrationsskript auf den korrekten Wert zurückgeführt.
Bleibt die Frage: Was ist mit den Feldern, die doch eine eigene französische Fassung brauchen, etwa der Titel einer Kategorie? Die naheliegende Antwort – “dann macht den ganzen Datensatz eben übersetzbar” – führt direkt zurück ins Klon-Problem.
Stattdessen nutzen wir ein Shadow-Field-Muster: Neben dem normalen Titelfeld erhält das Objekt eine zusätzliche Spalte allein für die französische Fassung. Der Datensatz bleibt sprachneutral, nur dieses eine Feld kennt eine Variante. Damit nicht Dutzende Ausgabestellen einzeln angepasst werden müssen, läuft die Titel-Ausgabe über einen zentralen Mechanismus, der im französischen Kontext automatisch das Französisch-Feld liefert und sonst den Standardtitel. So liessen sich rund 57 Stellen in den Templates mechanisch und ohne Regressionsrisiko umstellen.
Einige wenige Objekte – etwa Wettbewerbs- und Guide-Kategorien – brauchen tatsächlich eine echte Titelübersetzung. Für sie nutzen wir nun die “verbundene” Übersetzung, die TYPO3 von Haus aus mitbringt: Jede Kategorie bekommt genau eine fest verknüpfte Übersetzung pro Sprache. Anders als beim Kopiermechanismus erkennt das System diese Verknüpfung wieder und dupliziert sie bei späteren Änderungen nicht erneut.
Mit dem sauberen Standardverhalten wurde der selbst gebaute Workaround überflüssig. Wir konnten den nachträglichen “Klone-aufräumen”-Mechanismus und das zugehörige Wartungskommando ersatzlos entfernen. Toter Code, der zuvor jede Bereitstellung mitschleppte, ist verschwunden – das System wurde nicht nur korrekt, sondern auch schlanker.
Während der Vorbereitung auf TYPO3 v13 fiel eine vermeintlich überflüssige Einstellung weg, die Seiten ohne Übersetzung in der aktuellen Sprache aus den Menüs ausblendete. Die Folge: Plötzlich tauchten fremdsprachige Seiten in den deutschen, schweizerischen und französischen Menüs auf.
Die Korrektur stellt dieses “Gate” auf eine v13-taugliche Weise wieder her: Ein Menü zeigt nur noch Seiten, die in der aktuellen Sprache tatsächlich übersetzt sind. Der inhaltliche Fallback bleibt davon unberührt – für Deutschland und die Deutschschweiz greift weiterhin der Standardinhalt, wenn keine Übersetzung existiert, während die französische Version bewusst nur französische Inhalte zeigt. Sichtbarkeit der Seite und Fallback des Inhalts sind damit zwei getrennte, jeweils korrekt gesteuerte Mechanismen.
Der rote Faden dieses Projekts: Konsistente Sprach-Kennungen sind die Voraussetzung dafür, dass die SolR-Suche aktuelle Ergebnisse liefert. Solange die Verkostungsnotizen mit uneinheitlichen Sprach-IDs gespeichert waren, wurde der Index für einzelne Sprachen nicht zuverlässig aktualisiert – genau deshalb fehlten in der Weinsuche die frischen Treffer.
Nachdem die Datensätze einheitlich als “alle Sprachen” geführt und die betroffenen Indizes neu aufgebaut waren, lieferte die Suche in allen drei Sprachräumen wieder konsistente, aktuelle Resultate.
Nach der Sanierung dupliziert weder das Übersetzen noch das Speichern noch irgendeinen Datensatz. Die wenigen wirklich sprachabhängigen Felder erscheinen pro Sprache korrekt, die Suche ist über alle Sprachräume konsistent, und ein ganzer Block selbst gebauter Aufräum-Logik konnte ersatzlos entfallen.
Die wichtigste Lehre ist keine technische, sondern eine konzeptionelle: Mehrsprachigkeit beginnt nicht beim Übersetzen, sondern bei der Entscheidung, was übersetzt werden soll. Wer für jedes Objekt früh festlegt, ob es echt übersetzbar oder sprachneutral ist, und das im Datenmodell sauber abbildet, erspart sich Dubletten, explodierende Tabellen und schwer auffindbare Suchfehler. Nachträglich diese Wurzel zu sanieren ist möglich – es ist nur deutlich aufwendiger, als es von Beginn an richtig zu modellieren.
Planen Sie eine mehrsprachige Website oder kämpfen Sie mit einer bestehenden TYPO3-Installation, die sich beim Übersetzen seltsam verhält? Sprechen Sie uns an – wir schauen uns Ihre Sprach-Architektur gemeinsam an.
]]>Zwei Pflege-Aufgaben fraßen besonders viel Zeit.
Im Weingüter-Bereich konnte ein Winzer-Profil bisher mit genau einem Benutzerkonto verknüpft werden. Die Realität sieht anders aus: Hinter einem Weingut stehen oft mehrere Personen, die das Profil pflegen – und umgekehrt betreut eine Person manchmal mehrere Weingüter. Die starre Eins-zu-eins-Verknüpfung konnte das nicht abbilden, und das Zuordnen von Profil und Konto geschah weitgehend von Hand. Erschwerend kam eine Mehrdeutigkeit hinzu: Teilen sich mehrere Konten dieselbe Adresse, an wen geht dann das Profil?
Bei den Abo-Rechten gab es eine Wartezeit. Wer ein Abonnement abschloss und sich ein Konto anlegte, erhielt die zugehörigen Zugriffsrechte erst nach dem nächtlichen Datenabgleich – im Zweifel bis zu einen Tag später. Für jemanden, der gerade bezahlt hat und sofort loslegen möchte, ist das ein spürbarer Bruch im Erlebnis.
Aus der starren Eins-zu-eins-Verknüpfung haben wir eine echte n:m-Beziehung gemacht: Ein Weingut kann von mehreren Konten verwaltet werden, und ein Konto kann mehrere Weingüter betreuen. Für Nutzer mit nur einem Profil ändert sich nichts – sie landen wie gewohnt direkt im Bearbeitungsformular. Wer mehrere Weingüter betreut, bekommt einen kurzen Auswahlschritt vorgeschaltet (“Welches Weingut möchten Sie bearbeiten?”). Alle bestehenden Verknüpfungen – mehrere hundert – haben wir mit einer wiederholbaren Migration verlustfrei in das neue Modell überführt.
Das saubere Modell löst die alte Mehrdeutigkeit auf. Winzer-Profile werden jetzt automatisch den Abonnenten zugeordnet, die sich dieselbe Adresse teilen – eingebettet in die bestehende Logik für Rechte und Benutzergruppen. Teilen sich mehrere Konten eine Adresse, werden eben alle mit dem Profil verknüpft. Genau das war mit dem alten Einzelwert-Feld unmöglich.
Statt auf den nächtlichen Abgleich zu warten, fragen wir beim Login eine externe Abonnement-Schnittstelle ab. Existiert für die E-Mail-Adresse ein aktives Abonnement, werden die passenden Zugriffsrechte sofort gewährt. Vier Entscheidungen waren uns dabei wichtig:
Damit die Abo-Rechte über alle Wege gleich gepflegt werden, sorgt zusätzlich eine wiederkehrende Hintergrund-Aufgabe für Ordnung: Sie gleicht alle Konten mit den aktiven Abonnements ab, vergibt die zugehörige Zugriffsgruppe an alle Berechtigten – und entzieht sie denen, die sie nicht mehr haben dürfen. Entscheidend war, dass das Kriterium die vollständige Definition eines Abonnenten abbildet: So behalten bestehende Abonnenten ihre Gruppe (keine Regression), während die bisher übersehenen Konten sie endlich automatisch erhalten.
Manuelle Pflege ist selten ein Personalproblem – meistens ist sie ein Datenmodell-Problem. Wo ein Einzelwert die Wirklichkeit nicht abbilden kann, entsteht Handarbeit; wo eine Schnittstelle fehlt, entsteht Wartezeit. Eine saubere n:m-Modellierung und eine ausfallsichere API-Anbindung räumen beides aus dem Weg – und senken den Pflegeaufwand spürbar, ohne die Datenhoheit aus der Hand zu geben.
Stehen auch bei Ihnen wiederkehrende Zuordnungen im Backend oder Wartezeiten bei der Freischaltung im Weg? Sprechen Sie mit uns – wir schauen uns Ihr Datenmodell und Ihre Schnittstellen gemeinsam an.
]]>Verzeichnis- und Mitgliederseiten sind oft die wertvollsten, aber am schlechtesten auffindbaren Seiten einer Website: hunderte Detailprofile mit echten Daten – Namen, Adressen, Telefonnummern, Bildern – die für Suchmaschinen jedoch nur Fließtext sind. Genau hier setzen strukturierte Daten an. Auf der Weinplattform VINUM haben wir in einer Arbeitswoche mehrere Detailseiten mit schema.org-Markup ausgezeichnet: Winzer-Profile aus dem Weingüter-Kompass und Mitglieder des Wine Trade Clubs als LocalBusiness, Autorinnen und Autoren als Person. Das Besondere daran: Es war kein einziger Umbau am Datenmodell nötig.
Strukturierte Daten – maschinenlesbare Auszeichnungen im Format JSON-LD – sind die Eintrittskarte für Rich Results und für die lokale Suche. Eine Suchmaschine, die erkennt, dass es sich bei einem Eintrag um ein konkretes Unternehmen mit Adresse und Telefonnummer handelt, kann diesen Eintrag deutlich prominenter und in passenderen Kontexten ausspielen als eine reine Textseite.
Der typische Reflex lautet: “Dann brauchen wir erst einmal ein neues Datenmodell mit allen Feldern, die schema.org vorsieht.” Das ist teuer, langwierig und meistens unnötig. Unsere Ausgangslage war eine andere:
Die Aufgabe war damit weniger eine Frage des Datenmodells als eine Frage der sauberen Umsetzung: Wie erzeugt man aus vorhandenen Feldern ein gültiges, robustes und wartbares Markup?
Statt das Markup verstreut in den Templates zusammenzustückeln, kapselt jede Entität ihre Logik in einem eigenen kleinen Service mit genau einer Aufgabe: aus einem Objekt das fertige <script type="application/ld+json">-Tag erzeugen – oder einen leeren String, wenn keine sinnvollen Daten vorliegen.
final class VineyardProfileSchemaService
{
public function buildJsonLd(VineyardProfile $profile, string $absoluteUrl): string
{
// … Felder einsammeln, leere verwerfen, kodieren …
}
}
Der Controller ruft diesen Service auf der Detailseite auf und hängt das Ergebnis – falls nicht leer – in den Seitenkopf:
$jsonLd = $this->schemaService->buildJsonLd($profile, $absoluteUrl);
if ($jsonLd !== '') {
$pageRenderer->addHeaderData($jsonLd);
}
Dieses Muster haben wir vom bereits bestehenden Event-Markup übernommen und für Winzer-Profile, Wine-Trade-Club-Mitglieder und Autoren jeweils 1:1 repliziert. Der Vorteil: Jeder Service ist klein, testbar und folgt derselben Struktur. Neue Entitäten lassen sich in Stunden statt Tagen ergänzen.
Der Schlüssel zum Verzicht auf einen Datenmodell-Umbau liegt in einer einfachen Erkenntnis: Für ein LocalBusiness schreibt schema.org nur den Namen als Pflichtfeld vor. Alles andere – Telefon, Bild, Adresse, Öffnungszeiten – ist optional.
Wir bauen deshalb das Objekt aus genau den Feldern, die bereits vorhanden sind, und lassen leere Felder konsequent weg, statt Platzhalter oder neue Felder zu erzwingen. Technisch sorgt ein abschließender Filter dafür, dass keine leeren oder null-Werte im Ergebnis landen:
$data = array_filter([
'@context' => 'https://schema.org',
'@type' => 'LocalBusiness',
'name' => $profile->getVineyardName(), // Pflicht
'telephone' => $profile->getPhone(), // wird verworfen, wenn leer
'image' => $imageUrls,
]);
Fehlt der Name, liefert der Service einen leeren String – und es wird gar kein Markup ausgegeben. So entsteht nie ungültiges JSON-LD, egal wie vollständig ein einzelner Eintrag gepflegt ist.
Nicht jede Verzeichnisseite ist gleich. Wir haben pro Eintragsart den semantisch korrekten schema.org-Typ gewählt:
LocalBusiness. Da schema.org keinen eigenen Typ “Weingut” kennt, ergänzen wir bei den Winzern ein additionalType, das auf den passenden Wikidata-Eintrag verweist – so bleibt der Eintrag spezifisch, ohne den Standard zu verlassen.Person. Hier hinterlegen wir zusätzlich die Organisation, für die sie arbeiten, als verschachteltes Organization-Objekt.Als url dient jeweils die kanonische, absolut aufgebaute Adresse der Detailseite selbst – denn nur die indexierbare Einzelseite trägt SEO-Wert, nicht die Listenansicht.
Verzeichnisdaten werden oft von Redaktion oder den Mitgliedern selbst gepflegt. Solche Inhalte landen direkt im Seitenkopf – ein klassisches Einfallstor für XSS, wenn man unachtsam kodiert. Wir kodieren das JSON-LD mit JSON_UNESCAPED_UNICODE, behalten aber das Standard-Escaping der Schrägstriche bewusst bei. So wird ein im Text verstecktes </script> zu <\/script> und kann das umgebende Script-Tag nicht vorzeitig schließen. Umlaute und Akzente bleiben dabei trotzdem lesbar.
Mit dem minimal-gültigen Objekt ist der schnelle, günstige Hebel umgesetzt. Im nächsten Schritt stellt sich die Frage, welche zusätzlichen Felder den Aufwand lohnen. Gemeinsam mit dem Kunden haben wir hier priorisiert – nicht jedes denkbare Feld, sondern die mit dem größten Nutzen zuerst:
openingHoursSpecification (Wochentag, Öffnen, Schließen). Das ist der aufwändigste, aber auch wirkungsvollste Schritt, weil er die lokale Suche direkt bedient.Wichtig dabei: Jedes neue Feld bleibt optional und wird – wenn leer – weder auf der Seite noch im Markup ausgegeben. Das hält Profile aufgeräumt und das JSON-LD stets gültig.
Mehrere Hundert Detailseiten der Plattform liefern Suchmaschinen jetzt strukturierte, valide Daten – Unternehmen als LocalBusiness, Autoren als Person. Erreicht haben wir das ohne neue Datenbankfelder, ohne Migrationen und ohne Backend-Umbau, allein aus dem vorhandenen Bestand. Das wiederverwendbare Service-Muster macht jede weitere Eintragsart zu einer kleinen, klar umrissenen Erweiterung statt zu einem Projekt.
Strukturierte Daten sind einer der wenigen SEO-Hebel, die viel bewirken und wenig kosten – vorausgesetzt, man baut sie pragmatisch: minimal-gültige Objekte aus vorhandenen Feldern, leere Werte konsequent weglassen, sicher kodieren und die Logik in kleine, wiederverwendbare Services kapseln. Gerade Verzeichnis-, Mitglieder- und Profilseiten profitieren davon enorm, weil sie viele indexierbare Einzelseiten mit echten Daten besitzen.
Sie betreiben selbst ein Verzeichnis, ein Mitglieder- oder Branchenportal und möchten Ihre Detailseiten für Suchmaschinen besser auffindbar machen? Sprechen Sie mit uns – wir schauen uns an, welcher Markup-Hebel bei Ihnen am schnellsten wirkt.
]]>