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.

Maintainers

Package info

github.com/datashop-cc/contao-cookiebar-bridge

Type:contao-bundle

pkg:composer/datashop/contao-cookiebar-bridge

Transparency log

Statistics

Installs: 6

Dependents: 0

Suggesters: 0

Stars: 0

Open Issues: 0

1.0.1 2026-08-05 21:30 UTC

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:

  1. Serverseitige Zustimmungsabfragen in Twig-Templates und InsertTags (analog zu is_tag_accepted() bei numero2/contao-cookie-consent).
  2. 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.