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 (seit Mai 2024 TDDDG) vor derselben Aufgabe: Vor dem Laden eines Drittanbieter-Skripts muss eine aktive, informierte Einwilligung des Nutzers vorliegen. dp_cookieconsent gehört zu den in der deutschen TYPO3-Community am weitesten verbreiteten Extensions, die genau diese Aufgabe übernehmen. 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 laden, sobald ein Nutzer die Seite öffnet, die meisten davon Cookies setzen und damit eine Abmahnung wegen eines Verstoßes gegen § 25 TDDDG riskieren. Die Extension gruppiert die Dienste nach Kategorie und legt den HubSpot-Code erst nach Marketing-Consent nach; Google Fonts lassen sich zusätzlich self-hosted einbinden, 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 in einem Cookie, das sich über ein eigenes Layout auf eine gemeinsame Hauptdomain setzen lässt, sodass ein Nutzer nicht an jeder Fakultäts-Site dieser Domain 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 pflegt die Kategorisierung als Datensätze im Backend und gibt sie per Inhaltselement als Cookie-Liste in der Datenschutzerklärung aus, 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 Datensätze im Backend 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 eigenes serverseitiges Logging bauen, 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 bis v14 verfügbar; die aktuelle Version 14.0.6 ist als stabil freigegeben. Beim Sprung von v11 auf v12 bleiben die Namen der TypoScript-Konstanten gleich; zu prüfen ist aber der Standard-Typ des Banners, den die Reihe 12.x von „info“ auf „opt-in“ umgestellt hat. Für Nutzer älterer Versionen der Extension ist zu beachten, dass die Service-Definitionen weiterhin als Datensätze im Backend gepflegt werden; seit Version 14 bringt die Extension zusätzlich ein Site Set mit, dessen Einstellungen sich als YAML in Git-Workflows einbetten lassen.

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.