dp_cookieconsent für TYPO3: DSGVO-konformes Cookie-Management

Warum ein Cookie-Banner allein keine DSGVO-Konformität herstellt

Jede TYPO3-Installation, die Google Analytics, YouTube-Videos, Social-Media-Plugins oder externe Schriftarten einbindet, steht seit Inkrafttreten der DSGVO und des TTDSG vor derselben Aufgabe: Vor dem Laden eines Drittanbieter-Skripts muss eine aktive, informierte Einwilligung des Nutzers vorliegen. dp_cookieconsent ist die in der deutschen TYPO3-Community am weitesten verbreitete Extension, die genau diese Aufgabe übernimmt. Sie zielt auf Unternehmen, die ihre Website ohne externes Consent-Management-Tool DSGVO-konform betreiben wollen, und richtet sich damit an Mittelständler, Behörden und Bildungseinrichtungen, die keine laufenden Kosten für kommerzielle CMPs tragen wollen.

Typische Einsatzszenarien

Ein Industrieunternehmen mit Produktkatalog und 45 Landingpages nutzt Google Analytics, einen YouTube-Erklärfilm, HubSpot-Formulare und Google Fonts. Ohne dp_cookieconsent würden alle diese Dienste Cookies setzen, sobald ein Nutzer die Seite öffnet, und damit eine Abmahnung nach TTDSG riskieren. Die Extension gruppiert die Dienste nach Kategorie, legt den HubSpot-Code erst nach Marketing-Consent nach und lädt Google Fonts alternativ self-hosted, wodurch die Consent-Anfrage dort komplett entfällt.

Ein zweites typisches Bild liefert eine Universität mit einem Hauptportal und mehreren dezentralen Fakultäts-Websites. Jede Fakultät pflegt eigene Inhalte und bindet eigene Dienste ein, manchmal ein eingebettetes Kartenmaterial von OpenStreetMap, manchmal ein YouTube-Video, manchmal ein Piwik-Tracking. dp_cookieconsent zentralisiert die Consent-Verwaltung in der Haupt-Installation, liefert den Banner über Fluid-Partials an alle Sub-Sites und speichert die Einwilligung domainübergreifend, sodass ein Nutzer nicht an jeder Fakultäts-Site erneut zustimmen muss.

Ein dritter Fall sind kommunale Verwaltungen mit Online-Formularen und Kartenanwendungen. Hier kommt erschwerend hinzu, dass die Datenschutzbeauftragten des Landes regelmäßig Audits durchführen und eine vollständige Dokumentation der eingesetzten Dienste verlangen. dp_cookieconsent liefert die Kategorisierung und den Privacy-Text direkt aus TypoScript, was die Pflege durch die Redaktion ohne Entwickler-Eingriff ermöglicht.

Technische Architektur: Script-Blocking auf Template-Ebene

dp_cookieconsent arbeitet nach dem Prinzip “type-attribute swapping”: Alle Drittanbieter-Skripte im Quelltext werden nicht mit type=“text/javascript” ausgeliefert, sondern mit einem neutralen Typ wie type=“text/plain” und einem zusätzlichen data-cookieconsent-Attribut. Der Browser ignoriert solche Tags und führt sie nicht aus. Erst wenn der Nutzer im Banner zustimmt, ersetzt ein kleiner JavaScript-Runner die Typ-Attribute und triggert die verzögerte Ausführung. Der gleiche Mechanismus greift für iframes, die bis zur Einwilligung als Platzhalter dargestellt werden.

Konfiguriert wird die Extension vollständig über TypoScript-Konstanten und Setup, ergänzt durch eine YAML-Datei für die Service-Definitionen. Jeder Service ist dort mit Name, Beschreibung, Kategorie, Cookie-Namen und Cookie-Laufzeit hinterlegt, was die spätere Dokumentation für den Datenschutzbeauftragten erheblich vereinfacht. Fluid-Partials definieren das Aussehen des Banners und der Einstellungs-Modal, wodurch sich das Design ohne Extension-Änderung an die Corporate Identity anpassen lässt.

Häufige Probleme und Lösungen

Das erste und häufigste Problem: Trotz aktiviertem Banner laden Drittanbieter-Skripte trotzdem, weil sie über Include-Pfade eingebunden sind, die nicht durch TypoScript laufen. Typisch sind statische HTML-Blöcke, Fluid-Inhaltselemente mit hartcodierten Script-Tags oder Footer-Includes aus älteren Templates. Eine saubere Lösung erfordert einen vollständigen Site-Crawl mit Browser-Devtools oder einem automatisierten Tool, das alle ausgehenden Requests protokolliert und vergleicht, welche davon vor Consent ausgelöst werden.

Das zweite Problem ist die Consent-Speicherung. dp_cookieconsent speichert die Einwilligung in einem lokalen Cookie, was bei Nutzern mit strenger Browser-Konfiguration oder Inkognito-Modus zu wiederholten Banner-Einblendungen führt. Wer Consent-Quoten messen will, muss zusätzlich ein serverseitiges Logging aktivieren, das die Einwilligungen samt Zeitstempel und IP-Hash in einer Datenbanktabelle ablegt und damit eine belastbare Dokumentation für Audits liefert.

Das dritte Thema betrifft Performance. Der Banner lädt ein JavaScript-Bundle, das je nach Umfang der konfigurierten Services merklich groß werden kann und die First Contentful Paint verzögert. Gosign optimiert die Auslieferung über deferred Loading, reduziert unnötige Fluid-Partials und setzt wo möglich auf eine Kombination aus cookieless Analytics und self-hosted Assets, sodass der Banner nur noch für wenige Dienste notwendig ist.

Ein viertes Problem tritt bei Consent-Änderungen auf: Ein Nutzer gibt seine Einwilligung, nutzt die Seite, ändert später seine Meinung und widerruft die Zustimmung. dp_cookieconsent setzt das Cookie-Flag zurück, aber bereits geladene Skripte laufen im Hintergrund weiter, bis der Nutzer die Seite neu lädt. Eine saubere Lösung erfordert einen Reload-Trigger oder das gezielte Entfernen bereits gesetzter Cookies beim Widerruf, sodass der Datenschutz-Widerruf tatsächlich wirksam wird und nicht nur formal dokumentiert ist.

Migration und Versions-Kompatibilität

dp_cookieconsent ist für TYPO3 v11, v12 und v13 verfügbar, wobei die v13-Kompatibilität regelmäßig aktualisiert wird und aktuell als produktionsreif gilt. Der Sprung von v11 auf v12 erfordert in der Regel ein Re-Mapping der TypoScript-Konstanten, da einige Konstantennamen umbenannt wurden. Für Nutzer älterer Versionen der Extension ist zu beachten, dass die Service-Definitionen früher ausschließlich über Backend-Formulare gepflegt wurden, während neuere Versionen YAML-basiert arbeiten und damit deutlich einfacher in Git-Workflows einbettbar sind.

Wer von einem anderen Consent-Tool wie Cookiebot, OneTrust oder Usercentrics migriert, spart damit laufende Lizenzkosten, muss aber die Service-Konfiguration neu aufbauen. Gosign führt solche Migrationen inklusive Consent-Rate-Analyse durch, sodass der Umstieg messbar keine Einbußen bei der Zustimmungsquote verursacht.

Zusätzlich lohnt sich ein strategischer Blick auf die Frage, ob ein Cookie-Banner überhaupt noch die richtige Antwort ist. Wer konsequent self-hosted Fonts einsetzt, auf cookielose Analytics wie Matomo mit deaktivierten Cookies oder Plausible wechselt und Video-Embeds durch statische Vorschau-Bilder mit Klick-Laden ersetzt, kann den Banner für viele Seiten komplett entfernen. Der rechtliche Vorteil ist erheblich, weil jede vermiedene Einwilligung auch ein vermiedenes Abmahn-Risiko bedeutet und gleichzeitig die Conversion-Rate nicht durch den Banner-Dialog ausgebremst wird.