Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Borlabs Cookie: Debug-Konsole deaktivieren (v2 & v3)

    · Weswegen-Redaktion
    DSGVO

    Wenn Sie die Entwicklertools Ihres Browsers öffnen und dort auf einer Live-Seite Meldungen von Borlabs Cookie sehen, ist der Debug-Modus des Plugins noch aktiv. Das gehört nicht in den Produktivbetrieb: Die Ausgaben verraten Details zu Ihrer Consent-Logik und verwirren jeden, der die Konsole öffnet. In wenigen Minuten schalten Sie den Debug-Modus in Borlabs Cookie v2 und v3 an der richtigen Stelle aus, beheben den häufigsten Grund, warum die Meldungen danach trotzdem weiterlaufen (Caching), und prüfen sauber nach, dass die Konsole still bleibt.

    Was die Debug-Konsole überhaupt ausgibt

    Der Debug-Modus von Borlabs Cookie ist keine eigene Oberfläche, sondern eine Reihe von console.log-Ausgaben im Frontend. Sie erscheinen im JavaScript-Konsolentab der Browser-Entwicklertools (F12 bzw. Strg+Umschalt+I, im Reiter „Konsole“). Typische Meldungen betreffen zum Beispiel:

    • welche Consent-Cookies gesetzt sind und welchen Wert sie haben,
    • welche Cookie-Gruppen der Besucher akzeptiert oder abgelehnt hat,
    • ob und wann ein Content-Blocker ein eingebettetes Element (YouTube, Google Maps, Analytics) freigegeben hat.

    Für die Einrichtung ist das Gold wert: Man sieht sofort, ob ein Skript blockiert bleibt, weil die passende Consent-Gruppe fehlt. Auf einer öffentlichen Website hat diese Ausgabe aber nichts zu suchen. Sie kostet zwar kaum Ladezeit, macht Ihre Consent-Konfiguration aber für jeden Neugierigen lesbar und lässt bei anderen Entwicklern den Eindruck entstehen, die Seite sei „im Bau“.

    Wichtig zur Abgrenzung: Rote Fehlermeldungen (Uncaught …) stammen in der Regel nicht vom Debug-Modus, sondern von echten JavaScript-Fehlern. Die verschwinden nicht, wenn Sie Debug ausschalten – die müssen Sie separat beheben.

    Die Bezeichnung und die Position der Option unterscheiden sich zwischen den beiden großen Versionslinien. Prüfen Sie zuerst unter Plugins → Installierte Plugins, welche Version bei Ihnen läuft.

    Version 3 wurde komplett neu gebaut und hat das Menü umsortiert. Der Weg führt grundsätzlich so:

    1. Im WordPress-Backend links Borlabs Cookie öffnen.
    2. In die Einstellungen wechseln.
    3. Die Option Debug Console suchen und deaktivieren. Sie ist nur für angemeldete Administratoren sichtbar und erzeugt die Konsolenausgaben im Frontend.
    4. Speichern.

    Zwei Dinge sind bei Version 3 hilfreich zu wissen: Seit dem Update 3.2 ist die Debug Console standardmäßig deaktiviert – bei Altinstallationen oder nachträglich eingeschalteten Projekten kann sie aber weiterhin aktiv sein (Stand: Juli 2026). Und weil Borlabs die Menü-Beschriftungen zuletzt mit Version 3.4 angepasst hat, kann die genaue Bezeichnung je nach Unterversion minimal abweichen. Versionsunabhängig und dauerhaft schalten Sie die Ausgabe per Filter in der functions.php Ihres Themes ab:

    add_filter('borlabsCookie/frontendResources/disableDebugConsole', '__return_true');

    In der 2er-Reihe finden Sie die Einstellung so:

    1. Borlabs Cookie → Einstellungen öffnen.
    2. Zur Option Debug bzw. Debug-Modus scrollen.
    3. Den Schalter deaktivieren bzw. das Häkchen entfernen.
    4. Unten mit Einstellungen speichern bestätigen.

    Borlabs pflegt seine offizielle Dokumentation inzwischen nur noch für die 3er-Reihe. Läuft bei Ihnen noch 2.x, ist ein Umstieg auf Version 3 ohnehin empfehlenswert (Stand: Juli 2026). Die Debug-Option finden Sie dort verlässlich über die Einstellungen, wenn Sie nach dem Stichwort „Debug“ suchen.

    Nach dem Speichern generiert Borlabs Cookie seine Frontend-Dateien in vielen Versionen neu. Genau an dieser Neugenerierung hakt es am häufigsten – meist, weil der Browser oder ein Cache noch die alte Datei mit den Debug-Ausgaben ausliefert.

    Der häufigste Fehler: Meldungen bleiben trotz Deaktivierung

    Sie haben den Schalter umgelegt, laden die Seite neu – und die Konsole redet munter weiter. In fast allen Fällen liegt das an Caching, nicht an einer falschen Einstellung. Borlabs Cookie liefert JavaScript aus, und dieses JavaScript kann an mehreren Stellen zwischengespeichert sein. Arbeiten Sie die Cache-Ebenen der Reihe nach ab:

    1. Browser-Cache: Laden Sie die Seite hart neu (Strg+F5 bzw. Umschalt+Neu-laden) oder testen Sie in einem privaten Fenster. Damit schließen Sie den simpelsten Fall zuerst aus.
    2. Caching-Plugin: Leeren Sie den Cache von WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache o. ä. komplett. Gerade minifiziertes/kombiniertes JavaScript hält die alte Debug-Version hartnäckig fest.
    3. Server- und Objekt-Cache: Bei Hosting mit Server-seitigem Cache (z. B. Nginx-FastCGI, Varnish, Redis/Memcached) oder bei Plesk/Managed-WordPress den entsprechenden Cache über das Hosting-Panel leeren.
    4. CDN: Nutzen Sie Cloudflare o. Ä., leeren Sie dort den Cache (bei Cloudflare „Purge Everything“), sonst wird die alte Datei weiter aus dem Edge-Netz ausgeliefert.
    5. Borlabs-eigene Dateien: Einen eigenen Button zum gezielten Leeren der generierten Frontend-Dateien bietet Borlabs Cookie nicht – diese Dateien werden beim Speichern der Einstellungen neu geschrieben. Speichern Sie die Einstellungen nach dem Umlegen des Schalters deshalb noch einmal bewusst, damit die JS-Datei ohne Debug-Ausgabe frisch erzeugt wird.

    Die Reihenfolge ist bewusst gewählt: von der günstigsten zur aufwändigsten Maßnahme. Meist ist nach Schritt 1 oder 2 Ruhe. Mehr zum systematischen Vorgehen finden Sie unter /wordpress-cache-leeren/.

    Prüfen, ob die Konsole wirklich still ist

    Kontrollieren Sie das Ergebnis sauber, sonst „reparieren“ Sie eventuell nur Ihren eigenen zwischengespeicherten Browserstand:

    1. Ein privates/Inkognito-Fenster öffnen – so umgehen Sie den lokalen Browser-Cache zuverlässig.
    2. Ihre Seite aufrufen und die Entwicklertools öffnen (F12), Reiter Konsole.
    3. Einmal neu laden und den Cookie-Dialog bedienen (annehmen/ablehnen), damit auch die Consent-Aktionen durchlaufen.

    Erscheinen jetzt keine Borlabs-Cookie-Meldungen mehr, ist der Debug-Modus im Produktivbetrieb sauber deaktiviert. Bleiben ausschließlich rote Fehler übrig, sind das eigenständige Probleme, die nichts mit dem Debug-Schalter zu tun haben.

    Ein pragmatischer Tipp fürs Arbeiten: Halten Sie den Debug-Modus in einer Staging-Umgebung aktiv und in der Live-Umgebung aus. So verlieren Sie das Diagnosewerkzeug nie, riskieren aber auch keine offene Konsole für Besucher. Wie Sie Consent von Grund auf sauber aufsetzen, lesen Sie unter /borlabs-cookie-einrichten/.

    FAQ

    Verbessert das Deaktivieren der Debug-Konsole meinen PageSpeed spürbar? Nein. Die Konsolenausgabe ist ein paar console.log-Aufrufe und hat auf Ladezeit oder Core Web Vitals praktisch keinen messbaren Effekt. Der eigentliche Grund zum Abschalten ist Sauberkeit und Diskretion, nicht Performance.

    Ist der aktive Debug-Modus ein DSGVO-Problem? Nicht per se. Die Konsole zeigt technische Consent-Zustände, keine personenbezogenen Daten Dritter. Trotzdem gehört sie im Live-Betrieb aus, weil sie interne Konfiguration offenlegt und unprofessionell wirkt.

    Ich sehe gar keine Debug-Option – wo ist sie? Meist ist entweder die Version eine andere als gedacht (v2 vs. v3, siehe oben) oder die Option sitzt in einem Reiter, den Sie noch nicht geöffnet haben. Prüfen Sie zuerst die installierte Version unter Plugins und durchsuchen Sie dann die Einstellungen nach dem Stichwort „Debug“.

    Brauchen Sie Unterstützung bei DSGVO & Cookie-Consent (Borlabs & Co.)? Ypsilon.dev ist Ihre Webagentur aus Regensburg – jetzt kostenlose Erstberatung anfragen.