WBCE CMS – Way Better Content Editing.
You are not logged in.
Hallo liebe WBCE-Community,
ich arbeite aktuell an einem neuen Modul und wollte mal in die Runde fragen, wie generell das Interesse an so einer Lösung aussieht.
Da Datenschutz und rechtssichere Cookie-Banner ein Dauer-Thema sind, wollte ich eine Lösung für mich bauen, die komplett ohne lästige externe Skripte, Drittanbieter-Abos oder iFrames auskommt. Das Ziel: Ein extrem performantes, vollständig natives Cookie-Banner direkt für unser WBCE CMS.
? Hier sind die bisherigen Kern-Features:
DSGVO-Konform: Die Nutzer können granular zwischen Notwendigen, Analytischen und Marketing-Cookies wählen.
100% Nativ: Keine Abhängigkeiten nach außen. Alle Einstellungen (Texte, Farben, Optionen) werden sauber im Backend verwaltet und in der WBCE-Datenbank gespeichert.
Flexibles Design: Über das Admin-Tool kann man zwischen verschiedenen Layout-Positionen (Banner, zentriertes Modal, Top-Leiste etc.) wählen.
Automatische Farben: Das Banner kann sich automatisch die CSS-Variablen des aktiven Themes ziehen, oder man definiert im Admin-Tool ganz eigene Farben.
Bequeme Icon-Verwaltung: Icons können einfach über den Medien-Ordner hinterlegt und direkt im Modul ausgewählt werden.
Einbindung:
Geplant ist, dass die Einbindung später super simpel über einen PHP-Include im Template oder (noch einfacher) über ein Droplet [[CookieConsent]] im Editor funktioniert.
Ich habe euch mal ein paar Screenshots aus dem aktuellen Entwicklungsstand (Backend und Frontend-Ansicht) an diesen Beitrag angehängt.
Das Modul läuft in meinen ersten Tests schon sehr rund, aber bevor ich es finalisiere und für alle freigebe, wollte ich mal euer Feedback einholen:
Was haltet ihr von der Idee? Nutzt ihr lieber externe Dienste oder hättet ihr gerne so eine native Lösung im WBCE? Fehlt euch spontan noch ein wichtiges Feature?
Ich freue mich auf eure Meinungen!
Viele Grüße,
Thorsten (Thodde26)
Screenshots:




Last edited by thodde26 (26.05.2026 10:49:59)
Thorsten aka Thodde26
Offline
Konkurrenz belebt das Geschäft ;-)
https://forum.wbce.org/viewtopic.php?id=5768
Spaß beiseite, sieht gut aus. Wie wird dann das tatsächliche Blocken von Scripten realisiert werden?
Nicht ärgern. Nur wundern.
Online
thodde26
Hallo Florian!
Danke dir für das Lob, das geht natürlich runter wie Öl!
Zu deiner Frage, weil das ja der wichtigste Punkt bei der ganzen Geschichte ist: Das tatsächliche Blockieren wird direkt im Frontend über einen klassischen JavaScript-Wrapper (Type-Wechsel) gelöst.
Externe Skripte (wie Google Analytics, Matomo etc.) werden im Template oder im Code-Block einfach mit type="text/plain" und einem entsprechenden Daten-Attribut (z.B. data-category="analytics") eingebunden. Dadurch ignoriert der Browser das Skript beim ersten Laden komplett.
Sobald der User seine Einwilligung erteilt (oder wenn die Cookies beim Seitenaufruf bereits als akzeptiert ausgelesen werden), sucht das Modul-JS nach diesen blockierten Skripten, prüft die erlaubte Kategorie und stellt den Typ dynamisch auf text/javascript um, wodurch sie erst ausgeführt werden.
Für serverseitige Geschichten oder PHP-Abfragen kann man alternativ natürlich auch ganz klassisch das Vorhandensein des entsprechenden Cookies abfragen, bevor ein bestimmter Block ausgegeben wird.
Viele Grüße,
Thorsten aka Thodde26
Thorsten aka Thodde26
Offline
Ich meinte damit, wie redaktionsseitig die Scripte eingebunden werden müssen, damit das Blocking greift. Also wie sichergestellt wird, dass text/plain und category=... hinterlegt sind.
Bei dem oben verlinkten Klaro-Modul muss man z.B. statt des Original-Codes für eine Google-Map einen parametrisierten Droplet-Aufruf einfügen.
Nicht ärgern. Nur wundern.
Online
Ah, jetzt verstehe ich genau, worauf du hinauswillst! Absolut berechtigter Punkt.
Aktuell ist mein Ansatz da noch sehr pragmatisch und richtet sich vor allem an den Admin/Webmaster: Globale Skripte wie Matomo oder Analytics bindet man ja meist ohnehin zentral in der index.php des Templates oder in einem unsichtbaren Code-Block ein. Dort passt man den Schnipsel dann einmalig per Hand an.
Für den reinen Redakteur, der z.B. mitten auf einer Unterseite ein YouTube-Video oder eine Google Map einbauen möchte, ist das händische Anpassen im WYSIWYG-Quellcode natürlich viel zu fehleranfällig. Den Ansatz von Klaro mit den parametrisierten Droplets finde ich dafür extrem elegant.
Mein Plan ist es, das Modul im Kern genau so schlank und unabhängig zu belassen, aber optional ein kleines Set an "Helper-Droplets" (z.B. [[T26_Youtube?id=123]] oder für Maps) beizulegen. Diese Droplets werfen dann automatisch das fertige, blockierte text/plain-Konstrukt mitsamt Platzhalter-Bild aus. So bleibt es für den Redakteur idiotensicher.
Danke nochmal für den Input, genau durch solche Fragen wird das Konzept am Ende richtig rund!
P.S. sorry für die später rückmeldung erst mal garten unsicher gemacht
Viele Grüße,
Thorsten



Last edited by thodde26 (27.05.2026 06:54:12)
Thorsten aka Thodde26
Offline
florian