datashop / contao-cookiebar-bridge
Erweitert oveleon/contao-cookiebar um serverseitige Zustimmungsabfragen (Twig-Funktionen & InsertTags, analog numero2/contao-cookie-consent) sowie eine generische Sichtbarkeits-Option pro Cookie-Auswahl für Content-Elemente und Module.
Package info
github.com/datashop-cc/contao-cookiebar-bridge
Type:contao-bundle
pkg:composer/datashop/contao-cookiebar-bridge
Requires
- php: ^8.2
- contao/core-bundle: ^5.3
- oveleon/contao-cookiebar: ^2.0
- symfony/asset: ^6.4 || ^7.0
- symfony/config: ^6.4 || ^7.0
- symfony/dependency-injection: ^6.4 || ^7.0
- symfony/http-foundation: ^6.4 || ^7.0
- symfony/http-kernel: ^6.4 || ^7.0
Requires (Dev)
- contao/manager-plugin: ^2.3.1
Conflicts
- contao/core: *
This package is auto-updated.
Last update: 2026-08-05 21:31:23 UTC
README
Ergänzt oveleon/contao-cookiebar um zwei Dinge, die es dort nicht gibt:
- Serverseitige Zustimmungsabfragen in Twig-Templates und InsertTags (analog zu
is_tag_accepted()bei numero2/contao-cookie-consent). - Eine generische Sichtbarkeits-Option für beliebige Content-Elemente und Frontend-Module: "nur anzeigen, wenn Cookie X akzeptiert/nicht akzeptiert wurde".
Warum das nicht trivial ist
Die Cookiebar speichert den Zustimmungsstatus ausschließlich im localStorage des Browsers - serverseitig (PHP/Twig) ist davon nichts bekannt. Diese Bridge spiegelt den Zustand deshalb per JavaScript in einen echten HTTP-Cookie (ccb_bridge_consent), den PHP lesen kann.
Das hat einen Preis: Seiten, die den Zustand tatsächlich abfragen, sind personalisiert und dürfen nicht per Full-Page-Cache/Reverse-Proxy geteilt werden. Sobald in einem Request eine Zustimmungsabfrage ausgewertet wird, setzt der ResponseCacheGuardListener automatisch Cache-Control: private, no-store. Seiten ohne solche Abfragen bleiben normal cachebar.
Installation
composer require datashop/contao-cookiebar-bridge
Danach: Contao Manager "Datenbank aktualisieren" ausführen (neue Felder in tl_content/tl_module) und bin/console assets:install (bzw. Contao Manager macht das automatisch).
public/cookiebar-bridge.js und public/cookiebar-bridge.css werden automatisch auf jeder Frontend-Seite eingebunden (per AssetInjectionListener) - kein manueller Schritt im Seitenlayout nötig. Das wäre über den Datei-Picker im Layout ohnehin nicht möglich, da Assets aus public/-Ordnern von Composer-Paketen außerhalb von Contaos Dateibaum (tl_files) liegen.
1. Twig-Funktionen
{% if cookiebar_accepted(3) %}
{{ include('content_element/youtube.html.twig') }}
{% else %}
<p>Bitte YouTube-Cookies akzeptieren.</p>
{% endif %}
{% if cookiebar_not_accepted(3) %}
<p>Nur sichtbar, solange NICHT akzeptiert.</p>
{% endif %}
3 ist dabei die ID des tl_cookie-Datensatzes (nicht der Cookie-Gruppe).
2. InsertTags
Nutzbar im HTML-Editor oder in mediumtext-Feldern mit Contaos eingebauter Wenn-Dann-Logik:
{if {{cookiebar_accepted::3}}=='1'}
YouTube ist freigegeben.
{endif}
Es gibt außerdem {{cookiebar_not_accepted::3}} als Kurzform.
3. Sichtbarkeits-Option für Content-Elemente & Module
Jedes Content-Element und jedes Frontend-Modul bekommt im Bereich "Sichtbarkeit" (analog zum bestehenden "Zugriff geschützt") eine neue Checkbox "Anzeigen nach Cookie-Zustimmung". Ist sie aktiviert, erscheinen direkt darunter:
- Cookies - Mehrfachauswahl, "ODER"-Verknüpfung (Zustimmung zu einem der ausgewählten Cookies genügt)
- Bedingung - akzeptiert / nicht akzeptiert
- Platzhaltertext - optional, wird angezeigt solange die Bedingung nicht erfüllt ist
Der Platzhaltertext läuft durch Contaos InsertTag-Parser - {{cookiebar::show::Datenschutz}} (Link zum erneuten Öffnen der Cookiebar) funktioniert also direkt darin. Er wird in einen <div class="ccb-bridge-fallback"> gehüllt, dafür liefert public/cookiebar-bridge.css eine minimale Basis-Optik (heller roter Hintergrund, rote Schrift) - eigenes CSS überschreibt das problemlos.
Der Hook (getContentElement/getFrontendModule) greift auf den fertig gerenderten HTML-String, unabhängig davon ob das Element mit Twig oder einem klassischen .html5-Template gerendert wurde.
Sicherheitshinweis
Der ccb_bridge_consent-Cookie ist eine reine Momentaufnahme des localStorage. Wie jeder client-gesetzte Consent-Wert (auch bei numero2 und der Cookiebar selbst) kann er theoretisch manipuliert werden. Für echte Zugriffskontrolle (z.B. bezahlte Inhalte) ist das nicht geeignet - für die übliche Aufgabe "Drittinhalt nur nach Einwilligung laden" ist dieses Vertrauensmodell branchenüblich.
Architekturentscheidungen
- Der Sync-Cookie wird bei jedem
cookiebar_init/cookiebar_save-Event aktualisiert, damit er bei der nächsten Navigation immer aktuell ist. - Nach jeder in der Cookiebar tatsächlich gespeicherten Auswahländerung lädt die Seite automatisch neu, damit die serverseitig geprüften Inhalte sofort den neuen Stand zeigen. Ein sessionStorage-Guard verhindert Reload-Schleifen.